Vitalik's new article: How to expand Ethereum L1 and L2 in the future to ensure the cumulative value of ETH

Ethereum's goal is the same as it has been since day one: to build a global, censorship-resistant, permissionless blockchain. A free and open platform for decentralized applications, built on the same principles (what we might today call the regen and cypherpunk spirit) as GNU+Linux, Mozilla, Tor, Wikipedia, and many other great free and open source software projects before it.

Ethereum has also developed another quality that I really appreciate over the past decade: in addition to being an innovation in cryptography and economics, it is also an innovation in social technology. Ethereum as an ecosystem is a working, live demonstration of a new, more open and decentralized way of building. Political philosopher Ahmed Gatnash described his experience at Devcon this way:

… a glimpse into what an alternative world might look like — a world with few gatekeepers, a world without legacy systems. In a subversion of society’s standard status system, the people with the highest social status are nerds who spend all their time laser-focused on independently solving problems they really care deeply about, rather than playing games to climb the hierarchy of legacy institutions and amass power. Almost all power here is soft power. I find it beautiful and inspiring — it makes you feel like anything is possible in such a world, that such a world is actually within reach.

Technical projects and social projects are inherently intertwined. If you have a decentralized technical system at time T, but a centralized social process to maintain it, there is no guarantee that your technical system will still be decentralized at time T+1. Similarly, social processes are kept alive by technology in many ways: technology brings users, the ecosystem it forms provides incentives for developers to come and stay, it keeps the community solid and focused on building rather than just socializing, and so on.

You can use Ethereum to pay for things around the world, October 2024.

After a decade of hard work, and amidst this mix of technical and social attributes, Ethereum embodies another important quality: Ethereum does useful things for people at scale. Millions of people hold ETH or stablecoins as a form of savings, and many more use these assets for payments: I am one of them. It has effective, practical privacy tools, which I use to pay for VPNs to protect my internet data. It has ENS, a powerful decentralized alternative to DNS, and public key infrastructure more generally. It has practical and easy-to-use alternatives to Twitter. It has defi tools that provide millions of people with low-risk assets that yield higher returns than they can get in traditional finance.

Five years ago, I was reluctant to talk about the latter use case for the following main reasons: the infrastructure and code were immature, we were only a few years away from the massive and extremely traumatic smart contract hacks of 2016-17, and it didn’t make sense to do 7% APY instead of 5% APY if there was a 5% chance of getting -100% APY per year. On top of that, transaction fees were too high to make these things usable at scale. Today, these tools have shown their resilience over time, the quality of audit tools has improved, and we have more and more confidence in their security. We know what not to do. L2 scaling is working. Transaction fees have been low for nearly a year now.

We need to continue to build on Ethereum’s technical and social attributes and utility. If we have the former but not the latter, then we degenerate into an increasingly ineffective “decel” community that can bark to the wind about various mainstream actors being immoral and bad but has no position to actually offer a better alternative. If we have the latter but not the former, then we have the Wall Street greed is good mentality that many of us came here to escape.

The duality I just described has many implications. In this post, I want to focus on a specific one that is very important to short- and medium-term users of Ethereum: Ethereum’s scaling strategy.

The rise of L2

Today, our path to scaling Ethereum is with layer 2 protocols (L2s). The L2s of 2025 are a far cry from the early experiments of 2019: they have already reached key decentralization milestones, they are securing billions of dollars of value, and they are currently scaling Ethereum’s transaction capacity by 17x, with fees reduced by a similar amount.

Left: Phase 1 and Phase 2 Rollups. On January 22, Ink became the sixth Phase 1+ Rollup (and the third full EVM Phase 1+ Rollup). Right: Top Rollups by TPS, with Base leading the pack, accounting for about 40% of Ethereum capacity.

This all coincides with a wave of successful applications: various DeFi platforms, social networks, prediction markets, and exotic devices like Worldchain (now with 10 million users). The "enterprise blockchain" movement was widely seen as a dead end after the failure of consortium blockchains in the 2010s, but it has been revived with the emergence of L2s, with Soneium being a typical example.

These successes also demonstrate the social nature of Ethereum’s decentralized and modular approach to scaling: the Ethereum Foundation doesn’t have to find all of these users itself, but rather there are dozens of independent entities that have the incentive to do so. These entities have also made important contributions to the technology, and without these contributions, Ethereum would not be where it is today. As a result, we are finally approaching escape velocity.

Challenges: Scale and handling heterogeneity

Currently, L2 faces two major challenges:

• Scale: Our blob space barely covers L2 and today’s use cases, and falls far short of meeting future needs.

