Stellar Development Foundation, 11월 24일 Bell 프로토콜 30 투표 전 운영자 소프트웨어 요건 발표

활성화 전 세 갈래 작업

Stellar (XLM) Development Foundation이 Bell 업그레이드 가이드를 10월 23일부로 갱신하면서, 투표 전에 운영자별로 갖춰야 할 소프트웨어 버전을 정리해 놓았다. 이번 갱신은 Bell 프로토콜 30 업그레이드가 표결에 들어가기 전 단계를 다루며, 거래소와 지갑, 원장 데이터를 직접 읽는 서비스에 서로 다른 작업을 부과한다는 점이 눈에 띈다. 가이드는 인프라와 개발자 도구를 지원 버전과 짝지어 놓고, 모든 운영자에게 자사 통합 환경의 테스트를 요청한다. 이 검증 단계는 검증인 투표와 별개로 진행된다. 일정은 테스트넷 투표가 11월 4일(수), 메인넷 투표가 11월 24일(화)이지만 두 날짜 모두 바뀔 수 있고, 실제 적용 여부는 검증인 승인에 달려 있다. 재단이 이 문서를 따로 마련한 이유는 실무적 공백 때문이다. 검증인 승인은 프로토콜 30의 활성화 여부를 결정하지만, 거래소나 지갑이 평소 돌리는 소프트웨어가 사용자가 변화를 체감하는지를 결정한다. 가이드 자체는 네트워크에 아무 변화도 주지 않는다. 제안을 서비스별 점검 목록으로 옮겨 적은 문서일 뿐이다.

변경의 하류에 놓인 주체들에게 가이드는 책임을 세 갈래로 나눠 지정한다. 핫 월렛 인프라를 운영하는 거래소와 커스터디는 새로운 W 형식 계약 주소로 출금을 보낼 수 있는지 확인해야 한다. 지갑과 자산 발행사는 주소 입력을 받아들이고 이전 기록을 처리하는 기능을 점검한다. 인덱서, 익스플로러, 분석 도구처럼 원장 데이터를 직접 읽는 서비스에는 별도의 의무가 생긴다. 프로토콜 30은 원장 헤더에 새 값 형식을 넣기 때문에, 기존 XDR 정의를 그대로 쓰는 디코더는 활성화 이후 원장을 읽지 못할 수 있다. XDR은 Stellar 네트워크가 트랜잭션과 원장 데이터를 표현하는 데 쓰는 형식이다. 재단이 영향을 받는 팀에 투표 뒤가 아니라 투표 전에 정의를 갱신하라고 요청하는 이유다.

W 주소와 XDR 디코더

가장 잘 보이는 변화는 'W'로 시작하는 계약 주소 형식이다. 각 스마트 계약 주소는 64비트 식별자를 하나씩 가지며, 하나의 계약이 여러 고객에게서 도착하는 입금을 구분할 수 있게 된다. SDK 업데이트가 새 주소를 읽을 수 있게 만들지만, 지갑 주소를 검증하거나 표시하거나 저장하는 애플리케이션 코드, 그리고 이전 대상을 읽는 코드 역시 W 형식을 받아들일 수 있어야 한다. 하드웨어 지갑 화면을 포함한 지갑 소프트웨어가 이 범주에 들어간다. 기존 스마트 계약은 업그레이드 이후에도 그대로 작동하며, 새 계약 기능을 도입할지 여부는 개발자의 선택으로 남는다.

재단이 요구하는 버전은 stellar-core v30.0.0, 그리고 Horizon, RPC, Galexie 각 v30.0.0이다. JavaScript SDK는 v17.3.0, Go SDK는 v0.8.0이다. 유지보수 릴리스인 v16.4.0은 새 원장을 읽을 수 있지만 W 주소를 처리하지 못하므로, W 지원이 필요한 서비스는 v17.3.0 이상에 있어야 한다. Horizon과 RPC 엔드포인트는 원장을 애플리케이션에 노출하기 때문에, 원시 XDR을 직접 파싱하지 않고 이 API를 거쳐 체인을 조회하는 서비스에는 두 제품의 v30.0.0 정렬이 중요하다. Soroban Rust SDK 30.0.0-rc.1도 목록에 올랐으며, 안정 버전은 메인넷 투표 전에 나올 예정이다. Bell용 Stellar (XLM) CLI 빌드는 가이드가 갱신된 시점에 아직 준비 중이었다. Bell은 그 밖에 스마트 계약용 ML-DSA 서명 검증과 밀리초 단위 원장 시각 기록을 싣는다. 네트워크 트랜잭션 서명은 계속 Ed25519를 쓰며, 시각 기록 변경만으로 원장 생성 간격이 짧아지지는 않는다. 두 가지 준비는 서로 독립적이다. 이전 테스트를 통과했다는 사실이 디코더가 새 원장 헤더를 견딜 수 있는지와는 아무 관련이 없다.

릴리스 노트를 기준으로 읽으면 프로토콜 30은 추가적 변경이다. 기존 계약은 활성화를 그대로 통과하며, 새 기능을 받아들이는지는 개발자가 정한다. 위험은 체인 밖, 즉 프로토콜 변경이 손대지 않는 코드에 있다. 11월 24일 투표 시점까지 옮기지 못한 디코더나 주소 검증기가 지켜봐야 할 고장 지점이고, 검증인 수가 아니다. 하나의 계약이 여러 고객의 입금을 구분하게 해 주는 W 주소 방식은 전통 금융의 정산을 Stellar(XLM)에 얹는 커스터디와 거래소 경로를 겨눈다. Stellar에서 최초로 체결된 기관 리포 거래와 2027년으로 확정된 DTCC의 30조 달러 규모 토큰화 서비스가 같은 경로다. 아직 나오지 않은 Stellar CLI 빌드와 미공개 안정 버전 Soroban SDK는 메인넷 투표에서 끝나는 마감 시간을 남긴다. 활성화 이후에만 이전하는 서비스는 자신의 도구가 애초에 해석하도록 만들어지지 않은 원장을 읽게 된다.