솔라나 거래 처리 용량이 세 배로 증가

솔라나 거래 크기 상한 1232바이트에서 4096바이트로 확대 추진

솔라나가 한 번의 트랜잭션에 담을 수 있는 데이터 크기를 기존 1232바이트에서 최대 4096바이트로 확대하는 Transaction v1 도입을 준비하고 있다. 거래당 데이터 공간이 약 3.3배 늘어나면서 지금까지 여러 건으로 나눠 처리해야 했던 복잡한 작업이나 대규모 암호학 증명을 하나의 원자적 트랜잭션에 담을 수 있게 된다.

이번 변경은 SIMD-0296과 SIMD-0385를 통해 설계됐다. SIMD-0296은 거래 크기 상한을 4096바이트로 높이는 내용을 담고 있으며, SIMD-0385는 이를 실제로 사용할 새로운 v1 트랜잭션 형식을 정의한다. 제안 작성에는 솔라나 개발자 제이콥 크리치와 앤드루 피츠제럴드가 참여했다.

새로운 형식은 테스트 및 개발 환경에서 준비 작업이 진행되고 있으며 솔라나 재단은 메인넷 활성화를 위한 배포 절차를 진행하고 있다. 다만 기존 기사에서 거론된 수요일 적용 일정과 달리 솔라나 공식 기술 자료에서는 현재 기능 활성화를 대기 중인 상태로 표시하고 있으며, Agave v4.2를 통한 메인넷 적용 일정 역시 변동 가능한 대상으로 설명하고 있다.

기존 legacy와 v0 트랜잭션 형식은 그대로 유지된다. 따라서 모든 지갑이나 애플리케이션이 반드시 v1으로 이전해야 하는 것은 아니다. 1232바이트 이상의 공간이 필요한 서비스만 새로운 형식을 선택적으로 사용할 수 있다.

20년 가까이 사용된 인터넷 패킷 제약에서 벗어나

솔라나의 기존 1232바이트 제한은 블록체인의 연산 능력에서 나온 숫자가 아니라 초기 네트워크 전송 방식과 관련돼 있다. 솔라나는 안정적인 데이터 전송을 위해 IPv6의 최소 MTU인 1280바이트를 기준으로 패킷 크기를 제한했고, 네트워크 헤더 등을 제외한 뒤 실제 트랜잭션에 사용할 수 있는 공간을 1232바이트로 설정했다.

이 제한은 솔라나가 처음 설계됐을 당시에는 네트워크 안정성을 확보하는 데 적합했지만 이후 복잡한 온체인 애플리케이션이 늘어나면서 개발 제약으로 작용하기 시작했다. 대규모 서명이나 영지식증명, 복잡한 멀티시그 같은 데이터를 하나의 트랜잭션 안에 넣기 어려웠기 때문이다.

솔라나가 2022년 네트워크 전송에 QUIC를 도입하면서 기존 MTU에 맞춰 트랜잭션 전체를 하나의 패킷 안에 넣어야 할 기술적인 필요성도 줄었다. QUIC에서는 더 큰 데이터 스트림을 처리할 수 있기 때문에 프로토콜 차원에서 거래 크기를 확대할 수 있는 기반이 마련됐다.

4096바이트라는 새로운 상한도 임의로 선택된 것은 아니다. 솔라나 개선안에서는 4KB가 검증자 하드웨어에서 사용하는 일반적인 메모리 페이지 크기와 맞는다는 점을 고려했다. 이를 더 크게 확대하면 하나의 트랜잭션을 여러 메모리 페이지에 걸쳐 처리해야 해 검증자의 메모리 관리와 처리 비용이 커질 수 있다.

영지식증명과 대형 멀티시그 한 번에 처리

거래 크기가 확대되면 가장 직접적인 변화는 기존에 한 트랜잭션에 넣을 수 없었던 작업을 단일 거래로 처리할 수 있다는 점이다. 솔라나가 SIMD-0296에서 대표적으로 언급한 대상은 영지식증명과 대형 멀티시그, 새로운 암호학적 서명 방식이다.

Confidential Balances와 같은 기능에서 사용되는 일부 영지식증명은 기존 1232바이트 공간만으로 처리하기 어렵다. Winternitz 일회용 서명의 전체 데이터를 담거나 기업 환경에서 사용하는 중첩 멀티시그, 별도의 사전컴파일 기능이 없는 BLS 계열 암호학 서명을 온체인에서 사용하는 경우도 비슷한 제약을 받았다.

복잡한 결제에서도 활용 범위가 넓어진다. 여러 명의 승인이 필요한 거래나 다수 프로그램 호출을 묶은 작업, 일부 비공개 전송 기능을 지금보다 적은 수의 트랜잭션으로 구성할 수 있다. 여러 단계를 하나의 거래로 처리하면 중간 단계만 실행되고 나머지가 실패하는 문제도 줄일 수 있다.

솔라나 개발자들은 지금까지 거래 크기 제한을 우회하기 위해 Address Lookup Table이나 Jito 번들을 사용하는 경우가 있었다. 특히 Jito 번들은 여러 거래를 묶어 더 많은 데이터를 처리할 수 있게 하지만 프로토콜 자체의 단일 트랜잭션과 완전히 같은 원자성을 보장하는 구조는 아니다.

