Agave 4.2 업데이트: 알아야 할 모든 것

소개

Agave 4.2에서 Solana의 핵심 검증인 클라이언트는 다시 한번 새로운 지평을 엽니다. 이번 주요 릴리스는 많은 기대를 받은 세 가지 기능 게이트 기반 업그레이드에 초점을 맞춥니다. 200ms 슬롯 시간, 상태 보증금 90% 인하, 새로운 transaction v1 형식을 통한 4,096바이트 트랜잭션입니다. 또한 다음 릴리스에서 활성화할 예정인 Alpenglow의 모든 기능을 미리 제공하며, XDP 전송은 이제 기본으로 활성화됩니다.

주요 업데이트

• 새로운 Transaction v1 표준으로 트랜잭션 크기 3.3배 확대 *
• 상태 보증금(임대료) 90% 인하 *
• 슬롯 시간 200ms로 단축 *
• Alpenglow 기능 구현 완료
• 새로운 거버넌스 도구(SIMD 관련)

* 기능 게이트 기반 업그레이드

더 큰 트랜잭션(Transaction v1)

Agave 4.2 릴리스 주기에는 오랫동안 유지된 1,232바이트 제한을 최대 4,096바이트로 확대하는 기능 게이트 활성화가 포함됩니다. SIMD-0296: 더 큰 트랜잭션 크기에 공식 정의된 이 상한은 약 3.3배 늘어난 것으로, SIMD-0385: Transaction V1 형식에서 도입된 새로운 transaction v1 형식에만 적용됩니다. 레거시 및 v0 트랜잭션은 변경 없이 계속 작동하며 기존 1,232바이트 상한이 유지됩니다.

개발자에게 이는 단순히 명령어 데이터를 위한 공간이 늘어나는 것 이상의 의미가 있습니다. 이전에는 하나의 트랜잭션에 담을 수 없었던 암호학적 증명, 멀티시그 승인, 대규모 계정 목록 및 기타 페이로드를 이제 프로토콜 네이티브 단일 원자적 작업으로 실행할 수 있습니다. 이 변경으로 Solana의 컴퓨팅, 계정, 서명 또는 명령어 수 제한이 늘어나지는 않습니다.

기존 1,232바이트 제한은 Solana의 초기 네트워킹 아키텍처에서 비롯됐습니다. 트랜잭션은 개별 UDP 데이터그램으로 전송됐으며 IPv6의 최소 최대 전송 단위(MTU)인 1,280바이트 안에 들어가야 했습니다. 40바이트 IPv6 헤더와 8바이트 UDP 헤더를 제외하면 트랜잭션 자체에는 1,232바이트가 남았습니다. 모든 트랜잭션을 단일 패킷에 유지하면 단편화를 줄이고 전송 예측성을 높일 수 있었습니다.

Solana는 이미 오래전에 UDP에서 트랜잭션 수집용 QUIC으로 전환했습니다. QUIC 스트림은 단일 네트워크 데이터그램의 페이로드로 제한되지 않으므로 기존의 1,232바이트 상한은 더 이상 필요하지 않습니다. 클라이언트에는 여전히 수신 제어, 메모리 할당, 합의 검증을 위한 명시적 상한이 필요합니다. 하지만 이제 IPv6 MTU가 아니라 런타임과 애플리케이션 요구 사항에 따라 상한을 정할 수 있습니다.

계정 목록은 기존 크기 할당량의 상당 부분을 차지하는 경우가 많습니다. 각 Ed25519 공개 키 또는 프로그램 파생 주소는 32바이트를 차지하며, 트랜잭션은 명령어가 읽거나 수정하는 모든 계정을 식별해야 합니다. 이로 인해 이전에는 완전한 계정 키를 약 32개까지만 넣을 수 있었습니다. 이를 해결하기 위해 V0 트랜잭션은 각 32바이트 키를 1바이트 테이블 인덱스로 대체하는 Address Lookup Tables(ALTs)를 도입했습니다. 이를 통해 트랜잭션은 런타임의 계정 64개 제한까지 사용할 수 있습니다.

ALT는 효과적인 압축 방식이지만 안타깝게도 복잡성도 더합니다. 애플리케이션은 온체인에서 조회 테이블을 생성하고 관리해야 합니다. 원시 v0 메시지를 디코딩하는 RPC 서비스와 인덱서는 트랜잭션 메타데이터 또는 관련 테이블 상태를 사용해 전체 계정 목록을 재구성해야 합니다. 참조한 ALT가 이후 닫혀 더 이상 온체인에서 제공되지 않는 트랜잭션을 파싱할 때 문제가 발생합니다. 

