Vitalik's new article: The potential future of Ethereum, The Surge

Author: Vitalik Buterin

Compiled by Karen, Foresight News

Special thanks to Justin Drake, Francesco, Hsiao-wei Wang, @antonttc and Georgios Konstantopoulos.

Initially, there were two scaling strategies in the Ethereum roadmap. One (see an early paper in 2015) is ‘Sharding’: each Node only needs to validate and store a small portion of transactions, rather than validating and storing all transactions on the chain. Any other peer-to-peer network (such as BitTorrent) also works this way, so we can certainly make the blockchain work in the same way. The other is Layer2 protocol: these networks will be on top of Ethereum, allowing it to fully benefit from its security, while keeping most of the data and computation off the mainchain. Layer2 protocol refers to state channels in 2015, Plasma in 2017, and then Rollup in 2019. Rollup is more powerful than state channels or Plasma, but they require a lot of on-chain data bandwidth. Fortunately, by 2019, Sharding research had solved the problem of massive verification ‘data availability’. As a result, the two paths merged together, and we obtained a roadmap centered around Rollup, which is still Ethereum’s scaling strategy today.

The Surge, 2023 Roadmap Edition

The Rollup-centric roadmap proposes a simple division of labor: ETHereum L1 focuses on being a strong and Decentralization foundation, while L2 takes on the task of helping the ecosystem expand. This pattern is ubiquitous in society: the existence of the court system (L1) is not for pursuing super high speed and efficiency, but for protecting contracts and property rights, while entrepreneurs (L2) are to build on this solid foundation and lead humanity towards Mars (whether in a literal or metaphorical sense).

This year, the roadmap centered around Rollup has made significant progress: with the launch of EIP-4844 blobs, the data bandwidth of Ethereum L1 has increased significantly, and multiple Ethereum Virtual Machine (EVM) Rollups have entered the first phase. Each L2 exists as a ‘Sharding’ with its own internal rules and logic, and the diversity and diversification of Sharding implementation have now become a reality. However, as we can see, this path also faces some unique challenges. Therefore, our current task is to complete the roadmap centered around Rollup, address these issues, while maintaining the robustness and Decentralization unique to Ethereum L1.

The Surge: Key Targets

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 properties of Ethereum (Trustless, open, censorship-resistant);

4, the ETH community should feel like a unified ecosystem, not 34 different blockchains.

Contents of this chapter

1. Scalability Trilemma
2. Further Progress in Data Availability Sampling
3. Data Compression
4. Generalized Plasma
5. Mature L2 proof system
6. Cross L2 interoperability improvement
7. Expand Execution on L1

Scalability Trilemma

The scalability trilemma is an idea proposed in 2017, which suggests a contradiction between the three characteristics of blockchain: Decentralization (specifically, low cost of running Nodes), scalability (handling a large number of transactions), and security (attackers need to destroy a large part of the network Nodes to make a single transaction fail).

