We need to continue building the technical and social characteristics of Ethereum, as well as its practicality. If we have the former but lack the latter, then we will degenerate into an increasingly ineffective "decentralized" community, becoming a group that can only loudly condemn the unethical behavior and mistakes of mainstream actors, but is unable to provide better alternatives. If we have the latter but lack the former, then we will precisely fall into the same "greed is good" mentality as Wall Street, which is exactly what many people came here to escape.
The binary I just described has many implications. In this article, I want to focus on one specific implication that is crucial for Ethereum users in the short and medium term: Ethereum's scaling strategy.
The Rise of Layer 2
Today, the path we use to scale Ethereum is Layer 2 protocols (L2s). L2 in 2025 has made huge strides compared to the early experiments in 2019: they have achieved critical decentralization milestones, are protecting billions of dollars in value, and are currently expanding Ethereum's transaction capacity by 17x while significantly reducing transaction fees.

All of this is happening just as a wave of successful applications is arriving: various DeFi platforms, social networks, prediction markets, fantastical devices like Worldchain (now with 10 million users), etc. The widely dismissed "enterprise blockchain" movement has also been revived with the rise of L2, with Soneium providing a leading example.
These successes also prove the social aspect of Ethereum's decentralized and modular scaling approach: the Ethereum Foundation does not need to find all these users themselves, but has dozens of independent entities incentivized to do so. These entities have also made critical contributions to the technology, without which Ethereum could not have gotten to where it is today. As a result, we are finally approaching a tipping point.
Challenges: Scalability and Heterogeneity
The two main challenges facing current L2s are:
- Scalability: Our "blob space" can barely cover the current L2s and use cases, but is far from sufficient for future needs.
- The Challenge of Heterogeneity: The early vision for how Ethereum would scale was to create a blockchain with multiple shards, each a copy of the EVM, processed by a small number of nodes. Theoretically, L2 is the realization of this approach. However, in practice, there is a key difference: each shard (or set of shards) is created by a different entity, the infrastructure treats them as different chains, and they often follow different standards. Today, this translates into problems for developers and users in terms of composability and user experience.
The first problem is an easily understandable technical challenge, and has an easily described (but difficult to implement) technical solution: give Ethereum more blobs. In addition, the L1 can also make moderate scaling improvements in the short term, as well as improvements to proof-of-stake, statelessness and light verification, storage, the EVM, and cryptography.
The second problem, the coordination problem, has already attracted the attention of much of the public. Ethereum is no stranger to coordinating complex technical tasks across multiple teams: after all, we completed the Merge. Here, the coordination problem is more challenging because the number and diversity of participants and goals is greater, and the process started later. But even so, our ecosystem has solved difficult problems before, and we can do it again.
One possible shortcut to scaling is to abandon L2 and do all operations through the L1, significantly increasing the Gas limit (whether across multiple shards or on a single shard). However, this would compromise many of the advantages of Ethereum's current social structure, which has been highly effective at simultaneously capturing the benefits of different forms of research, development, and ecosystem-building cultures. Therefore, we should stick to the established path, scaling primarily through L2, but ensuring that L2 can deliver on their original promises.
This means the following:
- L1 needs to accelerate the expansion of blob space.
- L1 also needs moderate EVM expansions and Gas limit increases to handle the various activities that will still exist even in an L2-dominated world (e.g., proofs, large-scale DeFi, deposits and withdrawals, special large-scale exit scenarios, key vault wallets, asset issuance, etc.).
- L2 needs to continue improving security. They should be able to provide the same security guarantees as sharding (including, for example, censorship resistance, light client verifiability, lack of embedded trusted parties, etc.).
- L2 and wallets need to accelerate interoperability improvements and standardization. This includes chain-specific addresses, messaging and bridging standards, efficient cross-chain payments, on-chain configuration, etc. Using Ethereum should feel like using a single ecosystem, not 34 different blockchains.
- L2 deposit and withdrawal times need to become faster.
- Heterogeneity in L2 is good as long as basic interoperability needs are met. Some L2 will be minimally-governed Rollups running full EVM copies of L1. Others will experiment with different virtual machines (VMs). And some will be more like servers using Ethereum to provide additional security guarantees. We need L2 across this spectrum.
- We should think explicitly about ETH economics. We need to ensure that ETH can continue to accrue value even in an L2-dominated world, ideally solving the value accrual problem for different models.
Now let's discuss these topic areas in more detail.
Scalability: Blobs, Blobs, Blobs
With the implementation of EIP-4844, we now have 3 blobs per block, or 384 KB of data bandwidth per block. A simple calculation shows that this is equivalent to 32 KB per second, and with each transaction taking about 150 bytes, we can achieve around 210 transactions per second. Data from L2beat gives almost exactly the same numbers.
With the release plan for Pectra scheduled for March, we plan to double this number to 6 blobs per block.
Currently, Fusaka's goal is to primarily focus on PeerDAS, ideally containing only PeerDAS and EOF. PeerDAS can further increase the blob count by 2-3 times.
After that, the goal is to continue increasing the blob count over time. When we reach 2D sampling, we can achieve 128 blobs per block and continue to increase. At this point, combined with improvements in data compression techniques, we can achieve on-chain processing capacity of 100,000 transactions per second.
So far, the above content is just a restatement of the roadmap for the current state before 2025. The key question is: what can we actually change to accelerate this process? My answers are as follows:
- We should be more willing to explicitly relegate non-blob functionality to a secondary position.
- We should more clearly state that blobs are the ultimate goal and make related p2p R&D work a priority for talent acquisition.
- We can allow stakers to directly adjust the blob target, similar to the Gas limit. This will allow the blob target to grow faster with technological progress, without waiting for hard forks.
- We can consider some more aggressive approaches, by making more trust assumptions to accelerate the acquisition of more blobs, which can be achieved among resource-constrained stakers, but we should be cautious about this.
Improving 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). Most activity still takes place on Stage 0 Rollups (i.e., multi-signatures). This needs to change. One of the main reasons this change has not happened faster is that building a proof system and having enough confidence in it to be willing to forgo auxiliary tools and rely on it entirely for security is a very difficult challenge.
The two paths to this goal are:
- Stage 2 + Multi-Prover + Formal Verification: Using multiple proof systems to provide redundancy and using formal verification (see: Verified ZK-EVM Initiative) to gain confidence in their security.
- Native Rollups: Integrating the verification of EVM state transition functions as part of the protocol itself, for example through pre-compilation (see: [1] [2] [3] for research).
Today, we should pursue these two directions in parallel. For Stage 2 + Multi-Prover + Formal Verification, the roadmap is relatively clear. The main areas we can accelerate are more collaborative software stack development, reducing duplication of work, and increasing interoperability as a byproduct.
Native Rollups are still early-stage concepts. Significant active thinking is currently needed, especially on how to make native Rollup pre-compilation as flexible as possible. The ideal goal is to support not only precise clones of the EVM, but also EVMs with various arbitrary changes, so that L2s with modified EVMs can still use native Rollup pre-compilation and only need to "bring their own prover" for the modified parts. This can apply to pre-compilation, opcodes, state trees, and even other parts.
Interoperability and Standards
The goal is to have the same experience when moving assets and using applications between different L2s as if they were different "shards" of the same blockchain. Over the past few months, there has been a relatively clear roadmap to achieve this goal:
- Chain-Specific Addresses: Addresses should include on-chain accounts and some form of chain identifier. ERC-3770 is an early attempt at this concept, and now there are more refined ideas that also move the L2 registry to the Ethereum L1 itself.
- Standardized Cross-Chain Bridging and Cross-Chain Messaging: There should be standard ways to verify proofs and pass messages between L2s, without relying on any trust assumptions beyond the L2's own proof systems. Ecosystems relying on multi-signature bridges are unacceptable. If this is a trust assumption that would not exist if we adopted 2016-style sharding, then today such an assumption is unacceptable, without a doubt.
- Accelerated Deposit and Withdrawal Times: To have "local" messages complete in minutes (ultimately a block) rather than weeks. This involves faster ZK-EVM provers and proof aggregation technology.
- L2 Reading from L1 Synchronously: See: L1SLOAD, REMOTESTATICCALL. This greatly simplifies cross-L2 interoperability and also benefits key management wallets.
- Shared Ordering and Other Long-Term Work: Part of the value of Rollups is that they may be able to do these more efficiently.
As long as standards like these are met, there is still plenty of room for L2s to have different properties: for example, experimenting with different virtual machines, different ordering models, tradeoffs between scale and security, and other differences. However, users and application developers must be made clearly aware of the level of security they are obtaining.
To accelerate progress, various entities in the ecosystem (such as the Ethereum Foundation, client development teams, major application teams, etc.) can do most of the work. This will reduce the coordination overhead and make standard adoption simpler, as the work required for each L2 and wallet will be reduced. However, as extensions of Ethereum, L2s and wallets still need to put in the "last mile" effort to actually implement these features and deliver them to users.
The Economics of ETH

