Vitalik: To ensure the accumulation of ETH, how does Ethereum L1 and L2 expand in the future?

Author: Vitalik, founder of Ethereum

Compiled by: Baishui, Golden Finance

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

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

…a glimpse of what another world might look like—a world with few gatekeepers, a world without legacy systems. In a subversion of society's standard status system, those with the highest social status are nerds who spend all their time hyper-focused on independently solving problems they truly care deeply about, rather than playing games to climb the ranks of legacy institutions 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 a world like this, a world like this is actually within your reach.

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

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

After ten years of hard work, with 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, useful privacy tools, and I use it to pay for a VPN to protect my internet data. It has ENS, a powerful decentralized alternative to DNS and public key infrastructure more generally. It has a practical and easy-to-use alternative 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 would have been reluctant to talk about the latter use case, mainly for one reason: the infrastructure and code were not mature, and we were only a few years away from the massive and highly traumatic smart contract hacks of 2016-17, and if every year There is a 5% chance of getting -100% APY, so 7% APY instead of 5% APY makes no sense. Beyond that, transaction fees are too high to make these things available at scale. Today, these tools have shown their resilience over time, the quality of audit tools has improved, and we are increasingly confident in their security. We know what not to do. L2 extension is working. Transaction fees have been low for nearly a year.

We need to continue building on Ethereum’s technical and social properties and utility. If we have the former but not the latter, then we degenerate into an increasingly ineffective "decel" community that can roar into the wind that various mainstream actors are immoral and bad, but yet No position truly offers 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 are here to escape.

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

The rise of L2

Today, our way to scale Ethereum is through layer 2 protocols (L2s). L2s in 2025 are a far cry from the early experiments of 2019: they have reached key decentralization milestones, they are securing billions of dollars in value, and they are currently scaling Ethereum’s transaction capacity by 17x in fees also decreased by a similar magnitude.

Left: Phase 1 and Phase 2 Rollup. On January 22nd, Ink became the sixth Phase 1+ Rollup (and the third complete EVM Phase 1+ rollup). The picture on the right shows the top Rollup by TPS, with Base leading the way, accounting for about 40% of Ethereum’s capacity.

This all coincides with a wave of successful applications: various DeFi platforms, social networks, prediction markets, fancy contraptions like Worldchain (which now has 10 million users). The "enterprise blockchain" movement, widely seen as a dead end after the failure of consortium blockchains in the 2010s, has seen a resurgence with the emergence of L2s, of which Soneium is a prime 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 on its own, but rather has dozens of independent entities with incentives to do so. These entities have also made important contributions to the technology, without which Ethereum would not be where it is today. So we are finally approaching escape velocity.

Challenges: Scale and processing heterogeneity

Currently L2 faces two main challenges:

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

Heterogeneity Challenge: Early visions of how Ethereum would scale involved creating a blockchain with many shards, each of which was a copy of the EVM processed by a small subset of nodes. In theory, L2 is an 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 an easy-to-understand technical challenge, and has an easy-to-describe (but difficult-to-implement) technical solution: feed Ethereum more blobs. In addition to this, L1 also allows for modest scaling in the short term, as well as improvements to proof-of-stake, stateless and lightweight verification, storage, EVM, and cryptography.

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

A possible shortcut for scaling is to abandon L2 and do everything through L1 with higher gas limits (across multiple shards or on one shard). However, this approach undermines much of the benefit of Ethereum’s current social structure, which is highly effective in simultaneously reaping the benefits of different forms of research, development, and ecosystem-building culture. So we should stick with it and continue to scale primarily through L2, but make sure that L2 actually delivers on the promise that they're supposed to deliver.

This means the following:

• L1 needs to accelerate the expansion blob.
• L1 also requires modest scaling of the EVM and increased gas limits to be able to handle activities that will continue even in an L2-dominated world (such as proofs, large-scale defi, deposits and withdrawals, special large-scale exit scenarios, key library wallet, asset issuance).
• L2 needs to continue improving security. The same security guarantees one would 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, and more. Using Ethereum should feel like using one ecosystem, not 34 different blockchains.
• L2 deposit and withdrawal times need to get faster.
• L2 heterogeneity is good as long as basic interoperability requirements are met. Some L2s will be rollups based on minimal governance, running exact copies of the L1 EVM. Others will try using different VMs. Others will be more like servers using Ethereum to provide users with extra security. We need L2 in every part of that spectrum.
• We should explicitly consider the economics of ETH. We need to ensure that ETH can continue to accumulate value even in an L2-heavy world, ideally addressing various models of value accumulation.

Let us now discuss each topic 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 that number.

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

Fusaka's current goal is to focus primarily on PeerDAS and ideally nothing else besides PeerDAS and EOF. PeerDAS can increase the number of blobs 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 up to 128 blobs per slot and keep going. With this, and improvements in data compression, we can reach 100,000 TPS on-chain.

