EIP-7938: Exponential Gas Limit Increase via Default Client Voting Behavior

Writing more about the reasons for this EIP. To be upfront, it is unconventional. I do think it is time for being unconventional, because the current way of doing things is likely to make Ethereum irrelevant over the next 5-10 years.

Key considerations why I think we should commit to this gas limit change schedule:

  1. Strategic: Things happening on one layer (composability and UX-wise) is much more strategically important than previously thought.
  2. Technical: Validity proving Ethereum L1 at 1-block latency will become possible this year, and DAS with PeerDAS will also become reality
  3. Execution: Working backwards from a goal tends to have better outcomes than making incremental changes as they become possible.

1. Strategic

Ethereum L1 needs to be the economic center of Ethereum. There are a number of reasons for this:

  • Ethereum L1 will probably always drive fee revenue, as the moat for DA is much lower
  • If L1 is unimportant and loses its attraction of liquidity and DeFi, there will also be less of a reason for L2s to even remain attached to Ethereum
  • The Ethereum ecosystem does compete with other ecosystems, who are eager to get its market share. Fragmenting L1 liquidity across a number of different L2s is a very good way to lose this battle

2. Technical

In the last year, proving Ethereum L1 blocks became first possible, and is now cheap (typical proof cost per block is a few cents: https://ethproofs.org/). Within this year, we will have proving within a single slot delay, and all teams expect order of magnitude improvements to continue for at least a few years.

This means that for the first time, we will have the ability to significantly scale the L1 so that a lot of activity can continue to happen on it. Not just just do 10x the scale, we can do 100x to 1000x the current scale while keeping Ethereum’s most important properties:

  • Verifiability (it is very easy to check that the current continuation of the blockchain is according to the rules)
  • Censorship resistance (we can guarantee that any paying transaction will get included)

Ethereum’s current node architecture is a copy of Bitcoin’s from 2009. We will need to update the Ethereum node types for the 2020s and 2030s. Some roles (full nodes, attesting, FOCIL) are likely to be even lighter than they are today, while others (building, proving) will become more beefy; however, all the “beefy” node types come with an 1-out-of-n honesty assumption, making sure that they can always be easily replaced.


Barnabe discusses his vision for different node types more on this call (https://www.youtube.com/live/m5HFO4DYckQ?si=4fD0Z7PkJM-4pBpX). The key to maintaining security and keeping Ethereum unstoppable that all node types can still be run from home in some places.

3. Execution

In the past, we have been very reluctant to do certain things:

  • Commit to timelines
  • Plan actively for the future, several forks ahead
  • Execute efficiently

Committing to a scaling timeline makes it clear what the goal is, and lets us plan backward from the goal:

In addition to hard forks, scaling the EL 100x will require performance engineering. Having a concrete goal in mind will let us prioritize this work as well as the concrete upgrades as needed. A database for a 5x scaled EL might look very different from one that is scaled to 100x. The mempool certainly does. A lot of decisions become much easier if we know where we want to go.

The same goes for application developers. Ethereum L1 is currently still the home for DeFi – this might not be true for much longer if we don’t start strongly supporting applications. An important step in this direction is giving them dependable scaling timelines.

Doesn’t that make us like a Datacenter chain or Solana?

I think it is irrelevant whether some superficial aspects of Ethereum look more like Solana or not. The core value proposition of Ethereum is not the home staker, it is verifiability and censorship resistance. While the future world looks significantly different from now, I would argue it’s not clearly better or worse in those aspects, just a different set of tradeoffs. 99%+ of users today do not run their own node but use their wallet’s default RPC. Having ZK verifiability will actually make it easier (obviously it’s still going to be hard work getting it integrated into wallets). FOCIL or MCP can probably bring us better censorship resistance than we have today.

Another question might be – are we playing Solana’s game? Why should we IBRL, aren’t we certain to lose this?

I think it is not so certain we will lose this game. Ethereum L1 so far has the most liquidity of all chains. Why is it still here?

  • Existing DeFi moat
  • IBRL is not the only thing that matters
    At least as far as scaling is concerned, I do believe that at 100x the current scale, Ethereum L1 can support a very large range of value transaction that competing with it simply on scaling terms is not and interesting game to play anymore. On shorter block times, I think we are unlikely to go below ca. 1s to change proposers, but there are other options to improve UX (preconirmations) and DEX performance (MCPs).

Uniquely, Ethereum has a huge moat in DeFi liquidity, and those applications benefit significantly from being colocated. What we need to do is support these applications and making Ethereum the best home to them.

Conclusion

Due to these updates to the strategic and technical environments, I think by far the best strategy for Ethereum from here is, in addition to supporting L2s via blob scaling and UX/interop improvements, to significantly scale the L1. The endgame is scaling 100x-1000x. We need to commit to it as soon as possible, both because builders and applications need predictability, and because we need to prioritize properly so that it can actually get executed.

14 Likes