현재 투표 상황
XRP 레저 검증인(validator)들이 BatchV1_1 승인에 가까워지고 있지만, 9월 8일 기준 실시간 투표 데이터는 이 어멘드먼트(amendment, 프로토콜 개정안)가 2주간의 활성화 기간을 시작하는 데 필요한 임계치에 여전히 못 미치고 있음을 보여줍니다.
- BatchV1_1은 현재 XRPL 메인넷에서 35개 검증인 중 24표를 확보해, **68.57%**의 지지율을 기록 중입니다.
- 활성화에는 14일 연속 80% 초과 지지가 필요하며, 아직 카운트다운은 시작되지 않았습니다.
- 배치 트랜잭션은 활성화 이후 최대 8개의 작업을 담을 수 있고, 4가지 실행 모드를 지원합니다.
- XRPL 버전 3.3.0은 개발자들이 취약점 때문에 기존 배치 코드를 비활성화한 뒤 BatchV1_1을 도입했습니다.
- 이전 결함은 무단 지급을 가능하게 할 수 있었지만, 취약한 어멘드먼트는 XRPL 메인넷에서 한 번도 활성화된 적이 없습니다.
XRP스캔(XRPScan)에 따르면 BatchV1_1은 기본 고유노드목록(Unique Node List, UNL) 상 35개 검증인 중 24개의 지지를 받아 68.57%를 기록했습니다. 현재 검증인 수 기준으로 80%를 넘으려면 최소 29표의 찬성이 필요합니다.
‘9월 활성화설’은 아직 근거가 부족하다
이 어멘드먼트는 계정들이 최대 8개의 트랜잭션을 하나의 조율된 작업으로 묶을 수 있게 해줍니다. 다만 9월 중 활성화될 것이라는 일부 보도는, 필요한 과반(80%)이 아직 달성되지 않았기 때문에 여전히 추측성으로 남아 있습니다.
9월 활성화는 지지율이 먼저 80%를 넘고, 그 이후 14일 연속으로 그 수준을 유지해야만 가능합니다.
XRPL 어멘드먼트 활성화 규칙: 왜 이렇게 까다로운가
XRPL 어멘드먼트는 신뢰받는 검증인의 80% 이상 지지를 연속 2주간 유지해야만 활성화됩니다. 그 기간 중 지지율이 그 수준 아래로 떨어지면, 타이머는 리셋됩니다.
이는 상당히 보수적인 거버넌스 설계입니다. 단순 과반(50%)이 아니라 80%라는 높은 임계치를 요구하고, 그마저도 일시적 달성이 아니라 연속 2주간의 지속을 요구한다는 것은, 프로토콜 변경이 광범위하고 안정적인 검증인 합의 없이는 이뤄지지 않도록 설계됐다는 뜻입니다. 이는 소수의 검증인이 일시적으로 담합하거나, 여론이 잠깐 쏠렸다가 되돌아가는 상황에서 프로토콜이 불안정하게 변경되는 것을 방지하는 안전장치로 기능합니다.
BatchV1_1은 따라서 현재 35개 검증인 구성 기준으로 최소 5표의 추가 찬성이 필요합니다. 참여 검증인 집합 자체가 바뀌면 정확히 필요한 표수도 달라질 수 있습니다.
이 어멘드먼트에는 확정된 활성화 날짜가 없습니다. 설령 지금 당장 임계치를 넘더라도, 연속 2주간의 유지 기간이 끝나기 전까지는 활성화될 수 없습니다.
검증인 투표는 또한 바뀔 수 있습니다. 테스트 과정에서 호환성, 보안, 운영상의 우려가 발견되면 운영자들이 지지를 철회할 수 있습니다.
BatchV1_1이 실제로 무엇을 가능하게 하는가
XRPL 공식 문서에 따르면 배치 트랜잭션은 최대 8개의 내부 트랜잭션을 담을 수 있습니다. 이 작업들은 순서(sequencing), 수수료, 인가(authorization)를 관리하는 외부 트랜잭션 안에 패키징됩니다.
4가지 실행 모드가 제공될 예정입니다.
- 전부 아니면 전무(All or nothing): 모든 내부 트랜잭션이 성공해야 함
- 하나만(Only one): 첫 번째로 성공한 작업만 적용
- 실패까지(Until failure): 하나가 실패할 때까지 트랜잭션을 순차 처리
- 독립적(Independent): 다른 결과와 무관하게 포함된 모든 트랜잭션을 각각 시도
이 네 가지 모드의 조합은 상당히 세밀한 원자성(atomicity) 제어를 가능하게 합니다. 전통적인 데이터베이스 트랜잭션에서 익숙한 “전부 성공 아니면 전부 롤백”이라는 개념(All or nothing)뿐 아니라, 여러 대안 중 하나만 성공하면 되는 조건부 실행(Only one), 순차적 파이프라인 처리(Until failure), 완전히 독립적인 병렬 시도(Independent)까지 지원한다는 점에서, 스마트 컨트랙트가 아닌 네이티브 레저 레벨에서 복잡한 트랜잭션 로직을 표현할 수 있게 해줍니다.
잠재적 활용 사례로는 원자적 토큰 스왑(atomic token swap), 오퍼가 뒤따르는 NFT 발행, 묶음 플랫폼 수수료, 여러 계정이 관여하는 조율된 작업 등이 있습니다. 다중 계정 배치는 참여하는 모든 계정이 전체 묶음을 인가해야 합니다.
이 기능은 애플리케이션이 서로 의존적인 작업들을 조율하는 데 필요했던 외부 인프라를 줄여줄 수 있습니다. 커밋된 각 내부 트랜잭션은 별도의 메타데이터와 상위 배치에 대한 참조를 유지합니다.
버전 3.3.0이 출시됐을 당시 크립토뉴스(crypto.news)가 보도했듯, 코드 출시 자체가 기능 활성화를 의미하지는 않았습니다. 검증인 승인이 여전히 필요했습니다.
왜 재작성판인가 — 취약했던 원래 배치 코드
XRPL 버전 3.3.0은 8월 6일, 기존 배치 어멘드먼트를 대체하는 BatchV1_1을 도입했습니다. 개발자들은 연구자들이 치명적인 인가 결함을 발견한 뒤인 2월, 앞선 버전을 비활성화한 바 있습니다.
**프라나먀 케슈카마트(Pranamya Keshkamat)**와 칸티나 AI(Cantina AI)의 아펙스(Apex) 보안 툴이 배치 서명자를 검증하는 데 쓰이는 로직에서 오류를 발견했습니다. 이 결함은 공격자가 일부 참여자에 대한 검증을 건너뛰고, 피해자 계정으로부터 무단 트랜잭션을 제출할 수 있게 했을 가능성이 있었습니다.
이 취약점의 성격을 조금 더 짚어보면, 다중 서명이 필요한 배치 트랜잭션에서 일부 서명자에 대한 검증 로직에 결함이 있었다는 것은, 원칙적으로 일부 참여자의 동의 없이도 배치 전체가 유효한 것으로 처리될 수 있는 위험을 의미합니다. 다중 계정이 관여하는 트랜잭션 시스템에서 이런 유형의 결함은 특히 심각한데, 서명 검증이 시스템의 신뢰 기반 자체이기 때문입니다.
XRPL 랩스(XRPL Labs)는 취약한 어멘드먼트가 메인넷에서 활성화된 적이 없으며, 어떤 사용자 자금도 위험에 노출되지 않았다고 밝혔습니다. 검증인들은 이에 반대 투표하도록 권고받았고, 리플드(rippled) 버전 3.1.1은 원래 배치와 그 관련 수정본을 **지원 중단(unsupported)**으로 표시했습니다.
수정된 버전은 조기 종료(early-exit) 오류를 제거하고, 인가 안전장치를 추가했으며, 각 서명자를 검증하는 방식을 더 좁혔습니다. 이 대체판은 출시 전 독립적인 감사를 거쳤습니다.
이는 XRPL이 취약점을 발견한 이후 취한 대응 절차를 보여줍니다. 문제가 있는 코드를 메인넷 활성화 전에 차단하고(검증인 반대 투표 권고), 근본 원인을 수정한 뒤(조기 종료 오류 제거, 검증 로직 강화), 재출시 전 독립 감사를 거치는 표준적인 보안 사고 대응 절차를 밟은 셈입니다.
활성화는 전적으로 검증인에게 달려 있다
노드 운영자들은 BatchV1_1을 지지하는 투표를 하기 전에, 이를 지원하는 소프트웨어를 먼저 실행해야 합니다. XRPL은 또한 클리오(Clio) 운영자들에게, 어멘드먼트가 활성화될 경우 새로운 트랜잭션·레저 형식을 처리할 수 있도록 API 인프라를 버전 2.8.0으로 업그레이드할 것을 경고했습니다.
다음 확인해야 할 이정표는 80% 검증인 임계치입니다. 그 지점에 도달해야만 비로소 레저가 2주간의 과반 유지 기간의 시작을 기록합니다.
9월 말 활성화는 수학적으로는 여전히 가능하지만, 예정된 것은 아닙니다. 정확한 시점은 추가 검증인 투표와, 그 이후 중단 없이 유지되는 지지율에 달려 있습니다.
BatchV1_1 투표에 특별히 귀속될 수 있는 검증된 XRP 가격 움직임은 확인되지 않았습니다. 이 어멘드먼트는 XRP의 공급이나 발행 규칙이 아니라 트랜잭션 기능성을 변경하는 것이기 때문입니다.
정리
- 현재 지지율: 35개 검증인 중 24표, 68.57% — 80% 임계치까지 최소 5표 추가 필요
- 활성화 조건: 80% 초과 지지가 연속 14일간 유지돼야 하며, 중간에 하락하면 타이머 리셋
- 핵심 기능: 최대 8개 내부 트랜잭션을 4가지 실행 모드(전부/하나/실패까지/독립)로 묶어 처리하는 배치 시스템
- 배경: 2월 발견된 서명 검증 결함으로 원래 버전 비활성화, 8월 6일 감사를 거친 재작성판(BatchV1_1) 도입 — 메인넷에서 취약 버전이 실제 활성화된 적은 없음
- 9월 활성화 가능성: 수학적으로는 가능하나 예정되지 않음, 추가 투표와 지지율 유지 여부에 전적으로 좌우
- 가격 영향: 공급·발행 규칙이 아닌 트랜잭션 기능 변경이라, 이 투표 자체와 직접 연관된 검증된 가격 움직임은 없음
이 사안은 탈중앙화 네트워크에서 프로토콜 변경이 왜 그렇게 신중하게 설계돼 있는지를 보여주는 사례이기도 합니다. 유용한 신기능(배치 트랜잭션)이라도, 이전 버전에서 심각한 보안 결함이 발견됐던 이력이 있는 만큼, 검증인들은 80%라는 높은 합의 기준을 넘기 전까지 신중하게 접근하고 있습니다.
이 글은 투자 조언이 아닙니다.