Anza CEO 브레넌 와트, 솔라나(SOL) 18개 장 규모 프로토콜 사양서 제안

하나의 규칙책, 세 개의 클라이언트

검증인 클라이언트 세 개가 각자 독립적으로 구현돼 네트워크 규칙을 집행하는 상황에서, 그 규칙이 실제로 무엇인지는 누가 어떻게 확정할 수 있을까. 리플(XRP)과 달리 솔라나 개발 진영은 이 질문을 공식 안건으로 올렸다. Anza CEO 브레넌 와트(Brennan Watt)가 프로토콜 변경 검토 절차를 단일 공유 사양서로 옮기자고 제안한 것이다. 와트는 10월 30일 금요일 "프로토콜 사양으로의 전환"이라는 제안서를 솔라나 개선 제안(SIMD) 논의 게시판에 게시했고, 개발 전반을 조율하는 솔라나 재단은 11월 5일 목요일 사양 통합과 검토 절차 개정에 관한 논의가 공식 시작됐다는 개발 공지로 뒤따랐다. 지금까지 SIMD 문서는 규칙 변경의 검토 수단이자, 사실상 네트워크 프로토콜이 하는 일의 기록 역할을 겸했다. 이 논의가 열린 시점에 솔라나 가격은 24시간 동안 6.8% 하락을 흡수하고 있다. 이 하락은 100달러 선 이탈 이후의 조정이 이어지는 움직임이지 제안에 대한 반응이 아니며, 트레이더가 주시하는 지점은 솔라나 기술적 분석에서 확인된다. 와트의 논지는 이렇다. 기존 절차는 제안을 쌓아 두는 데는 능숙하지만, 이미 시행 중인 규칙은 검증인 코드와 개별 제안 문서 사이에 흩어져 있다는 것이다. 그는 같은 동작이 여러 곳에서 조금씩 다르게 서술될 수 있고, 한 변경이 닿는 지점을 전부 찾기 어렵다고 지적했다. 그의 해법은 아이디어 논의, 기술 검토, 필요한 거버넌스 승인은 그대로 두되, 실질 변경 자체는 공통 사양서를 향한 풀 리퀘스트로 옮기는 방식이다. 그러면 서로 다른 검증인 소프트웨어가 검토된 하나의 원천에서 동일한 규칙을 구현할 수 있다. 승인된 사양서 풀 리퀘스트는 해당 변경이 메인넷에서 활성화될 때까지 열려 있으므로, 문서는 실제로 돌아가는 규칙과 계속 일치한다. 아직 활성화되지 않은 SIMD는 식별자를 유지한 채 새 형식으로 이전해, 공통 사양서가 제안별 문서를 대신하더라도 기존 제안의 추적성이 유지된다.

에포크 1072에 고정된 초안

와트가 작성한 솔라나 프로토콜 사양서 초안은 18개 장으로 이뤄져 있으며, 트랜잭션과 메시지, 네트워크 통신, 상태 전이와 합의를 다룬다. 상위 호환 규칙은 메인넷 에포크 1072를 기준으로 참조된다. 초안은 검증된 에포크 스냅샷 또는 해당 에포크의 상태 루트로 인증된 상태에서 출발하는데, 이는 출발점 상태 자체에 대한 신뢰가 문서 밖에서 공급되는 입력이라는 뜻이다. 적용 범위는 의도적으로 한정돼 있다. 제네시스부터 체인을 재생하는 규칙은 정하지 않고, 에포크 1072에서 멈추며, 다음 에포크의 첫 블록도 정의하지 않는다. 초안을 하나의 에포크에 고정하면 규칙이 미래 지향적으로 유지된다. 1072 이후의 변경은 다시 쓴 과거가 아니라 고정된 기준선에 대비해 검증된다. 재단의 사양서 저장소도 같은 방향을 공유하며, 합의에 중대한 규칙을 하나의 완전하고 모호하지 않은 참조로 통합해 검증인 구현이 이를 활용하게 한다. 지금까지는 개별 SIMD 문서가 구체적 규칙 변경을 실어 왔다. 이 기록에는 블록 연산 한도를 1억 연산 단위로 올린 SIMD-0286 제안도 포함된다. 이전 프로토콜 작업도 Alpenglow의 150밀리초 최종성 목표처럼 단일 목표 방식을 취한 바 있다. 재단이 공지에서 언급한 배경은 클라이언트 다변화다. Agave, Firedancer, Mithril은 별개의 코드베이스이며, 각 노드 소프트웨어가 트랜잭션 처리와 합의 알고리즘에서 동일한 입력으로 동일한 결과에 도달해야 한다. 트랜잭션이 어떤 순서로 실행되는지도 같은 규칙이 지배하는 영역인데, 최대 추출 가능 가치 같은 효과가 발생하는 바로 그 지점이다. 이 규모에서 구현 간 불일치는 서류 문제가 아니다. 체인 자체를 갈라놓을 수 있다. 검증인 투표 뒤에 깔린 스테이킹 비중은 이 리스크를 기술적 문제이자 재무적 문제로 만든다. 네트워크의 이 측면이 낯선 독자에게는 솔플레어에서 SOL 스테이킹 가이드가 클라이언트 선택이 실무에서 어떻게 연결되는지 보여준다.

채택과 일정은 미정

공개 스레드에서 참여자 알노키(alnoki)는 문서로 쓰인 사양서는 클라이언트 구현에서만 보이는 내부 의존 관계를 놓칠 수 있고, 문서 하나만으로 구현들 사이의 모든 상호작용을 담지 못할 수 있다고 주장했다. 와트는 충분한 확신을 얻으려면 문서 작성과 병행해 개념 증명 구현을 만들어야 할 수 있다고 답했고, 제안 식별자는 공식 사양 검토 단계에서 부여돼야 한다는 점에 동의했다. 구현 도중 사양서가 바뀔 때 재검토를 어떻게 표시할지는 아직 검토 중이다. 제안 자체는 첫 번째 단계에 놓여 있다. 의견을 모으고 있으며, SIMD 절차 문서 개정은 폭넓은 합의가 형성될 때까지 미뤄진다. 변경 채택 여부도 적용 일정도 정해지지 않았다. 따라서 질문은 가장 날카로운 형태로 되돌아온다. 하나의 문서가 세 개의 독립 구현이 서로 다를 수 없을 만큼 솔라나를 정밀하게 기술할 수 있는가. 지금까지의 기록만 보면 답은 아직 열려 있다.