Analysis of Ethereum Technology Upgrade The Surge

Since October this year, the co-founder of Ethereum has published a series of articles on the potential futures of the Ethereum protocol, covering six parts of the Ethereum development roadmap. This article will interpret the second part of the series, The Surge, focusing on Ethereum's scalability and long-term development. From the technological roadmap of this stage, we can gain insight into how Ethereum will transform into a protocol capable of handling enormous demand (TPS reaching 100,000+), while maintaining decentralization and security.

Ethereum's Core Vision

Essentially, Ethereum aims to be the foundational layer of the decentralized internet. Ether supports complex decentralized applications through automatically executed smart contract code, and this flexibility makes it the preferred blockchain for developers to build decentralized applications including DeFi, NFTs, and more.

However, Ethereum has limitations in terms of scalability. Ethereum L1 can only process about 15 to 30 transactions per second, which is a significant gap compared to traditional payment networks. This leads to high gas fees during network congestion and limits Ethereum's ability to become a globally scaled infrastructure. This is precisely the issue that The Surge aims to address.

The main objectives of The Surge are as follows:

• Ethereum L1+L2 reaches 100,000+ TPS;
• Maintain the decentralization and robustness of L1;
• At least some L2 fully inherit the core attributes of Ethereum (trustless, open, censorship-resistant);
• Maximize interoperability between L2s: Ethereum should function as an ecosystem, rather than as dozens of different blockchains.

The Future Centered Around Rollups

The Surge refers to Ethereum's plan to significantly improve scalability, primarily through L2 solutions. Rollups are a key component of this strategy. The rollup-centered roadmap proposes a simple division of labor: Ethereum L1 focuses on being a robust and decentralized base layer, while L2 takes on the task of helping the ecosystem scale.

Rollups package transactions off-chain and then submit them back to the Ethereum mainnet, significantly increasing throughput while maintaining security and decentralization. Rollups can enhance Ethereum's scalability to over 100,000 TPS. This will be a transformative expansion, as it allows Ethereum to handle globally scaled applications without compromising its decentralized spirit.

The rollup-centric roadmap is seen as a long-term scaling solution. Ethereum 2.0 has reduced energy consumption by transitioning from PoW to PoS through The Merge, while rollups are considered the next significant milestone as a long-term scaling solution.

This year, the rollup-centric roadmap has achieved significant results: with the launch of EIP-4844 blobs, the data bandwidth of Ether L1 has greatly increased, and multiple Ethereum Virtual Machine (EVM) rollups have entered the first phase. Each L2 exists as a shard with its own internal rules and logic, and the diversity and pluralism of shard implementation methods have now become a reality.

Data Availability Sampling (DAS) further development

Another key aspect of The Surge is data availability sampling (DAS), a technique designed to address data availability issues. In decentralized networks like Ethereum, it's crucial that all nodes can verify data without needing to store or download everything.

DAS allows nodes to verify data without accessing the complete dataset, thereby improving scalability and efficiency.

There are two forms of DAS: PeerDAS and 2D DAS. PeerDAS is expected to enhance the trust assumptions in rollups, making them more secure. 2D DAS performs random sampling not only within blobs but also between blobs. By utilizing the linear properties of KZG commitments, a set of new virtual blobs is introduced to expand the blob set within a block, encoding the same redundant information.

With DAS, Ethereum can handle larger amounts of data, enabling faster and cheaper rollups without compromising decentralization.

In the further stages of the future, more work needs to be done to determine the ideal version of 2D DAS and to prove its security attributes.

The long-term realistic path is:

1. Implement the ideal 2D DAS;
2. Persist in using 1D DAS, sacrificing sampling bandwidth efficiency, and accepting a lower data limit for simplicity and robustness;
3. Abandon DA and fully adopt Plasma as the main Layer2 architecture.

It is worth noting that even if the decision is made to directly scale execution on the L1 layer, this option still exists. This is because if the L1 layer is to handle a large amount of TPS, the L1 blocks will become very large, and clients will want an efficient way to verify their correctness. Therefore, they will have to use the same techniques on the L1 layer as rollups (such as ZK-EVM and DAS).

Plasma and Other Solutions

In addition to Rollup, one of the early proposed off-chain scaling solutions, Plasma, is also another type of L2 solution.

Plasma creates child chains that process transactions independently of the main Ethereum chain and regularly submit summaries to the main network. For each block, the operator sends a Merkle branch to each user to prove the change in the user's asset state. Users can withdraw their assets by providing the Merkle branch. Importantly, this branch does not have to be rooted in the latest state.

Therefore, even if there are issues with data availability, users can still recover their assets by extracting the latest available state. If a user submits an invalid branch (for example, attempting to extract assets that have already been sent to others, or if the operator has arbitrarily created an asset), the legitimate ownership of the asset can be determined through the on-chain challenge mechanism.

