Détails

Source

Helius

Publication

28 oct. à 00h00

Lien direct

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

Contenu source (brut)

<h2>Introduction</h2><p>With Agave 4.4, Solana’s core validator client builds on the <a href="https://www.helius.dev/blog/alpenglow">Alpenglow</a> rollout, simplifying block validation, streamlining staking reward calculations, and lowering the SOL required to store programs and account data. These changes improve day-to-day efficiency while laying further groundwork for asynchronous execution. The recent reduction of target slot times to 200ms shortens epochs to roughly one day, which enables an even faster cadence of feature gate activations.</p><h3>Notable Agave 4.4 Release Cycle Updates</h3><ul class="list-bullet"><li value=1><strong>Allow Invalid Fee Payers:</strong> A key step towards enabling asynchronous execution</li><li value=2><strong>Auto Program Resizing:</strong> Refunds surplus rent during program upgrades</li><li value=3><strong>Standardizing Shreds:</strong> Protocol now enforces 32-data, 32-coding FEC sets</li><li value=4><strong>Inactive Stake Cleanup:</strong> Excludes inactive stake from reward calculations</li><li value=5><strong>Rent Reduction:</strong> Final three planned stages of the 90% reduction in state bonds</li></ul><h2>Allowing for Invalid Fee Payers</h2><p>The feature gate activation of <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0290-relax-fee-payer-constraint.md">SIMD-0290: Relax Fee-Payer Constraint</a> is expected to go live during the Agave 4.4 release cycle. This changes what happens when a block contains a transaction whose fee payer fails validation, for example, because it has insufficient SOL. Previously, including such a transaction invalidated the entire block. Under the new consensus rules, the transaction remains in the block, and validators skip execution, making no changes to account state.</p><p>A fee payer’s balance may change as earlier transactions execute. Requiring every transaction to have a valid fee payer therefore means validators must execute some preceding transactions before they can determine whether a block is valid. Treating fee-payer failures as skipped transactions removes this particular dependency.</p><p>This is groundwork for asynchronous execution, where validators can agree on blocks and transaction ordering before completing execution. Execution proceeds separately, applying the agreed transactions to account state. Solana is moving toward this design to support future improvements such as shorter block times and <a href="https://www.helius.dev/blog/constellation">multiple concurrent block proposers</a>.</p><p>Agave represents these skipped transactions as no-ops: they execute no instructions and pay no fees. They still consume block capacity according to their full requested or default resource budgets, limiting how many a leader can include. The implementation also preserves the leader’s ability to filter them out during block production, even though validators can accept them when replaying a block.</p><p>SIMD-0290 applies specifically to transactions using a recent blockhash for their lifetime specifier. Durable nonce transactions require additional handling, addressed separately by <a href="https://github.com/solana-foundation/solana-improvement-documents/pull/297">SIMD-0297: Relax Invalid Nonced Transactions Constraint</a>. The change is fully backward compatible with all previously valid transactions and blocks remaining valid.</p><h2>Auto-resizing Programs on Upgrade</h2><p>Agave 4.4 will include a feature gate activation for <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0433-loader-v3-set-program-data-to-elf-length.md">SIMD-0433: Loader V3: Set Program Data to ELF Length</a>, which makes program upgrades automatically resize the account storing the program’s compiled code.</p><p>Loader v3 (i.e., the current default loader for deploying and upgrading Solana programs) stores a program’s compiled <a href="https://www.helius.dev/blog/solana-virtual-machine#elf">ELF binary</a> in a <code>ProgramData</code> account, alongside metadata such as its upgrade authority. Previously, developers could only extend this account but never shrink it. Upgrading to a smaller binary therefore left unused space, and the SOL required to keep that space rent-exempt remained locked in the account.</p><p>With this change, the <code>Upgrade</code> instruction resizes the account to the metadata header plus the new ELF’s length. A smaller binary releases surplus lamports to the upgrade’s spill account, the designated recipient for leftover funds. A larger binary automatically expands the account, removing the separate extension step for ordinary upgrades. The <code>ProgramData</code> and buffer accounts must already contain enough lamports to meet the new rent requirement; otherwise, the upgrade fails.</p><p>Developers adopting smaller binaries can therefore recover SOL during their next upgrade. Any previously reserved spare capacity is also removed. For upgrades invoked through CPI, the 10 KiB account-growth limit still applies: larger increases require prior extension or a top-level upgrade instruction. Developers should check their spill-account destination before upgrading to ensure refunds reach the intended recipient.</p><p>This change incentivizes developers to upgrade to newer, more performant libraries and frameworks such as <a href="https://www.helius.dev/blog/pinocchio">Pinocchio</a>. It also reduces the amount of space programs take up in Accounts DB.</p><h2>Standardizing Shreds</h2><p>Agave 4.4 includes a tightening of Solana’s block propagation rules outlined in <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0317-enforce-32-data-shreds.md">SIMD-0317: Enforce 32 Data + 32 Coding Shreds</a>. This standardizes the structure validators use to distribute and reconstruct block data.</p><p>Solana distributes blocks through <a href="https://www.helius.dev/blog/turbine-block-propagation-on-solana">Turbine</a>, which breaks block data into shreds and relays them through layers of validators. Shreds are grouped into forward error correction (FEC) sets, combining data shreds with coding shreds containing recovery information. With a correctly constructed 32-data, 32-coding set, a receiver can reconstruct the original data from any 32 of the 64 shreds, helping it tolerate packet loss.</p><p>Each shred also carries a Merkle proof linking it to the set’s Merkle root, which is authenticated by the leader’s signature. For a set of 64 shreds, that proof has six entries, corresponding to the six levels between a leaf and the root. Agave’s proof-size check requires the size expected for this fixed 32:32 structure.</p><p>Clients already produce 32 data shreds and 32 coding shreds per set, but receiving validators have historically accepted more flexible configurations. SIMD-0317 closes that gap by making the fixed 32:32 structure a protocol requirement. This simplifies validation: a receiver can determine valid shred-index boundaries without waiting for a coding shred to reveal the set’s dimensions.</p><p>The fixed structure also simplifies detection of equivocation, where a leader distributes conflicting versions of the same data. Two shreds belonging to the same FEC set, with different Merkle roots and valid leader signatures, provide evidence of that conflict. Standardizing the format therefore reduces implementation complexity while making equivocation easier to identify.</p><h2>Removing Inactive Stake from Reward Calculations</h2><p>The Agave 4.4 release cycle will include a feature gate activation for <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0599-rm-inactive-stakes-from-per.md">SIMD-0599: Remove Inactive Stakes from Stake Delegations</a>, which simplifies how validators handle inactive stake accounts during partitioned epoch rewards at the beginning of each epoch. Inactive stake accounts may hold