The Possible Future of Ethereum: The Surge

The roadmap for Ethereum initially included two scalability strategies: sharding and Layer 2 protocols. Sharding allows each node to only verify and store part of the transactions, while Layer 2 builds networks on top of Ethereum, leveraging its security but keeping most data and computation off the main chain. These two approaches ultimately merged into a Rollup-centric roadmap, which remains Ethereum's scalability strategy to this day.

The roadmap centered around Rollup proposes a simple division of labor: Ethereum L1 focuses on becoming a strong and decentralized base layer, while L2 takes on the task of helping the ecosystem scale. This model is common in society: the court system (L1) exists to protect contracts and property rights, while entrepreneurs (L2) build on this foundation, driving human development.

This year, the Rollup-centric roadmap has made significant progress: the launch of EIP-4844 blobs has greatly increased the data bandwidth of Ethereum L1, and several Ethereum Virtual Machines (EVM) Rollups have entered the first phase. Each L2 exists as a "shard" with its own rules and logic, and the diversity in the implementation of shards has now become a reality. However, this path also faces some unique challenges. Our current task is to complete the Rollup-centric roadmap, address these issues, while maintaining the robustness and decentralization of 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 such as trustlessness, openness, and censorship resistance (.
4. Ethereum should feel like a unified ecosystem, rather than 34 different blockchains.

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

Scalability Triad Paradox

The scalability triangle paradox suggests that there is a contradiction between three characteristics of blockchain: decentralization, where the cost of operating nodes is low, scalability, where a large number of transactions can be processed, and security, where an attacker needs to compromise a significant portion of nodes in the network to cause a single transaction to fail.

The triangle paradox is not a theorem, and the posts introducing it do not come with a mathematical proof. It presents a heuristic mathematical argument: if a decentralized friendly node 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 nodes, which means that an attacker only needs to compromise a few nodes to get through with a malicious transaction, or )ii( your nodes will become powerful, while your chain will not be decentralized. The article aims to show that breaking the trilemma is difficult and requires stepping outside the implicit thinking framework of the argument to some extent.

For many years, some high-performance chains have often claimed to solve the trilemma without fundamentally changing their architecture, usually by optimizing nodes. This is always misleading, as running nodes on these chains is much more difficult than running nodes on Ethereum.

However, the combination of data availability sampling and SNARKs indeed resolves the triangle paradox: it allows clients to verify that a certain amount of data is available and that a certain number of computation steps are correctly executed, 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 characteristics of a non-scalable chain, meaning 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 cleverly uses technology to push the responsibility of monitoring data availability onto the users in an incentive-compatible manner. As early as 2017-2019, when we only had fraud proofs as a means to scale computational capacity, Plasma had very limited security execution capabilities. However, with the popularity of SNARKs, the Plasma architecture has become more feasible for a broader range of use cases than ever before.

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

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 an available data bandwidth of about 375 kB per slot. Assuming that transaction data is published directly on-chain, an ERC20 transfer is approximately 180 bytes, thus the maximum TPS for Rollups on Ethereum is: 375000 / 12 / 180 = 173.6 TPS.

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

This is a significant upgrade to Ethereum L1, but it is not enough. We want more scalability. Our mid-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 in the 253-bit prime field ). We broadcast the shares of the polynomial, where each share contains the 16 evaluation values from adjacent 16 coordinates out of a total of 8192 coordinates. Among these 8192 evaluation values, any 4096 ### can restore the blob based on the currently proposed parameters: any 64 out of 128 possible samples (.

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 other blobs on different subnets it needs by asking peers in the global p2p network ) who will listen to different subnets (. A more conservative version, SubnetDAS, only uses the subnet mechanism without additional inquiries to the peer layer. The current proposal is to have nodes participating in proof of stake use SubnetDAS, while other nodes ), namely 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 target of 16MB, where each node in data availability sampling has 16 samples * 128 blobs * 512 bytes per sample per blob = 1 MB of data bandwidth per slot. This is just barely within our tolerance range: it is feasible, but it means that bandwidth-limited clients cannot sample. We can optimize this to some extent by reducing the number of blobs and increasing the size of each blob, but this will increase the cost of reconstruction.

Therefore, we ultimately want to take a step further, conduct 2D sampling (2D sampling), a method that involves random sampling not only within the blob but also between blobs. By utilizing the linear properties of KZG commitments, we can expand the set of blobs in a block through a new set of virtual blobs, which redundantly encode the same information.

Therefore, ultimately we want to go further and conduct 2D sampling, which performs random sampling not only within the blobs but also between the blobs. The linear property of KZG commitments is used to extend a set of blobs within a block, which includes a new virtual blob list that redundantly encodes the same information.

It is crucial that the expansion of computational commitments does not require blobs, thus this scheme is fundamentally friendly to distributed block construction. The nodes that actually build the blocks only need to possess blob KZG commitments, 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, we will continuously increase the number of blobs on PeerDAS while carefully monitoring the network and improving the software to ensure security. This is a gradual process. At the same time, we hope for more academic work to standardize PeerDAS and other versions of DAS, as well as 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, it is still unclear which candidates are friendly to distributed block construction. Even using expensive "brute force" techniques, such as using recursive STARK to generate validity proofs for reconstructing rows and columns, is not sufficient to meet the demands, because although technically, the size of a STARK is O)log(n) * log(log)n() hash value ( using STIR), in practice, the STARK is almost as large as the entire blob.

I believe the long-term realistic path is:

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

Please note that even if we decide to directly expand execution at 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, so we will have to use the same technologies at the L1 layer as those used in 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 to distributed block construction protocols and mechanisms: although DAS is theoretically friendly to distributed reconstruction, this needs to be combined in practice with the package inclusion list proposal and its surrounding fork choice mechanism.

Data Compression

) What problem are we solving?

Each transaction in a 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 could 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 the 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-a04daca8af5d6af3c06b77a97aae477d.webp(

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

Signature Aggregation: We switched from ECDSA signatures to BLS signatures. The characteristic of BLS signatures is that multiple signatures can be combined into a single signature, which can prove all originals.