Contenu source (brut)
<p>Many thanks to <a href="https://x.com/0xIchigo" rel="noopener noreferrer" target="_blank">0xIchigo</a> and <a href="https://x.com/0xbrw" rel="noopener noreferrer" target="_blank">Brian Wong</a> for reviewing earlier versions of this work.</p><h2>Introduction</h2><p>Agave v3.1, the latest evolution of the Solana Agave client, is here! This update introduces a broad set of upgrades that improve client performance, validator operations, and the developer experience. The update also includes several important feature gate activations that lay the groundwork for in-protocol block reward distribution, meaningful state bond (i.e., rent) reductions, and, most notably, the upcoming Alpenglow consensus upgrade.</p><h3>Notable Agave 3.1 Updates</h3><ul class="list-bullet"><li value=1>Reduced Disk I/O During Replay</li><li value=2>Faster Client Restarts</li><li value=3>2x Faster Transaction Processing</li><li value=4>Increased CPI Account Infos Limits*</li><li value=5>Validator Vote Account V4 and Delayed Commission Updates*</li><li value=6>Reduced Turbine ChaCha Rounds*</li><li value=7>New Instruction Data Pointer*</li><li value=8>RPC Improvements</li></ul><p>* feature-gated upgrade</p><p></p><p>Whether you’re a validator operator or developer, this guide offers 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 3.1.8 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>Client Performance Gains</h2><p>This major Agave release includes a range of performance gains. Below, we highlight several of the most important improvements.</p><h3>Reduced Disk I/O During Replay </h3><p>Agave 3.1 brings a major reduction in disk activity during replay. The image below shows a 10-second profiling window from replay with Agave 3.0 processing real mainnet transactions. Disk operations (shown as red markers) exceed 1,100 events. This is an issue because each disk hit introduces I/O wait time, adding jitter to both banking and replay. </p><p></p><img src="/_next/image?url=/api/media/file/agave-IOPS-during-replay.PNG&w=3840&q=90" alt="Agave IOPS during replay, a comparison of Agave 3.0 and Agave 3.1" /><p></p><p>With Agave 3.1, disk I/O during replay is dramatically reduced. The same 10-second window shows fewer than 80 disk operations, representing a 93% drop. This improves replay stability while reducing disk wear, helping extend disk lifespan.</p><h3>Faster Client Restarts</h3><p>Client restart performance continues to improve dramatically, primarily driven by optimizations to AccountsDB. With Agave 1.* major releases, restarts commonly took more than 30 minutes. Agave 2.* releases reduced this to under 10 minutes. Under Agave 3.1, restart times drop even further, now typically taking less than 1 minute. Looking ahead, the next major release, Agave 4.0, is expected to push restart times below 30 seconds, further improving validator uptime and reducing recovery time after maintenance or unexpected failures.</p><h3>Faster Transaction Processing</h3><p>Agave 3.1 includes key fixes that significantly improve transaction processing efficiency. Previously, bugs in the transaction processing pipeline caused banking workers to spend excessive time synchronizing with <a href="https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained#what-is-proof-of-history"><span style="text-decoration: underline">Proof of History</span></a> rather than executing transactions, so in leader mode, the client was not actively scheduling transactions for roughly 61% of the time.</p><p></p><p>With these issues resolved in Agave 3.1, banking worker threads now spend ~91% of their time processing transactions. As a result, transaction processing is twice as fast, materially improving throughput and better utilization of leader time.</p><p></p><img src="/_next/image?url=/api/media/file/agave-scheduler-profiling-comparison.PNG&w=3840&q=90" alt="Agave scheduler profiling, a comparison of Agave 3.0 and Agave 3.1" /><p></p><p>Other performance enhancements worthly of mentioning include keeping the accounts index entirely in memory by default. Epoch boundary transitions have also been significantly improved, <a href="https://x.com/vaddotsol/status/1987056008326152541"><span style="text-decoration: underline">now completing in under 400ms</span></a>, down from over two seconds, resulting in far fewer skipped slots during epoch rollovers.</p><h2>Network Hardening</h2><p>Anza invests heavily in resilience through continuous stress testing, red teaming, and real-time situation monitoring for the Agave client. While the details of this work have previously been kept confidential, the program has matured sufficiently that this important work can now be publicly acknowledged. A dedicated invalidator team at Anza actively attacks Solana’s public testnet with a new set of tests every hour. </p><p></p><p>Tests fall into two primary categories. The first focuses on network-layer denial-of-service scenarios, stress-testing backpressure handling, and load shedding under extreme conditions. The second form of tests involves producing curated blocks containing unusual and adversarial transactions designed to push the limits of the Solana VM.</p><p></p><img src="/_next/image?url=/api/media/file/Solana-testnet-node-flooded-with-gigabits-of-traffic.PNG&w=3840&q=90" alt="A Solana testnet node is flooded with gigabits of traffic, an attack pattern that previously would have knocked the node offline" /><p></p><p>Anza systematically builds attack scenarios and develops defenses against them. This work is grounded in realistic threat models based on what a malicious, well-informed, reasonably staked validator could do and what an external, well-capitalized, and sophisticated developer could attempt.</p><p></p><img src="/_next/image?url=/api/media/file/anza-invalidator-team-testnet-adversarial-transactions.PNG&w=3840&q=90" alt="Visualization of Anza invalidator team’s testnet adversarial transactions" /><p></p><p>This level of preparedness was validated in December, when Solana sustained a major DDoS attack that lasted for weeks, reportedly peaking at nearly 6 Tbps, making it one of the largest attacks ever recorded against a distributed system. Despite the immense scale,<a href="https://x.com/mert/status/2003282344485224692"><span style="text-decoration: underline"> the network showed little measurable impact</span></a>, with sub-second confirmations and stable slot latency throughout the attack period.</p><p></p><img src="/_next/image?url=/api/media/file/largest-documented-DDoS-attacks.PNG&w=3840&q=90" alt="Largest documented DDoS attacks" /><p></p><h2>Increased CPI Account Infos Limits</h2><p><a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0339-increase-cpi-account-info-limit.md"><span style="text-decoration: underline">SIMD-0339: Increase CPI Account Infos Limit</span></a> is set to activate on mainnet during the Agave 3.1 release cycle. This increases the cross-program invocation (CPI) account info limit by almost 4x, from 64 to 255, addressing a long-standing pain point for developers building programs that need to pass large account lists through CPIs. Account infos are the serialized account metadata passed into CPI syscalls, enabling the callee program to read the accounts provided by the caller.</p><p></p><p>Previously, CPIs were restricted to just 64 account infos per syscall. This constraint forces programs to deduplicate and reconstruct account lists prior to CPI calls, adding complexity and overhead. In practice, many real-world programs routinely exceed this threshold, for example, wrappers around DEX aggregators such as DFlow or Jupiter.</p><p></p><p>In addit
