Contenu source (brut)
<h2>Introduction</h2><p>With Agave 4.1, Solana’s core validator client continues its steady evolution, delivering performance improvements today while laying the groundwork for larger blocks, 200ms slot times, and the eventual rollout of Alpenglow.<br></p><h3>Notable 4.1 Release Cycle Updates</h3><p></p><ul class="list-bullet"><li value=1>Faster release cadence, with major releases now every six weeks</li><li value=2>Continued Alpenglow readiness work, including BLS public key management*, Validator Admission Tickets*, and the community test cluster</li><li value=3>XDP adoption surpassing a critical network threshold</li><li value=4>Additional Pinocchio rewrites, including p-memo and p-ATA</li><li value=5>Reduced validator RAM usage</li><li value=6>Preparation for 200ms slot times**</li></ul><p></p><p>* Feature-gated upgrades</p><p>** Expected in Agave 4.2</p><p>Alongside the core client work, Anza and the broader ecosystem are also pushing forward on several major initiatives in parallel:</p><ul class="list-bullet"><li value=1><strong>Constellation:</strong> <a href="https://www.helius.dev/blog/constellation"><span style="text-decoration: underline">Constellation</span></a> proposes the first formal, protocol-level implementation of Multiple Concurrent Proposers (MCP) on a production blockchain at scale. Instead of giving a single leader broad discretion over transaction inclusion, Constellation introduces proposers and attesters that constrain what the leader can exclude from a valid block.</li><li value=2><strong>Quantum hardening:</strong> Anza’s research team has begun exploring <a href="https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary"><span style="text-decoration: underline">how Solana can be secured</span></a> against future quantum adversaries, including research around post-quantum signatures, account migration, consensus signatures, block propagation, and onchain signature verification.</li><li value=3><strong>Economic upgrades:</strong> A new wave of tokenomics proposals is also in the pipeline. SIMD-550 proposes <a href="https://www.helius.dev/blog/simd-550-solana-disinflation"><span style="text-decoration: underline">doubling Solana’s disinflation rate</span></a> from -15% to -30%, while <a href="https://github.com/solana-foundation/solana-improvement-documents/pull/553"><span style="text-decoration: underline">SIMD-553: Resource and Inclusion Fee </span></a>proposes splitting today’s signature fee into a base inclusion fee paid to the leader and a burned resource fee based on requested cost units.</li><li value=4><strong>New governance tooling:</strong> The next round of economic proposals is also being shaped by improved <a href="https://www.helius.dev/blog/solana-governance--a-comprehensive-analysis"><span style="text-decoration: underline">governance infrastructure</span></a>. New tooling allows not just validators, but also stakers, to participate directly in Solana governance, broadening who can weigh in on core protocol changes.</li></ul><p>There’s so much going on right now.</p><p></p><img src="/_next/image?url=/api/media/file/agave4-1-reduction-in-ram.png&w=3840&q=90" alt="Agave 4.1 Reduction in RAM Usage" /><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.1.0-rc.1 is now recommended for general use on mainnet. Validators, it’s time to upgrade!</p><h2>Alpenglow Readiness</h2><p>Much of the groundwork for the Alpenglow consensus upgrade is landing during the Agave 4.1 release cycle. These changes prepare the network for the transition from Tower BFT to Alpenglow, including BLS key management in the vote program, Validator Admission Tickets, and Fast Leader Handover markers.</p><h3>Community Test Cluster</h3><p>The remaining path to mainnet activation for Alpenglow now relies heavily on extensive real-world testing. Since May, a community test cluster of roughly 100 geographically distributed validators has been running the upgrade in a live network setting, testing the transition between Solana’s current Tower BFT-based consensus and Alpenglow ahead of mainnet activation.</p><p></p><p>The goal is to make the launch process as uneventful as possible. Validators on the cluster have been switching between Tower BFT and Alpenglow, exercising the migration path under real operator conditions rather than relying only on controlled internal testing. Discussions are taking place in the <a href="https://discord.com/channels/428295358100013066/1499484763361247392"><span style="text-decoration: underline">`ag-community-cluster` channel</span></a> in the Solana Tech Discord, and live cluster activity can be followed through community dashboards from <a href="https://ag.validblocks.com/"><span style="text-decoration: underline">Valid Blocks</span></a>, <a href="https://ag-community-status.stakingfacilities.com/"><span style="text-decoration: underline">Staking Facilities</span></a>, and <a href="https://solstat.noders.services/alpenglow"><span style="text-decoration: underline">Noders</span></a>.</p><p></p><img src="/_next/image?url=/api/media/file/alpenglow-test-cluster.png&w=3840&q=90" alt="Alpenglow Test Cluster" /><p></p><h3>BLS Pubkey Management</h3><p><a href="https://github.com/solana-foundation/solana-improvement-documents/pull/387/changes"><span style="text-decoration: underline">SIMD-0387: BLS Pubkey Management in Vote Account </span></a>will activate during the Agave 4.1 release cycle. This adds the <a href="https://github.com/anza-xyz/agave/pull/9310"><span style="text-decoration: underline">vote program plumbing</span></a> needed for validators to register BLS public keys in their vote accounts ahead of Alpenglow. Alpenglow uses BLS aggregate signatures to make votes cheaper to aggregate and verify, but BLS public keys are distinct from the Ed25519 vote authority keys used today. </p><p></p><p>Validators can add BLS public keys to their vote accounts while continuing to operate with their existing Ed25519 vote authority keys. Once Alpenglow is active, vote accounts without a registered BLS public key will not be able to participate in the new voting process.</p><h3>Alpenglow Validator Admission Tickets (VAT)</h3><p>The Agave 4.1 release cycle will also include the mainnet activation of <a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0357-alpenglow_validator_admission_ticket.md"><span style="text-decoration: underline">SIMD-0357</span></a>, which implements Validator Admission Tickets (VAT). VATs are designed to preserve a similar validator cost structure as Solana moves away from the current vote transaction model under Tower BFT.</p><p></p><p>Today, validators pay vote transaction fees continuously as they vote, adding up to ~2.1 SOL per epoch for validators that vote consistently. Under Alpenglow, those vote transactions are replaced by a new consensus design, so SIMD-0357 introduces a once-per-epoch admission cost instead. Each validator eligible to participate in Alpenglow voting pays a 1.6 SOL VAT per epoch, maintaining a comparable economic barrier while reducing the risk of an immediate, uncontrolled expansion of the validator set after Alpenglow launches.</p><p></p><p>Implementation is handled at the epoch boundary. When crossing into a new epoch, the runtime calculates the validator set for the next epoch, filters for vote accounts that have both a registered BLS public key and enough lamports to cover the VAT plus rent, and then deducts the VAT from accepted validators’ vote accounts. Those lamports are sent directly to the incinerator account. If more than 2,000 validators qualify, the voting set is capped by stake weight, with the top eligible validators selected.</p><p></p><p>
