솔라나 v1 업그레이드, 네트워크 오류 위험 및 수수료 제한 무력화 가능성
CryptoSlate2026년 9월 5일 07:054
솔라나(Solana) 블록체인의 v1 트랜잭션 포맷 업그레이드가 네트워크 안정성에 예상치 못한 위험을 초래할 수 있다는 우려가 제기되었습니다. 이번 업그레이드는 트랜잭션당 최대 페이로드 용량을 기존 1,232바이트에서 4,096바이트로 3배 이상 확대하는 것을 목표로 하지만, 준비되지 않은 시스템에서는 심각한 오류를 유발하거나 잘못된 수수료 제한을 적용할 수 있다는 지적이 나왔습니다.
솔라나의 공식 업그레이드 페이지에 따르면, v1 트랜잭션 포맷은 9월 4일 현재 메인넷에 아직 활성화되지 않은 상태입니다. 다만, 테스트넷에서는 이미 활성화되었으며 개발넷에서도 운영 중입니다. 지난 8월 28일 공개된 솔라나 변경 로그에는 v1 트랜잭션이 '곧 출시될 예정'이라고 명시되어 있어, 인프라 운영자들에게 업그레이드할 수 있는 사전 준비 기간을 제공했습니다.
v1 트랜잭션 포맷은 페이로드 용량을 대폭 늘리는 동시에, 기존 v0 및 레거시 트랜잭션은 기존 제한과 작동 방식을 유지합니다. 따라서 사용자나 애플리케이션이 기존 포맷을 계속 사용한다면 별도의 마이그레이션 작업이 필요하지 않습니다. 그러나 이번 업그레이드의 핵심은 RPC(Remote Procedure Call) 클라이언트, 인덱서, 릴레이어, 수수료 스폰서 등 솔라나 네트워크와 상호작용하는 다양한 시스템들이 v1 포맷에 대비해야 한다는 점입니다.
가장 직접적인 문제는 RPC 소비자들이 v1 트랜잭션에 대응하기 위해 특정 파라미터를 명시적으로 설정해야 한다는 것입니다. `getTransaction`, `getBlock`, `blockSubscribe`와 같은 RPC 호출 시 `maxSupportedTransactionVersion: 1` 정수형 파라미터를 전달해야 합니다. 이 설정을 누락할 경우, v1 트랜잭션에 대한 `getTransaction` 요청은 `-32015` 오류를 반환하게 됩니다. 또한, v1 트랜잭션이 하나라도 발생하면 `getBlock` 함수는 해당 블록 전체에 대해 실패하며, `blockSubscribe`의 경우 `block: null`을 내보내고 영향을 받은 슬롯부터는 더 이상 블록을 진행하지 못하게 됩니다. 이 파라미터는 RPC 서비스에게 클라이언트가 디코딩할 수 있는 가장 높은 포맷 버전을 알려주는 역할을 할 뿐, v1 데이터를 직접 요청하거나 레거시 및 v0 트랜잭션 반환 방식을 변경하지는 않습니다.
더욱 은밀하게 작동하는 오류들도 존재합니다. v1 트랜잭션에서는 컴퓨트 유닛(compute unit) 제한, 로드된 계정(loaded account) 데이터 제한, 우선순위 수수료(priority fee) 등이 `ComputeBudget` 지침 대신 `transactionConfig` 객체로 이동합니다. 만약 기존 `ComputeBudget` 지침만을 계속 스캔하는 인덱서의 경우, v1 트랜잭션에 대해 0 컴퓨트 예산으로 보고하게 되며 별도의 오류 메시지를 발생시키지 않습니다. 이는 잠재적으로 네트워크의 자원 할당 및 수수료 책정에 혼란을 야기할 수 있습니다.
Geyser 및 gRPC 소비자들도 유사한 함정에 빠질 수 있습니다. 프로토콜 버퍼(protobuf)의 `versioned` 플래그는 v0과 v1 모두에서 `true`로 설정됩니다. 따라서 최신 상태로 업데이트되지 않은 소비자들은 v1 트랜잭션을 v0으로 잘못 인식하고 빈 예산으로 처리할 가능성이 있습니다. 이를 해결하기 위해서는 프로토콜 버퍼 스텁(stub)을 다시 생성하고 `Message.config` 필드 7을 읽기 전에 해당 플래그를 확인해야 합니다. 이는 프로토콜 통신 방식에 대한 깊이 있는 이해가 필요한 부분입니다.
릴레이어, 페이마스터(paymaster), 기타 서버 서명자(server signer)들 역시 정책 검증 로직을 변경해야 합니다. `ComputeBudget` 지침을 스캔하여 수수료 상한선을 강제하던 스폰서의 경우, v1 트랜잭션이 해당 지침을 실행하지 않는 'no-op'으로 처리될 수 있기 때문에 더 이상 유효한 상한선을 적용할 수 없습니다. 따라서 서버는 v1 트랜잭션의 `0x81` 접두사를 식별하고 `transactionConfig` 내에서 수수료 및 자원 제한을 강제해야 합니다. 이는 합의 알고리즘의 결함이나 자금에 직접적인 위험을 초래하는 문제가 아니라, 애플리케이션 레벨에서의 통제 오류입니다.
온체인 프로그램(onchain program)들은 더 까다로운 제약에 직면합니다. 솔라나 측에 따르면, 현재 사용 가능한 시스템 변수(sysvar)나 시스템 호출(syscall) 중 어느 것도 v1 메시지 설정을 직접적으로 노출하지 않습니다. 따라서 `ComputeBudget` 지침에 기반하여 작동 방식을 제어하던 프로그램들은 v1이 활성화되면 이러한 검사에 더 이상 의존해서는 안 됩니다. 이는 프로그램 개발자들이 v1 트랜잭션 포맷을 고려하여 로직을 재검토하고 수정해야 함을 의미합니다.
솔라나 v1 업그레이드를 위해 최소한으로 업그레이드해야 하는 요구 사항을 갖춘 릴리스에는 `@solana/k`가 포함됩니다. 그러나 이 외에도 다양한 인프라 컴포넌트들이 v1 포맷의 변경 사항을 인지하고 이에 맞춰 업데이트를 진행해야 합니다. 이러한 준비 과정이 지연되거나 불완전할 경우, 트랜잭션 처리 지연, 네트워크 중단, 잠재적인 수수료 책정 오류 등 다양한 문제가 발생할 수 있으며, 이는 솔라나 생태계 전체의 신뢰도에 영향을 미칠 수 있습니다.
솔라나 커뮤니티와 개발자들은 이번 v1 트랜잭션 포맷 업그레이드의 잠재적 위험을 인지하고, 관련 인프라를 신속하고 철저하게 업데이트함으로써 네트워크의 안정성과 효율성을 보장해야 할 것입니다. 특히, RPC 호출 시 `maxSupportedTransactionVersion` 설정을 잊지 않고 적용하는 것이 기본적인 예방 조치입니다. 또한, `ComputeBudget` 지침에만 의존하는 로직은 v1 포맷에 대응하도록 수정되어야 하며, 프로토콜 버퍼 관련 오류 방지를 위한 업데이트도 필수적입니다. 이러한 조치들을 통해 솔라나의 트랜잭션 처리 능력이 향상되더라도, 네트워크의 견고성이 훼손되지 않도록 주의를 기울여야 할 시점입니다.