v1 트랜잭션은 현재 ALT를 통해 지원되는 전체 계정 집합을 담을 만큼 큽니다. 완전한 공개 키 64개가 2,048바이트를 차지합니다. 따라서 v0에서 마이그레이션하는 애플리케이션은 조회 테이블 항목을 해석한 뒤 생성된 주소를 v1 트랜잭션에 직접 포함할 수 있습니다.

또한 1,232바이트의 트랜잭션 크기는 네이티브 프리컴파일이 없는 영지식 증명 및 BLS 구현과 같은 암호학적 기능에 특히 제약이 큽니다. 이러한 워크로드에는 수백 또는 수천 바이트의 증명이나 서명 데이터가 포함될 수 있습니다. 4,096바이트 상한은 일반적인 암호학적 사용 사례를 다수 수용합니다. 

Transaction V1 사양

직렬화된 v1 트랜잭션은 버전 바이트 0x81로 시작합니다. 그 뒤에 3바이트 레거시 형식 메시지 헤더, 32비트 트랜잭션 구성 마스크, 32바이트 수명 지정자, 명령어 및 주소 수, 전체 32바이트 주소 배열, 구성 값, 고정 크기 명령어 헤더, 연속된 명령어 페이로드, 마지막으로 서명이 이어집니다. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

명령어 헤더는 프로그램 계정 인덱스, 명령어 계정 수, 명령어 데이터 길이를 명시적으로 식별합니다. 따라서 각 명령어의 페이로드를 해석하지 않고도 메시지 경계를 파악할 수 있습니다.

V1 트랜잭션은 계속해서 서명 12개, 계정 주소 64개, 명령어 64개, 명령어당 계정 인덱스 255개로 제한됩니다. 대규모 트랜잭션도 요청된 컴퓨팅 유닛 제한, 로드된 계정 데이터 제한, 계정 잠금 규칙 및 블록에서 사용 가능한 실행 용량 안에 들어가야 합니다.

기존 파서는 v1을 최대 길이만 늘어난 v0으로 취급할 수 없습니다. 직렬화된 트랜잭션을 검사하는 인덱서, RPC, SDK 및 서명 인프라는 0x81 접두사를 인식하고 새로운 필드 순서를 구현해야 합니다. 특히 v1 서명은 레거시 및 v0 트랜잭션처럼 메시지 앞이 아니라 트랜잭션 끝에 배치됩니다.

Transaction v1은 Compute Budget 프로그램 구성 명령어를 트랜잭션 헤더의 필드로 대체합니다. 초기 `TransactionConfigMask`에서는 다음 항목을 선언할 수 있습니다.

• lamport 단위 총 우선순위 수수료
• 컴퓨팅 유닛 제한
• 로드된 계정 데이터 크기 제한
• 요청된 힙 크기

설정된 각 비트는 함께 제공되는 4바이트 구성 값을 식별하며, 64비트 우선순위 수수료는 마스크 위치 두 개를 차지합니다. 이 마스크는 향후 트랜잭션 버전에서 확장할 수 있도록 설계됐습니다.

상태 보증금(임대료) 인하

일반적으로 ‘임대료’라고 부르는 높은 상태 보증금 요건은 계정을 많이 사용하는 애플리케이션이 겪는 Solana의 가장 큰 마찰 요인 중 하나입니다. 임대료는 반복해서 지불하는 스토리지 수수료가 아니라 계정 상태가 온체인에 유지되는 동안 보유해야 하는 환급 가능한 보증금이므로 명칭이 다소 오해를 부릅니다. 계정을 닫으면 일반적으로 lamport를 회수할 수 있지만, 그전까지는 개발자나 사용자가 선불로 제공해 묶어둬야 하는 자본입니다.

Agave 4.2에는 SIMD-0437: lamports_per_byte를 696까지 점진적으로 인하의 기능 게이트 기반 구현이 도입됩니다. 이에 따라 `lamports_per_byte` 상수는 6,960에서 696으로 낮아집니다. 임대료가 90% 인하되는 것입니다. 더 정확히는 임대료 면제 최소 잔액이 줄어듭니다. 이는 6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696의 독립적인 기능 게이트 5개를 통해 적용됩니다. 

게이트 중 하나가 활성화되면 Agave는 Bank의 임대료 구성을 업데이트하고 Rent sysvar를 통해 새 값을 게시합니다. 단계적 출시는 네트워크가 각 가격 수준에서 애플리케이션의 반응을 관찰하고, 상태 증가나 검증인 리소스 사용량이 우려될 경우 다음 인하 전에 중단할 수 있게 합니다.

