Under Public Pressure, Vitalik Calls on L2: Support ETH Again

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

Original author: Vitalik

Original text compiled by: Odaily Planet Daily

Ethereum’s goal has not changed since day one: to build a global, censorship-resistant, permissionless blockchain platform. This is a free and open platform for decentralized applications, whose principles resonate with those of GNU + Linux, Mozilla, Tor, Wikipedia, and many great free and open-source software projects (which can now be referred to as the spirit of regeneration and cypherpunk).

Over the past decade, Ethereum has also developed a characteristic that I greatly appreciate: in addition to innovations in cryptography and economics, Ethereum is also a social technological innovation. The Ethereum ecosystem as a whole demonstrates a more open and decentralized way of collaboration. Political philosopher Ahmed Gatnash described his experience at Devcon as follows:

… This allowed me to glimpse what an alternative world could look like—a world with almost no barriers, completely disconnected from traditional systems. Here, the social hierarchy of status is upended, and those who hold the highest social status are the geeks who focus on independently solving the issues they deeply care about, rather than those who play games to climb the ladder of traditional institutions and accumulate power. Here, almost all power is soft power. I find this beautiful and very inspiring—it makes one feel that in such a world, anything is possible, and that world is actually within reach.

Technical projects and social projects are inherently intertwined. If at time point T you have a decentralized technical system, but it is maintained by a centralized social process, there is no guarantee that your technical system will remain decentralized at time point T+1. Similarly, social processes are also maintained in various ways by technology: technology attracts users, the ecosystem created by technology provides retention incentives for developers, and technology grounds the community in building rather than just socializing, etc.

After ten years of effort, under the joint governance of technical and social attributes, Ethereum has shown another important quality: Ethereum can provide practical services to people on a large scale. Millions use ETH or stablecoins as a means of saving, and more people use these assets for payments: I am one of them. Ethereum has efficient and practical privacy tools that I use to pay for VPN services to protect my internet data. It also has ENS, a robust decentralized alternative for DNS and a broader public key infrastructure. Additionally, Ethereum features easy-to-use decentralized Twitter alternatives and DeFi tools that provide hundreds of millions with higher yields and lower risks than traditional finance.

Five years ago, I was reluctant to discuss the latter’s use cases, mainly because the infrastructure and code were not yet mature. I had just experienced those large-scale, painful smart contract hacking incidents of 2016-2017, and if there was a 5% probability of losing 100% of returns each year, a 7% annual yield would be meaningless compared to a 5% annual yield. Furthermore, transaction fees were too high to enable the large-scale application of these tools. Today, these tools have proven their resilience over time, the quality of auditing tools has improved, and we are increasingly confident in their security. We have learned what not to do. L2 scaling technology is working, and transaction fees have remained at very low levels for almost a year.

We need to continue enhancing the technical and social attributes of Ethereum as well as its practicality. If we have only the former without the latter, we will become an increasingly ineffective ‘decentralized’ community that only protests the ‘immoral and erroneous behavior’ of mainstream institutions without truly providing better alternatives. If we have only the latter without the former, we will be no different from Wall Street’s ‘greed is good’ mentality, which many people joined the Ethereum community to escape.

This duality of technology and practicality has many far-reaching implications. In this article, I want to focus on a specific aspect that is crucial for Ethereum users in the short and medium term: Ethereum’s scaling strategy.

The rise of Layer 2

Today, our path to scale Ethereum is through Layer 2 protocols. The Layer 2 of 2025 has made tremendous leaps compared to the early experiments of 2019: they have reached key decentralization milestones, protecting billions of dollars in assets, and have increased Ethereum’s transaction capacity by 17 times while reducing fees by the same margin.

All of this is happening just as a wave of successful applications is emerging: various DeFi platforms, social networks, prediction markets, and novel projects like Worldchain (which already has 10 million users). Additionally, the ‘enterprise blockchain’ movement, which was considered a dead end in the 2010s due to the failure of consortium chains, is revitalizing with the rise of Layer 2, with Soneium being a prominent example.

These successes also demonstrate the social advantages of Ethereum’s decentralized and modular scaling approach: the Ethereum Foundation does not need to personally find all users, but rather has dozens of independent entities spontaneously driving it. These entities have also made crucial contributions to the technology; without them, Ethereum could not have achieved today’s success. It is for this reason that we are finally approaching ‘escape velocity’.

Challenge: Scaling and heterogeneity handling

Currently, Layer 2 faces two major challenges:

• Scaling: The current ‘Blob space’ barely supports existing Layer 2 and its application scenarios, but it is far from sufficient to meet future demands.