• Heterogeneity Challenges: An early vision for how Ethereum would scale involved creating a blockchain with many shards, each of which was a copy of the EVM handled by a small subset of nodes. In theory, L2 is exactly the implementation of this approach. In practice, however, there is a key difference: each shard (or set of shards) is created by a different actor, is treated as a different chain by the infrastructure, and often follows different standards. Today, this translates into composability and user experience issues for developers and users.

The first problem is a well-understood technical challenge, and has an easily described (but hard to implement) technical solution: give Ethereum more blobs. Beyond that, L1 can also allow for modest scaling in the short term, as well as improvements to proof-of-stake, stateless and lightweight validation, storage, EVM, and cryptography.

The second issue that has received a lot of public attention is the coordination problem. Ethereum is no stranger to performing complex technical tasks across multiple teams: after all, we did a merge. Here, the coordination problem is more challenging because the number and diversity of participants and goals is greater, and the process starts later in the game. But even so, our ecosystem has solved hard problems before, and we can do so again.

One possible shortcut to scaling is to abandon L2 and do everything through L1 with a higher gas limit (either across multiple shards or on a single shard). However, this approach undermines most of the benefits of Ethereum's current social structure, which has been very effective in simultaneously gaining the benefits of different forms of research, development, and ecosystem-building culture. Therefore, we should stick with it and continue to scale primarily through L2, but make sure that L2 actually delivers on the promises they are supposed to deliver.

This means the following:

• L1 needs to speed up the expansion of blobs.

• L1 will also require modest scaling of the EVM and increased gas limits to be able to handle activities that will continue even in an L2-dominated world (e.g. proofs, large-scale defi, deposits and withdrawals, special mass exit scenarios, keystore wallets, asset issuance).

• L2 needs to continue to improve security. The same security guarantees that people expect from sharding (including, for example, censorship resistance, light client verifiability, lack of fixed trusted parties) should be available on L2.

• L2 and wallets need to accelerate improvements and standardize interoperability. This includes chain-specific addresses, messaging and bridging standards, efficient cross-chain payments, on-chain configuration, etc. Using Ethereum should feel like using one ecosystem, not 34 different blockchains.

• L2 deposit and withdrawal times need to become faster.

• L2 heterogeneity is good as long as basic interoperability needs are met. Some L2s will be governance-minimized Rollups running exact copies of the L1 EVM. Others will attempt to use different VMs. Others will be more like servers using Ethereum to provide additional security for users. We need L2s in every part of that spectrum.

• We should think explicitly about the economics of ETH. We need to ensure ETH continues to accrue value even in an L2-heavy world, ideally addressing various models of value accrual.

Now let’s discuss each subject area in more detail.

blobs, blobs, blobs

With EIP-4844 we now have 3 blobs per slot, or 384 kB of data bandwidth per slot. A quick calculation shows that this is 32 kB per second, and each transaction takes about 150 bytes on-chain, so we get ~210 tx/sec. The L2beat data gives almost exactly this number.

For the Pectra release scheduled for March, we plan to double this to 6 blobs per slot.

Fusaka's current goal is to focus mainly on PeerDAS, ideally with nothing else besides PeerDAS and EOF. PeerDAS could increase the number of blobs by another 2-3 times.

After that, the goal is to keep increasing the number of blobs over time. When we do 2D sampling, we can get to 128 blobs per slot and keep going from there. With this, and improvements in data compression, we can get to 100,000 TPS on-chain.

So far, the above is a restatement of the current roadmap to 2025. The key question is: what changes can we actually make to speed up this process? Here are my answers:

• We should be more willing to explicitly deprioritize non-blob functionality.

• We should be more aware that blobs are the target, and make related p2p R&D a priority for talent acquisition.

• We can let stakers adjust the blob target directly, similar to the gas limit. This will allow the blob target to increase more quickly in response to technological improvements without waiting for a hard fork.

• We could consider more aggressive approaches that allow us to acquire more blobs faster and provide more trust assumptions for stakers with fewer resources, but we should be cautious about this.

Improving Security: Proof Systems and Native Rollups

Today, there are three Phase 1 Rollups (Optimism, Arbitrum, Ink) and three Phase 2 Rollups (DeGate, zk.money, Fuel). Most activity still happens on Phase 0 Rollups (i.e. multisig). This needs to change. A big reason this hasn’t changed sooner is that it’s hard to build a proof system and have enough confidence in it to be willing to throw off the training wheels and rely entirely on it for security.

There are two ways to achieve this:

• Phase 2 + Multiple Provers + Formal Verification: Use multiple proving systems for redundancy and use formal verification (see: Proven ZK-EVM Plan) to ensure its security.

• Native Rollup: Incorporating EVM state transition function verification as part of the protocol itself, e.g. via a precompile (for research, see: [1] [2] [3]).

Today, we should be working on both. For phase 2 + multiple provers + formal verification, the roadmap is relatively easy to understand. The main practical area where we can accelerate is more collaboration on the software stack, reducing the need to duplicate work while increasing interoperability.

Native Rollup is still an early idea. There is a lot of active thinking to be done, especially on the topic of how to make native rollup precompiles as flexible as possible. An ideal goal would be to have it support not just exact clones of the EVM, but also EVMs with all sorts of arbitrary changes, so that an L2 with a modified EVM can still use a native rollup precompile and just "bring your own prover" for the modifications. This could be done for precompiles, opcodes, state trees, and possibly other parts.

Interoperability and standards

Our goal is to make the experience of moving assets and using applications between different L2s the same as if they were different “shards” of the same blockchain. For several months, there has been a fairly easy-to-understand roadmap for how to do this:

• Chain-specific addresses: The address should include some kind of identifier for the account on the chain and the chain itself. ERC-3770 was an early attempt at this, and now there are more complex ideas that also move the L2 registry to Ethereum L1 itself.

• Standardized cross-chain bridges and cross-chain messaging: There should be standard ways to verify proofs and pass messages between L2s, and these standards should not require trusting anything other than the proof system of the L2 itself. An ecosystem that relies on multi-signature bridges is unacceptable. If this is a trust assumption, it wouldn’t exist if we did 2016-style sharding, so it’s unacceptable today.

• Speed ​​up deposit and withdrawal times so that “native” messages can be finalized in minutes (and eventually a timeslot) rather than weeks. This involves faster ZK-EVM provers and attestation aggregation.

• Synchronously read L1 from L2. See: L1SLOAD, REMOTESTATICCALL. This makes cross-L2 interoperability easier and also helps keystore wallets.

• Shared sorting and other long-running work. Part of the value of rollups is that they may be able to do this more efficiently.

As long as these criteria are met, there is still a lot of room for L2 to have very different properties from each other: try different virtual machines, different ordering models, scale vs. security tradeoffs, and other differences. However, users and application developers must be clear about the level of security they are getting.

To make faster progress, most of the work can be done by entities operating across the ecosystem: the Ethereum Foundation, client development teams, major application teams, etc. This will reduce the coordination work and make it easier to adopt standards because each individual L2 and wallet will have to do less work. However, as an extension of Ethereum, L2 and wallets will still need to step up to the last mile work of actually implementing these features and bringing them to users.

The Economics of ETH

ETH as a three-phase asset

We should adopt a multi-pronged strategy to cover all major possible sources of value for ETH as a three-phase asset . Some key elements of this strategy are as follows:

• Broad agreement to solidify ETH as the primary asset for the larger (L1+L2) Ethereum economy , supporting applications using ETH as primary collateral, etc.

• Encourage L2 to support ETH through a certain percentage of fees . This can be achieved by burning a portion of fees, staking forever and donating the proceeds to Ethereum ecosystem public goods, or some other scheme.

• Partially support rollup-based rollups as a way for L1 to capture value through MEV , but don't try to force all rollups to be based on this (because it won't work for all applications) and don't assume that this alone will solve the problem.

• Increase the number of blobs, consider a minimum blob price, and consider blobs as another possible source of revenue. As a possible future example, if you take the average blob fee of the past 30 days and assume it remains constant (due to induced demand) while the number of blobs increases to 128, Ethereum will destroy 713,000 ETH per year. However, this favorable demand curve is not guaranteed, so don't assume that this alone will solve the problem.

Conclusion: The Road Ahead

Ethereum has matured as a technology stack and social ecosystem, bringing us closer to a more free and open future where hundreds of millions of people can benefit from crypto assets and decentralized applications. However, there is still much work to be done, and now is the time to redouble our efforts.

If you are an L2 developer, please contribute to tooling to make blobs scale more safely, contribute to code to extend EVM execution, and contribute to features and standards that make L2 interoperable.

If you are a wallet developer, similarly get involved in contributing and implementing standards to make the ecosystem more seamless for users while remaining as secure and decentralized as it was when Ethereum was just L1.

If you are an ETH holder or community member, please actively participate in these discussions; many areas still need active thinking and brainstorming.

The future of Ethereum depends on the active participation of each of us.

Special thanks to Tim Beiko, Justin Drake, and developers from various L2 teams for their feedback and review.