XRP 레저 3.3.0 배포, 활성화 카운트다운 0건

XRP레저(XRP Ledger·XRPL) 서버 소프트웨어 xrpld 3.3.0이 배포됐지만, 새 기능이 메인넷에서 작동하려면 검증자 투표 절차를 더 거쳐야 한다.

XRP레저 공식 개발 문서는 8월 6일 xrpld 3.3.0을 공개하고 노드 운영자에게 즉시 업그레이드하라고 밝혔다. 이번 버전에는 △BatchV1_1 △ConfidentialTransfer △DynamicMPT △PermissionDelegationV1_1 △Sponsor △fixCleanup3_3_0 등 6개 개정안이 포함됐다.

이번 사안의 핵심은 배포와 활성화가 다르다는 점이다. XRP레저에서 개정안은 신뢰 검증자 80% 이상이 14일 연속 찬성해야 켜진다. 중간에 찬성률이 기준 아래로 내려가면 카운트는 다시 시작된다.

XRPL Dashboard는 24일 기준 3.3.0 관련 14일 활성화 카운트다운이 0건이라고 표시했다. ConfidentialTransfer와 Sponsor는 아직 'In development' 항목으로 분류됐다. 3.3.0이 공개됐더라도 새 기능이 곧바로 원장 규칙에 반영된 상태는 아니라는 뜻이다.

이번 업그레이드는 단순 기능 추가만은 아니다. BatchV1_1과 PermissionDelegationV1_1은 앞선 버전에서 문제가 발견돼 비활성화됐던 기능을 고쳐 다시 실은 성격이 강하다. 공식 릴리스는 기존 Batch와 PermissionDelegation을 각각 새 버전으로 대체했다고 설명했다.

BatchV1_1은 여러 거래를 묶어 처리하는 배치 트랜잭션 개정안이다. ConfidentialTransfer는 전송 정보를 보호하는 기능이고, DynamicMPT는 다목적 토큰(MPT)의 활용 범위를 넓히는 개정안이다. PermissionDelegationV1_1은 계정 권한 위임, Sponsor는 거래 비용 부담 구조와 맞닿아 있다.

노드와 검증자도 구분해야 한다. 일반 노드는 네트워크를 따라가지만 반드시 개정안 투표 주체는 아니다. 검증자는 합의와 개정안 투표에 참여한다. 따라서 노드 준비율과 검증자 투표율을 같은 지표로 보면 실제 활성화 상황을 잘못 읽을 수 있다.

전체 노드의 최신 버전 전환율과 개정안 투표에 참여하는 신뢰 검증자의 지지율은 서로 다른 지표다. 두 수치를 같은 기준으로 해석하면 배포 이후 실제 활성화 단계가 어디까지 진행됐는지 오독할 수 있다.

유투데이(U.Today)는 리플X(RippleX) 엔지니어 발언을 전하며 '충분히 업데이트됨' 기준을 검증자 목록만이 아니라 네트워크 전체 기준으로 봐야 한다는 해석을 소개했다. 이 보도는 3.3.0 업그레이드율을 약 32%로 설명했다.

반면 일부 보도에 나온 '노드 60% 준비' 수치는 공식 릴리스, XRP레저 개정안 문서, 공개 대시보드에서 직접 확인되지 않았다. 현재 공개 지표로는 기능 활성화가 임박했다고 보기보다 배포 이후 업그레이드와 투표를 기다리는 단계로 보는 편이 맞다.

운영상 리스크는 오래된 서버 버전에 남는 경우다. XRP레저 문서는 개정안이 활성화됐을 때 구버전 서버가 이를 처리하지 못하면 'amendment blocked' 상태가 될 수 있다고 설명한다. 이 경우 서버는 거래 처리, 합의 참여, 향후 개정안 투표를 정상적으로 수행할 수 없다.

국내 이용자에게도 이 차이는 의미가 있다. 거래소 이용자가 곧바로 새 기능을 체감하는 이슈라기보다, 지갑·탐색기·결제 서비스·토큰 발행 도구를 운영하는 개발자와 인프라 사업자가 먼저 확인해야 할 네트워크 운영 이슈에 가깝다.

XRP레저 기반 애플리케이션 확대와 관련해서는 본지도 XRP레저 기반 대출 프로토콜 개발이 메인넷 적용에 검증인 승인을 전제로 한다는 점을 전한 바 있다. 프로토콜 기능이 늘어도 애플리케이션이 안정적으로 호출할 접속층이 부족하면 활용 폭은 제한된다.

XRP레저 3.3.0은 배포를 마쳤고, 기능 활성화에는 검증자 투표와 14일 유지 조건이 남아 있다. 공개 대시보드 기준 24일 현재 14일 활성화 카운트다운은 0건이다.