Solana mainnet activated SIMD-0286, raising block limits to 100M CUs. This week also brought new Agave, Firedancer, Solana SDK, Subscriptions SDK, Caravel, LiteSVM, and Yellowstone Vixen releases, plus several proposals and client improvements across the developer ecosystem.
Releases
Solana mainnet activated a notable feature gate tied to block capacity.
- Mainnet activated SIMD-0286: Raise Block Limits to 100M CUs. View the feature gate account in Solana Explorer.
New versions
- Agave v4.2.0-rc.0, v4.3.0-alpha.2
- Firedancer Testnet v1.1.2
- Solana SDK (Rust) v4.1.0
- Subscriptions SDK (Rust) v0.4.1
- Caravel v0.5.1
- LiteSVM v0.15.0
- Yellowstone Vixen v0.7.0
Ecosystem work
SIMDs
- The proposal to double disinflation has been merged
What this means (WTM) - Disinflation is the rate at which Solana decreases the rate by which it mints more SOL via validator and staking rewards. By doubling the disinflation rate, Solana will reach its terminal inflation rate of 1.5% sooner rather than later. - Creating a Sysvar for epoch stakes was proposed
WTM - The stake values of each validator during an epoch represent how much of the leader schedule a validator node occupies, their share of the SOL rewards, and the weight of their voting power in Solana governance. This change creates a new account with data that will surface these values in the Solana runtime. - A discussion was started to unblock specific instructions from LoaderV3 from being called by other programs or itself
WTM - This proposal unlocks several restrictions that were previously made in SIMD-0219. In its place, the discussion is proposing a check between the program id and the account itself. This would enable use cases like programs that change other programs that deploy other programs, and other general program administration needs. - Allowing programs to work within the slot they were modified was proposed in a discussion
WTM - Programs are disabled by default during the slot they are deployed. This is an obvious footgun because it creates downtime for the program during the slot it’s changed every time it’s changed. This is against standard deployment practice where stateless software is expected to be deployed in infrastructure without any downtime as much as possible.
Validator clients (Agave, Firedancer, Mithril)
- Tightening Alpenglow block limits was proposed
WTM - These limits restrict the number of blocks that a validator can hold at any given time when participating in consensus. Validators ensure a higher chance of being able to participate in consensus by keeping multiple possible blocks instead of losing the chance to vote. A new Alpenglow paper with new limit thresholds will be released soon. This PR preempts that change. - Agave created a custom pool implementation for asynchronous transaction replay verification
WTM - Agave already tries to ensure that processing and executing transactions aren’t blocked by time and memory verifying transactions. This particular change moves that implementation from an off-the-shelf solution (Rayon) that isn’t purpose built for this use case to a custom queue and thread pool made for this purpose.This implementation purportedly would improve performance on transaction replay. - Agave will use an Anza fork of the rust-rocksdb interface
WTM - Forking dependencies onto your own organization allows teams to slim them down, customize them and add features that would otherwise not be added by the team upstream. This change allows Anza to maintain their independence with the option to upstream any improvements. In this particular instance, Agave wants to improve performance by using an in-house version of rust-rocksdb by minimizing memory allocations, et. - Preparations are being made to parallelize parsing transactions before loading them for ordering and execution
WTM - This change prepares Agave to validate incoming transactions in parallel before they are queued for ordering and execution in the Banking Stage. Previously, reserving storage, copying transaction data, and parsing it were tightly coupled on one thread, which is relatively slower. Transactions can now be shared with many more worker threads, which allow the validation to be shared across more compute. - Account hashing (on TPU and TVU) will be more performant on Agave
WTM - Account hashing occurs before account state to be updated in-memory in both the leader when it builds blocks, and in non-leaders when it validates blocks for execution and voting. By improving performance here, we minimize time and memory in this intermediate step and buy more time and memory for executing transactions. - Firedancer is creating an offline replay service
WTM - This service will allow Firedancer to test correctness between Agave and itself in order to ensure that consensus is tied between the two implementations. Together with the conformance work on the Agave side, this allows for better correctness between the two client implementations. - Mithril improved its implementation of ed25519 signature verification
WTM - ed25519 is the chosen signature scheme on Solana. All transactions have to be verified with this signature scheme. By implementing it correctly, Mithril can participate better as a validator node and will be in line with the other client implementations.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
- Solana Rust SDK adds support for more cryptography primitives as syscalls [1] [2]
WTM - Two SIMDs were previously opened to add the keccak_p1600 and big mod exp syscalls which support several cryptography operations on Solana. More of this work has to be supported on the Rust SDK, the validator client implementations, etc.
Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)
- Anchor is working to make its automatic updates safer
WTM - Because the `avm` and `anchor` CLI commands are critical infrastructure for a lot of users, it is important for updates to use sensible defaults. This change installs both stable avm and anchor commands by default with an opt-in option flag to install nightly updates.
Testing frameworks (mollusk, litesvm, surfpool)
- LiteSVM allows for configuring epoch stake numbers within its testing harness
WTM - With the upcoming governance votes and economics changes on Solana, it makes sense to be able to simulate how this would change stake values with every epoch. This addition to the test harness allows LiteSVM to be used for these use cases.
Other ecosystem updates
Builders and teams shared additional releases, discussions, dashboards, and research across RPC, developer education, testing, WASM clients, and zero-knowledge tooling.
- The Solana Foundation shared a data dashboard on RPC metrics.
- Helius released a Preconfirmations feature on its RPC.
- ChiiYuen led a discussion on the Firedancer paper.
- redacted_noah wrote about on-chain cranks and conditional execution.
- Jupiter DevRel released its monthly changelog.
- mctursh created a solution for historical account state.
- zelimir** shared a new hashing library with performance benchmark results.
- OkohEbina and a_ix_d published a new Devs at a Bar podcast episode.
- exoaursen released a new version of Spume, a WASM client for Solana.
- Blueshift released xark, a ZK-circuit prover.
- Blueshift released parallax, a fixture-based test harness built on LiteSVM.
Follow Solana developer updates
Catch up on last week’s issue, and follow @solana_devs for weekly Solana engineering updates.