솔라나 v1 거래 4096바이트 전환 앞두고 호환성 점검

솔라나(SOL)의 새 거래 포맷 v1이 메인넷 활성화를 앞두고 인프라 호환성 점검대에 올랐다. 단일 거래 최대 크기를 1,232바이트에서 4,096바이트로 늘리는 변화지만, 쟁점은 체인 합의 장애보다 RPC, 인덱서, gRPC, 수수료 스폰서가 새 포맷을 제대로 읽는지에 맞춰져 있다.

솔라나재단(Solana Foundation)은 네트워크 업그레이드 페이지에서 아가브(Agave) 4.2가 메인넷에 올라갔지만 ‘Larger Transaction Sizes’ 기능은 2026년 9월 4일 기준 활성화 대기 상태라고 밝혔다. 같은 기능은 v1 거래 포맷을 통해 기존 거래 한도를 약 3.3배로 키우는 내용을 담고 있다.

이번 변경은 단순한 크기 확대가 아니다. SIMD-0296과 SIMD-0385는 대형 멀티시그, 영지식증명(ZK proof), 배치 전송 같은 용도를 배경으로 제시했다. v1에서는 기존 거래에서 쓰던 주소 조회 테이블 의존을 줄이고, 수수료와 리소스 제한 정보를 별도 설정값인 transactionConfig로 옮긴다.

기존 시스템의 읽기 방식은 이 지점에서 문제가 될 수 있다. 인덱서와 수수료 스폰서가 ComputeBudget instruction만 훑어 우선 수수료나 컴퓨트 유닛 한도를 계산하면 v1 거래의 fee cap을 놓치거나 0으로 읽을 수 있다. 솔라나재단의 transaction-v1 예제 저장소는 v1 메시지가 ComputeBudget instruction 대신 TransactionConfig를 담는다고 설명했다.

솔라나 RPC 문서는 getTransaction, getBlock, blockSubscribe 호출에 maxSupportedTransactionVersion: 1을 넣어야 한다고 안내한다. 이 값을 생략하거나 0으로 두면 v1 거래가 들어올 때 getTransaction은 에러를 낼 수 있고, getBlock은 해당 블록 전체 읽기에 실패할 수 있다.

웹소켓 구독도 예외가 아니다. blockSubscribe는 설정이 맞지 않으면 block: null을 내보낼 수 있다. 솔라나 개발 문서는 이를 빈 블록이 아니라 실패로 처리해야 한다고 안내했다. v1 거래는 직렬화된 거래의 첫 바이트 129, 즉 0x81로 식별된다.

gRPC와 Geyser 경로에서는 더 조용한 오류가 날 수 있다. 솔라나 개발 문서는 gRPC에는 maxSupportedTransactionVersion 같은 옵트인 값이 없고, 오래된 protobuf 스텁은 Message.config 필드를 버릴 수 있다고 경고했다. 이 경우 시스템은 멈추지 않지만 v1 거래를 v0처럼 보고 수수료 설정을 빠뜨릴 수 있다.

솔라나재단의 예제 저장소는 @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0, yellowstone-grpc geyser 15.1.1 등을 최소 버전으로 제시했다. 읽기, 전송, 블록 인덱싱, gRPC 예제도 별도로 제공한다.

코어 툴링 쪽 검증도 이어지고 있다. anza-xyz의 solana-sdk 이슈 #831은 v1 최대 크기 4,096바이트가 디시리얼라이저와 sanitizer에서 제대로 강제되지 않는 문제를 제기했다. 다만 솔라나 상태 페이지는 2026년 9월 4일 기준 Mainnet Beta RPC Nodes가 운영 중이며 당일 보고된 인시던트가 없다고 표시했다.

이번 사안은 솔라나 v1 거래 한도 확대와 관련한 인프라 호환성 점검 성격이 강하다. 앞선 쟁점이 4,096바이트 한도와 클러스터별 기능 활성화 여부였다면, 이번에는 실제 v1 거래가 들어올 때 백엔드 시스템이 새 구조를 읽을 수 있는지가 핵심이다.

솔라나 업그레이드 페이지는 2026년 9월 4일 기준 ‘Larger Transaction Sizes’ 기능이 활성화 대기 상태라고 표시했다. 해당 일정은 솔라나 처리 구조를 한 번에 바꾸는 단일 이벤트라기보다 지갑, RPC, 인덱서, 개발 도구가 순차적으로 준비해야 하는 기술 로드맵에 가깝다.

기술적으로 v1 거래는 기존 v0와 레거시 거래를 대체하지 않는다. 기존 포맷은 계속 작동하지만, 더 큰 거래 크기와 transactionConfig를 쓰는 애플리케이션은 새 포맷 지원이 전제된다. 통상 블록체인 인프라 업그레이드에서는 합의 규칙뿐 아니라 데이터를 읽고 저장하는 주변 시스템의 호환성이 실제 운영 리스크를 좌우한다.

수수료 스폰서와 인덱서는 특히 영향을 받을 수 있다. 수수료 상한이나 컴퓨트 유닛 한도를 잘못 읽으면 이용자 대신 비용을 부담하는 서비스가 예상과 다른 비용 구조에 노출될 수 있고, 거래 분석 시스템도 v1 거래의 리소스 설정을 잘못 기록할 수 있다. 이는 체인이 멈추는 장애와는 다르지만, 서비스 운영자에게는 별도 점검이 필요한 영역이다.

국내 거래소나 지갑 사업자도 솔라나 입출금과 온체인 모니터링을 운영한다면 같은 문제에서 자유롭지 않다. 거래 자체보다 블록·거래 조회, 인덱싱, 리스크 감시, 수수료 계산 경로가 v1 메시지 구조를 처리하는지 확인해야 한다. 특히 외부 노드 제공업체나 Geyser 기반 데이터를 쓰는 경우 protobuf 재생성과 라이브러리 버전 점검이 필요하다.

솔라나 v1 거래가 실제로 들어오기 전까지 핵심 점검 항목은 △RPC 호출 옵션의 maxSupportedTransactionVersion: 1 설정 △transactionConfig 저장 경로 반영 △gRPC protobuf 스텁 재생성 △0x81 버전 프리픽스 인식 여부다. 솔라나 업그레이드 페이지 기준으로 ‘Larger Transaction Sizes’는 2026년 9월 4일 현재 활성화 대기 상태다.