Détails

Source

Helius

Publication

15 mai à 17h32

Lien direct

https://www.helius.dev/blog/agave-v4-0

Contenu source (brut)

<p>Many thanks to 0xIchigo and Brian Wong for reviewing earlier versions of this work.</p><h2>Introduction</h2><p>With Agave 4.0, Solana’s core validator client takes yet another step forward, improving core performance paths while preparing the network for larger blocks and the much-anticipated Alpenglow consensus update.</p><h3>Notable Agave 4.0 Release Cycle Updates</h3><ul class="list-bullet"><li value=1>XDP dramatically accelerates Turbine’s retransmit</li><li value=2>Lower-latency Replay Stage</li><li value=3>Alpenglow readiness: fast leader handover markers and chained block ID validation*</li><li value=4>Expanded cryptographic support: G2 arithmetic and BLS12-381 syscalls*</li><li value=5>Improved serialization with Wincode</li><li value=6>Minimum stake delegation increase with Stake Program v5*</li><li value=7>Re-enabling the ZK ElGamal proof program*</li><li value=8>SBPFv3 program support*</li></ul><p></p><p>* feature-gated upgrades</p><p></p><p>Whether you’re a validator operator or developer, this guide gives you the updates and insights needed to make the most of the latest improvements. Each section of this article is self-contained, allowing readers to focus on the topics most relevant to them. </p><p></p><p>At the time of writing, Agave v4.0.0-rc.0 is considered a mainnet upgrade candidate (MUC), with Anza seeking volunteers to help bring the release to 25% of stake. Validators: it’s time to upgrade!</p><h2>XDP Ready for Wider Adoption</h2><p>XDP (short for eXpress Data Path) is the high-performance networking path that Agave uses to accelerate Turbine. It lets Agave load an <a href="https://github.com/anza-xyz/agave/tree/v4.0/xdp-ebpf"><span style="text-decoration: underline">eBPF program</span></a> close to the network interface card, allowing shred traffic to bypass much of the standard Linux packet-processing path.</p><p></p><p>This matters because Turbine becomes the main bottleneck as Solana pushes toward higher block limits. Leaders must fan out shreds to hundreds of peers, and large validators can already approach 150,000 outbound packets per second under current conditions. As the network moves toward the long-standing goal of 100 million CU blocks, packet dispatch and retransmit performance need to scale with execution throughput. XDP creates that headroom by making block propagation immensely faster.</p><p></p><p>With Agave 4.0, XDP is now ready for wider validator adoption. It has been stress-tested under various configurations, hardened further, and undergone additional routing improvements. Production results are immensely encouraging, with Turbine retransmit being orders of magnitude faster.</p><p></p><p><a href="https://x.com/i/web/status/2046822618406522925" target="_blank" rel="noopener noreferrer">View X post</a></p><p></p><img src="/_next/image?url=/api/media/file/transmit-stage-performance-comparison-agave-4-0.png&w=3840&q=90" alt="Transmit Stage Performance Comparison Agave 4.0" /><p></p><p>For further context on why XDP is such a significant improvement, see our previous <a href="https://www.helius.dev/blog/solana-performance-engineering#:~:text=So%2C%20when%20looking%20at%20the%20entire%20system%2C%20why%20is%20rewriting%20Turbine%20to%20use%20XDP%20such%20a%20big%20deal%3F%C2%A0"><span style="text-decoration: underline">interview with Anza engineer Alessandro Decina</span></a>.</p><h2>Faster Replay Stage</h2><p>Agave 4.0 speeds up replay by moving two expensive verification steps off the replay threads’ critical path. In v4.0, entry verification and transaction signature verification are both dispatched asynchronously, allowing replay to keep processing while background jobs confirm that the slot is valid.</p><p>The first change moves PoH entry verification into the background. Previously, replay verified the entry hash chain inline before continuing. A second change applies the same idea to transaction signatures, but with an important split: Agave now separates transaction hash/message verification from Ed25519 signature verification. The hash path still runs up front so transactions can be sanitized and executed safely, while the more expensive signature checks run in the background and are joined before the block is accepted.</p><p>The practical impact is a much less blocked replay stage, especially during busy slots where signature checks scale with transaction count.</p><h3>Further Adoption of Wincode</h3><p>Wincode is a serialization and deserialization library <a href="https://x.com/zbr0wn/status/1993747984006435032"><span style="text-decoration: underline">developed by Anza</span></a>, built for in-place initialization and direct memory writes to minimize intermediate buffering. It delivers <a href="https://youtu.be/dLNVmnW5izQ?si=ZNQGop1kyIjdH_LP&amp;t=215"><span style="text-decoration: underline">top-tier performance among Rust serializers</span></a> while remaining fully compatible with the more popular bincode.</p><p>In Agave 4.0, more performance-critical serialization paths are transitioning from bincode to wincode. Since nearly all data written to disk or sent over the network in Solana relies on bincode, optimizing these paths has a broad impact.</p><h2>Minimum Stake Delegation Increase (Stake Program v5)</h2><p>A significant update to the Stake Program is coming with Agave 4.0. This feature-gated change, outlined in <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0490-upgrade-stake-to-v5.md"><span style="text-decoration: underline">SIMD-0490</span></a>, is preparation for Solana’s broader drive to reduce stake bonds (AKA rent).</p><p>The most notable change is that <strong>the minimum stake delegation rises from 1 lamport to 1 SOL</strong>. This prevents the cost of creating and maintaining stake accounts from becoming too low as rent requirements decrease, which could introduce a potential attack vector. While many smaller stake accounts exist below this threshold, they account for only 0.02% of total active stake and will be grandfathered in once the update goes live.</p><p>The upgrade also cleans up several parts of stake account handling. It switches rent calculations to use the <a href="https://orbmarkets.io/address/SysvarRent111111111111111111111111111111111/history?hideSpam=true"><span style="text-decoration: underline">Rent sysvar</span></a> instead of relying on each account’s stored <strong>rent_exempt_reserve</strong>, makes sysvar account inputs optional for stake program operations, and rewrites the Split implementation to fix longstanding edge cases. </p><p></p><p>The validator operator community has expressed comfort with the new 1 SOL minimum. Tooling and dapps that interact with the stake program will need to check their logic to account for the new minimum.</p><h2>Improved Cryptographic Support </h2><p>Several feature activations throughout the Agave 4.0 release cycle aim to expand Solana’s native cryptographic capabilities, enabling better support for modern use cases, including ZK proofs and BLS signatures.</p><h3>Re-enabling the ZK ElGamal Proof Program</h3><p>The <a href="https://github.com/solana-foundation/solana-improvement-documents/pull/153"><span style="text-decoration: underline">ZK ElGamal Proof program</span></a> is a native Solana program that verifies zero-knowledge proofs used in Token-2022 confidential transfers, enabling validation of encrypted balances and transactions without revealing the underlying data. It serves as a generalized verifier for ElGamal-based cryptographic proofs, forming a key component of Solana’s privacy-preserving token functionality. </p><p>The program was disabled on mainnet following a <a href="https://solana.com/news/post-mortem-june-25-2025"><span style="text-decoration: underline">June 2025 security incident</span></a>, in which a flaw in the proof verification logic, specifically a missing element in the Fiat-Shamir transcript hashing, made it possible to construct forged proofs