Solana 논스 전환 계획: 전달 거래가 만료돼도 승인은 남는다
Solana는 오프라인 서명을 유지하면서 durable nonce를 없애는 방안을 추진한다. 프로그램 기반 대체 설계는 오래 유지되는 승인과 이를 전달하는 짧은 수명의 거래를 분리한다.
내용이 바뀌지 않은 승인 캡슐을 만료된 운반함에서 새 운반함으로 옮기는 AI 생성 개념도. 실제 지갑 화면이나 Solana 전환 완료를 보여 주는 장면이 아니다.
핵심 요약
- 10월 16일 개발 소식에 사용 중단 계획이 소개됐다. 최종 대체안과 제거일은 미정이며, 약 6개월의 전환 기간은 적합한 대체안이 준비되는 시점에 달려 있다.
- 오프라인 권한자가 메시지에 서명하면 전달자가 일반 거래에 담아 보낸다. 전달 거래의 블록해시를 새로 받아도 승인 메시지의 서명을 다시 받을 필요는 없다.
- 대체 프로그램은 파생 주소와 내부 호출로 동작한다. 앱 호환성, 서명이 고정하는 범위, 승인 취소는 따로 살펴봐야 한다.
사건의 흐름 한눈에 보기
Solana Foundation의 10월 16일 개발 소식이 durable nonce 사용 중단 발표를 소개했다. 제거 완료가 아니라 계획이다.
조건이 붙은 전환 일정
오프라인에서 승인을 모으는 데 걸리는 시간은 일반 Solana 거래의 유효 기간보다 길 수 있다. 지금은 durable nonce가 이 간극을 메운다. Solana Foundation은 2026년 10월 16일 개발 소식에서 이를 없애는 계획을 소개했지만, 업그레이드 페이지의 상태는 여전히 개발 중이다. 온체인 프로그램이 오프라인 서명을 검증하는 방식에 Anza의 Programmatic Signer와 Blueshift의 Vector를 후보로 제시한다. 최종 대체안과 제거 날짜는 정하지 않았다.[1][2]
페이지가 예상하는 제거 시점은 적합한 대체안이 준비된 뒤 약 6개월이다. 대체안의 감사가 끝나고 메인넷에서 가동될 때까지 기존 durable nonce가 유지된다고도 설명한다. 10월 발표일부터 세는 기한이 아니다. Anza의 자체 문서는 현재 Devnet 배포와 감사 진행 상태를 명시하고, v1 및 메인넷 배포 전에 감사와 수정이 필요하며 인터페이스도 바뀔 수 있다고 밝힌다. Vector 코드와 프로그램 주소의 공개만으로 감사를 마친 메인넷 배포를 입증할 수는 없다. 이 글은 공개 설계를 설명하며 네트워크 전환 완료를 보도하는 것이 아니다.[1][4]
현재 논스가 유지하는 것
일반 거래는 최근 블록해시를 참조하며, 받아들여질 수 있는 시간이 제한된다. durable nonce 거래는 그 자리에 System Program의 논스 계정에 저장된 값을 넣는다. 서명자는 오프라인에서 거래를 승인하고 다른 사람이 나중에 제출할 수 있으며, 일반적인 블록해시 만료를 피한다. 저장된 값은 재실행도 막는다. 논스가 다음 값으로 바뀌면 이전 값에 서명한 거래를 그대로 다시 쓸 수 없다.[3]
여기서 실패는 두 가지로 나뉜다. 현재 문서에 따르면 이미 사용된 논스처럼 검증 단계에서 탈락한 거래는 수수료나 상태 변경 없이 버려진다. 반면 검증을 통과한 뒤 명령 실행 중 실패하면 논스는 다음 값으로 바뀌고 수수료도 부과된다. 앱의 동작은 실패했는데 기존에 서명한 거래는 더 이상 쓸 수 없는 것이다. 거절된 모든 시도가 논스를 소모한다고 설명하면 이 차이를 놓친다.[3]
승인과 전달 수단의 수명을 나눈다
Programmatic Signer는 동작을 세 겹으로 나눈다. 실행 메시지에는 앱에 시킬 명령이 들어간다. 승인 메시지는 그 실행 내용을 실행기와 논스 계정에 묶고, 필요한 권한자들이 정확히 그 바이트에 서명한다. 전달 거래는 승인과 서명을 네트워크로 운반하며 일반적인 최근 블록해시와 수수료 납부자를 사용한다. 프로그램들이 오프라인 서명을 검사하고 자체 논스를 갱신한 뒤 승인된 명령을 호출한다. 검증자가 받는 것은 일반 거래다.[4][5]
서명한 승인을 배송 봉투 안의 내용물로 생각할 수 있다. 봉투가 만료되면 전달자가 새 전달 거래를 만들고 바깥 거래에 다시 서명한다. 안의 승인에는 서명을 다시 받을 필요가 없다. 다만 이 비유에는 분명한 경계가 있다. 전달자는 승인된 명령을 고치거나 승인 메시지 안의 계정을 바꿔 끼울 수 없다. Anza의 문서에서 실행 메시지의 블록해시 필드는 예상 논스 값을 담고, 바깥 전달 거래의 같은 필드는 최근 블록해시를 담는다. 이름이 같아도 역할이 다르다.[5]
실제로 행동하는 계정과 서명의 범위도 달라진다
프로그램은 오프라인 권한자를 위해 프로그램 파생 주소(PDA)로 행동하고, 프로그램 간 호출(CPI)로 앱을 부른다. 기존 키 쌍의 계정과 파생 계정은 서로 바꿔 써도 되는 동일한 신원이 아니다. 최상위 호출만 허용하는 프로그램은 이 경로를 거부할 수 있다. 바깥 거래 서명자만 읽는 인덱서는 전달자를 보지만 실제 행동한 PDA는 내부 명령에 나타날 수 있다. 오프라인 승인을 지원하려면 만료 필드 하나를 바꾸는 것보다 더 많은 호환성을 살펴야 한다.[1][4]
서명이 무엇을 고정하는지도 후보마다 다르다. Programmatic Signer는 서명된 승인 안의 변경을 금지하면서 전달자가 Submit 앞뒤에 다른 명령을 덧붙이는 것은 허용한다. Vector는 passthrough의 내용까지 포함해 모든 최상위 명령을 서명 대상 해시에 묶는다. 전달자는 서명 이후 그 명령을 추가·삭제·재배열할 수 없다. 두 방식 모두 프로그램이 관리하는 재실행 방지와 CPI를 사용하지만, 승인 주변에 덧붙일 수 있는 작업의 경계는 다르다. 어느 설명도 특정 앱이 이미 호환된다는 증거는 아니다.[1][5][6]
만료·취소·재시도는 서로 다른 사건이다
공개된 두 설계 모두 승인에 기본 만료 시한을 두지 않는다. 따라서 전달 거래의 만료는 승인의 취소가 아니다. 해당 논스를 다음 값으로 바꾸면 이전 값에 묶인 승인은 무효가 된다. 업무상 마감 시각이 필요하다면 서명한 내용에 포함된 명령이 이를 검사해야 한다. 승인 도구가 날짜를 보여 주는 것만으로는 충분하지 않으며, 실제 실행 규칙이 그 날짜를 확인해야 한다.[1][5][6]
또한 실행이 실패해 거래가 되돌려지고 논스가 그대로라면, 두 설계에서는 같은 승인으로 다시 시도할 수 있다. 현재 durable nonce의 실행 실패 처리와 다른 점이다. 그렇다고 언젠가는 성공한다거나 네트워크 시도가 무료라는 약속은 아니다. 일반적인 거래 수수료는 적용된다. 계획을 읽을 때 유용한 질문은 무엇을 승인했는지, 어느 계정이 행동하는지, 무엇이 승인을 무효화하는지, 상대 앱이 그 호출 경로를 받아들이는지다. Foundation은 일반 거래는 계획된 제거의 영향을 받지 않으며, 전환 대상은 durable nonce를 쓰는 흐름이라고 설명한다.[1][3][6][7]
이어서 읽을 이야기
같은 주제를 다른 사례와 배경에서 살펴보세요.
