Scaling the Ethereum L1 is a key component of the future R&D roadmap. Within the next five years, Ethereum aims to significantly improve L1 execution. This will happen in parallel to improvements to data availability and consensus (e.g. while we plan to increase blob capacity and improve UX for L2s doesn’t mean we can’t also increase the gas limit and improve UX on L1).

There are various EIPs and proposals in the near and longer term pipeline to scale L1 as @drakefjustin outlines here:

Based on this roadmap we can 100x the gas limit within the next five years. Some of these increases will be made in a step function manner after certain EIPs are implemented and we know it’s safe to increase the gas limit .

If five years seems like a long time, remember that Ethereum’s goal is to scale while preserving the ability for anyone to verify the network or participate in consensus without relying on third parties. We love our solo stakers and node runners! Also, we are stewarding a multi-hundred billion dollar protocol.

Picking the low hanging fruit

The 10x increases to the gas limit are farther away but we can also make smaller increases at any time as validators can manually adjust their nodes to signal that they are willing to handle bigger blocks. This is happening today:

As @dankrad outlines in the above tweet, we may see an increase to the L1 gas limit from 30 Mgas/block -> 36 Mgas/block very soon. Typically we try to increase gas on L1 periodically when the core devs deem it safe to do so and as hardware and bandwidth requirements become more manageable over time. Some proposals like EIP-7783 by @giulio2002 would change this to a predetermined schedule that gradually increases the gas limit over time.

There are some other “low hanging fruit” upgrades as @davidecrapis puts it in a recent tweet that should help pave the way for further, more minor, increases to the gas limit.

Core devs recently discussed including EIP-7623 in the upcoming Pectra hardfork (no date set but end of Q1 ealy Q2 2025 is my estimate). This EIP would adjust pricing for CALLDATA reducing the maximum block size and giving us the ability to increase the execution gas limit. CALLDATA was where L2s would post their data prior to EIP-4844 and blobs.

Post 4844 L2s primarily post their data to blobs as it’s significantly cheaper than using L1 CALLDATA, therefore we can revisit how we price this resource and free up space for EVM operations. As Davide estimates this could result in a 2x increase to the gas limit.

Delaying the state root is another proposal aiming to be included in the Fusaka hardfork. This would remove the calculation of the stateroot (computationally intensive) from the critical path of block verification and delay it by one slot, improving latency and paving the way for faster block times (a scalability and UX upgrade for L1). This upgrade also couples nicely with some of the more complex scalability improvements that will come with SNARKifying the EVM.

In order to achieve the orders of magnitude gas limit increases we’ll need to be able to prove the EVM in real time, or close to realtime, as delaying the state root gives us the luxury of doing so over 2 slots vs. 1.

Picking the not so low hanging fruit

ZK magic will be the primary tool we use to achieve the 100x gas limit increase which can be viewed as the north star for the execution roadmap.

As @jtguibas says,

“we’re about to prove the entirety of ethereum on these bad boys:”

The bad boys he is referring to are ZK provers and Justin Drake expects that vendors will be able to prove the entirety of the EVM on these machines within the next year. Instead of running an execution layer client and naively re-executing every transaction yourself all you will need to do is verify a proof. Running the ZK version of the execution client will effectively eliminate the hardware requirements otherwise needed to run a vanilla client making verifying a 30 Mgas or 3 Ggas block the same.

ZK may also help accelerate the statelessness roadmap giving us the option to pivot away from verkle trees (a prerequisite to statelessness) to binary merkle trees, a more optimal tree structure that is both SNARK friendly and quantum secure. Statelessness pushes the responsibilities of state storage to block builders meaning other nodes on the network no longer have to store the full state data allowing them to keep up with larger block sizes. This will be further supplemented with history expiry or EIP-4444.

Core devs are targeting a May 2025 release for EIP-7639 this is the first upgrade related to history expiry that aims to bound historical data in execution clients. EIP-7639 proposes to prune historical state prior to the merge and is expected to free up a couple hundred gigabytes of disk space for node operators and won’t require a hardfork. While this won’t directly translate into any scalability improvements, it helps make nodes more lightweight and makes decisions around gas limit increases easier to digest.

Before we can safely increase the gas by 100x as outlined in Justin Drake’s roadmap we’ll need one final ingredient: multi-dimensional EIP-1559. We discussed CALLDATA repricing earlier, multi-dimensional EIP-1559 expands on this and gives us the ability to reprice resources that impact state growth and storage size growth. By fine tuning these parameters we can make resources like EVM execution more abundant while keeping the others at more manageable levels vs. a uniform increase.

We’re at 30 Mgas/block today; these upgrades will take us to 3 Ggas/block, a 100x increase, within the next five years.

Bonus: other roadmap items helping to scale Ethereum

The Ethereum R&D roadmap is not sequential; many aspects of it are being developed in parallel and sometimes proposals have a nice side effect of improving scalability even though that was not their initial purpose.

One such proposal is EIP-7732. Like the name suggests ePBS enshrines what MEV Boost does extra-protocol (decouples the task of block proposing from block building) and eliminates the need for relay’s improving Ethereum’s censorship resistant properties. As a by-product, it streamlines the block production pipeline giving validators more time to produce a block resulting in bandwidth and CPU optimizations that can translate into gas limit increases as Giulio mentioned here.

There have also been discussions to decrease Ethereum’s slot times; this would improve UX for users of L1 and based rollups but would also increase L1 execution and blob capacity as a added benefit.

There’s a lot to get excited about when it comes to scaling the L1 (whether directly or indirectly) and most importantly the path to 100x the gas limit is clear and achievable. See you at 36 Mgas and beyond soon!

Disclaimer:

1. This article is reprinted from [2077 Research]. All copyrights belong to the original author [@acseth2032]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The Gate Learn team does translations of the article into other languages. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.