Original Title: Simplifying the L1
Original Author: Vitalik Buterin
Original Compiler: GaryMa, Wu Says Blockchain
Abstract
Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing to significantly reduce complexity by simplifying the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or a similar virtual machine), thereby lowering development costs, error risks, and attack surfaces. A smooth transition is suggested through backward compatibility strategies (such as an on-chain EVM interpreter), and unifying erasure codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus critical code closer to Bitcoin's simplicity, enhancing resilience and participation, with a cultural emphasis on simplicity and setting a maximum line count target.
Ethereum's goal is to become a global ledger: a platform for storing human civilization's assets and records, serving fields such as finance, governance, and high-value data certification. This requires support in two aspects: scalability and resilience. The Fusaka hard fork plan aims to increase the available space for L2 data by tenfold, while the currently proposed roadmap for 2026 also plans for a similar significant enhancement for the L1 layer. Meanwhile, Ethereum has completed its transition to proof of stake (PoS), client diversity is rapidly increasing, zero-knowledge (ZK) verification and quantum resistance research are steadily advancing, and the application ecosystem is becoming increasingly robust.
This article aims to focus on an equally important yet often underestimated element of resilience (and even scalability): protocol simplicity.
The most impressive aspect of the Bitcoin protocol is its elegant simplicity:
There exists a chain composed of blocks, each block linked to the previous one via a hash.
The validity of a block is verified through proof of work (PoW), which checks whether the leading bits of the hash are zero.
Each block contains transactions, and the coins spent in transactions come either from mining rewards or from previous transaction outputs.
That's it! Even a clever high school student can fully understand how the Bitcoin protocol operates, and a programmer could even write a client as a hobby project. The simplicity of the protocol brings numerous key advantages for Bitcoin (and Ethereum) to become a trusted, neutral global base layer:
1. Easy to understand: Reducing the complexity of the protocol allows more people to participate in protocol research, development, and governance, reducing the risk of domination by a technical elite.
2. Lower development costs: Simplifying the protocol significantly reduces the cost of creating new infrastructure (such as new clients, provers, developer tools, etc.).
3. Reduced maintenance burden: Lowering the cost of long-term protocol maintenance.
4. Reduced error risk: Lowering the likelihood of catastrophic errors occurring in protocol specifications and implementations, while making it easier to verify that such errors do not exist.
5. Smaller attack surface: Reducing the complex components of the protocol lowers the risk of being attacked by special interest groups.
Historically, Ethereum (sometimes due to my personal decisions) has often failed to maintain simplicity, leading to excessive development costs, increased security risks, and a closed research and development culture, while the benefits pursued through this complexity have often proven illusory. This article will explore how Ethereum can approach Bitcoin's simplicity five years from now.
Simplifying the Consensus Layer
The new consensus layer design (historically referred to as the "Beacon Chain") aims to leverage the experiences of the past decade in consensus theory, ZK-SNARK development, staking economics, and more, to build a long-term optimal and simpler consensus layer. Compared to the existing Beacon Chain, the new design significantly simplifies:
1. 3-slot finality design: Removing concepts such as slots, epochs, committee reorganization, and related efficient processing mechanisms (like synchronized committees). The basic implementation of 3-slot finality requires only about 200 lines of code and has security close to optimal compared to Gasper.
2. Reducing the number of active validators: Allowing the use of simpler fork choice rules to enhance security.
3. STARK-based aggregation protocol: Anyone can become an aggregator without needing to trust the aggregator or pay high fees for duplicate bit fields. The complexity of aggregation cryptography is high, but its complexity is highly encapsulated, resulting in lower systemic risk.
4. Simplifying P2P architecture: The above factors may support a simpler and more robust peer-to-peer network architecture.
5. Redesigning the validator mechanism: Including mechanisms for entry, exit, withdrawals, key transitions, inactivity leaks, etc., simplifying the line count and providing clearer guarantees (such as weak subjectivity periods).
The advantage of the consensus layer lies in its relative independence from the EVM execution layer, thus allowing for significant ongoing improvements. The greater challenge lies in how to achieve similar simplifications in the execution layer.
Simplifying the Execution Layer
The complexity of the EVM has been increasing, and much of this complexity has proven unnecessary (partly due to my personal decision-making errors): the 256-bit virtual machine has overly optimized for specific cryptographic forms that are gradually becoming outdated, and precompiles are optimized for single-use cases that are rarely used.
Addressing these issues one by one has limited effectiveness. For example, removing the SELFDESTRUCT opcode required significant effort but yielded only minor benefits. Recent debates about EOF (EVM Object Format) have also highlighted similar challenges.
I recently proposed a more radical solution: rather than making medium-scale (but still disruptive) changes to the EVM for a 1.5x benefit, we should transition to a better, simpler virtual machine for a 100x benefit. Similar to "The Merge," we reduce the number of disruptive changes but make each change more meaningful. Specifically, I suggest replacing the EVM with RISC-V or another virtual machine used by Ethereum's ZK provers. This would bring:
1. Significant efficiency improvements: Smart contract execution (in the prover) would run directly without interpreter overhead. Succinct data shows performance can improve by over 100 times in many scenarios.
2. Major simplicity improvements: The RISC-V specification is extremely simple compared to the EVM, and alternatives (like Cairo) are equally straightforward.
3. Motivation to support EOF: Such as code partitioning, friendlier static analysis, and larger code size limits.
4. More developer choices: Solidity and Vyper could add backends to compile to the new virtual machine. If RISC-V is chosen, mainstream language developers could easily port their code to this virtual machine.
5. Removal of most precompiles: Possibly retaining only highly optimized elliptic curve operations (which will disappear even after quantum computers become mainstream).
The main drawback is that, unlike the ready-to-go EOF, the benefits of the new virtual machine will take longer to reach developers. We can mitigate this issue by implementing high-value EVM improvements in the short term (such as increasing contract code size limits, supporting DUP/SWAP17–32).
This will lead to a simpler virtual machine. The core challenge is: how to handle the existing EVM?
Backward Compatibility Strategy for Virtual Machine Transition
The biggest challenge in simplifying (or improving without increasing complexity) the EVM lies in balancing the achievement of goals with backward compatibility for existing applications.
- First, it needs to be clarified: the Ethereum codebase (even within a single client) does not have only one definition.
- The goal is to minimize the green area: the logic required for nodes to participate in Ethereum consensus, including computing the current state, proving, verifying, FOCIL (fork choice rules), and "ordinary" block construction.
- The orange area cannot be reduced: if the protocol specification removes or changes a certain execution layer function (such as the virtual machine, precompiles, etc.), clients processing historical blocks still need to retain the relevant code. However, new clients, ZK-EVM, or formal provers can completely ignore the orange area.
The newly added yellow area: valuable for understanding the current chain or optimizing block construction, but not part of the consensus logic. For example, Etherscan and some block builders support ERC-4337 user operations. If we replace certain Ethereum functions (like EOA and its supported old transaction types) with an on-chain RISC-V implementation, the consensus code will be significantly simplified, but dedicated nodes may continue to use the original code for parsing.
The complexity of the orange and yellow areas is encapsulated complexity; those who understand the protocol can skip these parts, and Ethereum implementations can ignore them. Errors in these areas will not trigger consensus risks. Therefore, the code complexity of the orange and yellow areas poses far less danger than that of the green area.
The idea of moving code from the green area to the yellow area is similar to Apple's strategy of ensuring long-term backward compatibility through the Rosetta translation layer. Inspired by a recent article from the Ipsilon team, I propose the following virtual machine change process (using EVM to RISC-V as an example, but it can also apply to EVM to Cairo or RISC-V to a better virtual machine):
1. Require new precompiles to provide on-chain RISC-V implementations: Allow the ecosystem to gradually adapt to the RISC-V virtual machine.
2. Introduce RISC-V as a developer option: The protocol supports both RISC-V and EVM, allowing contracts from both virtual machines to interact freely.
3. Replace most precompiles: Replace other precompiles with RISC-V implementations, except for elliptic curve operations and KECCAK (due to the need for extreme speed). Remove precompiles through a hard fork while changing the code at that address (similar to the DAO fork) from empty to RISC-V implementation. The RISC-V virtual machine is extremely simple, and even stopping here would simplify the protocol.
4. Implement an EVM interpreter in RISC-V: As smart contracts go on-chain (as required by ZK provers). After several years of initial release, existing EVM contracts will run through this interpreter.
After completing step 4, many "EVM implementations" will still be used for optimizing block construction, developer tools, and chain analysis, but will no longer be part of the critical consensus specification. Ethereum consensus will "natively" only understand RISC-V.
Simplifying by Sharing Protocol Components
Reducing the overall complexity of the protocol through a third method (which is also the easiest to underestimate) is to share unified standards as much as possible across different parts of the protocol stack. Different protocols doing the same thing in different scenarios is often of no benefit, yet this pattern still frequently occurs, mainly due to a lack of communication between different parts of the protocol roadmap. Here are several specific examples of how sharing components can simplify Ethereum.
Unified Erasure Codes
We need erasure codes in three scenarios:
1. Data availability sampling: Clients verify that blocks have been published.
2. Faster P2P broadcasting: Nodes can accept blocks after receiving n/2 fragments, balancing latency and redundancy.
3. Distributed historical storage: Ethereum's historical data is stored in shards, where each group of n/2 fragments can recover the remaining fragments, reducing the risk of losing a single fragment.
If the same erasure code (whether Reed-Solomon, random linear codes, etc.) is used in all three scenarios, the following advantages will be gained:
1. Minimized code volume: Reducing the total number of lines of code.
2. Increased efficiency: If nodes download partial fragments for a certain scenario, this data can be used for other scenarios.
3. Ensured verifiability: Fragments from all scenarios can be verified based on the root.
If different erasure codes are used, at least compatibility should be ensured, for example, horizontal Reed-Solomon codes for data availability sampling operating in the same field as vertical random linear codes.
Unified Serialization Format
Ethereum's serialization format is currently only partially solidified, as data can be re-serialized and broadcast in any format. An exception is the transaction signature hash, which requires a standardized format for hashing. In the future, the degree of solidification of serialization formats will further increase for the following reasons:
1. Complete account abstraction (EIP-7701): The complete content of transactions is visible to the virtual machine.
2. Higher gas limits: Execution layer data needs to be placed in data blobs.
At that time, we have the opportunity to unify the serialization formats across Ethereum's three layers: execution layer, consensus layer, and smart contract call ABI.
I propose using SSZ, because SSZ:
1. Is easy to decode: Including within smart contracts (due to its design based on 4-byte structures and fewer edge cases).
2. Is widely used in the consensus layer.
3. Is highly similar to the existing ABI: Tool adaptation is relatively simple.
There have been efforts to fully migrate to SSZ, and we should consider and continue these efforts when planning future upgrades.
Unified Tree Structure
If migrating from EVM to RISC-V (or another optional minimal virtual machine), the hexadecimal Merkle Patricia tree will become the biggest bottleneck in proving block execution, even on average. Migrating to a binary tree based on a better hash function will significantly improve prover efficiency while reducing data costs in scenarios like light clients. During the migration, it should be ensured that the consensus layer uses the same tree structure. This will allow Ethereum's consensus layer and execution layer to be accessed and parsed through the same code.
From Now to the Future
Simplicity is similar to decentralization in many ways; both are upstream goals of resilience. Clearly valuing simplicity requires a certain cultural shift. The benefits are often difficult to quantify, while the costs of additional effort and giving up certain flashy features are immediately apparent. However, over time, the benefits will become increasingly significant—Bitcoin itself is an excellent example.
I propose emulating tinygrad by setting a clear maximum line count target for Ethereum's long-term specifications, bringing Ethereum's consensus critical code closer to Bitcoin's simplicity. The code handling Ethereum's historical rules will continue to exist but should be placed outside the critical consensus path. At the same time, we should adhere to the principle of choosing simpler solutions, prioritizing encapsulated complexity over systemic complexity, and making design choices that provide clear attributes and guarantees.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
