솔라나(SOL)의 단일 거래 최대 크기가 1232바이트에서 4096바이트로 확대됐다. 여러 거래로 나눠야 했던 영지식(ZK) 증명과 대형 멀티시그 작업을 하나의 거래로 처리할 수 있게 됐다.
솔라나재단은 v1 거래 포맷이 메인넷 에포크 1035 시작 시점인 한국시간 15일 오전 10시께 활성화됐다고 밝혔다. 이번 변경은 테스트넷과 개발자넷에도 적용됐다.
거래 크기 확대는 SIMD-0296과 새 거래 구조를 정의한 SIMD-0385를 통해 이뤄졌다. 최대 크기는 기존보다 3.3배 커졌다.
기존 1232바이트 제한은 복잡한 작업을 여러 거래로 쪼개야 하는 제약으로 작용했다. v1 포맷에서는 기밀 전송에 활용되는 ZK 증명, 대형 멀티시그, 배치 거래, Winternitz 일회용 서명, BLS 같은 서명 체계를 한 거래에 담을 수 있다.
v1 거래는 기존 포맷을 대체하지 않는다. 레거시와 v0 거래는 계속 사용할 수 있어 추가 용량이 필요하지 않은 애플리케이션은 기존 방식을 유지하면 된다.
반면 4096바이트 거래를 사용하려는 애플리케이션은 v1 포맷을 선택해야 한다. 솔라나 데이터를 읽는 지갑과 애플리케이션, RPC, 인덱서, 탐색기도 새 거래 구조를 해석할 수 있어야 한다.
거래 조회 애플리케이션은 v1 지원 여부를 명시해야 한다. 인덱서는 기존 ComputeBudget 명령어 대신 거래 헤더의 transactionConfig에서 연산 한도와 수수료 정보를 읽어야 한다.
본지는 앞서 솔라나 v1 거래 전환을 앞두고 RPC와 인덱서의 호환성 점검이 필요하다고 보도했다. 이번 메인넷 활성화로 주변 인프라가 실제 거래를 처리할 수 있는지가 운영 단계의 과제가 됐다.
v1 거래는 주소 조회 테이블을 사용하지 않고 거래 안에 주소를 직접 담는다. SIMD-0385는 거래당 주소를 최대 64개, 서명을 최대 12개, 명령어를 최대 64개로 제한한다.
주소 조회 테이블을 활용하던 기존 v0 거래와 구조가 다른 만큼 개발자는 사용 사례에 맞춰 포맷을 선택해야 한다. 기존 거래와 새 거래가 당분간 함께 운영되는 구조다.
4096바이트 상한은 검증인 하드웨어의 표준 4KiB 메모리 페이지 크기에 맞춘 값이다. 거래가 네트워크 전송 단위를 넘으면 여러 QUIC 프레임으로 나뉘고, 일부 프레임이 유실될 경우 전체 묶음을 재전송해야 한다.
솔라나재단은 이런 전송 비용과 수신 측 버퍼 부담을 고려해 거래 크기를 무작정 늘리지 않고 4KiB에서 제한했다고 설명했다. 크기 확대와 네트워크 비용 사이의 균형을 반영한 수치다.
인프라 운영자도 소프트웨어를 점검해야 한다. 솔라나재단은 Jito-Solana 검증인과 RPC 운영자에게 4.2.2 이상 버전으로 업데이트할 것을 안내했다.
이전 RPC 버전에서는 v1 거래가 저장 과정에서 v0으로 낮춰 표시될 수 있다. 거래 원문과 수수료 정보를 정확히 처리하려면 관련 시스템의 버전과 파서 지원 여부를 확인해야 한다.
이번 업그레이드는 솔라나의 처리량 수치나 SOL 가격을 직접 바꾸는 조치는 아니다. 핵심은 기존 거래 한도 때문에 분할됐던 복잡한 작업을 단일 원자적 거래로 구성할 수 있게 됐다는 점이며, 실제 활용 범위는 지갑·개발 도구·RPC·인덱서의 v1 지원 여부에 달려 있다.

