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

소개

Agave 4.0을 통해 Solana의 핵심 검증인 클라이언트가 또 한 단계 발전합니다. 핵심 성능 경로를 개선하는 동시에 더 큰 블록과 많은 기대를 받는 Alpenglow 합의 업데이트에 대비합니다.

주요 Agave 4.0 릴리스 주기 업데이트

• XDP로 Turbine 재전송 대폭 가속
• Replay Stage 지연 시간 단축
• Alpenglow 준비: 빠른 리더 인계 마커와 체인형 블록 ID 검증*
• 암호화 지원 확대: G2 연산과 BLS12-381 syscall*
• Wincode를 통한 직렬화 개선
• Stake Program v5를 통한 최소 스테이킹 위임량 상향*
• ZK ElGamal 증명 프로그램 재활성화*
• SBPFv3 프로그램 지원*

* 기능 게이트가 적용된 업그레이드

검증인 운영자든 개발자든 이 가이드에서 최신 개선 사항을 최대한 활용하는 데 필요한 업데이트와 인사이트를 확인할 수 있습니다. 각 섹션은 독립적으로 구성되어 있어 가장 관련성 높은 주제에 집중할 수 있습니다. 

이 글을 작성하는 시점에 Agave v4.0.0-rc.0은 메인넷 업그레이드 후보(MUC)로 간주되며, Anza는 이 릴리스가 전체 스테이킹의 25%에 도달하도록 도울 자원자를 찾고 있습니다. 검증인 여러분, 이제 업그레이드할 때입니다!

더 폭넓은 도입을 준비한 XDP

XDP(eXpress Data Path의 약자)는 Agave가 Turbine을 가속하는 데 사용하는 고성능 네트워킹 경로입니다. Agave가 네트워크 인터페이스 카드 가까이에 eBPF 프로그램을 로드할 수 있게 해 샤드 트래픽이 표준 Linux 패킷 처리 경로 대부분을 우회하도록 합니다.

Solana가 더 높은 블록 한도로 나아가면서 Turbine이 주요 병목 지점이 되기 때문에 이는 중요합니다. 리더는 수백 개의 피어에 샤드를 분산해야 하며, 현재 조건에서도 대형 검증인의 초당 송신 패킷 수는 이미 150,000개에 근접할 수 있습니다. 네트워크가 오랜 목표인 1억 CU 블록을 향해 나아가려면 패킷 전송 및 재전송 성능이 실행 처리량에 맞춰 확장되어야 합니다. XDP는 블록 전파 속도를 크게 높여 이러한 여유를 확보합니다.

Agave 4.0에서 XDP는 이제 더 많은 검증인이 도입할 준비를 마쳤습니다. 다양한 구성에서 스트레스 테스트를 거쳤고, 안정성이 더욱 강화되었으며, 라우팅도 추가로 개선되었습니다. 프로덕션 결과는 매우 고무적이며, Turbine 재전송 속도는 수십 배 이상 빨라졌습니다.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

2026년 4월 22일 오전 5:25

XDP가 왜 중요한 개선인지 더 자세히 알아보려면 이전에 진행한 Anza 엔지니어 Alessandro Decina와의 인터뷰를 참고하세요.

더 빨라진 Replay Stage

Agave 4.0은 비용이 큰 두 가지 검증 단계를 replay 스레드의 주요 경로에서 분리해 replay 속도를 높입니다. v4.0에서는 엔트리 검증과 트랜잭션 서명 검증이 모두 비동기 방식으로 전달되므로, 백그라운드 작업이 슬롯의 유효성을 확인하는 동안에도 replay가 처리를 계속할 수 있습니다.

첫 번째 변경 사항은 PoH 엔트리 검증을 백그라운드로 옮깁니다. 이전에는 replay가 계속 진행하기 전에 엔트리 해시 체인을 인라인으로 검증했습니다. 두 번째 변경 사항은 같은 방식을 트랜잭션 서명에 적용하되 중요한 분리를 추가합니다. 이제 Agave는 트랜잭션 해시/메시지 검증과 Ed25519 서명 검증을 분리합니다. 해시 경로는 트랜잭션을 정리하고 안전하게 실행할 수 있도록 먼저 처리되며, 비용이 더 큰 서명 검사는 백그라운드에서 실행된 후 블록 승인 전에 결합됩니다.

