Ethereum's scaling strategy aims to enhance the scalability of L1 and L2 by combining Rollups and sharding technology, while ensuring decentralization and interoperability to meet the growing demand for decentralized applications.
Author: Vitalik Buterin
Translation: Blockchain in Plain Language
In a blog post on Monday, Vitalik discussed the current state of development following the previous Merge and proposed several potential improvements to Ethereum's proof-of-stake model. These include lowering the financial threshold for individual stakers and shortening the block confirmation time on Ethereum. Today, he published another news piece discussing the current status of the Surge and the work needed for improvements. The following is the main text:
Initially, Ethereum's roadmap included two scaling strategies. One (for example, see early papers from 2015) is "sharding"; the other strategy is layer 2 protocols. In 2015, "layer 2 protocols" referred to state channels, in 2017 it was Plasma, and in 2019 it became Rollups. Rollups are more powerful than state channels or Plasma, but they require a significant amount of on-chain data bandwidth. Fortunately, by 2019, sharding research had addressed the problem of large-scale verification of "data availability." As a result, these two paths gradually merged, forming today's Rollups-centered roadmap, which has become Ethereum's current scaling strategy.
The Surge, 2023 version roadmap.
The Rollups-centered roadmap proposes a simple division of labor: Ethereum L1 focuses on being a robust and decentralized base layer, while L2 is responsible for helping the ecosystem scale.
This year, the Rollups-centered roadmap has made significant progress: through the EIP-4844 proposal, Ethereum L1's data bandwidth has been greatly enhanced, and several EVM Rollups have entered the first phase. Now, each L2 exists as a "shard" with its own rules and logic, forming a highly heterogeneous and diverse sharding implementation. But as we have seen, choosing this path also brings unique challenges. Therefore, our task is to refine the Rollups-centered roadmap, address these issues, while maintaining the robustness and decentralization of Ethereum L1.
Key Goals of The Surge
Achieve a combined total of 100,000+ TPS for L1 and L2
Maintain the decentralization and robustness of L1
Ensure that at least some L2s fully inherit Ethereum's core attributes (trustless, open, censorship-resistant)
Maximize interoperability between L2s. Ethereum should function as a unified ecosystem, not as 34 different blockchains.
Table of Contents
Background: The Scalability Trilemma
Further Progress on Data Availability Sampling
Data Compression
Generalized Plasma
Maturation of L2 Proof Systems
Improvements in Cross-L2 Interoperability
Execution Scaling on L1
1. Background: The Scalability Trilemma
The scalability trilemma is a concept proposed in 2017, emphasizing the difficulty of balancing decentralization, scalability, and security in blockchains. While breaking this trilemma is not impossible, it is quite challenging.
Some high-performance chains claim to solve the trilemma through software engineering techniques, but this claim is often misleading, as running nodes on these chains is typically more difficult than on Ethereum.
However, the combination of data availability sampling and SNARKs can effectively address the trilemma, allowing clients to verify data availability and confirm the correctness of computation steps with less data to download. SNARKs are trustless, while data availability sampling retains the property that malicious blocks are not accepted by the network even when subjected to a 51% attack.
The Plasma architecture is also a method to address the trilemma, maintaining compatibility through incentive mechanisms and shifting the responsibility of monitoring data availability to users. Although the security application scope of Plasma was limited during 2017-2019 due to reliance on fraud proofs, the security of the Plasma architecture has been enhanced in broader scenarios with the popularization of SNARKs.
2. Further Progress on Data Availability Sampling
1) What problem are we trying to solve?
As of March 13, 2024, after the Dencun upgrade, Ethereum supports approximately 375KB of data bandwidth per 12-second slot, with a maximum aggregated TPS of about 173.6. If calldata is considered, the maximum TPS can be increased to 607. Through PeerDAS, the plan is to increase the number of data blocks to 8-16, with an expected TPS of 463-926. Although these improvements are significant, higher scalability is still needed, with a mid-term goal of 16MB per slot, combined with data compression to achieve approximately 58,000 TPS.
2) What is it and how does it work?
PeerDAS is a data availability implementation based on one-dimensional sampling, utilizing polynomials of degree 4096 and 16 evaluations per share to recover data blocks. Each client listens to a few subnets and retrieves data blocks from other subnets through a P2P network. A more conservative SubnetDAS relies solely on the subnet mechanism. The goal is to increase the number of data blocks to 256 to achieve 16MB of data per slot, with the cost of data availability sampling being 1MB of bandwidth per slot. While feasible, clients with limited bandwidth cannot sample. The ultimate goal is to advance to two-dimensional sampling, utilizing KZG commitments to expand the data block set, thereby simplifying the process of distributed block construction.
3) Work to be done and trade-offs
The next step is to implement and promote PeerDAS, gradually increasing the number of data blocks, and monitoring the network and improving software to ensure security. Additionally, more academic research is needed to formalize PeerDAS and other versions of DAS and explore their security concerning fork choice rules. The long-term goal is to determine the ideal version of two-dimensional DAS and prove its security, ultimately migrating to a quantum-resistant, trustless alternative to replace KZG. Currently, no suitable candidates for distributed block construction have been found, even using recursive STARKs to generate validity proofs, as there are size issues since the actual size of STARKs is nearly equivalent to the full data block.
The long-term path includes:
A. Achieving the ideal two-dimensional DAS;
B. Continuing to use one-dimensional DAS, accepting a lower data ceiling in exchange for simplicity and robustness;
C. Abandoning data availability and fully adopting Plasma as the primary layer 2 architecture.
Even if the choice is to scale execution on L1, these options still need to be considered. If L1 handles a large amount of TPS, the blocks will be very large, and clients will need to effectively verify their correctness, so the same technologies (ZK-EVM and DAS) used in Rollups must be employed on L1.
4) Interaction with other parts of the roadmap
If data compression (see below) is achieved or Plasma is widely used, the demand for two-dimensional DAS may decrease or at least be postponed. Additionally, DAS poses challenges to the protocols and mechanisms for distributed block construction: although DAS is theoretically applicable to distributed reconstruction, in practice, it needs to be combined with proposals for inclusion lists and their surrounding fork choice mechanisms.
3. Data Compression
1) What problem are we trying to solve?
In Ethereum Rollups, each ERC20 transfer occupies about 180 bytes of data space, which limits the scalability of layer 2 protocols. For example, with 16MB of data per slot, we could theoretically achieve about 7407 TPS. If we can reduce the number of bytes each transaction occupies on-chain, scalability will be significantly enhanced.
2) Solutions
Through various data compression techniques, we can reduce the space occupied by each transaction on-chain, specifically:
A. Zero-byte compression: Representing the number of long strings of zero bytes with two bytes.
B. Signature aggregation: Replacing ECDSA signatures with BLS signatures, allowing multiple signatures to be combined into one, effectively reducing verification costs. While not applicable on L1, it is more meaningful in L2 environments.
C. Pointer replacement for addresses: Replacing 20-byte addresses with 4-byte historical pointers to save space, but this requires incorporating some historical data into the state.
D. Custom transaction value serialization: Using a custom floating-point format or dictionary for common values to represent transaction values compactly, such as representing 0.25 ETH as 250,000,000,000,000,000 wei.
Through these compression techniques, we can not only improve the scalability of L2 protocols but also bring greater scalability potential to the entire Ethereum network. By combining data availability sampling and sharding expansion, we expect to achieve tens of thousands of TPS throughput, ensuring that Ethereum can support decentralized applications and meet future growth demands.
3) Work to be done and trade-offs
The main task is to implement these compression schemes, with key trade-offs including:
Switching to BLS signatures: This requires significant effort and may reduce compatibility with trusted hardware; ZK-SNARK encapsulation could be considered as an alternative.
Complexity of dynamic compression: Replacing addresses with pointers will increase the complexity of client code.
Reduced auditability: Posting state differences rather than transactions on-chain will affect auditability and may render certain software (like block explorers) inoperable.
4) Interaction with other parts of the roadmap
The adoption of ERC-4337 and its integration into L2 EVM will accelerate the deployment of aggregation technologies, while solidifying some ERC-4337 functionalities on L1 will also promote its application on L2.
4. Generalized Plasma
1) What problem are we trying to solve?
Even with 16 MB data blocks and data compression, 58,000 TPS is insufficient to meet the demands of high-bandwidth industries such as consumer payments and decentralized social networks, especially considering that scalability may decrease by 3 to 8 times when privacy is taken into account. Currently, Validium, as an off-chain data storage solution, can protect user funds to some extent, but operators may disappear, leading to user funds being frozen. We can find better solutions.
2) What is it and how does it work?
Plasma is a scaling solution where operators publish blocks off-chain and then upload the Merkle roots of these blocks to the blockchain. Each user receives a Merkle branch that can be used to prove changes to their assets. Users only need to provide this branch to withdraw their assets; notably, this branch does not need to be based on the latest state, allowing users to recover their assets based on the latest available state even if data is unavailable. If a user submits an invalid branch, the challenge mechanism on the blockchain will determine the ownership of the assets.
Early versions of Plasma were primarily used for payments and had limited scalability. However, by requiring each Merkle root to be verified by SNARK, the functionality of Plasma has been significantly enhanced, and the challenge process has become simpler, supporting a wider variety of assets. When operators do not cheat, users can quickly withdraw funds without waiting for a week-long challenge period.
The Plasma system does not need to be perfect. Even if it can only protect a portion of assets (such as tokens that have not been transferred in the past week), it represents a significant improvement over current super-scalable EVM states like Validium.
Another structure is a hybrid of Plasma and Rollups, such as Intmax. It stores only a small amount of data (like 5 bytes) on-chain for each user, combining the features of Plasma and Rollups. In a 16 MB environment, it can theoretically achieve 266,667 TPS while providing high scalability and privacy protection.
3) Work to be done and trade-offs
The main task is to put the Plasma system into practical use. It is worth noting that "Plasma and Validium" are not completely opposed; Validium can improve its security by adding Plasma features. The research focus is on building optimized functionalities for EVM and other applications, such as trust requirements, L1 gas costs, and resistance to denial-of-service attacks. However, the conceptual complexity of Plasma is higher than that of Rollup, requiring more research to establish a better general framework.
The main trade-off in designing with Plasma is its higher dependency on operators and the difficulty of achieving complete "trust-based" solutions, but hybrid Plasma/Rollup designs can often avoid this issue.
4) Interaction with other parts of the roadmap
The more effective the Plasma solution, the less pressure L1 will face regarding high-performance data availability. Additionally, moving activities to L2 can also alleviate L1's MEV pressure.
5. Maturation of Proof Systems
1) What problem are we trying to solve?
Currently, most Rollups are not fully trustless, as there are still security committees overseeing the behavior of proof systems. In some cases, the proof system is not even activated or is merely advisory. Leading Rollups include some specific applications (like Fuel) as well as Optimism and Arbitrum, which are both full EVM Rollups that have achieved partial trustlessness. However, the development of Rollups is hindered by concerns over code vulnerabilities, necessitating the search for fully trustless solutions.
2) What is it and how does it work?
First, let's review the "staged" system, summarized as follows:
Stage 0: Users can run nodes and synchronize the chain, and verification can be fully trust-based.
Stage 1: A trustless proof system is required to ensure that only valid transactions are accepted. The security committee can override the proof system, but only under a 75% voting threshold, and at least 26% of the members must not belong to the main company building the Rollup. The upgrade mechanism needs a long delay so that users can withdraw funds before a malicious upgrade occurs.
Stage 2: A trustless proof system must be in place to ensure that only valid transactions are accepted. The security committee only intervenes when there is a flaw in the proof system, and the upgrade mechanism must have a very long delay.
The main challenge in reaching Stage 2 is building confidence in the reliability of the proof system, which can be approached in two main ways:
A. Formal verification: Using modern mathematics and computational techniques to prove that the proof system only accepts blocks that conform to EVM specifications, a technology that is already mature, and new advancements are making this approach more feasible.
B. Multiple verifiers: Constructing multiple proof systems and using a multi-signature mechanism to move funds between these systems. If the proof systems agree, the security committee has no authority to intervene; if they disagree, the committee can only choose one and cannot unilaterally decide.
A stylized diagram of multiple verifiers, combining an optimistic proof system, a validity proof system, and a security committee.
3) Work to be done and trade-offs
For formal verification, we need to complete many tasks, particularly creating a formal verification version of a complete SNARK prover. This work is complex, but we have begun. A simplified approach is to first create a formal verification SNARK prover for a minimal virtual machine (like RISC-V or Cairo), and then implement EVM within this virtual machine and prove its equivalence to the EVM specification.
For multiple verifiers, there are two main tasks. First, we need to build confidence in at least two different proof systems, ensuring that they are each secure and that their failure modes are different and do not occur simultaneously. Second, we need to have a high assurance of the basic logic of the merged proof systems. While this can be simplified through methods such as storing funds in a multi-signature contract representing each proof system, this will increase on-chain gas costs. Therefore, a balance must be found between efficiency and security.
4) Interaction with other parts of the roadmap
Moving activities to L2 can reduce L1's MEV pressure.
6. Improvements in Cross-L2 Interoperability
1) What problem are we trying to solve?
Currently, a major issue in the L2 ecosystem is the difficulty users face in navigation, and common navigation methods (such as centralized bridging and RPC clients) introduce trust assumptions. To truly make L2 a part of Ethereum, we need to provide users with a unified ecosystem experience.
An example of a painfully poor (and even dangerous) cross-L2 user experience—personally, I lost $100 here due to a chain selection error—although this is not Polymarket's fault, cross-L2 interoperability should be the responsibility of wallets and the Ethereum standards (ERC) community. In a normally functioning Ethereum ecosystem, sending tokens from L1 to L2 or from one L2 to another should have the same experience as sending tokens within the same L1.
2) Improvements in Cross-L2 Interoperability
Improvements in cross-L2 interoperability can be categorized into several areas, with the main goal of narrowing the gap between the existing L2 ecosystem and the ideal state. Specific improvement directions include:
A. Chain-specific addresses: Addresses should contain chain information, simplifying the cross-L2 transfer process and allowing wallets to automatically determine the sending method.
B. Chain-specific payment requests: Generating standardized payment messages to facilitate personal payments and decentralized application funding requests.
C. Cross-chain exchanges and gas payments: Creating open protocols to express cross-chain operations, supporting asset transfers between different L2s.
D. Light clients: Users should be able to verify the authenticity of the chain without solely relying on RPC providers, achieving trust independence.
These improvements will enhance interoperability between L2s, making the user experience smoother and safer during cross-chain interactions.
E. Keystore Wallet: Centrally stores keys, allowing updates in one place while reading from multiple L2s. This requires L2s to have standardized methods for cost-free reading from L1, with related proposals including:
A. L1SLOAD: Efficiently reading L1 storage data from L2.
B. REMOTESTATICCALL: Allowing L2 to call L1 functions at no cost to read information.
With the Keystore wallet, users can more conveniently manage cross-chain key updates.
F. Shared Token Bridge Concept: Envisioning a world where all L2s are validity proof rollups, creating a shared minimal rollup that maintains different L2 token balances and allows for cross-L2 batch transfers. This can reduce L1 gas fees and improve the efficiency of cross-L2 transfers.
G. Synchronized Composability: Allowing synchronous calls between specific L2s and L1 or among multiple L2s, enhancing the financial efficiency of DeFi protocols. Rollup-based solutions naturally support these technologies.
These improvements will enhance interoperability between L2s, making the user experience smoother and safer during cross-chain interactions.
3) Remaining Work and Trade-offs
Many examples face timing and hierarchy issues regarding standardization. Premature standardization may lead to the entrenchment of subpar solutions, while delayed standardization could result in unnecessary fragmentation. In some cases, short-term solutions may be simple but not ideal, while long-term solutions are more comprehensive but may take years to implement.
These tasks are not only technical issues but also social issues, involving cooperation between L2s, wallets, and L1. Whether we can successfully address these issues tests the cohesion of the community.
4) Interaction with Other Parts of the Roadmap
Most proposals are higher-level constructs with little impact on L1, the only exception being shared ordering, which will have a significant impact on MEV.
7. Expanding L1 Execution Capacity
1) What Problem Are We Trying to Solve?
If L2 is highly scalable but L1 transaction volume remains low, it could pose risks to Ethereum:
The economic condition of ETH assets becomes more fragile, affecting the long-term security of the network.
L2 relies on L1's financial ecosystem; if the ecosystem weakens, the attractiveness of L2 will also decrease.
L2 takes longer to achieve the same security assurances as L1.
If a particular L2 fails, users need to recover assets through L1, so L1 must be able to handle complex L2 liquidations.
Therefore, it is crucial to expand L1 and ensure it can accommodate more application scenarios.
2) What Is It and How Does It Work? Increasing the gas limit is the most direct way to scale L1, but this may lead to centralization and undermine Ethereum's credibility. Sustainability is still under discussion, and other technological implementations need to be considered to improve the verification efficiency of large blocks.
Other scaling strategies involve identifying specific functionalities that can reduce costs without compromising decentralization and security. For example:
A. Specific Computations to Reduce Costs:
EOF: A new EVM bytecode format that facilitates static analysis, allows for faster implementation, and can lower gas costs.
Multidimensional Gas Pricing: Setting independent fees and limits for computation, data, and storage, increasing average capacity without increasing security risks.
Lowering Gas Costs for Specific Operations: For example, reducing gas fees for addition and other simple operations to be lower than multiplication.
B. EVM-MAX and SIMD:
EVM-MAX: Allows for more efficient native large number mathematics by optimizing storage through module isolation.
- SIMD: Efficiently executing the same instruction on a set of values, aiding the scalability of privacy protocols and L2 proof systems.
C. Native Rollups: Creating multiple parallel-running EVM copies, equivalent to the rollup model but more natively integrated into the protocol.
3) Remaining Work and Trade-offs
L1 scaling has three strategies that can be implemented individually or in parallel:
A. Technical Improvements: Optimizing client and historical data processing, simplifying L1 verification, and subsequently increasing gas limits.
B. Lowering Costs for Specific Operations: Enhancing average processing capacity without increasing risks.
C. Native Rollups: Creating multiple EVM copies to provide developers with flexibility.
These technologies each have their pros and cons. For example, native rollups have limited composability and cannot synchronize operations across multiple Rollups. Increasing gas limits may reduce the number of validating nodes and independent stakers, while lowering costs for specific operations may increase overall complexity.
An important question is: what should be placed on L1 and what should be placed on L2? It is not feasible to place everything on L1 due to the potential transaction volume, which would affect L1's verification capacity (unless using native rollups). Therefore, we need to clarify principles to avoid increasing gas limits that could harm the decentralization of Ethereum L1, ultimately leading to most activities still occurring on L2, causing L1 to lose its uniqueness.
A proposed perspective on the "division of labor" between L1 and L2.
4) Interaction with Other Parts of the Roadmap
Bringing more users to L1 means needing to enhance its scale and other aspects. This will lead to more MEV remaining on L1, increasing the demand for handling MEV and enhancing the value of L1's fast time slots. At the same time, this also relies on the smooth operation of L1 verification.
Note: For readability, this article has been streamlined based on the original text. For details, please refer to the original: https://vitalik.eth.limo/general/2024/10/17/futures2.html
Article link: https://www.hellobtc.com/kp/du/10/5477.html
Source: https://vitalik.eth.limo/general/2024/10/17/futures2.html
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