It is worth noting that the Trilemma is not a theorem, and the post introducing the Trilemma does not come with a mathematical proof. It does provide a heuristic mathematical argument: if a Decentralization-friendly Node (such as a consumer 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 Nodes, meaning that an attacker can get a malicious transaction through by compromising a small number of Nodes, or (ii) your Node will become powerful, but your chain will not be Decentralized. The purpose of this article is not to prove that breaking the Trilemma is impossible; rather, it aims to demonstrate that breaking the Trilemma is difficult, requiring some degree of thinking outside the framework implied by the argument.

Over the years, some high-performance chains have often claimed to have solved the trilemma without fundamentally changing the architecture, usually by optimizing the nodes using software engineering techniques. This is always misleading, as running nodes on these on-chain networks is much more challenging than running nodes on the Ethereum network. This article will explore why this is the case and why L1 client software engineering alone cannot scale Ethereum.

However, the combination of data availability sampling and SNARKs does solve the trilemma: it allows clients to verify that a certain amount of data is available and a certain number of computational steps are executed correctly with only a small amount of data downloaded and minimal computation. SNARKs are trustless. Data availability sampling has a subtle few-of-N trust model, but it preserves the fundamental properties of a non-scalable chain, such that even a 51% attack cannot force bad blocks to be accepted by the network.

Another way to resolve the trilemma is the Plasma architecture, which cleverly shifts the responsibility of monitoring data availability to users in an incentivized manner. From 2017 to 2019, when we only had fraud proof as a means to expand computational capabilities, Plasma was severely limited in secure execution. However, with the widespread adoption of SNARKs (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 Dencun is upgraded and launched, there are approximately 3 blobs of about 125 kB per 12-second slot on the Ethereum blockchain, or about 375 kB of available bandwidth per slot. Assuming that transaction data is published directly on-chain, the ERC20 transfer is about 180 bytes, so the maximum TPS of Rollup on the Ethereum blockchain is: 375000 / 12 / 180 = 173.6 TPS

If we add the calldata of Ethereum (theoretical maximum value: 30 million Gas per slot / 16 gas per byte = 1,875,000 bytes per slot), 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 major upgrade for Ethereum L1, but it’s not enough. We want more scalability. Our mid-term goal is to have 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 the Ethereum network, each blob is a 4096-degree polynomial over a 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. From these 8192 evaluation values, any 4096 (64 out of 128 possible samples according to the current proposed parameters) can recover the blob.

The working principle of PeerDAS is to allow each client to 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 who listen to different subnets. A more conservative version, SubnetDAS, uses only the subnet mechanism without the additional querying peer layer. The current proposal is for Nodes participating in Proof of Stake to use SubnetDAS, while other Nodes (i.e., clients) use PeerDAS.

In theory, we can scale up the “1D sampling” to a considerable size: if we increase the maximum number of blobs to 256 (target is 128), then we can achieve the goal of 16MB, with data availability sampling 16 samples per Node * 128 blobs * 512 bytes per sample per blob = 1MB 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 blob size, but this will increase the reconstruction cost.

Therefore, we ultimately want to go further and perform 2D sampling, a method that not only randomly samples within the blob, but also randomly samples between blobs. By leveraging the linear properties of KZG commitments, we can extend a set of new virtual blobs redundantly encoding the same information within a Block.

Therefore, in the end, we want to go further and perform 2D sampling, which is not only within a block, but also between blocks for random sampling. The linear properties promised by KZG are used to expand the set of blobs within a Block, which includes a new virtual blob list that redundantly encodes the same information.

2D sampling. Source: a16z crypto

It is crucial that the extension of the computation commitment does not require a blob, making the scheme fundamentally friendly to distributed block construction. The actual Node that constructs the Block only needs to have the KZG commitment of the blob, 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 inherently friendly to distributed block construction.

What are the links to existing research?

1. Introduction to the original post on data availability (2018):
2. Follow-up paper:
3. Explanation article about DAS, paradigm:
4. 2D availability with KZG commitment:
5. PeerDAS on ethresear.ch: and the paper:
6. EIP-7594:
7. SubnetDAS on ethresear.ch:
8. The subtle difference in recoverability in 2D sampling:

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

Next is the implementation and launch of PeerDAS. Afterwards, we will continue to increase the number of blobs on PeerDAS while carefully observing the network and improving the software to ensure security. This is an iterative process. At the same time, we hope to have more academic work to standardize the interaction between PeerDAS, other versions of DAS, and security issues related to fork choice rules.

In the further 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 move away from KZG to an alternative that is quantum safe and does not require trusted setup. Currently, we are not sure which candidate solutions are friendly to distributed Block construction. Even using the expensive ‘brute force’ technique, that is, using recursive STARK to generate validity proof for reconstructing rows and columns, is not enough to meet the demand, because although technically a STARK has a size of O(log(n) * log(log(n)) hash value (using STIR), in reality, a STARK is almost as large as the entire blob.

The long-term realistic path I think is:

1. Implement ideal 2D DAS;
2. Persist in using 1D DAS, sacrificing sampling bandwidth efficiency, accepting lower data upper limit for simplicity and robustness.
3. Give up DA and fully accept Plasma as the main Layer2 architecture we follow.

Please note that even if we decide to scale directly on the L1 layer, this option exists. This is because if the L1 layer has to handle a large number of TPS, the L1 Block will become very large, and clients will want an efficient way to verify their correctness. Therefore, we will have to use the same technology as Rollups (such as ZK-EVM and DAS) on the L1 layer.

How to interact with other parts of the roadmap?

If data compression is implemented, the demand for 2D DAS will be reduced, or at least the latency will be reduced. If Plasma is widely used, the demand will be further reduced. DAS also poses challenges to the construction protocol and mechanism of distributed blocks: although DAS is theoretically friendly to distributed reconstruction, it needs to be combined with the proposal of package inclusion list and the surrounding fork selection mechanism in practice.

Data Compression

**What problem are we solving?

Each transaction in Rollup will consume a large amount of on-chain data space: transferring ERC20 requires about 180 bytes. Even with ideal data availability sampling, this also limits the scalability of the Layer protocol. With each slot of 16 MB, we get:

16000000 / 12 / 180 = 7407 TPS

What if we could not only solve the problem of the numerator, but also the problem of the denominator, and let each transaction in the Rollup 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:

In zero-byte compression, two bytes are used to replace each long sequence of zero bytes to indicate how many zero bytes there are. Furthermore, we make use of specific attributes of the transaction:

Signature Aggregation: We have switched from ECDSA signatures to BLS signatures, which have the property that multiple signatures can be combined into a single signature that proves the validity of all the original signatures. At the L1 layer, BLS signatures are not considered due to the high computational cost of verification even if aggregation is performed. However, using BLS signatures makes sense in environments like L2 where data is scarce. The aggregation feature of ERC-4337 provides a way to implement this functionality.

Replace Address with pointers: If a certain Address has been used before, we can replace the 20-byte Address with a 4-byte pointer that points to a position in the history.

Custom serialization of transaction values - Most transaction values have few digits, for example, 0.25 ETH is represented as 250,000,000,000,000,000 wei. The maximum base fee and priority fee are also similar. Therefore, we can use a custom decimal floating-point format to represent most currency values.

What are the links to existing research?

1. Explore sequence.xyz:
2. L2 Calldata optimized contract:
3. Rollups based on validity proof (also known as ZK rollups) release state differences instead of transactions:
4. BLS Wallet - Implement BLS aggregation through ERC-4337:

What else needs to be done, what are the trade-offs?

The next step is to actually implement the above solution. The main considerations include:

1. Switching to BLS signatures requires a lot of effort and may drop compatibility with trusted hardware chips that enhance security. ZK-SNARK encapsulation using other signature schemes can be used as a substitute.

2. Dynamic compression (e.g., replacing Address with pointers) would make the client code more complex.

3. Publishing state differences on-chain instead of transactions will drop auditability and make many software (such as blockchain explorers) unable to work.

How to interact with other parts of the roadmap?

Adopting ERC-4337, and eventually incorporating some of its content into L2 EVM, can greatly accelerate the deployment of aggregation technology. Placing some of the content of ERC-4337 on L1 can speed up its deployment on L2.

Generalized Plasma

What problem are we solving?

Even with 16 MB blobs and data compression, 58,000 TPS may not be enough to fully meet the needs of consumer payments, Decentralization socializing, or other high-bandwidth applications, especially when we start considering privacy factors, which could drop scalability by 3-8 times. For high-volume, low-value use cases, one current option is to use Validium, which keeps data off-chain and employs an interesting security model: operators cannot steal user funds, but they may temporarily or permanently freeze funds for all users. But we can do better.

What is it, how does it work?

Plasma is a scaling solution that involves an operator publishing Blocks off-chain and putting the Merkle roots of these Blocks on-chain (in contrast to Rollup, which puts complete Blocks on-chain). For each Block, the operator sends a Merkle proof to each user to prove what changes have occurred to their assets, or that no changes have occurred. Users can withdraw their assets by providing the Merkle proof. Importantly, this proof does not have to be rooted in the latest state. Therefore, even if there are data availability issues, users can still recover their assets by withdrawing their available latest state. If a user submits an invalid proof (e.g., withdrawing assets they have already sent to others, or the operator arbitrarily creating an asset), the legitimacy of the vesting of the assets can be judged through the on-chain challenge mechanism.

Plasma Cash chain map. The transaction spending coin i is placed at the i-th position in the tree. In this example, assuming all previous trees are valid, we know that Eve currently owns Token 1, David owns Token 4, and George owns Token 6.

Early versions of Plasma could only handle payment use cases and could not be effectively further promoted. However, if we require each root to be verified using SNARK, then Plasma will become much more powerful. Each challenge game can be greatly simplified, as we exclude most possible paths for operators to cheat. At the same time, new paths are opened up, allowing Plasma technology to be extended to a wider range of asset categories. Finally, in the case of operators not cheating, users can immediately withdraw funds without waiting for a week-long challenge period.

One method (not the only method) for creating an EVM Plasma chain: Use ZK-SNARK to build a parallel UTXO tree that reflects the balance changes made by the EVM and defines a unique mapping of the ‘same Token’ at different points in history. Then, a Plasma structure can be built on top of it.

A key insight is that the Plasma system does not need to be perfect. Even if you can only protect a subset of assets (for example, only Tokens that have not moved in the past week), you have already greatly improved the current state of the highly scalable EVM (i.e. Validium).

Another type of structure is a hybrid Plasma/Rollup, such as Intmax. These constructions put a very small amount of data on-chain for each user (e.g., 5 bytes), which allows for certain features between Plasma and Rollup. In the case of Intmax, you can achieve high scalability and privacy, although theoretically limited to about 266,667 TPS in a capacity of 16 MB.

**What are the links related to existing research?

1. Original Plasma paper:
2. Plasma Cash:
3. Plasma Cashflow:
4. Intmax (2023):

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

The remaining main task is to put the Plasma system into practical production applications. As mentioned above, Plasma is not a choice between “Plasma” and “Validium”: any Validium can enhance its security attributes to some extent by incorporating Plasma features into its exit mechanism. The focus of the research is on obtaining the best attributes for the EVM (considering trust requirements, worst-case L1 Gas costs, and the ability to resist DoS attacks), as well as alternative specific application structures. In addition, compared to Rollup, Plasma has a higher conceptual complexity, which needs to be directly addressed through research and the construction of a better general framework.

The main trade-offs of using Plasma design are that they rely more on operators and are harder to base, although the hybrid Plasma/Rollup design can often avoid this weakness.

How to interact with other parts of the roadmap?

The more effective the Plasma solution is, the less pressure there is on L1 with high-performance data availability. Moving activities to L2 can also reduce the MEV pressure on L1.

Mature L2 Proof System

What problem are we solving?

Currently, most Rollups are not Trustless. There is a security committee that has the power to override (optimistic or validity) the behavior of the proof system. In some cases, the proof system does not even run, or even if it runs, it only has a “consultation” function. The most advanced Rollups include: (i) some Trustless application-specific Rollups, such as FUEL; (ii) as of the time of writing, Optimism and Arbitrum are two full EVM Rollups that have implemented part of the trustless milestone called the “first phase”. The reason why Rollup has not made greater progress is because of concerns about bugs in the code. We need a trustless Rollup, so we must face and solve this problem.

What is it, how does it work?

First, let’s review the ‘stage’ system introduced in the beginning of this article.

Phase 0: Users must be able to run Nodes and synchronize the chain. It doesn’t matter if the verification is completely trustworthy/centralized.

Phase 1: There must be a (trustless) proof system to ensure that only valid transactions are accepted. The security committee, which can overturn the proof system, is allowed, but it must have a 75% threshold vote. In addition, the quorum-blocking portion (i.e., 26%+) of the committee must be outside the main company building Rollup. We allow for a weaker upgrade mechanism (e.g., DAO), but it must have sufficient latency, and if it approves a malicious upgrade, users can withdraw their funds before the fund goes live.

Phase 2: There must be a (trustless) proof system to ensure that only valid transactions are accepted. The security committee only intervenes when there are provable errors in the code, for example, if two redundant proof systems are inconsistent with each other, or if one proof system accepts two different post-state roots of the same Block (or does not accept any content for a sufficiently long time, such as a week). Upgrading mechanisms are allowed but must have a long latency.

Our goal is to reach Phase 2. The main challenge of reaching Phase 2 is gaining enough confidence to prove that the system is actually reliable enough. There are two main methods to accomplish this:

1. Formal Verification: We can use modern mathematics and computing technology to prove (optimistic and validity) that the system only accepts Blocks that conform to the EVM specification. These technologies have been around for decades, but recent advancements (such as Lean 4) have made them more practical, and AI-assisted proof advancements may further accelerate this trend.
2. Multiple Provers: Create multiple proof systems and invest funds into these proof systems and security committees (or other small tools with trust assumptions, such as TEE). If the proof systems agree, the security committee has no power; if they disagree, the security committee can only choose between them, it cannot unilaterally impose its own answer.

The programmatic diagram of multiple proofs combines an optimistic proof system, a validity proof system, and a security committee.

What are the links to existing research?

1. EVM K Semantics (formal verification work from 2017):
2. Speech on the concept of multi-proof (2022):
3. Taiko plans to use multi-proof:

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

For Formal Verification, the workload is huge. We need to create a formal verification version of the entire SNARK prover for the Ethereum Virtual Machine (EVM). This is an extremely complex project, although we have already started. There is a trick that can greatly simplify this task: we can create a formally verified SNARK prover for a minimal Virtual Machine (such as RISC-V or Cairo), and then implement EVM in this minimal Virtual Machine (and formally prove its equivalence to other Ethereum Virtual Machine specifications).

For multi-proof, there are two main parts that have not been completed yet. First, we need to have enough confidence in at least two different proof systems, ensuring that they are both equally secure and ensuring that if they have problems, these problems should be different and unrelated (so they won’t occur simultaneously). Second, we need to have very high trust in the underlying logic of the merged proof system. This part of the code is much smaller. There are some methods to make it very small, just by storing funds in a secure multi-signature contract (Safe multisig) that represents contracts from different proof systems as signers, but this will increase on-chain Gas costs. We need to find a balance between efficiency and security.

How to interact with other parts of the roadmap?

Moving the activity to L2 can reduce the MEV pressure on L1.

Cross L2 interoperability improvement

What problem are we solving?

One of the main challenges facing the current L2 ecosystem is that users find it difficult to navigate within it. In addition, the simplest methods often reintroduce trust assumptions: centralized cross-chain interaction, RPC clients, and so on. We need to make using the L2 ecosystem feel like using a unified Ethereum ecosystem.

What is it? How does it work?

There are many categories of improvements for cross-L2 interoperability. In theory, the ETH-based Rollup is similar to implementing Sharding L1. The current ETH-based L2 ecosystem still has these shortcomings in practice:

1. Address of a specific chain: The Address should contain information about the chain (L1, Optimism, Arbitrum, etc.). Once this is achieved, the cross L2 sending process can be achieved by simply putting the Address into the “send” field, at which point the Wallet can handle how to send in the background (including using Cross-Chain Interaction protocol).

2. Payment Request on a Specific Chain: Should be able to easily and standardize the creation of a message in the form of ‘Send X Y Tokens to me on Chain Z’. This has two main applications: (i) Payments between individuals or between individuals and merchant services; (ii) DApp funding requests.

3. Cross-Chain Interaction Exchange and gas payment: There should be a standardized open protocol to express Cross-Chain Interaction operations, such as “I will send 1 ether to the person who sent me 0.9999 ether on Arbitrum (on Optimism)” and “I will send 0.0001 ether to the person who included this transaction on Arbitrum (on Optimism)”. ERC-7683 is an attempt at the former, while RIP-7755 is an attempt at the latter, although both have broader applications than these specific use cases.

4. Light client: Users should be able to verify the chains they are interacting with, not just trust RPC providers. Helios from a16z crypto can do this (for the ETH mainnet itself), but we need to extend this trustlessness to L2. ERC-3668 (CCIP-read) is one strategy to achieve this goal.

How does the light client update its view of the Ethereum header chain? Once you have the header chain, you can use Merkle proofs to verify any state object. Once you have the correct L1 state object, you can use Merkle proofs (and signatures if you want to verify pre-commits) to verify any state object on L2. Helios has achieved the former. Extending to the latter is a standardization challenge.

1. Keystore Wallet: Nowadays, if you want to update the Secret Key that controls your Smart Contract Wallet, you have to update it on all N chains where the Wallet exists. Keystore Wallet is a technology that allows the Secret Key to exist in only one place (either on L1 or possibly on L2 in the future), and then any L2 with a copy of the Wallet can read the Secret Key from there. This means that the update only needs to be done once. To improve efficiency, Keystore Wallet requires L2 to have a standardized way to read information from L1 without cost; there are two proposals for this, namely L1SLOAD and REMOTESTATICCALL.

How Keystore Wallet Works

2. A more aggressive “shared Token bridge” concept: Imagine a world where all L2 are validity proof Rollups and each slot submits to the Ethereum network. Even in such a world, transferring an asset from one L2 to another in its native state still requires withdrawal and deposit, which incurs a significant amount of L1 gas fees. One way to address this issue is to create a shared minimal Rollup, whose sole function is to maintain which L2 owns each type of Token and how much balance each has, and to allow these balances to be batch updated through a series of cross-L2 transfer operations initiated by any L2. This will allow cross-L2 transfers without the need to pay L1 gas fees for each transfer, and without the use of technologies such as ERC-7683 based on Liquidity Provider.

3. Synchronous composition: allows synchronous calls between specific L2 and L1 or multiple L2. This helps improve the financial efficiency of the Decentralized Finance protocol. The former can be achieved without any cross-L2 coordination, while the latter requires shared ordering. Rollup-based technology automatically applies to all of these technologies.

What are the links to existing research?

Specific Address for Chain: ERC-3770:

**ERC-7683:

**RIP-7755:

**Scroll keystore Wallet design style:

**Helios:

**ERC-3668 (sometimes referred to as CCIP Read):

The proposal of ‘pre-commitment (based on sharing)’ put forward by Justin Drake:

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL in Optimism:

**AggLayer, including the idea of a shared token bridge:

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

Many of the examples above face the dilemma of when and which layers of standards should be standardized. If standardized too early, it may entrench a subpar solution. If standardized too late, it may result in unnecessary fragmentation. In some cases, there is both a short-term solution with weaker attributes but easier implementation, as well as a long-term solution that is the ‘ultimate right’ but takes years to achieve.

These tasks are not just technical issues, they are also (and may even be primarily) social issues that require cooperation between L2, wallets, and L1.

How to interact with other parts of the roadmap?

Most of these proposals are at a higher layer, so they have little impact on the L1 level. One exception is shared ordering, which has a significant impact on maximal extractable value (MEV).

Expand execution on L1

What problem are we solving?

If L2 becomes highly scalable and successful, but L1 can still only handle very low volume, then Ethereum may face many risks:

1. The economic situation of ETH assets will become more unstable, which in turn will affect the long-term security of the network.

2. Many L2s benefit from close connections with highly developed financial ecosystems on L1. If this ecosystem is significantly weakened, the incentives to become an L2 (rather than an independent L1) will be weakened.

3, L2 needs a long time to achieve the same security guarantee as L1.

4. If L2 fails (for example, due to malicious behavior or disappearance of the operator), users still need to recover their assets through L1. Therefore, L1 needs to be strong enough to occasionally handle the highly complex and chaotic finishing work of L2.

For these reasons, continuing to expand L1 itself and ensuring that it can continue to accommodate more and more use cases is very valuable.

What is it? How does it work?

The simplest way to expand is to directly increase the Gas limit. However, this may lead to centralization of L1, thereby weakening another important feature of Ethereum L1: the credibility of being a robust underlying layer. There is still a debate about how sustainable it is to simply increase the Gas limit to what extent, which will also vary depending on which other technologies are implemented to make the verification of larger Blocks easier (e.g., historical expiry, statelessness, L1 EVM validity proof). Another important thing that needs continuous improvement is the efficiency of Ethereum client software, which is much higher now than five years ago. An effective L1 Gas limit increase strategy will involve accelerating the development of these verification technologies.

1. EOF: A new EVM bytecode format that is more friendly to static analysis and can achieve faster implementation. Considering these efficiency improvements, EOF bytecode can obtain lower gas fees.
2. Multidimensional Gas Pricing: Different basic fees and limits are set for computation, data, and storage, which can increase the average capacity of Ethereum L1 without increasing the maximum capacity (thus avoiding new security risks).
3. drop specific opcodes and precompiled Gas costs - Historically, to prevent denial-of-service attacks, we have repeatedly increased the Gas costs of certain underpriced operations. One more thing that can be done is to drop the Gas cost of overpriced opcodes. For example, addition is much cheaper than multiplication, but currently the costs of the ADD and MUL opcodes are the same. We can drop the cost of ADD, and even lower the cost of simpler opcodes like PUSH. EOF is more optimized in this regard overall.
4. EVM-MAX and SIMD: EVM-MAX is a proposal that allows for more efficient native large number modulus operations as a separate module for the EVM. Unless intentionally exported, the computed values by EVM-MAX calculations can only be accessed by other EVM-MAX opcodes. This allows for a larger space to optimize the storage format of these values. SIMD (single instruction multiple data) is a proposal that allows for efficient execution of the same instruction on arrays of values. Together, they can create a powerful co-processor alongside the EVM, which can be used for more efficient encryption operations. This is particularly useful for privacy protocols and L2 protection systems, thus it will aid in L1 and L2 scalability.

These improvements will be discussed in more detail in future Splurge articles.

Finally, the third strategy is native rollups (or enshrined rollups): essentially, creating many parallel running EVM replicas, resulting in a model equivalent to what rollup can provide, but more natively integrated into the protocol.

What are the links to existing research?

1. Polynya’s ETH Layer 1 scaling roadmap:
2. Multi-dimensional Gas Pricing:
3. EIP-7706:
4. EOF:
5. EVM-MAX:
6. SIMD:
7. Native rollups:
8. Max Resnick’s interview on the value of expanding L1:
9. Justin Drake on using SNARK and native rollups for scalability:

What else needs to be done, what are the trade-offs?

L1 expansion has three strategies, which can be carried out separately or in parallel:

1. Improve technology (such as client code, stateless client, historical expiration) to make L1 easier to verify, and then increase the gas limit.
2. drop the cost of specific operations, increase the average capacity without increasing the worst-case risk;
3. Native rollups (i.e., creating N parallel replicas of the EVM).

Understanding these different technologies, we will find that there are different trade-offs. For example, native Rollups have many of the same weaknesses in composability as regular Rollups: you cannot send a single transaction to synchronize operations across multiple Rollups, as you can with contracts on the same L1 (or L2). Increasing the Gas limit will weaken other benefits that can be achieved 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 Ethereum Virtual Machine (EVM) cheaper may increase the overall complexity of the EVM.

A major question that any L1 expansion roadmap needs to answer is: What are the ultimate visions of L1 and L2? Obviously, it is absurd to put all content on L1: potential use cases may involve hundreds of thousands of transactions per second, which would make L1 completely unable to verify (unless we adopt the native Rollup approach). But we do need some guiding principles to ensure that we do not end up in a situation where the gas limit is increased by 10 times, severely compromising the Decentralization of Ethereum L1.

A perspective on the division of labor between L1 and L2

How to interact with other parts of the roadmap?

Bringing in more users to L1 means not only improving scalability, but also improving other aspects of L1. This means that more MEV will stay on L1 (rather than just becoming an L2 issue), so the need to handle MEV explicitly will become more urgent. This will greatly enhance the value of rapid slot time on L1. At the same time, this also heavily depends on the smooth progress of L1 (the Verge) validation.

Recommended reading: “Vitalik’s new article: The possible future of Ethereum, the Merge”