실질적으로 replay stage의 차단이 크게 줄어듭니다. 특히 트랜잭션 수에 따라 서명 검사량이 늘어나는 혼잡한 슬롯에서 효과가 큽니다.

Wincode 도입 확대

Wincode는 Anza가 개발한 직렬화 및 역직렬화 라이브러리입니다. 제자리 초기화와 직접 메모리 쓰기를 지원하도록 설계되어 중간 버퍼링을 최소화합니다. 널리 사용되는 bincode와 완전히 호환되면서도 Rust 직렬화 도구 중 최고 수준의 성능을 제공합니다.

Agave 4.0에서는 성능이 중요한 더 많은 직렬화 경로가 bincode에서 wincode로 전환됩니다. Solana에서 디스크에 쓰거나 네트워크로 전송하는 거의 모든 데이터가 bincode를 사용하므로, 이러한 경로를 최적화하면 광범위한 효과를 얻을 수 있습니다.

최소 스테이킹 위임량 상향(Stake Program v5)

Agave 4.0에는 Stake Program의 중요한 업데이트가 포함됩니다. SIMD-0490에 설명된 이 기능 게이트 변경 사항은 스테이킹 보증금, 즉 임대료를 줄이려는 Solana의 광범위한 계획에 대비합니다.

가장 주목할 만한 변경 사항은 최소 스테이킹 위임량이 1 lamport에서 1 SOL로 상향된다는 점입니다. 임대료 요건이 낮아질 때 스테이킹 계정 생성 및 유지 비용이 지나치게 낮아져 잠재적인 공격 경로가 생기는 것을 방지합니다. 이 기준보다 적은 금액을 보유한 소규모 스테이킹 계정이 많지만, 전체 활성 스테이킹에서 차지하는 비중은 0.02%에 불과하며 업데이트가 적용된 후에도 기존 조건을 인정받습니다.

이번 업그레이드는 스테이킹 계정 처리의 여러 부분도 정리합니다. 각 계정에 저장된 rent_exempt_reserve에 의존하는 대신 Rent sysvar를 사용하도록 임대료 계산 방식을 전환하고, stake program 작업에서 sysvar 계정 입력을 선택 사항으로 변경하며, 오랫동안 남아 있던 엣지 케이스를 해결하도록 Split 구현을 다시 작성합니다. 

검증인 운영자 커뮤니티는 새로운 최소 기준인 1 SOL에 대해 수용할 수 있다는 입장을 밝혔습니다. stake program과 상호작용하는 도구와 dapp은 새로운 최소 기준을 반영하도록 로직을 점검해야 합니다.

향상된 암호화 지원 

Agave 4.0 릴리스 주기 전반에 걸쳐 활성화되는 여러 기능은 Solana의 네이티브 암호화 기능을 확장하는 것을 목표로 합니다. 이를 통해 ZK 증명과 BLS 서명 등 최신 사용 사례를 더 효과적으로 지원합니다.

ZK ElGamal 증명 프로그램 재활성화

ZK ElGamal 증명 프로그램은 Token-2022 기밀 전송에 사용되는 영지식 증명을 검증하는 Solana 네이티브 프로그램입니다. 기본 데이터를 노출하지 않고 암호화된 잔액과 트랜잭션을 검증할 수 있습니다. ElGamal 기반 암호화 증명을 위한 범용 검증기 역할을 하며, 개인정보를 보호하는 Solana 토큰 기능의 핵심 구성 요소입니다. 

이 프로그램은 2025년 6월 보안 사고 이후 메인넷에서 비활성화되었습니다. 증명 검증 로직의 결함, 구체적으로 Fiat-Shamir 트랜스크립트 해싱에서 한 요소가 누락되어 검증을 통과할 수 있는 위조 증명을 만들 수 있었습니다. 실제 악용 사례는 관찰되지 않았지만 잠재적 영향 때문에 기능 게이트를 통해 프로그램을 비활성화하고, 수정과 감사가 완료될 때까지 기밀 전송을 중단했습니다. 문제가 해결되고 구현의 안정성이 강화됨에 따라 이제 메인넷에서 프로그램을 다시 활성화할 예정입니다.

alt_bn128을 위한 G2 연산