Although the development of Plasma has lagged behind rollups to some extent, it is still regarded as part of Ethereum's broader scalability toolkit.

In addition, there is discussion about improving data compression techniques and cryptographic proofs to further enhance the efficiency of rollups and other L2 solutions. The idea is to compress as much data as possible while ensuring that all necessary information is still available for Ethereum nodes to validate. These technological improvements are likely to play a key role in achieving higher throughput on Ethereum.

Early versions of Plasma could only handle payment use cases and were not effective for further promotion. However, if each root is verified using SNARK, then Plasma becomes much more powerful. The process can be greatly simplified as most potential paths for operator cheating are excluded. At the same time, it also opens up new paths, allowing users to immediately withdraw funds without waiting for a week-long challenge period, provided that the operator does not cheat.

One method (not the only method) to create an EVM plasma chain is to construct a parallel UTXO tree using ZK-SNARKs that reflects the balance changes made by the EVM, defining a unique mapping of "the same coin" at different historical periods. Plasma structures can then be built on top of this.

The performance of Plasma is quite good, which is also a key reason why everyone is designing technical structures to overcome its security shortcomings.

Cross-L2 Interoperability Improvements

One of the main challenges facing today's L2 ecosystem is the weak interoperability between L2s, and how to make the experience of using the L2 ecosystem feel like using a unified Ethereum ecosystem is an urgent issue that needs improvement.

There are many categories of cross L2 interoperability improvements. Theoretically, Rollup-centric Ethereum is similar to execution sharding L1. The current Ethereum L2 ecosystem still faces the following issues in practice before reaching the ideal state:

• Specific chain address: The address should contain chain information (L1, Optimism, Arbitrum......). Once this is achieved, the cross L2 sending process can be implemented simply by placing the address in the send field, at which point the wallet can handle how to send in the background (including using cross-chain protocols).

• Payment requests on a specific chain: Should be able to easily and standardize create messages in the form of "Send me X amount of Y type tokens on chain Z". This mainly has two application scenarios: payments between individuals or payments between individuals and merchant services; dApp requests for funds.

• Cross-chain exchange and Gas payment: There should be a standardized open protocol to express cross-chain operations. ERC-7683 and RIP-7755 are attempts in this field, although the applications of both are broader than these specific use cases.

• Light Client: Users should be able to actually verify the chain they are interacting with, rather than just trusting the RPC provider. ERC-3668 (CCIP-read) is one strategy to achieve this.

• Shared Token Bridge Concept: In a world where all L2s are validity proof rollups and each slot submits to Ethereum, transferring an asset from one L2 to another in its native state still requires withdrawals and deposits, which incurs a significant amount of L1 Gas fees.

One way to solve this problem is to create a shared minimalist Rollup whose sole function is to maintain which L2 owns each type of token and how much balance each holds, and to allow these balances to be updated in bulk through a series of cross-L2 send operations initiated by any L2. This would enable cross-L2 transfers without having to pay L1 gas fees for each transfer, nor would it require using liquidity provider-based technologies such as ERC-7683.

• Synchronous composability: Allows for synchronous calls to occur between specific L2s and L1, or between multiple L2s. This helps to improve the financial efficiency of DeFi protocols. The former can be achieved without any cross-L2 coordination; the latter requires shared ordering. Rollup-based technologies automatically apply to all these technologies.

Many of the examples above face the dilemma of when to standardize and which layers to standardize. If standardization occurs too early, it may entrench a poor solution. If standardization occurs too late, it may cause unnecessary fragmentation.

A current consensus is that in certain cases, there exists a short-term solution that has weaker attributes but is easier to implement, as well as a "final correct" long-term solution that may take years to realize. These tasks are not merely technical issues; they are also (and may primarily be) social issues that require cooperation between L2 and wallets, as well as L1.

Continue to expand Ethereum L1

Expanding Ethereum L1 itself and ensuring that it can continue to accommodate an increasing number of use cases is very valuable.

There are three strategies for L1 expansion, which can be carried out individually or in parallel:

1. Improve technology (e.g., client code, stateless clients, historical expiration) to make L1 easier to verify, then increase the Gas limit;
2. Reduce the cost of specific operations while increasing average capacity without increasing worst-case risk;
3. Native Rollups (i.e., creating N parallel copies of EVM).

These different technologies each have their own trade-offs. For example, native rollups share the same weakness in composability as regular rollups: they cannot send a single transaction to synchronously execute operations across multiple rollups. Increasing the Gas limit may undermine other benefits achievable through simplified L1 verification, such as increasing the proportion of users running verification nodes and increasing the number of solo stakers. Depending on the implementation, making specific operations in the EVM cheaper may increase the overall complexity of the EVM.

Decentralization and Security

The balance between scalability and decentralization is one of the repeatedly mentioned themes. Many blockchain projects choose to sacrifice decentralization for higher throughput. For example, a certain blockchain each