We should take a multi-pronged approach that covers all the main sources of value for ETH as a tripoint asset. Some key components of this strategy may include:
- In general, a consensus has been reached to establish ETH as the primary asset of the larger (L1 + L2) Ethereum economy, supporting the use of ETH as the main collateral for applications.
- Encourage L2 to support ETH, allocating a portion of fees to ETH. This can be achieved through burning a portion of fees, permanently staking and donating the proceeds to public goods in the Ethereum ecosystem, or adopting other various approaches.
- Support Rollups based on, as a way for L1 to capture value through MEV, but should not force all Rollups to be based on this (as it does not work for some applications), and do not assume that this alone can solve the problem.
- Increase the number of Blobs, consider a minimum Blob price, and view Blobs as another potential revenue source. For example, assuming that the average Blob fee over the past 30 days is maintained (driven by demand), and the number of Blobs increases to 128, Ethereum would burn 713,000 ETH per year. However, this demand curve is not guaranteed to be effective, so do not rely solely on this to solve the problem.
Summary: The Path Forward
Ethereum, as a technical stack and social ecosystem, has matured, bringing us closer to a more free and open future, where billions of people will 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 the development of tools that can safely scale Blobs, contribute to expanding the code execution of your EVM, and contribute to making L2 interoperability functions and standards. If you are a wallet developer, also actively participate in contributing and implementing standards to make the ecosystem more seamless for users, while maintaining the same level of security and decentralization as when Ethereum was the L1. If you are an ETH holder or community member, please actively participate in these discussions; there are still many areas that need proactive thinking and collective wisdom. The future of Ethereum depends on each of us actively participating in it.