SIMD-0302: alt_bn128 G2 Syscall 추가는 Solana의 기존 BN254(alt_bn128) 암호화 syscall을 확장해 덧셈, 뺄셈, 스칼라 곱셈을 포함한 G2 곡선 점의 네이티브 연산을 지원합니다. G1과 G2는 페어링 기반 암호화에 사용되는 두 타원 곡선 그룹이며, G2는 더 큰 확장 필드에 정의됩니다.

이는 주로 G1 연산에 집중된 현재 syscall 세트의 핵심 공백을 메우고, 페어링 기반 암호화를 온체인에서 직접 더 완전하게 지원합니다. 특히 BLS 서명 검증과 고급 ZK 증명 시스템 같은 사용 사례에 유용합니다.

네이티브 G2 지원이 없어 일부 프로젝트는 기존 syscall을 기반으로 Blueshift의 Dean Little이 구축한 엔드투엔드 BLS 서명 라이브러리인 solana-alt-bn128-bls 같은 커스텀 구현에 의존했습니다. syscall 수준에서 G2 연산을 활성화하면 이러한 우회 구현이 필요 없어져 Solana에서 프로덕션급 암호화 프로토콜을 네이티브로 더 쉽게 구축할 수 있습니다.

alt_bn128의 리틀 엔디언 지원

SIMD-0284: alt_bn128에 리틀 엔디언 호환성 추가는 Solana의 기존 alt_bn128 암호화 syscall을 확장해 리틀 엔디언 입력 및 출력 형식을 지원합니다. 이전에는 이 syscall이 빅 엔디언 인코딩만 허용해 도구와 라이브러리를 사용하는 개발자, 특히 Ethereum 생태계의 도구를 사용하는 개발자에게 불편을 초래했습니다. Solana의 ZK 팀 대부분이 리틀 엔디언으로 작동하는 ark-bn254를 사용하기 때문입니다. 이 변경 사항은 이전 버전과 호환되며 alt_bn128의 타원 곡선 연산과 관련된 기존 사용 사례에 대한 지원을 확대합니다.

BLS12-381 Syscall

마지막으로 SIMD-0388: BLS12-381 Syscall은 BLS12-381 타원 곡선의 암호화 연산을 네이티브로 지원해 최신 128비트 보안 수준의 페어링 친화적 곡선을 Solana 프로그램에 도입합니다. 지금까지 Solana는 페어링 기반 암호화에 BN254(alt_bn128)를 사용해 왔지만, 이는 해당 보안 표준을 충족하지 못하며 Ethereum처럼 널리 도입된 다른 생태계와의 호환성도 제한합니다.

이 업그레이드는 완전히 새로운 syscall 인터페이스를 도입하는 대신, 기존 곡선 syscall에 BLS12-381 G1 및 G2 연산을 위한 새 식별자를 추가합니다. 개발자는 익숙한 인터페이스로 그룹 연산, 점 검증, 압축 해제, 배치 페어링 검사를 수행할 수 있으며 암호화 기능도 크게 확장됩니다.

영지식 증명과 BLS 서명 검증을 전반적으로 개선할 뿐 아니라, 이 작업은 Alpenglow 합의를 구현하는 핵심 기반이기도 합니다. 특히 검증인이 BLS 소유 증명을 온체인에서 검증할 수 있어 악성 키 공격을 방지합니다. 이제 다음 섹션에서 자세히 살펴보겠습니다.

Alpenglow 준비

BLS12-381 syscall은 Agave 4.0 릴리스 주기에 활성화되는 여러 기능 게이트 중 하나로, Alpenglow 합의 업그레이드의 기반을 마련합니다. 아래에서는 출시에 기여하는 추가 활성화 항목을 소개합니다. 현재 Alpenglow는 Agave 4.1과 함께 2026년 3분기에 메인넷에 적용될 예정입니다.

체인형 블록 ID 검증

SIMD-0340: 체인형 블록 ID 검증은 TowerBFT와 Alpenglow 합의 모두에서 일관된 정식 체인을 보장하기 위해 검증인이 블록 계보를 검증해야 하는 방식을 정의합니다. 슬롯 번호만으로는 블록을 고유하게 식별할 수 없습니다. 특히 같은 슬롯에 여러 블록이 생성될 수 있는 이중 제안 상황에서는 클라이언트가 슬롯 순서에만 의존해 올바른 부모-자식 관계를 판단할 수 없습니다.