계정의 임대료 면제 최소 잔액은 할당된 데이터 크기에 고정된 128바이트 스토리지 오버헤드를 더해 계산합니다.

minimum_balance = (128 + account_data_size) × lamports_per_byte

이 변경에서도 임대료 메커니즘 자체는 바뀌지 않습니다. 계정에는 여전히 최소 잔액이 필요하며 계정을 닫으면 해당 잔액을 회수할 수 있습니다. 보증금으로 묶어야 하는 SOL의 양만 달라집니다.

표준 SPL Token 계정은 165바이트입니다. 128바이트 오버헤드를 포함하면 유효 크기는 293바이트입니다. 임대료가 90% 인하되면 이러한 계정에 필요한 SOL 비용이 약 ~$0.16에서 2센트 미만으로 줄어듭니다. 

이는 스테이블코인 결제, 토큰 배포, 로열티 시스템, 직접 에어드롭에 특히 중요한 영향을 줍니다. 지갑은 SPL 토큰을 직접 보유하지 않습니다. 일반적으로 각 민트마다 Associated Token Account (ATA)가 필요합니다. 수신자에게 필요한 ATA가 아직 없다면 송신자가 전송과 함께 생성할 수 있지만, 수신자의 임대료 면제 잔액도 충당해야 합니다. 이는 이후 결제 때마다 지불하는 비용이 아니라 각 지갑과 민트 조합에 한 번만 드는 온보딩 비용입니다. 하지만 규모가 커지면 기업이 온보딩 비용을 지원할지 사용자에게 전가할지를 결정할 만큼 큰 금액이 될 수 있습니다.

Solana의 상태 증가

단계적 인하가 중요한 이유는 상태 보증금을 낮추면 공격자가 불필요한 상태를 생성하고 유지하기 위해 묶어야 하는 금액도 줄어들기 때문입니다. Solana 상태는 복제되고 인덱싱되며 스냅샷에 포함되고 모든 검증인이 유지합니다. 따라서 영구적인 상태 증가는 결국 디스크 요구 사항, AccountsDB 작업, 나아가 운영 비용에 영향을 줍니다.

Solana Foundation의 최근 분석에 따르면 AccountsDB 스토리지 파일은 권장 할당량 1TB 중 약 495GB를 차지합니다. 계획된 임대료 인하 후 공격자가 남은 용량을 모두 소진하려면 약 1,720만 달러 상당의 SOL을 투입해야 합니다. 권장 검증인 스토리지 할당량을 2TB로 두 배 늘리면 공격자에게 필요한 자본은 5,100만 달러로 증가합니다.

새 계정 생성과 기존 계정 폐쇄를 모두 고려했을 때 상태는 하루에 약 0.3GB씩 증가하는 것으로 나타났습니다.

에포크 997에서 생성된 상태 스냅샷은 상태 사용량이 극도로 집중돼 있음을 보여줍니다. SPL Token 계정이 가장 큰 범주였으며, OpenBook과 Serum 계정은 활성 상태의 약 30%를 차지했습니다. 이는 온체인 오더북의 복잡한 아키텍처를 반영합니다. 또한 분석에서는 SPL Token 공간의 약 30%가 Pump.fun 토큰 런치패드 유형의 자산과 관련된 것으로 추정했습니다.

안전 조치

상태 보증금을 안전하게 낮추려면 반대 방향으로 되돌릴 수 있는 실행 가능한 경로가 필요합니다. 런타임을 추가로 변경하지 않은 채 나중에 임대료 면제 최소 잔액을 높이면 기존 계정은 즉시 새 기준에 미달하게 됩니다. 해당 계정에 쓰기 잠금을 거는 트랜잭션은 추가 상태를 할당하지 않더라도 실패할 수 있으며, 이는 광범위한 장애로 이어질 수 있습니다.

이를 위해 SIMD-0392: 임대료 인상에 맞춘 런타임 조정은 실행 후 최소 잔액 규칙을 변경해 임대료가 오를 때 기존 계정에 종전 규칙을 적용할 수 있도록 합니다. 계정이 이미 존재하고 크기가 늘어나지 않으며 소유자가 그대로라면 허용되는 최소 잔액은 다음 중 더 낮은 값이 됩니다.

1. 현재 임대료율에 따른 최소 잔액
2. 계정의 실행 전 잔액

새 계정은 계속해서 현재 임대료 면제 최소 잔액을 충족해야 합니다. 할당된 크기를 늘리거나 소유자를 변경하는 계정도 마찬가지입니다. 잔액 0은 계속 계정 폐쇄를 의미합니다. 따라서 기존 상태는 이전 보증 금액으로 계속 운영할 수 있고, 새로 할당된 상태에는 최신 요율이 적용됩니다.

