Vitalik Buterin floats five designs to decrease Ethereum max block size

Ethereum co-founder Vitalik Buterin and the Ethereum Foundation are considering at least five ways to reduce Ethereum’s maximum block size in hopes to optimize the blockchain for the "rollup-centric roadmap."

On Feb. 5, Buterin and Ethereum Foundation researcher Toni Wahrstätter said that with the focus on rollups in the medium and long term, it is argued that the way block space is used is not yet optimized — noting that effective block size has essentially doubled over the past 12 months. 

“This might be a result of more and more rollups starting to use Ethereum for DA and trends like Inscriptions,” explained Buterin and Wahrstätter.

Reducing the maximum size of the "EL parts o Beacon blocks would make room for more blobs. Source: Ethereum Research

The blog post discusses five different solutions — varying in complexity — to increase block gas limits and disincentivize the use of calldata, which could then reduce maximum block size and variance to make room for more data blobs in the future.

By increasing the block gas limit and the price for nonzero calldata bytes, a smaller and less variable block size can be achieved, making space to add more blobs in the future.

The Ethereum gas limit refers to the maximum amount of gas spent on executing transactions or smart contracts in each block. A limit is set to ensure that blocks are not too large, which would impact network performance and synchronization. Calldata, which consumes gas, increases the load on the network, so solutions are being sought to increase the gas limit without compromising security.

One of the first, more simple solutions proposed by Buterin and Wahrstätter involves increasing the calldata cost from 16 to 42 gas, which would reduce the maximum block size from 1.78 megabytes to 0.68 megabytes. This would then make room to increase the block gas limit.

Buterin said there is a "sweet spot" between calldata price and gas limit. Source: Ethereum Research

However, Buterin argues this disincentivizes using calldata for data availability and would negatively impact apps like StarkNet that require large calldata for on-chain proofs.

Instead, a second solution could be to increase calldata cost but decrease other opcode costs.

Calldata refers to the data provided as input to a smart contract function call, while opcodes — or operation codes — are instructions that specify which computation should be performed in the Ethereum Virtual Machine (EVM).

Another solution would be to cap calldata per block, as proposed in EIP-4488, wrote the pair. However, this could also disincentivize using calldata for data availability and impacts apps that are heavily dependent on it.

Thus, creating a separate calldata fee market, such as how data blobs are handled, could be used to potentially increase gas limits. The price for using calldata would automatically adjust based on how much demand there is. However, the downside was increased complexity in analysis and implementation.

The final idea is offering an “EVM loyalty bonus” to compensate calldata-heavy apps.

Blobs are large data packets, integrated into Ethereum’s blockchain to optimize data handling and storage, which will be rolled out with the EIP-4844 Dencun upgrade.

However, the pair concluded that simply raising the calldata cost to 42 might be “too blunt an approach” while creating separate fee markets could “add too much complexity.”

A balanced solution could be to increase the cost of calldata while reducing the cost of some operations, or perhaps moving towards a model that offers incentives for using calldata inside the EVM.

Buterin previously proposed calldata limits per block to lower gas costs back in 2021.

In January, Vitalik Buterin suggested raising the Ethereum gas limit by 33% to 40 million to improve network throughput.

Increasing the gas limit allows more transactions per block, theoretically increasing the overall throughput and capacity of the network. However, it also increases loads on hardware and the potential risk of network spam and attacks.