Original Title: Scaling Ethereum L1 and L2s in 2025 and beyond
Original Author: Vitalik
Original Translation: 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 are in line with 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 technology 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 gave me a glimpse of what an alternative world might look like—a world with almost no barriers, completely disconnected from traditional systems. Here, the social status hierarchy is upended, and the highest social status is held by those geeks focused on independently solving the issues they truly care about, rather than those playing the game 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 essentially intertwined. If you have a decentralized technical system at time T, but it is maintained by a centralized social process, there is no guarantee that your technical system will still be decentralized at time T+1. Similarly, social processes are also maintained by technology in various ways: technology attracts users, the ecosystems brought by technology provide retention incentives for developers, technology grounds the community, focusing on building rather than just socializing, and so on.
After ten years of effort, under the joint governance of technical and social attributes, Ethereum has demonstrated another important quality: Ethereum can provide practical services to people on a large scale. Millions of people use ETH or stablecoins as a form of savings, 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, there are user-friendly decentralized Twitter alternatives and DeFi tools on Ethereum, providing millions with higher yields and lower-risk assets compared to traditional finance.
Five years ago, I was reluctant to discuss the latter use cases, mainly because the infrastructure and code were not yet mature. We had just gone through the large-scale and painful smart contract hacks of 2016-2017, and if there was a 5% chance of losing 100% of the yield each year, then a 7% annual yield compared to a 5% annual yield was meaningless. Moreover, 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 know what not to do. L2 scaling technology is working, and transaction fees have remained very low for nearly a year.
We need to continue enhancing Ethereum's technical and social attributes as well as its practicality. If we only have the former without the latter, we will become an increasingly ineffective "decentralized" community that only protests against the "immoral and erroneous behaviors" of mainstream institutions without truly providing better alternatives. If we only have 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 scaling Ethereum is through Layer 2 protocols. The Layer 2 of 2025 has made significant leaps compared to the early experiments of 2019: they have achieved key decentralization milestones, are 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 has coincided with a wave of successful applications: various DeFi platforms, social networks, prediction markets, and novel projects like Worldchain (which now has 10 million users). Additionally, the "enterprise blockchain" movement, which was considered a dead end due to the failures of consortium chains in the 2010s, has been revitalized 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 seek out all users, but rather has dozens of independent entities spontaneously driving the effort. These entities have also made critical contributions to the technology; without them, Ethereum could not have achieved its current success. Because of this, we are finally approaching "escape velocity."
Challenges: Scaling and Heterogeneity Issues
Current Layer 2 faces two main challenges:
Scaling: The current "Blob space" is barely sufficient to support existing Layer 2 and its use cases, but it is far from enough to meet future demands.
Heterogeneity issues: Ethereum's original scaling vision was to create a blockchain composed of multiple shards, each shard being a copy of the EVM, processed by a small number of nodes. In theory, 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 in the infrastructure, and often follows different standards. This situation brings issues for developers and users regarding composability and user experience.
The first issue is an easily understood technical challenge, with a simple solution that is difficult to implement: providing more "Blob space" for Ethereum. Additionally, Ethereum L1 can alleviate pressure in the short term through moderate scaling, as well as improvements in proof of stake, stateless and light verification, storage, EVM, and cryptography.
The second issue is a coordination challenge and has already attracted widespread public attention. The Ethereum ecosystem is no stranger to completing complex technical tasks through cross-team collaboration—after all, we completed The Merge. However, the coordination issues here are more challenging because there are more participants, the goals are more diverse, and the process started later. Nevertheless, our ecosystem has solved many difficult problems in the past, and we can do so 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 sacrifices too much of the advantages of Ethereum's current social structure, which is very effective in integrating different forms of research, development, and ecosystem building culture. Therefore, we should stick to the current path, continue to scale primarily through Layer 2, while ensuring that Layer 2 truly delivers on its promises.
This means the following:
Layer 1 needs to accelerate the expansion of Blob capacity.
Layer 1 also needs to moderately scale the EVM and increase Gas limits to accommodate activities that Layer 1 will still host even in a Layer 2-dominant environment (e.g., 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 configurations, etc. Using Ethereum should feel like using a single ecosystem, not 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 2 will be based on governance-minimized Rollups, running identical copies of Layer 1 EVM; some Layer 2 will attempt different virtual machines; others will resemble servers, leveraging Ethereum to provide users with additional security guarantees. We need to cover a spectrum of Layer 2.
We need to clearly consider the economics of ETH. Even in a Layer 2-dominant world, 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, each slot has 3 Blobs, with a data bandwidth of 384kB per slot. A simple estimate indicates that this corresponds to 32kB per second, with each transaction occupying about 150 bytes on-chain, allowing us to support approximately 210 transactions per second (TPS). According to data from L2beat, this estimate aligns almost perfectly.
Pectra, scheduled for release in March, will double the number of Blobs to 6 per slot.
Currently, Fusaka's goals are primarily focused on PeerDAS, planning to prioritize only the implementation of PeerDAS and EOF. PeerDAS may further 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 could reach 100,000.
The above is a restatement of the established roadmap before 2025. The key question is: how do we accelerate this process? My answers are as follows:
More clearly lower the priority of non-Blob functionalities.
More clearly indicate that Blobs are the goal and list related peer-to-peer R&D as a priority for talent recruitment.
Allow stakers to directly adjust Blob targets, similar to Gas limits. This would enable Blob targets to increase more rapidly with technological improvements without waiting for hard forks.
Consider more aggressive methods to increase the number of Blobs more quickly by introducing more trust assumptions for low-resource stakers, but we need to be cautious about this.
Enhancing Security: Proof Systems and Native 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 for the slow change process is that building a reliable proof system and establishing sufficient confidence to fully rely on its security (abandoning "training wheels") is very difficult.
To achieve this goal, there are two paths:
Stage 2 + Multiple Proof Systems + Formal Verification: Achieve redundancy through multiple proof systems and enhance security confidence using formal verification (e.g., "verified ZK-EVM projects").
Native Rollup:
Integrate the verification of the EVM state transition function into the protocol itself, for example, through precompiled contracts.
At the current stage, both paths need to be advanced in parallel. For "Stage 2 + Multiple Proof Systems + Formal Verification," the roadmap is relatively clear. Development can be accelerated by strengthening collaboration in the software stack, which not only reduces redundant work but also enhances interoperability as a byproduct.
For native Rollups, this is still in the early stages, and more thought is especially 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 to support modified EVMs, allowing modified EVM Rollups to still use the precompiled contracts of native Rollups, only introducing custom provers for the 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 and using applications between different L2s as smooth as interactions between different "shards" on the same blockchain. Currently, there is a relatively clear roadmap in this area:
Chain-specific addresses: Addresses should include account information on the chain as well as identifiers for the chain itself. For example, ERC-3770 is an early attempt, and there are now more complex designs, even migrating the L2 registry to Ethereum L1.
Standardizing cross-chain bridges and messaging: There should be standardized methods to verify proofs and pass 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 such trust assumptions did not exist in the 2016 sharding design, they are also unacceptable today.
Accelerating deposit and withdrawal times: The time for "local" messages should be reduced from weeks to minutes (with the ultimate goal being one block time). This requires faster ZK-EVM provers and support for proof aggregation technologies.
Reading L1 data synchronously from L2: For example, L1SLOAD and REMOTESTATICCALL, these functions will greatly simplify interoperability across L2s while aiding the functionality of key storage wallets.
Shared ordering and other long-term work: One reason for the value of Rollup-based designs is that they can more efficiently implement features like shared ordering.
Under the premise of meeting these standards, L2s can differ in security, performance, and design models based on demand. For example, different virtual machines, ordering models, and trade-offs between scale and security can be explored. However, the levels of security for each L2 must be clearly defined for users and developers.
To accelerate 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 decrease accordingly. However, as an extension of the Ethereum ecosystem, L2s and wallets also need to strengthen the "last mile" of development work to ensure these features truly reach users.
The Economics of ETH
We should adopt a multi-faceted strategy that covers all major potential sources of value for ETH as a three-point asset. Key components of this strategy may include:
Broad consensus to solidify ETH as the primary asset in the larger (L1 + L2) Ethereum economic system, supporting applications that use ETH as the main collateral.
Encouraging L2s to support ETH and allocating a portion of fees. This can be achieved by burning a portion of fees, permanently staking fees and donating the proceeds to public goods in the Ethereum ecosystem, or through various other means.
Supporting Rollup-based designs as a partial path for L1 to capture value through MEV, but not forcing all Rollups to be based on this design, as it does not apply to all applications and cannot be assumed to solve all problems on its own.
Increasing the number of Blobs, considering setting a minimum Blob price, and treating Blobs as another potential source of income. For example, if the average Blob fee over the past 30 days remains unchanged (driven by demand), while the number of Blobs increases to 128, Ethereum would destroy 713,000 ETH annually. However, the demand curve may not necessarily be so favorable, so this alone cannot solve the problem.
Conclusion: The Path Forward
Ethereum has matured in both its technology 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 on our efforts.
If you are an L2 developer, participate in the development of tools to safely scale Blobs, develop code to scale EVM execution, and implement functionalities and standards that enable interoperability for L2s.
If you are a wallet developer, you also need to contribute and implement standards to ensure that the ecosystem provides a seamless experience 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 require in-depth thought and brainstorming. The future of Ethereum depends on the active participation of each of us.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