SIMD-0438: 임대료 면제 최소 잔액 인상을 위한 안전장치는 `lamports_per_byte`를 기존 값인 6,960으로 복원하는 별도의 보호용 기능 게이트를 추가합니다. 임대료 인하로 과도한 상태 증가나 기타 중대한 운영 문제가 발생할 때만 활성화하도록 설계됐습니다. 인하가 시작되기 전에 게이트가 마련되므로 상태 증가 사고가 발생하는 도중에 핵심 개발자가 새로운 합의 변경을 설계하고 검토한 뒤 배포할 필요가 없습니다.

5개의 인하 게이트, SIMD-0392의 종전 규칙 적용 조항, SIMD-0438의 복구 수단이 함께 작동해 프로토콜 수준에서 출시를 되돌릴 수 있습니다. 네트워크는 보증금을 점진적으로 낮추고 활성 상태와 검증인 스토리지의 동작을 관찰할 수 있습니다. 중간 값에서 중단하거나 모든 기존 계정에 즉시 잔액 추가를 요구하지 않고 원래 요건을 복원할 수도 있습니다.

200ms로 단축된 슬롯 시간

Solana에서 가장 기대되는 성능 업그레이드 중 하나는 목표 슬롯 시간을 400ms에서 200ms로 줄이는 것입니다. 가장 큰 이점은 지연 시간 감소입니다. 슬롯이 200ms가 되면 Solana의 4슬롯 리더 구간은 1.6초에서 800ms로 줄어듭니다. 확인 시간이 단축되고 악의적인 리더가 트랜잭션을 지연하거나 순서를 바꾸거나 선택적으로 포함할 수 있는 시간도 제한됩니다. 슬롯이 짧아지면 오라클 소비자와 마켓 메이커 같은 애플리케이션도 더 세밀한 온체인 타이밍을 활용할 수 있습니다.

이 제안은 Solana의 기존 경제 구조와 처리량을 유지하도록 설계됐습니다. 인플레이션 매개변수, Alpenglow의 Validator Admission Ticket 비용, 슬롯당 작업 제한이 비례해 조정됩니다. 다만 Alpenglow보다 200ms 슬롯이 먼저 도입되면 검증인이 두 배 더 자주 투표해야 하므로 검증인 투표 비용이 약 두 배로 늘어날 수 있습니다.

200ms 슬롯에 관한 자세한 내용은 Agave 4.1 분석의 이전 보도를 확인하세요.

기타 주요 업데이트

Agave 4.2 릴리스 주기에는 규모는 작지만 주목할 만한 여러 개선 사항이 활성화될 예정입니다.

Alpenglow 준비 상태

Agave 4.2는 Alpenglow의 모든 기능을 제공하지만 새로운 합의 프로토콜을 메인넷에서 활성화하지는 않습니다. 핵심 엔지니어링 팀은 Agave 4.3에서 진행될 것으로 예상되는 합의 마이그레이션에 앞서 이번 릴리스 주기에 추가 테스트, 감사, 강화를 진행합니다. 따라서 4.2를 실행하는 검증인에는 Votor 투표 엔진과 BLS 인증서 검증 구성 요소를 포함한 전체 Alpenglow 구현이 이미 포함됩니다. 

코드 보안 검토를 확대하기 위해 Anza는 최대 50,000 SOL의 상금과 8월 5일부터 19일까지의 제출 기간을 제공하는 Alpenglow 버그 바운티 대회도 진행합니다. Alpenglow는 개발, 모노레포 마이그레이션, 내부 감사 기간에 기존 Agave 바운티 대상에서 제외됐습니다. 이번 대회를 통해 바운티 대상에 포함되며 이전 검토에서 놓쳤을 수 있는 문제를 찾는 것이 목적입니다.

Stake Program의 부동소수점에서 고정소수점으로 전환

Agave 4.2 릴리스 주기에는 SIMD-0391: Stake Program의 부동소수점을 고정소수점으로 전환의 기능 게이트 기반 구현도 포함됩니다. Stake Program의 워밍업 및 쿨다운 계산에 사용되는 IEEE-754 부동소수점 연산을 결정론적 고정소수점 정수 연산으로 대체합니다. 주된 목적은 부동소수점 연산을 지원하지 않는 표준 eBPF 도구 체인과의 호환성입니다. Solana의 SBF 도구 체인은 결정론적 소프트 플로트 루틴으로 이를 에뮬레이션할 수 있지만 비효율적이며, Stake Program을 `no_std` 구현으로 마이그레이션하는 데 걸림돌이 됩니다.

