솔라나(SOL), 트랜잭션 용량 4,096바이트로 3배 이상 확대—호환성 리스크 대두

4,096바이트 트랜잭션, 메인넷 직전

Solana (SOL)가 단일 온체인 트랜잭션의 최대 크기를 기존의 3배 이상으로 확대하는 작업을 진행 중이다. 메인넷 활성화를 앞둔 최종 구간에서 Solana 네트워크와 주변 인프라 전반의 호환성 공간이 드러나고 있다. v1 트랜잭션 포맷은 트랜잭션당 상한을 1,232바이트에서 4,096바이트로 올리며, 생산 환경 배포를 앞두고 생태계 참여자들이 준비 상태에 대한 우려를 제기했다. 실패 시나리오는 구체적이다. v1을 지원하도록 업데이트되지 않은 RPC 클라이언트, 인덱서, 각종 데이터 서비스는 v1 트랜잭션이 포함된 블록을 읽으려다 오류를 내거나 아예 작동을 멈출 수 있다. 블록 익스플로러, 분석 플랫폼, 지갑 백엔드, 과거 체인 데이터를 재생하는 모든 서비스가 영향 범위 안에 놓여 있으며, 일부는 눈에 띄는 장애가 아니라 조용한 데이터 누락 형태로 증상이 나타날 수 있다.

이번 상향이 의미 있는 이유는 그것이 가능하게 하는 작업 때문이다. Solana는 여러 명령어를 하나의 원자적 트랜잭션에 담는 구조인데, 현재 1,232바이트 상한 때문에 개발자들은 다단계 DeFi 거래, 계정 일괄 생성, 압축 데이터 기록 같은 복잡한 연산을 여러 트랜잭션으로 쪼개야 했고, 분할 때마다 수수료와 지연이 더해졌다. 4,096바이트가 되면 훨씬 풍부한 연산을 단일 원자 단위에 담을 수 있다. 이런 이유로 v1 트랜잭션이 테스트넷에 배포되며 4,096바이트로 확대된 이후 이번 변경은 촉박하게 지켜져 왔다. 업그레이드는 이미 Solana의 테스트넷과 데브넷 환경에서 활성화돼 개발자들이 새 포맷에 맞춰 작업할 시간을 갖고 있다. 다만 9월 4일 기준 메인넷에서는 활성화되지 않았고, 덕분에 인프라 운영자들은 변경이 생산 환경에 도달하기 전 소프트웨어를 패치할 시간을 벌고 있다. 이 포맷 전환은 병렬로 파이프라인을 통과하는 여러 Solana 네트워크 업그레이드 중 하나로, 다운스트림 공급자 전체의 조정 부담을 키운다.

저장소 임대료, 6,333 램포트로 인하

용량이 확대되는 동안 네트워크의 상태 경제는 반대 방향으로 재가격되고 있다. 핵심 개발팀 Anza가 공식 게시물을 통해 밝힌 바에 따르면 Solana (SOL) 메인넷은 SIMD-0437의 1단계를 활성화했고, 온체인 상태 바이트당 부과되는 저장소 임대료를 6,960 램포트에서 6,333 램포트로 낮췄다. 인하율은 약 9%다. 저장소 임대료란 계정이 보유한 데이터에 붙는 램포트 잔액을 말하므로, 단위 비용 인하는 단순 토큰 계정부터 복잡한 프로그램의 데이터셋까지 체인에 상태를 유지하는 비용을 직접 줄인다.

SIMD-0437은 의도적으로 5단계에 걸쳐 진행된다. 관찰된 상태 증가를 조건으로 하는 이후 단계들은 단위 비용을 바이트당 696 램포트까지 단계적으로 끌어내린다. 원래 요금 대비 누적 약 90% 인하 규모다. 설계에는 명시적 안전밸브가 있다. 겸동 제안인 SIMD-0438은 상태 증가에 스트레스 징후가 보이면 원래 요금 체계를 복원할 수 있다. 요컨대 이번 인하는 일발성 경제 리셋이 아니라 점진적이며 되돌릴 수 있는 조치다. 실익은 시간이 갈수록 누적된다. 저렴해진 상태는 체인상 계정 보유의 장기 비용을 낮추는데, 프로그램을 배포하는 개발자와 Solana(SOL) 구매 가이드를 참고하는 신규 진입자 모두 계정 유지 비용이 줄어드는 직접 수혜자다. 이 변화는 Solana의 토크노미스에도 직결된다. 임대료는 수수료 번 fee burn 및 스테이킹 수익률과 함께 SOL 공급 역학을 형성하는 레버 중 하나이기 때문이다. 하드웨어 풋프린트가 상태 크기에 비례하는 검증자 운영자들은 인하된 요금이 상태 증가를 가속하는지, 즉 SIMD-0438이 존재하는 바로 그 조건을 주시할 것이다. 실시간 시세를 추적하는 독자는 Bybit에서 현물과 선물 가격을 실시간으로 확인할 수 있다.

696 램포트까지의 로드맵과 v1 대응

v1 대응 부담에 관한 새로운 기술 세부 사항이 확인됐다. Anza는 메인넷 활성화 목표를 잠정 9월 9일로 잡았으며, 데브넷은 이미 에포크 1140에서 활성화됐다. 사양은 SIMD-0296과 SIMD-0385로 제공되며, 레거시 및 v0 포맷은 그대로 유지되므로 발신자 측 마이그레이션은 필요 없다. 리스크는 읽는 쪽에 있다. RPC 소비자는 정수형 maxSupportedTransactionVersion을 1로 전달해야 하며, 그렇지 않으면 getTransaction은 오류 -32015를 반환하고, getBlock은 블록에 v1 트랜잭션이 단 하나라도 있으면 전체가 실패하며, blockSubscribe는 null을 반환한 채 정지한다. 실패가 조용히 일어날 수도 있다. v1은 컴퓨트 한도와 우선순위 수수료를 ComputeBudget 명령어가 아닌 transactionConfig 객체로 옮기기 때문에, 명령어 목록만 훑는 인덱서는 오류 없이 컴퓨트 예산 0을 기록할 수 있다. 최소 호환 버전은 @solana/kit 8.0.0, web3.js 3.0.0-rc.3, Rust 4.2.x, solders 0.29.0이며, Geyser 플러그인 15.1.1이 임시 다운그레이드 브리지를 제공한다.

(06:58 UTC 기준) 두 소식을 함께 놓고 보면 하나의 흐름이 읽힌다. Solana (SOL)는 처리량만이 아니라 상태 자체를 확장하고 있다. 트랜잭션당 용량은 3배 이상 오르고, 그 데이터를 영속화하는 비용은 90% 인하 방향으로 흘러간다. 그리고 두 변경 모두 복잡성을 외부로, 즉 호환성 부담을 떠안는 RPC 공급자와 인덱서 쪽으로 밀어낸다. 단기 리스크는 프로토콜 자체가 아니라 이 인프라 적응 지연이며, 그래서 단계적 활성화와 SIMD-0438의 롤백 레버가 중요하다. Lily Liu의 토큰 슈퍼사이클 논지를 다룬 우리의 기존 보도에서 논했듯, 상태 경제는 바로 알트코인 시장의 인프라 경쟁이 판가름 나는 지점이다.