• Heterogeneity issue: Ethereum’s initial scaling vision was to create a blockchain composed of multiple shards, each a copy of the EVM, processed by a small number of nodes. Theoretically, Layer 2 is the realization of this vision. However, there is a key difference in practice: each shard (or group of shards) is created by different participants, treated as different chains within the infrastructure, and often follows different standards. This situation brings issues for developers and users in terms of composability and user experience.

The first question is an easily understandable technical challenge, with a simple solution but difficult implementation: providing more ‘Blob space’ for Ethereum. Additionally, Ethereum L1 can relieve pressure in the short term through moderate scaling and improvements in proof of stake, stateless and light verification, storage, EVM, and cryptographic techniques.

The second question is a coordination challenge that has garnered widespread public attention. The Ethereum ecosystem is no stranger to completing complex technical tasks through cross-team collaboration—after all, we accomplished The Merge. However, the coordination issues here are more challenging because the number of participants is larger, the goals are more diverse, and the process started later. But even so, our ecosystem has solved many difficult problems in the past, and we can do it again this time.

One possible shortcut to scaling is to abandon Layer 2 and achieve much higher gas limits directly through Layer 1 (whether through multiple shards or a single shard). However, this approach would sacrifice too much of the advantages of Ethereum’s current social structure, which is extremely effective in integrating different forms of research, development, and ecosystem building culture. Therefore, we should stick to the existing roadmap and continue to scale primarily through Layer 2 while ensuring that Layer 2 truly delivers on its promises.

This means the following points:

• Layer 1 needs to accelerate the expansion of Blob capacity.

• Layer 1 also needs to moderately scale the EVM and increase gas limits to cope with activities that Layer 1 will still support even in a Layer 2-dominated environment (such as zero-knowledge proofs, large-scale DeFi, deposit and withdrawal operations, special large-scale exit scenarios, key storage wallets, asset issuance, etc.).

• Layer 2 needs to continuously enhance security. Layer 2 should provide the same security guarantees as sharding (including censorship resistance, light client verifiability, no embedded trusted parties, etc.).

• Layer 2 and wallets need to accelerate improvements and standardize interoperability. This includes chain-specific addresses, messaging and cross-chain bridge standards, efficient cross-chain payments, on-chain configuration, etc. Using Ethereum should feel like using a single ecosystem rather than 34 different blockchains.

• Layer 2 withdrawal times need to be significantly shortened.

• As long as basic interoperability needs are met, the heterogeneity of Layer 2 is beneficial. Some Layer 2s will be Rollups based on governance minimization, running an exact copy of Layer 1 EVM; some Layer 2s will experiment with different virtual machines; others will behave more like servers, leveraging Ethereum to provide users with additional security. We need a range of Layer 2s that cover this spectrum.

• We need to clearly consider the economics of ETH. Even in a world dominated by Layer 2, we must ensure that ETH can continue to accumulate value and provide solutions for various value accumulation models.

Next, we will discuss each topic in detail.

Scaling: Blob, Blob, or Blob

In EIP-4844, there are 3 Blobs per slot, with a data bandwidth of 384 kB per slot. A simple estimate indicates that this corresponds to about 32 kB per second, and each transaction occupies about 150 bytes on-chain, so we can support about 210 transactions per second (TPS). According to data from L2beat, this estimate matches almost perfectly.

Pectra, scheduled for release in March, will double the number of Blobs to 6 per slot.

Currently, Fusaka’s goals are mainly focused on PeerDAS, with plans to prioritize only the implementation of PeerDAS and EOF. PeerDAS could potentially increase the number of Blobs by 2-3 times.

The next goal is to continuously increase the number of Blobs. When 2D sampling is reached, the number of Blobs can be increased to 128 per time slot, with further increases possible in the future. Combined with improvements in data compression, on-chain TPS can reach 100,000.

The above is a reiteration of the established roadmap before 2025. The key question is: how do we accelerate this process? My answer is as follows:

• More clearly deprioritize non-Blob functionalities.

• More clearly indicate that Blobs are the target and list related point-to-point development as a priority for talent recruitment.

• Allow stakers to directly adjust Blob targets, similar to gas limits. This will enable Blob targets to increase more quickly with technological improvements without waiting for a hard fork.

• More aggressive approaches can be considered to increase the number of Blobs more quickly by introducing more trust assumptions for low-resource stakers, but we need to approach this cautiously.

Enhancing security: Proof systems and local Rollups

Currently, there are three stage 1 Rollups (Optimism, Arbitrum, Ink) and three stage 2 Rollups (DeGate, zk.money, Fuel). However, most activity still occurs on stage 0 Rollups (i.e., multi-signature schemes). This situation needs to change. One significant reason why the process is slow to change is that building a reliable proof system and establishing sufficient confidence to fully rely on its security (abandoning ‘training wheels’) is very challenging.

