Ethereum's Possible Future: The Surge

The roadmap for Ethereum initially included two scaling strategies: sharding and Layer 2 protocols. Sharding allows each node to verify and store only a small portion of transactions, while Layer 2 protocols build networks on top of Ethereum, leveraging its security while keeping most data and computation off the main chain. As research progressed, these two paths eventually merged, forming a Rollup-centric roadmap, which remains Ethereum's scaling strategy to this day.

The roadmap centered around Rollups presents a simple division of labor: Ethereum L1 focuses on being a robust and decentralized foundational layer, while L2 takes on the task of helping the ecosystem scale. This model is ubiquitous in society: the existence of the court system (L1) is not to pursue super speed and efficiency, but to protect contracts and property rights, while entrepreneurs (L2) build upon this solid foundational layer to drive human progress.

This year, the Rollup-centric roadmap has achieved significant results: with the launch of EIP-4844 blobs, the data bandwidth of Ethereum L1 has increased dramatically, and multiple Ethereum Virtual Machines (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. However, this path also faces some unique challenges. Therefore, our current task is to complete the Rollup-centric roadmap and address these issues while maintaining the robustness and decentralization unique to Ethereum L1.

The Surge: Key Objectives

1. In the future, Ethereum can achieve over 100,000 TPS through L2.

2. Maintain the decentralization and robustness of L1;

3. At least some L2 fully inherit the core attributes of Ethereum: trustlessness, openness, and censorship resistance.

4. Ethereum should feel like a unified ecosystem, not 34 different blockchains.

( The content of this chapter

1. Scalability Triangle Paradox
2. Further Developments in Data Availability Sampling
3. Data Compression
4. Generalized Plasma
5. Mature L2 Proof Systems
6. Improvements in Cross-L2 Interoperability
7. Expand execution on L1

) scalability triangle paradox

The scalability triangle paradox is an idea proposed in 2017, which suggests that there is a contradiction between three characteristics of blockchain: decentralization ###, specifically low costs of running nodes ###, scalability ( with a high number of transactions processed ), and security ( where an attacker needs to compromise a large portion of the nodes in the network to cause a single transaction to fail ).

It is worth noting that the triangle paradox is not a theorem, and posts introducing the triangle paradox do not come with a mathematical proof. It does provide a heuristic mathematical argument: if a decentralized-friendly node (, for example, a consumer-grade laptop ), can verify N transactions per second, and you have a chain that processes k*N transactions per second, then (i) each transaction can only be seen by 1/k of the nodes, which means an attacker only needs to compromise a few nodes to execute a malicious transaction, or (ii) your nodes will become powerful while your chain will not be decentralized. The purpose of this article is not to prove that breaking the triangle paradox is impossible; rather, it aims to show that breaking the ternary paradox is difficult and requires, to some extent, stepping outside the thinking framework implied by the argument.

For many years, some high-performance chains have claimed to resolve the trilemma without fundamentally changing the architecture, usually by applying software engineering techniques to optimize nodes. This is always misleading, as running nodes on these chains is much more difficult than running nodes on Ethereum. This article will explore why this is the case and why scaling Ethereum cannot be achieved solely through L1 client software engineering.

However, the combination of data availability sampling and SNARKs does solve the triangle paradox: it allows clients to verify that a certain amount of data is available and that a certain number of computational steps have been executed correctly while only downloading a small amount of data and performing minimal computation. SNARKs are trustless. Data availability sampling has a subtle few-of-N trust model, but it retains the fundamental property of a non-scalable chain, which is that even a 51% attack cannot force bad blocks to be accepted by the network.

Another way to solve the three difficult dilemmas is the Plasma architecture, which uses clever techniques to push the responsibility of monitoring data availability onto users in a compatibility-incentivized manner. As early as 2017-2019, when we only had fraud proofs as a means to scale computational capacity, Plasma was very limited in secure execution. However, with the popularity of SNARKs( zero-knowledge succinct non-interactive arguments of knowledge), the Plasma architecture has become more feasible for a wider range of use cases than ever before.

( Further progress on data availability sampling

)# What problem are we solving?

On March 13, 2024, when the Dencun upgrade goes live, the Ethereum blockchain will have 3 blobs of approximately 125 kB per slot every 12 seconds, or about 375 kB of available data bandwidth per slot. Assuming that transaction data is published directly on-chain, an ERC20 transfer is approximately 180 bytes, therefore the maximum TPS for Rollup on Ethereum is: 375000 / 12 / 180 = 173.6 TPS.

If we add the theoretical maximum value of Ethereum's calldata ###: each slot 30 million Gas / 16 gas per byte = each slot 1,875,000 bytes ###, then it becomes 607 TPS. Using PeerDAS, the number of blobs may increase to 8-16, which will provide 463-926 TPS for calldata.

This is a significant upgrade to Ethereum L1, but it's not enough. We want more scalability. Our medium-term goal is 16 MB per slot, which, combined with improvements in Rollup data compression, will bring ~58000 TPS.

(# What is it? How does it work?

PeerDAS is a relatively simple implementation of "1D sampling". In Ethereum, each blob is a 4096-degree polynomial over the 253-bit prime field ). We broadcast shares of the polynomial, where each share contains 16 evaluation values from 16 adjacent coordinates out of a total of 8192 coordinates. Among these 8192 evaluation values, any 4096 of ### can recover the blob based on the currently proposed parameters: any 64 out of 128 possible samples of (.

![Vitalik's New Article: The Possible Future of Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(

The working principle of PeerDAS is to have each client listen to a small number of subnets, where the i-th subnet broadcasts the i-th sample of any blob, and requests blobs on other subnets it needs by querying peers in the global p2p network, asking who will listen to different subnets ). A more conservative version, SubnetDAS, only uses the subnet mechanism without additional queries to the peer layer. The current proposal is to let nodes participating in proof of stake use SubnetDAS, while other nodes (, i.e., clients ), use PeerDAS.

Theoretically, we can scale a "1D sampling" quite large: if we increase the maximum number of blobs to 256( with a target of 128), then we can achieve a goal of 16MB, and with 16 samples per node in data availability sampling * 128 blobs * 512 bytes per sample per blob = 1 MB of data bandwidth per slot. This is just barely within our tolerance: it is feasible, but it means bandwidth-constrained clients cannot sample. We can optimize this to some extent by reducing the number of blobs and increasing the size of the blobs, but this will make the reconstruction cost higher.

Therefore, we ultimately want to go further and perform 2D sampling (2D sampling). This method not only performs random sampling within the blob but also conducts random sampling between blobs. By utilizing the linear properties of KZG commitments, we expand the set of blobs in a block through a new set of virtual blobs that redundantly encode the same information.

Therefore, in the end, we want to go further and perform 2D sampling, which not only samples randomly within the blobs but also between the blobs. The linear property of KZG commitments is used to extend the set of blobs within a block, which contains a new virtual blob list that redundantly encodes the same information.

It is crucial that the expansion of commitment does not require a blob, so this scheme is fundamentally friendly to distributed block construction. Nodes that actually construct blocks only need to have the blob KZG commitment, and they can rely on data availability sampling (DAS) to verify the availability of data blocks. One-dimensional data availability sampling (1D DAS) is also essentially friendly to distributed block construction.

(# What else needs to be done? What are the trade-offs?

Next is the implementation and launch of PeerDAS. After that, the number of blobs on PeerDAS will be continuously increased while carefully monitoring the network and improving the software to ensure security, which is a gradual process. At the same time, we hope for more academic work to standardize PeerDAS and other versions of DAS and their interactions with issues such as the security of fork choice rules.

In the further stages of the future, we need to do more work to determine the ideal version of 2D DAS and prove its security properties. We also hope to eventually transition from KZG to a quantum-safe alternative that does not require a trusted setup. Currently, we are still unclear about which candidate solutions are friendly for distributed block construction. Even using expensive "brute-force" techniques, such as using recursive STARKs to generate validity proofs for reconstructing rows and columns, is not sufficient to meet the demand, because although technically, the size of a STARK is O)log(n) * log(log)n###( hash value ( using STIR), in reality, STARK is almost as large as the entire blob.

I believe the long-term reality path is:

1. Implement the ideal 2D DAS;
2. Persist in using 1D DAS, sacrificing sampling bandwidth efficiency for simplicity and robustness, accepting a lower data upper limit.
3. Abandon DA and fully accept Plasma as our primary Layer 2 architecture of focus.

Please note that even if we decide to expand execution directly on the L1 layer, this option still exists. This is because if the L1 layer has to handle a large amount of TPS, L1 blocks will become very large, and clients will want an efficient way to verify their correctness. Therefore, we will have to use the same technologies on the L1 layer as Rollup( such as ZK-EVM and DAS(.

)# How to interact with other parts of the roadmap?

If data compression is achieved, the demand for 2D DAS will decrease, or at least be delayed. If Plasma is widely used, the demand will further decrease. DAS also poses challenges for distributed blockchain construction protocols and mechanisms: although DAS is theoretically friendly to distributed reconstruction, in practice it needs to be combined with the package inclusion list proposal and its surrounding fork choice mechanism.

) data compression

(# What problem are we solving?

Each transaction in the Rollup consumes a large amount of on-chain data space: an ERC20 transfer requires about 180 bytes. Even with ideal data availability sampling, this limits the scalability of Layer protocols. Each slot is 16 MB, we get:

16000000 / 12 / 180 = 7407 TPS

What if we can not only solve the problems of the numerator but also the problems of the denominator, allowing each transaction in the Rollup to occupy fewer bytes on-chain?

What is it and how does it work?

In my opinion, the best explanation is this picture from two years ago:

![Vitalik's new article: The possible future of Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(

In zero-byte compression, each long sequence of zero bytes is replaced with two bytes that indicate how many zero bytes there are. Furthermore, we leverage specific properties of transactions:

Signature Aggregation: We switch from ECDSA signatures to BLS signatures.