This is a weekly newsletter on the latest Solana engineering news this week. If you want to stay updated on Solana tech every week, follow Solana Changelog at @solana_devs and @readylayerone and turn on notifications.
Releases
Notable feature gates
Devnet
New versions
- Agave v4.4.0-beta.0
- Firedancer Mainnet Release v26.09.5
- Superbank v0.7.1-rc2, v0.7.0
- Web3.js v3.0.0-rc.1
- Kit v8.4.0
- Stake Program Rust SDK v5.1.0
- Memo Program Legacy JS SDK v0.3.1
- Token 2022 Program v11.1.0
- LiteSVM v0.17.0
Ecosystem work
SIMDs
-
A discussion was started to modify the Application Binary Interface (ABI) v1 to use registers r3-r5 as the place to load instruction pointers and metadata
- WTM (what this means) - An ABI defines where crucial data sits in memory as instructions within your transaction are being processed. The discussion is about using three reserved places in memory (the registers in the proposal) to store crucial data about the size of the instruction accounts and data and where they are located. Doing this allows for programs to do lookups instead of copying data from memory region to memory region, which is the much slower way the runtime does this today.
-
A proposal was made to make CPIs on the runtime saner and more performant
- WTM - Calling other programs on Solana requires a syscall (a specified operation on the runtime with a well-defined behavior and cost) that stores redundant account information in memory and transforms that information only to be transformed back again during processing. The change proposed here removes both the unnecessary transformation step and the duplicated memory allowing for runtime and space allocated to run an instruction.
-
An additional data field in the Vote Account for commission history was proposed
- WTM - Vote Accounts serve as the identity of validator nodes that support the network and contain information about stake, rewards and commissions. Changes will be made during Alpenglow that replace some of this information for the current epoch. This proposal restores that information in the Vote Account.
-
Adding location information to the Vote Account and making the leader schedule take geography into account during assignment was proposed
- WTM - The Leader Schedule defines when each validator node gets to build blocks during an epoch. This is usually determined randomly and the more stake a validator has, the more slots in an epoch it gets allocated to be leader and thus receive rewards. The benefit of making the leader schedule geographically-aware would be that users of the network have a greater chance of sending their transactions to a leader closer to that part of the world. See this visualization by @TheWattenhofer to see how leaders span the globe more broadly once this proposal is implemented:
Validator clients (Agave, Firedancer, Mithril)
- Agave plans to expose the Alpenglow rank map in its RPC methods API
- WTM - The RPC API allows validator operators to peer into the state of the network while operating. This change allows validator operators to serve the read layer (streaming service meant to push events to subscribers) giving them updates on the votes from vote accounts with a given certificate. Vote transactions are being removed from transactions and so votes by individual validators need to be parsed out from the certificates that are onchain.
- Improvements to shred ingest latency are being worked out in Agave
- WTM - The change described prioritizes shred ingest (receiving block data from the leader) over shred repair (requesting missing or broken block data from other validators). This approach gives more space for blocks to be received by non-leader nodes so that repair becomes more of a last resort.
- Contention on replay hashing and verifying is being reduced in Agave
- WTM - This change, like in the previous Changelog, is a more judicious use of the jemalloc arenas to allocate memory for easier use again for threads. In this case, it’s for the handoff between the hash and verification threads within the the replay service.
- More work to replace rayon with custom threadpooling is being implemented in Agave’s retransmit service
- WTM - Rayon is an off-the-shelf Rust crate that allows developers to create worker thread pools. Agave has found this to use more memory and compute than is actually required. A work-stealing pattern where jobs are placed in a queue and threads pick the jobs up on their own was used in other places of the Agave stack and is being used as a performance improvement in the Retransmit service as well.
- Agave is improving its slot repair service
- WTM - Repair is responsible for requesting missing shreds for a block from other validators in order to complete its own block for replaying and voting. This change is a simple optimization that skips attempting repair on slots whose shreds are already full (i.e. no shreds are missing). This is a relatively low-hanging optimization since it is work that no longer needs to be done.
- Airdrop on the Solana CLI will link to the Solana web faucet
- WTM - Airdrops are no longer supported on the Solana CLI and are only done today through the faucet.solana.com website. This change communicates this to users so that receiving test SOL on Testnet and Devnet becomes understood much more easily.
RPC 2.0
- Superbank is preparing its Alpenglow implementation
- WTM - An RPC is also an interface to validator stake and vote information. This change prepares Superbank as part of the RPC/read layer to serve requests to users related to Alpenglow primitives.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
- Seed length validation for PDA derivation is being added to the Solana Rust SDK
- WTM - Seeds serve as inputs to derive a program account address used to hold program state, etc. This change allows for additional checks before seeds are added as input to a helper function that derives a corresponding address.
Solana Program Library (SPL) and Core BPF
- The ed25519-programmatic-signer program will use V1 transactions exclusively
- WTM - Since the programmatic signer programs use a lot more cryptography, they will require a lot more transaction bytes to store the operations and execute. Using V1 transactions gives them the right space by default.
Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)
- Caravel is adding token program CPIs helper instructions
- WTM - Token Program helpers are standard in every program framework implementation. Caravel supporting these would make it more in line with other program frameworks like Anchor.
Other interesting things
-
@accretion_xyz wrote an essay about bugs program devs miss when upgrading their state accounts
-
@SteveCleanBrook hosted a Pirates Parley episode with the CEO of @accretion_xyz, @claudijd
-
@TheWatterhoffer published an article about efforts to reduce latency by switching to Alpenglow
-
@SolanaFnDn and @anza_xyz released a whiteboard session explaining how Alpenglow works
-
@clairefxyz published an article on her efforts to optimize compilation using error handling in p-token as an example
-
A new wallet CLI app was open sourced on Github https://github.com/ax-x2/solx
-
@0xnaga launched a site talking about MEV strategies on Solana
