Solana Developers Propose 20% to 25% Increase in Block Compute Units

Solana developers are actively exploring ways to enhance the network's efficiency and transaction capacity by increasing the Compute Units (CU) per block. Currently, Solana operates with a block limit of 48 million CUs, which functions similarly to Ethereum’s “Gas,” limiting transaction complexity and ensuring fair resource distribution.

Two recent Solana Improvement Document proposals, SIMD-0207 and SIMD-0256, outline potential adjustments to the CU limit. SIMD-0207 proposes a modest increase to 50 million CUs, while SIMD-0256 suggests a more significant jump to 60 million CUs. These adjustments aim to enhance the network’s transaction processing capacity while maintaining overall stability for validators and node operators. The primary goal is to allow more transactions to fit within each block, thereby reducing network congestion during peak usage and enhancing user experience by lowering transaction delays and failures.

However, increasing the block CU limit comes with potential risks. Heavier processing demands could slow block validation times, affecting smooth network synchronization across all nodes. Validators and infrastructure providers might need to upgrade their systems to handle the additional load efficiently. Additionally, unforeseen technical issues during the rollout could lead to temporary network instability.

Solana’s core developers favor a gradual, incremental approach to increasing the CU limit. This phased strategy allows developers and the validator community to carefully monitor network performance under incrementally higher loads. It provides opportunities to identify and address any emerging challenges before committing to further major capacity adjustments. This cautious approach is in contrast to a previously discussed conceptual target of 96 million CUs, which was considered too aggressive due to the risks of straining existing network infrastructure.

Other related block parameters, such as maximum writable account data units and maximum vote compute units, remain unchanged under these proposals. This helps prevent excessive strain on core network functions like state writing or consensus voting, while still permitting an increase in overall computational capacity. The proposals also support the execution of more computationally complex smart contract transactions within single blocks, accommodating future decentralized applications (dApps) that require significant on-chain processing power.