솔라나, 거래 v1 4,096바이트 확대…ALT 제거 상쇄

Solana Foundation은 2026년 8월 17일 Solana 거래 v1이 거래 크기 한도를 기존 1,232바이트에서 4,096바이트로 넓히는 한편, 주소 조회 테이블(Address Lookup Table·ALT)을 없애 계정 주소를 직접 담도록 설계됐다고 밝혔다.

v1은 더 복잡한 원자적 거래와 데이터 집약적 작업에 공간을 제공하지만, ALT가 압축하던 주소를 풀어 쓰면서 늘어난 용량 일부를 소모한다. 현재와 같은 64개 계정 한도도 유지돼 계정을 많이 쓰는 애플리케이션에는 계속 제약으로 작용할 수 있다.

ALT는 거래가 사용하는 계정 수를 줄이는 기능이 아니라 메시지에서 계정을 식별하는 데 필요한 바이트를 줄이는 방식이다. v0에서는 ALT를 통해 계정 하나를 약 1바이트의 조회 인덱스로 표현할 수 있지만, v1은 각 계정의 32바이트 공개 키 전체를 포함한다.

Solana Foundation이 30일간 거래의 16분의 1 표본을 분석한 결과, 관측된 v0 거래의 약 62%가 최소 1개의 ALT를 참조했다. 여러 ALT를 이용하는 밀집형 거래를 v1으로 변환하면 직렬화 크기가 1,500바이트 넘게 증가할 수 있다.

현재 거래의 절반은 v1 전환에 따른 추가 크기가 420바이트 미만이었고, 90%는 1,400바이트를 밑돌았다. Solana Foundation은 현재 작업량이 대체로 4,096바이트 한도와 양립할 수 있다고 평가했으나, 거래 구성 요소마다 확보되는 여유는 다르다고 설명했다.

상위 수준 명령어 수용 여력은 대체로 충분한 반면 계정 여유는 거래별 차이가 컸다. 64개 계정 한도가 바뀌지 않기 때문에 거래 크기가 커져도 계정 집약형 애플리케이션에서는 이 제한이 병목으로 남을 가능성이 있다.

v1은 수수료와 자원 요청을 거래 메타데이터에 직접 표시한다. 검증자는 이를 바탕으로 거래 우선순위를 더 일찍 정하고 블록을 효율적으로 구성할 수 있으며, 거래 수신 단계에서 상태에 의존하는 ALT 해석 절차도 제거한다.

기존 v0 거래에서 검증자는 완전한 계정 집합을 파악하기 전에 Bank와 AccountsDB에서 참조된 ALT를 불러와야 한다. 이어 조회 테이블 계정 소유자와 상태, 쓰기·읽기 전용 인덱스를 검증하고, 이를 전체 계정 주소로 변환해 정적 계정 키와 결합하는 과정을 거친다.

명령어 구조도 달라진다. 레거시와 v0 형식은 가변 길이 CompiledInstruction 객체를 순차 직렬화해 앞선 명령어를 읽거나 건너뛰어야 다음 명령어의 경계를 알 수 있다. v1은 고정 폭 명령어 헤더를 가변 길이 페이로드와 분리해 검증자가 명령어 경계와 전체 계정 집합을 더 일찍 확인하도록 한다.

수수료·자원 요청을 메타데이터로 옮기고 명령어 헤더와 페이로드를 분리하는 데 따른 크기 변화는 제한적이다. 반면 ALT 압축 제거로 늘어나는 바이트는 거래가 ALT에서 불러오는 계정 수에 따라 빠르게 커질 수 있어, v1의 구조 변경 가운데 계정 규모에 비례해 직렬화 크기를 실질적으로 늘리는 요인으로 꼽혔다.

ALT 하나를 넣는 데는 일반적인 인코딩에서 약 34바이트의 고정 비용이 들며, 이후 선택하는 쓰기 또는 읽기 전용 계정마다 약 1바이트가 추가된다. 적은 수의 테이블에서 많은 계정을 불러오는 밀집형 구성은 고정 비용을 분산해 압축 효과가 크지만, 여러 테이블에서 소수 계정을 가져오는 분산형 구성은 테이블 비용이 반복돼 효과가 작다.

표본의 현재 거래 크기 분포는 약 360바이트, 680바이트, 1,040바이트 부근에서 뚜렷한 봉우리를 보였고 1,232바이트 한도 가까이에도 거래가 몰렸다. Solana Foundation은 이를 서명, 계정 주소, 명령어와 ALT 사용 조합이 비교적 일정한 반복 거래 템플릿들이 섞인 결과로 해석했다.

정적 계정 키는 분포 대부분에서 가장 큰 직렬화 구성 요소였으며, 메시지에 직접 포함되는 계정마다 32바이트를 차지했다. 컴파일된 명령어는 두 번째로 큰 가변 요소지만, 직렬화 크기는 연산 소비량과 같지 않다. 작은 상위 수준 명령어가 많은 내부 명령어를 만들 수 있고 큰 데이터 페이로드도 크기에 정비례해 연산을 소비하는 것은 아니기 때문이다.

조회 항목 바이트의 밀도는 주로 약 540~940바이트 크기의 거래에 집중됐고 현재 거래 크기 한도 근처에도 일부 분포했다. 거래별 조회 항목 크기 분포에서는 0바이트에 큰 비중이 나타났는데, 여기에는 ALT를 사용할 수 없는 레거시 거래와 조회 항목이 없는 v0 거래가 포함된다.

60~1,232바이트 구간을 확대한 분포에서는 매끄러운 감소 대신 반복적인 봉우리가 나타났다. 이는 ALT를 추가로 참조할 때마다 드는 고정 비용과 선택 계정 인덱스마다 붙는 1바이트 비용을 반영한다.

지갑·SDK·RPC 제공자는 v1 직렬화와 디코딩, 거래 생성 기능을 새로 지원하고 ALT를 전제로 한 처리 방식을 없애야 한다. 트레이더·라우터·서처는 더 복잡한 원자적 경로를 구성할 수 있지만, ALT를 밀집해 쓰던 거래일수록 주소를 직접 넣는 데 새 바이트 예산을 더 많이 쓴다.

4,096바이트 한도는 프라이버시, 멀티시그, 암호 응용 분야에서 증명·서명 등 데이터가 큰 구조를 담을 여지를 늘린다. 다만 연산 한도와 계정 한도는 늘리지 않으므로 실제 추가 수용 능력은 거래가 사용하는 계정과 데이터 구성에 따라 달라진다.