Ethereum Plans to Optimize Block Size for Rollup-Centric Future

Ethereum, the second-largest cryptocurrency by market capitalization, is looking for ways to reduce its maximum block size and improve its scalability and efficiency. The Ethereum Foundation and its co-founder Vitalik Buterin have proposed several strategies to achieve this goal, which aligns with their vision of a “rollup-centric roadmap” for the network.

What are rollups and why are they important?

Rollups are a layer-2 scaling solution that allows transactions and computations to be executed off-chain, while only storing the data on the main chain. This reduces the load on the Ethereum network and increases its throughput and security. Rollups are expected to play a key role in Ethereum’s transition to Ethereum 2.0, which will introduce a proof-of-stake consensus mechanism and shard chains.

According to Buterin and Ethereum Foundation researcher Toni Wahrstätter, rollups can potentially increase Ethereum’s scalability by a factor of 100 or more, depending on the type of rollup and the application. They also noted that rollups are already being used by several projects, such as Optimism, Arbitrum, zkSync, StarkNet, and Loopring, for various purposes, such as decentralized exchanges, gaming, and DeFi.

How does block size affect rollups?

Block size refers to the amount of data that can be stored in each block on the Ethereum network. The block size is determined by the block gas limit, which is the maximum amount of gas that can be spent on executing transactions or smart contracts in each block. Gas is a unit of measurement that represents the computational cost of an operation on the Ethereum network.

One of the challenges that Ethereum faces is how to optimize the utilization of block space for rollups. Since rollups rely on data availability on the main chain, they need to use a portion of the block space to store their data. This portion is called calldata, and it consumes gas as well. However, calldata also increases the load on the network, which affects its performance and synchronization.

Therefore, the Ethereum Foundation and Buterin are exploring different ways to balance the trade-off between calldata usage and block gas limit. Their goal is to reduce the maximum block size and variance, while creating room for more data blobs in the future. Data blobs are chunks of data that can be used by rollups or other applications for data availability.

What are the proposed solutions to optimize block size?

In a blog post on February 5, Buterin and Wahrstätter discussed five different solutions, each varying in complexity and trade-offs. The primary objective is to increase the cost of calldata, while decreasing the cost of other opcodes, thereby reducing the maximum block size and creating room for more data blobs in the future.

The first solution is to simply increase the cost of calldata from 16 to 42 gas, which would reduce the maximum block size from 1.78 megabytes to 0.68 megabytes. However, this approach could disincentivize the use of calldata for data availability, which could negatively impact applications that rely on large calldata for on-chain proofs, such as StarkNet.

The second solution is to increase the cost of calldata, while simultaneously decreasing the cost of other opcodes, such as SSTORE, SLOAD, and EXTCODESIZE. This approach aims to strike a balance between incentivizing calldata usage and optimizing gas costs. However, this solution would require a careful analysis of the impact on existing contracts and applications.

The third solution is to cap the amount of calldata per block, as outlined in Ethereum Improvement Proposal (EIP) 4488. This would limit the maximum block size to 1.5 megabytes, regardless of the block gas limit. However, this approach also raises concerns about disincentivizing calldata usage for data availability, which may affect applications heavily reliant on it.

The fourth solution is to create a separate calldata fee market, similar to how data blobs are handled. This would allow the price for calldata usage to automatically adjust based on demand and supply. However, the downside to this proposal is the increased complexity in analysis and implementation.

The fifth solution is to introduce a new opcode called CALLDATALOAD64, which would allow loading 64 bytes of calldata at a lower cost than the existing CALLDATALOAD opcode, which loads 32 bytes. This would encourage the use of calldata for data availability, while reducing the maximum block size. However, this solution would also require changes to the EVM and the rollup protocols.

What are the next steps for Ethereum?

Buterin and Wahrstätter stated that they are open to feedback and suggestions from the Ethereum community on the proposed solutions. They also emphasized that the optimization of block size is not a one-time decision, but a continuous process that will require constant monitoring and adjustment.

They concluded that the rollup-centric roadmap is a promising direction for Ethereum, as it offers a scalable and secure way to support a wide range of applications and use cases. They also expressed their hope that the Ethereum community will work together to find the best solutions to optimize the network for the rollup-centric future.