이 변경 사항은 각 블록이 부모를 올바르게 참조하도록 명시적인 체인 검증 규칙을 도입합니다. 분기를 방지하고 네트워크가 단일 기록으로 수렴하도록 돕습니다. TowerBFT에서는 FEC 세트가 슬롯 내부와 슬롯 간 모두에서 부모의 Merkle root를 참조하도록 요구합니다. Alpenglow는 슬롯의 모든 FEC 세트에 이중 Merkle root 구조를 사용합니다. 이러한 검사가 실패하면 해당 블록 또는 슬롯은 중단 상태로 표시됩니다. 이 규칙을 적용하면 합의 안전성이 강화되고, 검증인이 잘못되거나 충돌하는 블록을 수신해도 복구할 수 있습니다.

빠른 리더 인계 마커

SIMD-0337: Alpenglow 빠른 리더 인계를 위한 마커는 검증인이 부모 슬롯이 완전히 완료되어 안전하게 그 위에 블록을 구축할 수 있는 시점을 판단하도록 명시적인 신호 규칙을 정의합니다. 이는 빠른 리더 전환을 위한 전제 조건입니다. 이 변경 사항은 DATA_COMPLETE_SHRED의 배치 요건을 강화하고 새로운 “부모 준비 완료” 마커를 도입해 샤드 스트림 자체에서 블록의 완전성을 명확하게 감지할 수 있도록 합니다.

현재는 슬롯이 완전히 전송되었는지가 불명확해 다음 리더의 시작이 지연될 수 있습니다. 추가 샤드를 기다리거나 불완전한 데이터를 기반으로 블록을 구축할 위험을 감수해야 하기 때문입니다. 완료 신호 방식을 표준화하면 다음 리더는 별도의 조율이나 추측 없이 더 일찍 블록 생성을 시작할 수 있습니다.

이는 Alpenglow의 빠른 리더 인계 설계를 구성하는 핵심 요소입니다. 리더 간 공백을 최소화하면 네트워크 처리량이 직접 향상됩니다.

투표 트랜잭션 비용 모델 업데이트

SIMD-0458: 정적 SimpleVote 트랜잭션 비용 사용 중단은 투표 트랜잭션에 고정 CU 비용을 적용하지 않도록 변경해 비투표 트랜잭션에 사용되는 표준 트랜잭션 비용 모델과 일치시킵니다. 

현재 단순 투표 트랜잭션에는 결정론적 실행 비용에 관한 기존 가정을 바탕으로 3,428 CU가 고정 부과됩니다. 새 모델에서는 투표 트랜잭션도 다른 트랜잭션처럼 동적으로 측정되어 비용 계산의 일관성이 높아지고 별도의 Vote CU 한도가 필요 없어집니다.

투표 트랜잭션이 런타임에서 실제로 소비하는 CU는 동일하지만, 블록 패킹 중 계산 방식은 달라집니다. 특히 이제 투표에는 계정 데이터 로드 비용 등을 포함해 약 ~16,000 CU가 추정치로 추가되므로, 리더가 블록을 구성할 때 선점되는 CU가 증가합니다.

이 변경 사항은 Vote program의 실행 프로필이 고정되어 있다는 가정을 없앤 SIMD-0387(투표 계정의 BLS Pubkey 관리)을 따릅니다.

그 밖의 주요 업그레이드

Agave 4.0 릴리스 주기의 추가 주요 사항으로는 SBPFv3 프로그램 지원, 사전 자금이 입금된 계정 생성 기능, 스냅샷 압축 해제를 위한 직접 I/O가 있습니다.

SBPFv3 프로그램 지원

Agave 4.0 릴리스 주기에는 SBPFv3 프로그램의 배포와 실행을 지원하는 기능 게이트가 포함됩니다. Solana Berkeley Packet Filter(SBPF)는 Solana가 Rust를 기반으로 포크한 eBPF입니다. 온체인 프로그램이 실행 전에 컴파일되는 저수준 바이트코드 형식이자 가상 머신입니다. 이 업데이트는 SIMD-0178, SIMD-0189, SIMD-0377 등 세 가지 SIMD에 설명된 작업을 결합합니다. 

