Solana Proposes 60M CU Block Limit to Boost Network Throughput

• Solana proposes increasing block limits to 60M CUs for higher transaction capacity.
• SIMD-0207 will roll out first with a smaller 50M CU increase.
• Validators must upgrade software to support new block size compatibility.

The Solana Foundation has put forward a proposal to increase its network’s block limit to 60 million Compute Units (CUs). This adjustment, aimed at boosting transaction capacity, follows an earlier proposal under SIMD-0207, which suggested a smaller increase from 48 million to 50 million CUs. The current proposal plans to push the limit further to accommodate rising network demands without compromising validator performance.

Increased Capacity Without Changing Key Constraints

According to a public improvement document on Github, the new proposal focuses exclusively on modifying the Max Block Units parameter. Other constraints, including Max Writable Account Units and Max Vote Units, remain fixed. Specifically, Max Writable Account Units will stay at 12 million CUs, while Max Vote Units hold at 36 million CUs. Additionally, the Max Block Accounts Data Size Delta will remain unchanged at 100MB.

By only modifying the Max Block Units , the network intends to add more room for non-vote transactions. At the same time, keeping individual account writing limits stable allows for continued transaction parallelism. Hence, while more activity can be packed into each block, the ability to write to a single account does not change. This proposed upgrade is designed to follow and not replace SIMD-0207.

According to the outlined plan, SIMD-0207’s smaller increase to 50 million CUs will roll out first. The intention is to monitor for any performance or structural concerns that may arise from increasing the longstanding 48 million CU cap. Consequently, the new 60 million CU proposal will act as a more aggressive follow-up, contingent on successful deployment and observation of SIMD-0207’s effects. 

Alternative Proposals and Network Considerations

An alternative plan considered was a much larger jump to 96 million CUs. However, this approach was rejected due to network stability and turbine performance concerns. The foundation noted potential issues within supporting infrastructure, including validator and user node performance.

The current phased approach ensures any network enhancements are aligned with observed performance metrics. Any unforeseen problems discovered during the initial increase can be resolved before applying the more significant 60 million CU limit. 
Following the change, more transactions will be accepted per block , improving overall throughput. However, blocks might take longer to process. Older software versions may also reject blocks that use the new limit. Therefore, validators must update their systems to maintain compatibility and stay in sync with the network.