To achieve this goal, there are two paths:

• Phase 2 + multi-proof systems + formal verification: Achieve redundancy through multiple proof systems and enhance security confidence through formal verification (e.g., ‘verified ZK-EVM projects’).

• Local Rollup: Integrate the verification of EVM state transition functions into the protocol itself, such as through precompiled contracts.

At the current stage, both paths need to be advanced in parallel. For ‘Phase 2 + multi-proof systems + formal verification’, the roadmap is relatively clear. Development can be accelerated by strengthening cooperation in the software stack, which not only reduces redundant work but also enhances interoperability as a by-product.

For local Rollups, this is still in the early stages, and more thought is needed on how to maximize the flexibility of precompiled contracts. An ideal goal is to support not just a complete clone of the EVM, but also an EVM that includes arbitrary modifications, allowing modified EVM Rollups to still use the precompiled contracts of the local Rollup, only introducing custom provers for their modified parts. This may involve adapting precompiled contracts, opcodes, state trees, and other components.

Interoperability and standardization

The goal is to make the experience of transferring assets between different L2s and using applications as seamless as interactions between different ‘shards’ on the same blockchain. Currently, there is a relatively clear roadmap in this regard:

• Chain-specific address: The address should include account information on the chain as well as the identifier for the chain itself. For example, ERC-3770 is an early attempt, and there are now more complex designs, even migrating the registry of L2 to Ethereum L1.

• Standardization of cross-chain bridges and messaging: There should be standardized methods to verify proofs and transfer messages between L2s, and these standards should not rely on trust mechanisms like multi-signature bridges. An ecosystem dependent on multi-signature bridges is unacceptable. If this trust assumption was absent in the sharding design of 2016, it is equally unacceptable today.

• Accelerating deposit and withdrawal times: The time for ‘local’ messages should be reduced from weeks to minutes (the ultimate goal is one block time). This requires faster ZK-EVM provers and support for proof aggregation techniques.

• Synchronously reading L1 data from L2: For example, L1SLOAD and REMOTESTATICCALL, these functions will greatly simplify interoperability across L2s while also aiding the functionality of key store wallets.

• Shared ordering and other long-term work: The design based on Rollups has value partly because it can achieve functionalities like shared ordering more efficiently.

Given these standards, L2 can differ in security, performance, and design models according to demand. For instance, different virtual machines, ordering models, and trade-offs between scale and security can be explored. But for users and developers, the security levels of each L2 must be clearly defined.

To expedite progress, cross-domain institutions within the ecosystem can take on a larger share of the work, such as the Ethereum Foundation, client development teams, and mainstream application development teams. This will reduce coordination costs, making the adoption of standards an easier decision, as the development workload for each L2 and wallet will subsequently decrease. However, as an extension of the Ethereum ecosystem, L2 and wallets also need to strengthen the ‘last mile’ of development work to ensure these features are truly delivered to users.

The economics of ETH

We should adopt a multi-faceted strategy that covers all major potential value sources for ETH as a triple asset. Key components of this strategy may include the following points:

• Widely reach consensus to solidify ETH as the primary asset of the larger (L1 + L2) Ethereum economy, supporting applications that use ETH as the primary collateral.

• Encourage L2s to support ETH and allocate a portion of fees. This can be achieved by burning a portion of fees, permanently staking fees and donating the proceeds to Ethereum ecosystem public goods, or through other various means.

• Support Rollup-based designs, partly as a path for L1 to capture value through MEV, but all Rollups should not be forced to be based on this design, as it does not apply to all applications, and it cannot be assumed that this method alone can solve all problems.

• Increase the number of Blobs, consider setting a minimum price for Blobs, and treat Blobs as another possible source of revenue. For example, assuming the average fee for Blobs over the past 30 days remains constant (driven by demand), while the number of Blobs increases to 128, Ethereum will destroy 713,000 ETH annually. However, the demand curve may not be so favorable, so this alone cannot solve the problem.

Conclusion: The Road Ahead

Ethereum has matured in both its technical stack and social ecosystem, leading us toward a more free and open future, where hundreds of millions can benefit from crypto assets and decentralized applications. However, there is still a lot of work to be done, and now is the time to double down.

• If you are an L2 developer, participate in the development of tools to make Blobs scale more securely, develop code to scale the execution of EVM, and implement functions and standards that enable L2 to be interoperable.

• If you are a wallet developer, you also need to contribute and implement standards to ensure that the ecosystem provides seamless experiences for users while maintaining the same security and decentralization characteristics as Ethereum L1.

• If you are an ETH holder or community member, actively participate in these discussions; there are many areas that need in-depth thinking and brainstorming. Ethereum’s future relies on each of our active participation.