Vitalik: Ethereum L1 and L2 Scaling in 2025 and Beyond

Original title: Scaling Ethereum L1 and L2s in 2025 and beyond

Author: Vitalik, founder of Ethereum; Translator: Baishui, Golden Finance

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

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 can call the regeneration and cypherpunk spirit today) as GNU + Linux, Mozilla, Tor, Wikipedia, and many other great free and open source software projects before it.

Over the past decade, Ethereum has also developed another feature that I really appreciate: in addition to innovations in cryptography and economics, Ethereum 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 of what another world might look like — a world with few gatekeepers, a world without legacy systems. In an overturn 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 there is a centralized social process maintaining it, then 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 formed by technology provides incentives for developers to come and stay, it keeps the community solid and focused on building rather than just socializing, etc. You can use Ethereum to pay fees 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’m 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, mainly for the following 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 auditing tools has improved, and we have increasing 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 the technical and social properties and utility of Ethereum. 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 are 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 Layer 2

Today, our path to scaling Ethereum is Layer 2 protocols (L2s). The L2s of 2025 are a far cry from the early experiments of 2019: they have 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). The right graph is a summary of the top ranked by TPS, with Base in the lead, accounting for about 40% of Ethereum's capacity.

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

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

Challenges: Scale and Handling Heterogeneity

There are two main challenges with L2 today:

• 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 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 different actors, 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: feed Ethereum more blobs. Beyond that, L1 can also scale modestly in the short term, as well as improve proof-of-stake, stateless and lightweight validation, storage, the EVM, and cryptography.

The second problem, which 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 actors 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 so again.

One possible shortcut to scaling is to abandon L2 and do everything via 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 is very 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 L2s actually deliver on the promises they are supposed to deliver.

This means the following:

• L1 needs to speed up scaling blobs.

• L1 also needs 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 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, 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 needs are met. Some L2s will be governance-minimally based rollups, running exact copies of the L1 EVM. Others will try to use different VMs. Others will be more like servers that use Ethereum to provide additional security for users. We need L2s in every part of this spectrum.

• We should explicitly think 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 of these topic areas 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 this number almost exactly.

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, ideally with nothing else besides PeerDAS and EOF. PeerDAS could increase the number of blobs by another 2-3x.

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 then move on from there. With this, and improvements in data compression, we could get to 100,000 TPS on-chain.

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

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

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

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

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

Increasing 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 rollups (i.e. multisig) in phase 0. This needs to change. One 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 + Multi-Prover + Formal Verification:Use multiple proof systems for redundancy and use formal verification (see: the proven ZK-EVM initiative) to ensure its security.

• Native Rollups: Make EVM state transition function verification part of the protocol itself, e.g. via precompiles (for research, see: [1] [2] [3]).

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

Native Rollups is still an early idea. There is a lot of active thinking to be done, especially on the topic of how to make native rollups 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 the native rollups precompile and just "bring your own prover" for the modifications. This could be for precompiles, opcodes, state trees, and possibly other parts.

Interoperability and Standards

The goal is that the experience of moving assets and using applications between different L2s should be the same as if they were different “shards” of the same blockchain. For months there has been a fairly easy to follow roadmap for how to do this:

• Chain-specific addresses:An address should include an account on the chain and some kind of identifier for the chain itself. ERC-3770 was an early attempt at this, and there are now more sophisticated ideas that also move the L2’s 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 done in minutes (eventually one timeslot) instead of 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 with keystore wallets.

• Shared ordering and other long-term 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’s still a lot of room for L2s to have properties that are very different from each other: try different VMs, different ordering models, scale vs. security tradeoffs, and other differences. However, users and application developers must be clear about the level of security they’re getting.

To make faster progress, much 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 effort and make it easier to adopt the standard because each individual L2 and wallet will have to do less work. However, as Ethereum scales, L2s 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-Point Asset

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

• Broadly agree to solidify ETH as the primary asset for the larger (L1+L2) Ethereum economy, supporting applications that use ETH as primary collateral, etc.

• Encourage L2 to back ETH via a percentage of fees. This could be done by burning a portion of fees, perpetually staking and donating proceeds to Ethereum ecosystem public goods, or some other scheme.

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

• Increase blob count, consider minimum blob price, and consider blobs as another possible source of revenue. As an example of a possible future, if you take the average blob fee over the past 30 days, and assume it remains constant (due to induced demand) while the number of blobs increases to 128, then 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.

Summary: The Road Ahead

Ethereum as a technology stack and social ecosystem has matured, 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 a lot of work to do, and now is the time to redouble our efforts.

If you are an L2 developer, contribute to tooling to make blobs scale more securely, contribute to code to extend EVM execution, and contribute to features and standards that make L2 interoperable. If you are a wallet developer, please also contribute and implement standards to make the ecosystem more seamless for users while being 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 require active thinking and brainstorming. The future of Ethereum depends on the active participation of each of us.