v1에서는 최대 거래 크기가 4096바이트로 늘어나는 동시에 하나의 트랜잭션에서 최대 64개 계정과 64개 명령을 사용할 수 있도록 설계됐다. 서명 수 상한은 기존과 동일한 12개다.

새로운 v1 형식 읽지 못하는 서비스는 업데이트 필요

기존 지갑과 애플리케이션이 당장 v1 거래를 생성할 필요는 없지만 블록체인 데이터를 읽는 서비스에는 별도의 준비가 필요하다. 메인넷에서 v1 거래가 실제로 생성되기 시작하면 RPC와 gRPC를 통해 트랜잭션을 수집하는 탐색기와 지갑, 거래 애플리케이션, 데이터 인덱서가 새로운 데이터 구조를 인식할 수 있어야 한다.

업데이트하지 않은 서비스는 v1 트랜잭션 데이터를 처리하지 못해 요청에 실패하거나 일부 항목을 잘못 표시할 수 있다. 특히 새로운 형식에서는 기존 거래와 데이터 배치 구조가 달라지기 때문에 우선순위 수수료와 같은 정보를 읽는 방식도 함께 변경된다.

Transaction v1은 기존 v0에서 사용하던 Address Lookup Table을 포함하지 않는다. v1에서는 더 커진 트랜잭션 공간을 활용해 필요한 주소 정보를 거래 안에 직접 넣는 방식을 사용한다. 기존 legacy와 v0는 계속 지원되기 때문에 Address Lookup Table을 사용하는 기존 애플리케이션이 즉시 작동을 멈추는 것은 아니다.

대형 트랜잭션은 네트워크 대역폭과 검증자의 처리 자원을 더 많이 사용한다. SIMD-0296에서는 별도의 바이트당 기본 수수료를 신설하지 않지만 스케줄러가 더 큰 거래의 자원 소비를 반영해야 한다고 명시했다. 네트워크 혼잡 상황에서는 대형 거래를 빠르게 포함시키기 위해 더 높은 우선순위 수수료가 요구될 수 있다.

이더리움도 2027년 계정 추상화 개편 추진

솔라나가 단일 거래에 담을 수 있는 데이터 공간을 확대하는 동안 이더리움에서는 거래 수수료와 계정 사용 방식을 바꾸는 별도의 프로토콜 개편이 논의되고 있다. 중심에 있는 것이 EIP-8141 Frame Transaction이다.

EIP-8141은 거래를 여러 개의 프레임으로 구성하고 각 프레임에서 검증과 실행, 가스 결제를 유연하게 정의할 수 있도록 하는 계정 추상화 제안이다. 기존처럼 거래를 보내는 계정이 반드시 직접 ETH로 가스를 지불해야 하는 구조에서 벗어나 다른 계정이나 페이마스터가 비용을 부담하거나 별도의 수수료 결제 방식을 구성할 수 있도록 하는 것이 주요 목표 가운데 하나다.

이 구조가 적용되면 애플리케이션은 스테이블코인을 비롯한 다른 자산을 이용해 사용자의 가스 비용을 정산하는 서비스를 구현할 수 있다. 이용자가 이더리움 애플리케이션을 처음 사용하기 위해 별도로 ETH부터 확보해야 하는 절차를 줄이는 데 활용될 수 있다.

다만 EIP-8141이 2027년 예정된 Hegotá 업그레이드에 최종 확정됐다고 보기는 아직 이르다. 이더리움 공식 개발 현황에서 EIP-8141은 Hegotá의 비주요 기능으로 포함을 검토하는 CFI 단계에 있으며, 계정 추상화를 Hegotá에서 계속 개발한다는 방향이 정해진 상태다. Hegotá 자체 일정도 앞선 Glamsterdam 업그레이드의 개발 진행에 따라 변경될 수 있다.

솔라나는 복잡한 단일 거래 처리 범위 확대

솔라나와 이더리움이 추진하는 두 변경은 해결하려는 문제가 다르다. 솔라나의 Transaction v1은 한 번에 처리할 수 있는 거래 데이터의 물리적 한도를 직접 확대하는 데 초점이 맞춰져 있다. 기존 1232바이트 제한 때문에 여러 트랜잭션이나 별도의 우회 구조를 사용해야 했던 작업을 최대 4096바이트의 단일 거래로 옮기는 방식이다.

반면 이더리움의 EIP-8141은 한 거래에 담는 데이터 크기보다 계정이 거래를 승인하고 가스 비용을 부담하는 방식을 재구성하는 데 초점을 둔다. 솔라나는 복잡한 영지식증명과 멀티시그, 암호학적 서명 등을 하나의 원자적 트랜잭션으로 처리할 수 있는 공간을 확대하고, 이더리움은 계정 추상화를 프로토콜 내부로 가져오는 작업을 진행하는 셈이다.

솔라나의 4096바이트 Transaction v1은 기존 legacy와 v0 거래를 없애지 않고 추가되는 선택적 형식이다. 메인넷 활성화 이후에도 기존 형식은 계속 작동하며 더 큰 거래 공간이 필요한 개발자만 v1을 사용할 수 있다. 반면 지갑과 탐색기, 거래 서비스 등 솔라나 온체인 데이터를 읽는 인프라는 v1 거래가 등장하기 전에 새로운 형식을 처리할 수 있도록 업데이트해야 한다.