So far, the above is a restatement of the status quo roadmap to 2025. The key question is: What changes can we actually make to speed up this process? My answer is as follows:

• We should prefer to explicitly deprioritize non-blob functionality.
• We should be more aware that blobs are targets and make related p2p R&D a priority for talent acquisition.
• We can let stakers adjust blob targets directly, similar to gas limits. This will allow blob targets to grow faster in response to technology improvements without having to wait for a hard fork.
• We could consider more aggressive approaches that would allow us to acquire more blobs faster and provide more trust assumptions to stakers with fewer resources, but we should be cautious about this.

Improving security: proven systems and native rollups

Today, there are three first-stage rollups (Optimism, Arbitrum, Ink) and three second-stage rollups (DeGate, zk.money, Fuel). Most activity still occurs on phase 0 rollup (i.e. multi-sig). This situation needs to change. A big reason why this situation isn't changing sooner is that it's difficult to build a proven system and have enough confidence in it to be willing to throw off the training wheels and rely solely on it for safety.

There are two ways to achieve this:

• Phase 2 + Multi-Prover + Formal Verification: Use multiple proof systems for redundancy and formal verification (see: Proven ZK-EVM scheme) to ensure their security.
• Native Rollup: Verify EVM state transition functions as part of the protocol itself, e.g. via precompilation (for research, see: [1] [2] [3]).

Today we should be doing both at the same time. For phase 2 + multiple provers

• formal verification, the roadmap is relatively easy to understand. The main practical areas where we can accelerate is working more together across software stacks, reducing the need to duplicate work while increasing interoperability.

Native Rollup is still an early idea. There's a lot of active thinking to be done, especially on the topic of how to maximize flexibility in native rollup precompilation. An ideal goal would be to have it support not only exact clones of the EVM, but also EVMs with various arbitrary changes, such that an L2 with a modified EVM could still be precompiled with native rollup and only bring its own proofs for the modifications device". This can be used for precompilation, opcodes, state trees and possibly other parts.

Interoperability and standards

Our goal is that the experience of moving assets and using applications between different L2s is the same as if they were different "shards" of the same blockchain. For months now, there's been a fairly easy-to-understand roadmap on 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 sophisticated ideas that also move the registry for L2 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 L2 itself. An ecosystem relying on multi-signature bridges is unacceptable. If this was a trust assumption that wouldn't exist if we did 2016 style sharding, then it's unacceptable today.
• Speed ​​up deposit and withdrawal times so that "native" messages can be completed in minutes (eventually a time slot) instead of weeks. This involves faster ZK-EVM provers and proof aggregation.
• Read L1 synchronously from L2. See: L1SLOAD, REMOTESTATICCALL. This makes cross-L2 interoperability easier and also helps with keystore wallets.
• Share sorting and other long-term work. Part of the value of aggregation-based ones is that they may be able to do this more efficiently.

As long as these criteria are met, there's still plenty of room for L2s to have properties that are distinct from each other: try different VMs, different ordering models, scale vs. security tradeoffs, and other differences. However, users and application developers must be aware of the level of security they are getting.

To make faster progress, much of the work can be done by entities operating across the ecosystem: the Ethereum Foundation, client development teams, main application teams, etc. This will reduce coordination efforts and make adoption of the standard a breeze, as each individual L2 and wallet will have less work to do. However, as an extension to Ethereum, L2 and wallets still need to step up to the last mile 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 the strategy are as follows:

• There is broad agreement to solidify ETH as the primary asset of the larger (L1+L2) Ethereum economy, support applications that use ETH as primary collateral, etc.
• L2 is encouraged to support ETH through a certain percentage of fees. This could be accomplished by burning a portion of fees, staking them permanently, and donating the proceeds to Ethereum ecosystem public goods, or some other scheme.
• There is partial support for rollup-based rollups as a way for L1 to obtain value through MEV, but don't try to force all rollups to be based on this (as it won't work for all applications), and don't think that alone will solve the problem.
• Increase the number of blobs, consider the lowest blob price, and consider blobs as another possible source of revenue. As a possible future example, if you take the average blob fee over the past 30 days and assume it stays the same (due to induced demand) while the number of blobs increases to 128, Ethereum will burn 713,000 ETH per year. However, this favorable demand curve is not guaranteed, so don't think that alone will solve the problem.

Summary: 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 cryptoassets 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 expand more safely, to code to extend EVM execution, and to features and standards that make L2 interoperable.

If you are a wallet developer, also be involved in contributing and implementing standards to make the ecosystem more seamless for users, while being as secure and decentralized as it was when Ethereum was only L1.

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

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

This article would like to thank Tim Beiko, Justin Drake, and developers from various L2 teams for their feedback and review.