Optimizing Blocks on Solana.
Introduction
Extremely high utilisation of the Solana network has put the network's components to the test, particularly the transaction scheduler and priority fee implementation, both of which are crucial to block optimisation. Although the network has not changed during this spike in usage, there are a number of measures that developers and operators can take right now to guarantee that performance stays high. Additionally, there are changes in the works that will be included in the next software release to further enhance network application performance.
Actions to Improve the Network
Apply Priority Fees: A lot of applications developed on Solana platforms still do not utilise priority fees, which causes transactions to be discarded or delayed. Adding dynamic priority fees to dApps will assist in resolving problems with user experience. The integration is simple to use. Visit click here to learn more. Additionally, priority fees are being incorporated into the CLI for program deployment.
Optimise Program CU Usage: A transaction deducts the total amount of compute units (CU) available in a block upon network confirmation. Currently, a block's overall compute cap is 48M CU, and this cap is frequently reached during periods of high traffic. You can enhance the number of transactions that can land on the network by reducing the number of CUs used in your programs. Visit here to learn more.
CU Budget Request Optimisation: Developers have the option to set a compute unit budget for a particular transaction when it is presented to the network. The default figure, which is larger than what most transactions need, is utilised if no budget is given. Many transactions do not use the entire CU budget that is allotted to them because there is currently no penalty for requesting a greater budget than the transaction actually uses. Since the scheduler cannot determine how much compute remains in a block until the transaction is processed, requesting too much compute up front may result in poor transaction scheduling. Better scoped CU requests that adhere to transaction constraints should be implemented by developers.
Use Stake-Weighted QoS: As an extra sybil resistance mechanism, infrastructure providers should implement stake-weighted QoS, a core protocol feature that was implemented last year and enables block builders to identify and prioritise transactions proxied through a staked validator. Stake-weighted QoS guidelines will be available soon; when they are, they will be linked here.
