The Solana network has been experiencing extremely high usage which has tested components of the network — specifically the implementation of priority fees and the transaction scheduler, both of which play important roles in block optimization. While the network has remained stable during this period of high usage, there are a number of tools developers and operators can implement today to ensure continued high performance, as well as additional changes in the works that will be released in the forthcoming software release to improve network application performance.
Immediate Actions to Improve Network Performance
- Implement Priority Fees: Many applications built on Solana today still do not make use of priority fees, resulting in delayed or dropped transactions. Integrating dynamic priority fees into dApps will help address user experience issues. It is a straightforward integration. Read more: https://solana.com/developers/guides/advanced/how-to-use-priority-fees.
- Priority fees are also being integrated into the CLI for use in program deployment.
- Exchanges can read use this updated guide for calculating priority fees: https://solana.com/docs/more/exchange#prioritization-fees-and-compute-units
- Optimize Program CU Usage: When a transaction is confirmed on the network, the transaction subtracts a number of total compute units (CU) available in a block. Today the total compute cap on a block is 48M CU, and during times of congestion this cap is often reached. Reducing the number of CUs used in your programs can increase the amount of transactions that can land on the network. Read more: https://solana.com/developers/guides/advanced/how-to-optimize-compute
- CU Budget Request Optimization: When a transaction is submitted to the network, developers can specify a compute unit budget for their specific transactions. If no budget is set, a default value is used, which is higher than most transactions require. As there is currently no penalty for requesting a higher budget than the transaction actually uses, many transactions do not use the entire CU budget they are allocated. Requesting too much compute upfront can lead to inefficient scheduling of transactions, as the scheduler does not know how much compute is left in a block until the transaction is executed. Developers should implement better scoped CU requests that match the transaction requirements.
- Use Stake-Weighted QoS: Infrastructure providers should adopt stake-weighted QoS, a core protocol feature introduced last year which allows block builders to identify and prioritize transactions proxied through a staked validator, as an additional sybil resistance mechanism. A guide to stake-weighted QoS is coming soon, and will be linked here once ready.
Upcoming Core Protocol Changes in v1.18
- The Transaction Scheduler: This component of the validator stack that helps efficiently and economically fill blocks is scheduled for improvement within the v1.18 software release, targeted for mid April. Changes to this component require careful testing. This new scheduler implementation will be introduced alongside the current scheduler in the v1.18 software release, but will not be enabled by default. Validator operators will be able to enable and monitor the performance of the new scheduler and easily failover back to the old scheduler if any problems are detected.
The Solana Foundation will continue to keep the community updated. For the latest information, please refer to the Solana Foundation's X account.