SIMD-0178은 정적 syscall을 도입해 syscall 참조가 런타임 ELF 재배치 대신 링크 시점에 해석되도록 합니다. 현재 이러한 재배치는 프로그램 로더를 복잡하게 만듭니다. 이를 제거하면 실행이 간소화되고 보안 위험이 줄어듭니다.

SIMD-0189는 프로그램에 허용되는 ELF 레이아웃을 강화합니다. 더 엄격한 파일 구조를 요구해 검증인이 파싱해야 하는 엣지 케이스와 처리해야 하는 예기치 않은 데이터를 줄입니다. 링커 도구 체인이 규격을 준수하는 바이너리를 자동으로 생성할 예정이므로 개발자에게는 별다른 영향이 없어야 합니다.

마지막으로 SIMD-0377은 32비트 점프 연산 같은 추가 명령어 지원을 포함해 SBPF 가상 머신이 LLVM에서 생성되는 최신 eBPF 명령어 세트와 더 잘 일치하도록 업데이트합니다. Solana VM과 업스트림 도구의 호환성을 높이는 동시에 프로그램을 더 효율적인 바이트코드로 컴파일하는 것이 목표입니다. 개발자는 애플리케이션 로직을 변경하지 않고도 프로그램 로딩 속도 향상, 공격 표면 축소, 컴퓨트 사용량 절감 가능성을 얻을 수 있습니다.

사전 자금 입금 계정 생성

SIMD-0312: CreateAccountAllowPrefund는 Agave 4.0 릴리스 주기에 메인넷에서 활성화될 예정입니다. system program에 새 명령어를 도입해 새로 생성되는 계정이 0 lamport 잔액으로 시작해야 한다는 요건을 없앱니다. 계정 생성 전에 자금을 미리 입금할 수 있어 일반적인 개발 워크플로가 간소화되고 불필요한 명령어가 줄어듭니다.

이전에는 대상 계정이 이미 lamport를 보유하고 있으면 CreateAccount 명령어가 실패했습니다. 그 결과 개발자는 계정 초기화를 여러 단계로 나눠야 했습니다. 일반적으로 전송 후 allocate와 assign을 수행해야 했기 때문에 복잡성이 증가하고 추가 컴퓨트 비용이 발생했습니다. 이 패턴은 계정에 자금을 미리 입금하는 프로그램에서 특히 흔합니다.

새 명령어는 사전 자금이 입금된 계정을 직접 초기화할 수 있도록 해 이러한 단계를 단일 호출로 통합합니다. 실제로 CPI 오버헤드를 줄이고 일반적인 흐름에서 수천 컴퓨트 유닛을 절약할 수 있어, 앞으로 개발자는 더 깔끔하고 성능이 뛰어난 경로를 사용할 수 있습니다. 기존 명령어를 수정하는 대신 새 명령어로 도입되므로 이전 버전과 완전히 호환됩니다.

스냅샷 압축 해제를 위한 직접 I/O 

Agave 4.0은 운영 체제 페이지 캐시를 통해 스냅샷 쓰기를 처리하는 대신 기본적으로 직접 I/O를 사용하도록 스냅샷 압축 해제 방식을 변경합니다. 이를 통해 시작 시간과 스냅샷 복원 성능을 개선합니다. 스냅샷 데이터는 일반적으로 디스크로 스트리밍되며 메모리에서 더 자주 사용되는 검증인 데이터를 밀어낼 필요가 없으므로 특히 유용합니다. 파일 시스템이 O_DIRECT를 지원하지 않는 경우 운영자는 --no-accounts-db-snapshots-direct-io를 사용해 이 기능을 비활성화할 수 있습니다. 향후 릴리스에서는 스냅샷 생성에도 직접 I/O가 적용될 예정입니다. 

결론

Agave v4.0은 다양한 성능 개선과 런타임 최적화를 제공하는 대규모 클라이언트 업그레이드입니다. 네트워크를 더 빠르고 안전하게 만들며 개발 편의성을 높이도록 설계된 변경 사항을 제공합니다.

다음 주요 이정표는 Agave 4.1과 Apenglow 합의 업데이트입니다.

추가 자료

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