Solana Tech Roundup

This past week the features that disallows new rent-paying accounts and enables dynamic account sizing went live. What this means is that any account you create in a program must be rent-exempt. When you can dynamically size accounts, changing your account becomes much simpler and allows for account migrations as a program upgrades. You can find a guide on account migrations here.

Upcoming Change

Fee Changes

There are a number of upcoming transaction fee changes coming, namely being able to prioritize transactions with an increased fee payment and increased fees for "hot" writable accounts.

You must use the ComputeBudgetProgram.requestUnits instruction from web3.js with the fee being higher than 0 for your compute usage to prioritize your transactions. This instruction must be one of the first three instructions on the transaction. Transactions are prioritized by highest fee/compute requested. You can find and example usage here.

You can use getFeeForMessage to understand the current network fee given your transaction message.

Commit Highlight

• Add partial curve25519 syscall support

This syscall is required for confidential transactions in token22. You can find token22 information and other feature information here.

List of Changes

May 6

• Explicitly remove accounts with zero lamports from stake cache
  • Stake Cache update partially relies on the accounts data which doesn't store 0 lamport accounts. Remove 0 lamport accounts by default from the stake cache as well
• Check account owner when initializing vote-accounts
• Speed up getting transaction compute costs
• Fail transaction sanitization when ix program id used lookup table
  • Static program ids are required so that estimated compute can be calculated

May 7

• Add partial curve25519 syscall support
  • Includes VRF verification, zk-token ops, nft transfer proof, and ed25519 signature verification
• Add sender stake to quic packets
  • This will be used to help manage stake weighted transaction processing in the future

May 8

• Greedy receive in banking stage
  • QUIC transaction are received as packet batches of size 1, causing sigverify and banking stages to back up. Greedy receive alleviates the back up.

May 10

• Add sanitized types for use in banking stage
  • Loading addresses from an on-chain lookup table is expensive, so for v2 transactions there is now a lightweight SanitizedVersionedTransaction for use in the banking stage
• Enable 0rtt
  • Zero round trip time on quic connections improves latency