대부분의 애플리케이션은 변경할 필요가 없습니다. 다만 유효 스테이킹, 활성화 중인 스테이킹 또는 비활성화 중인 스테이킹을 독립적으로 재현하는 인덱서와 스테이킹 도구는 기능이 활성화된 후 새로운 정수 규칙을 구현해야 합니다.

새로운 거버넌스 도구

Agave 4.2 릴리스 주기에는 지난해부터 개발해 온 새로운 거버넌스 도구도 출시됩니다. 이 도구는 검증인과 네이티브 스테이커가 주요 경제 및 프로토콜 수준의 의사 결정에 대한 입장을 표시할 수 있는 온체인 절차를 제공합니다. 

핵심 구성 요소인 svmgov는 제안 생성, 지지, 스테이킹 가중 투표, 최종 확정을 관리하는 Anchor 기반 프로그램입니다. 투표 가중치는 Node Consensus Network (NCN)이 생성한 에포크별 스테이킹 스냅샷에서 가져옵니다. 독립 운영자는 스냅샷을 도출하고 표준 Merkle 루트에 합의한 뒤 이를 온체인에 게시합니다. 이후 검증인은 Merkle 증명으로 활성 스테이킹을 증명합니다. 

활성 스테이킹이 100,000 SOL 이상인 검증인은 제안을 생성할 수 있습니다. 제안이 투표 절차로 넘어가려면 클러스터 스테이킹의 15%가 지지해야 합니다. 거버넌스 저장소에는 투표와 지지 현황 추적을 위한 Rust CLI 및 웹 프런트엔드도 포함됩니다.

전체 제안 문서는 별도의 Solana Governance Proposals 저장소에 있으며 특정 Git 커밋에 고정됩니다. 온체인 제안 계정에는 링크, 수명 주기 상태, 투표 집계가 저장됩니다. 검증인은 처음에 자신에게 위임된 모든 스테이킹으로 투표하지만, 개별 위임자는 자신의 SOL에 대한 주권을 유지합니다. 스테이커는 특정 스테이킹 계정에 대해 재정의 투표를 제출해 해당 스테이킹을 검증인의 집계에서 제외하고 자신의 투표에 따라 다시 배분할 수 있습니다.

Solana Governance Proposals(SGPs)는 SIMD를 대체하는 것이 아니라 보완하기 위한 것입니다. SGP는 네트워크가 변경을 추진해야 하는지라는 방향성 질문에 답하고, 관련 SIMD는 해당 변경을 구현하는 방법을 명시합니다.

이미 3개의 SGP가 지지 단계를 통과했으며 새로운 시스템에서 첫 번째 거버넌스 투표가 진행됩니다.

• SGP-0001: Solana 헌장은 개발자, 검증인, 스테이커의 역할을 정의하고 SGP 절차를 공식적으로 확립하는 표준 거버넌스 사회계약의 비준을 제안합니다.
• SGP-0002: 디스인플레이션 두 배 확대는 최종 인플레이션율 1.5%는 그대로 유지하면서 SOL의 연간 디스인플레이션율을 15%에서 30%로 두 배 높일 것을 네트워크에 요청합니다. 이를 통해 최종 인플레이션율에 도달할 것으로 예상되는 기간을 약 5.7년에서 2.8년으로 단축합니다. 
• SGP-0003: 리소스 및 포함 수수료는 기존의 고정 기본 수수료 구조를 리더에게 지급되는 2,500lamport의 포함 수수료와 요청된 트랜잭션 비용 단위를 기준으로 산정해 전액 소각하는 별도의 리소스 수수료로 대체할 것을 제안합니다. 우선순위 수수료 배분은 변경하지 않습니다.

결론

Agave 4.2는 최근 Solana 릴리스 중 가장 큰 영향을 미치는 버전입니다. 더 빠른 200ms 슬롯은 네트워크를 실시간 응답성에 한층 가깝게 합니다. 예정된 상태 보증금 90% 인하로 계정 생성 비용은 대폭 낮아집니다. 4,096바이트 transaction v1은 복잡한 명령어, 암호학적 증명, 계정을 많이 사용하는 애플리케이션에 훨씬 넓은 공간을 제공합니다. 이러한 변경을 통해 Solana는 개발자와 사용자 모두에게 더 빠르고 저렴하며 표현력이 뛰어난 플랫폼이 됩니다.

추가 자료

• Agave 4.2 릴리스 일정
• 기능 게이트 추적기 일정
• Agave 4.2 변경 로그
• Agave 4.2 풀 리퀘스트