Compiled by GaryMa Wu Blockchain about blockchain
Original link:
https://vitalik.eth.limo/general/2025/05/03/simplel1.html
summary
Ethereum aims to be a global ledger, which requires scalability and resilience. This article focuses on the importance of protocol simplicity and proposes to significantly reduce complexity, development costs, error risks, and attack surfaces by simplifying the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or similar virtual machines). It is recommended to smoothly transition through backward compatibility strategies (such as on-chain EVM interpreters) and unify erasure codes, serialization formats (SSZ), and tree structures for further simplification. The goal is to make the key Ethereum consensus code close to the simplicity of Bitcoin, improve resilience and participation, and culturally value simplicity and set a maximum line of code goal.
Ethereum aims to become a global ledger: a platform for storing assets and records of human civilization, serving the fields of finance, governance, and high-value data authentication. This requires support from two aspects: scalability and resilience. The Fusaka hard fork plans to increase the available space for L2 data by 10 times, and the current proposed 2026 roadmap also plans to bring similar significant improvements to the L1 layer. At the same time, Ethereum has completed the transition to Proof of Stake (PoS), client diversity has increased rapidly, zero-knowledge (ZK) verification, quantum resistance research is also progressing steadily, and the application ecosystem is becoming increasingly robust.
This article aims to focus on an equally important but often underestimated factor of resilience (and scalability): protocol simplicity.
The most amazing thing about the Bitcoin protocol is its elegant simplicity:
1. There is a chain of blocks, each connected to the previous block via a hash.
2. The validity of the block is verified by Proof of Work (PoW), which checks whether the first few digits of the hash value are zero.
3. Each block contains transactions, and the coins spent on transactions either come from mining rewards or from previous transaction outputs.
That’s it! Even a smart high school student can fully understand how the Bitcoin protocol works, and a programmer can even write a client for it as a side project.
The simplicity of the protocol brings a number of key advantages to Bitcoin (and Ethereum) as a trusted, neutral, global base layer:
1. Easy to understand : Reduce the complexity of the protocol, allow more people to participate in protocol research, development and governance, and reduce the risk of being dominated by the technical elite.
2. Reduce development costs : Simplifying the protocol significantly reduces the cost of creating new infrastructure (such as new clients, provers, developer tools, etc.).
3. Reduce maintenance burden : Reduce the cost of long-term agreement maintenance.
4. Reduce the risk of errors : Reduce the possibility of catastrophic errors in protocol specifications and implementations, and facilitate verification that such errors do not exist.
5. Reduce the attack surface : Reduce the complex components of the protocol and reduce the risk of being attacked by special interest groups.
Historically, Ethereum (and sometimes my own decisions) has often failed to keep things simple, leading to excessive development costs, increased security risks, and a closed R&D culture, all in pursuit of complexity that often proved to be illusory gains. This article will explore how Ethereum, five years later, is approaching the simplicity of Bitcoin.
Simplifying the consensus layer
The new consensus layer design (historically called the "beacon chain") aims to build a long-term optimal and simpler consensus layer by leveraging the past decade of experience in consensus theory, ZK-SNARK development, staking economics, and more. Compared to the existing beacon chain, the new design is significantly simplified:
1. 3-slot finality design : remove the concepts of slot, epoch, committee reorganization, and related efficient processing mechanisms (such as synchronization committee). The basic implementation of 3-slot finality only requires about 200 lines of code, and compared with Gasper, the security is close to optimal.
2. Reduce the number of active validators : Allows for simpler fork selection rule implementations and enhances security.
3. Aggregation protocol based on STARK : Anyone can become an aggregator without having to trust the aggregator or pay high fees for duplicate bit fields. Aggregation cryptography is more complex, but its complexity is highly encapsulated and the systemic risk is lower.
4. Simplified P2P architecture : The above factors may support a simpler and more robust peer-to-peer network architecture.
5. Redesign the verifier mechanism : including entry, exit, withdrawal, key conversion, inactivity leak and other mechanisms, simplify the number of lines of code and provide clearer guarantees (such as weak subjectivity cycle).
The advantage of the consensus layer is that it is relatively independent from the EVM execution layer, so there is a lot of room for continuous improvement. The greater challenge is how to achieve similar simplification at the execution layer.
Simplify the execution layer
The EVM has grown in complexity, and much of that complexity has proven unnecessary (partly due to my own poor decisions): the 256-bit VM was over-optimized for a specific form of cryptography that is now increasingly obsolete, and precompiles were optimized for a single use case that is rarely used.
Solving these problems one by one has limited success. For example, removing the SELFDESTRUCT opcode required a lot of effort but brought only small benefits. The recent debate on EOF (EVM Object Format) also showed similar challenges.
I recently proposed a more radical solution: instead of making moderately sized (but still disruptive) changes to the EVM in exchange for a 1.5x gain, we could transition to a better, simpler VM to achieve a 100x gain. Similar to The Merge, we reduce the number of breaking changes but make each one more meaningful. Specifically, I propose replacing the EVM with RISC-V, or another VM used by Ethereum’s ZK prover. This would result in:
1. Significantly improved efficiency : Smart contract execution (in the prover) does not require interpreter overhead and runs directly. Succinct’s data shows that performance can be improved by more than 100 times in many scenarios.
2. Significantly improved simplicity : The RISC-V specification is extremely simple compared to the EVM, and alternatives (such as Cairo) are equally simple.
3. Motivations for supporting EOF : such as code partitioning, more friendly static analysis, larger code size limit, etc.
4. More developer choices : Solidity and Vyper can add backends to compile to new virtual machines. If RISC-V is chosen, mainstream language developers can also easily port their code to the virtual machine.
5. Remove most precompilation : probably only highly optimized elliptic curve operations will be kept (even these will disappear when quantum computers become popular).
The main disadvantage is that, unlike the ready-to-go EOF, the benefits of a new VM take a long time to trickle down to developers. We can mitigate this by implementing high-value EVM improvements in the short term (such as increasing the contract code size limit, supporting DUP/SWAP17–32).
This will result in a simpler virtual machine. The core challenge is: how to deal with the existing EVM?
Backward compatibility strategy for virtual machine transition
The biggest challenge in simplifying (or improving without adding complexity) the EVM is balancing the target implementation with backward compatibility for existing applications.
First of all, it is important to be clear: there is not only one way to define the Ethereum codebase (even within a single client).
The goal is to minimize the green area : the logic required for a node to participate in Ethereum consensus, including computing the current state, proofs, validation, FOCIL (fork choice rule), and “normal” block construction.
The orange area cannot be reduced: if the protocol specification removes or changes an execution layer function (such as a virtual machine, precompilation, etc.), clients that process historical blocks must still retain the relevant code. However, new clients, ZK-EVM, or formal provers can completely ignore the orange area.
Newly added yellow areas : Very valuable for understanding the current chain or optimizing block building, but not part of the consensus logic. For example, Etherscan and some block builders support ERC-4337 user operations. If we replace some Ethereum functions (such as EOA and the old transaction types it supports) with on-chain RISC-V implementations, the consensus code will be significantly simplified, but dedicated nodes may continue to use the original code for parsing.
The complexity in the orange and yellow areas is encapsulation complexity . People who understand the protocol can skip these parts, and Ethereum implementations can ignore them. Errors in these areas will not cause consensus risks. Therefore, the code complexity in the orange and yellow areas is much less harmful than the complexity in 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 the recent article by the Ipsilon team, I propose the following VM change process (using EVM to RISC-V as an example, but it can also be used for EVM to Cairo or RISC-V to a better VM):
1. Require new precompilations to provide on-chain RISC-V implementations : Allow the ecosystem to gradually adapt to the RISC-V virtual machine.
2. Introducing RISC-V as a developer option : The protocol supports both RISC-V and EVM, and the contracts of the two virtual machines can interact freely.
3. Replace most precompilations : Except for elliptic curve operations and KECCAK (due to the need for extreme speed), replace other precompilations with RISC-V implementations. Remove precompilations through hard forks, and change the code at this address (similar to the DAO fork) from empty to RISC-V implementation. The RISC-V virtual machine is extremely simple, and even stopping here will only simplify the protocol.
4. Implementing an EVM interpreter in RISC-V : On-chain as a smart contract (already done because of the need for ZK prover). Existing EVM contracts run through this interpreter several years after the initial release.
After step 4 is complete, many "EVM implementations" will still be used to optimize block construction, developer tools, and chain analysis, but will no longer be part of the key consensus specification. Ethereum consensus will "natively" only understand RISC-V.
Simplify through shared protocol components
The third way to reduce the overall complexity of the protocol (and the most underestimated) is to share unified standards in different parts of the protocol stack as much as possible. It is usually unhelpful for different protocols to do the same thing in different scenarios, but this pattern still occurs frequently, mainly due to a lack of communication between different parts of the protocol roadmap. Here are a few specific examples of simplifying Ethereum through shared components.
Unified Erasure Coding
We need erasure codes in three scenarios:
1. Data availability sampling : The client verifies that the block has been published.
2. Faster P2P broadcasting : A node can accept a block after receiving n/2 fragments, achieving a balance between latency and redundancy.
3. Distributed historical storage : Ethereum historical data is stored in shards, and each group of n/2 fragments can restore the remaining fragments, reducing the risk of losing a single fragment.
If the same erasure code (whether Reed-Solomon, random linear code, etc.) is used in all three scenarios, the following advantages will be obtained:
1. Minimize the amount of code : reduce the total number of lines of code.
2. Improve efficiency : If a node downloads a partial fragment for a scene, this data can be used in other scenes.
3. Ensure verifiability : All scenes’ fragments are verifiable against the root.
If different erasure codes are used, at least compatibility should be ensured, for example, horizontal Reed-Solomon codes for data availability sampling and vertical random linear codes operate in the same domain.
Unified serialization format
Ethereum's serialization format is currently only partially fixed, as data can be reserialized and broadcast in any format. The exception is the transaction signature hash, which needs to be hashed in a standardized format. In the future, the degree of fixation of the serialization format will be further improved due to the following reasons:
1. Complete account abstraction (EIP-7701) : The complete content of the transaction is visible to the virtual machine.
2. Higher Gas Limit : Execution layer data needs to be placed in data blocks (blobs).
By then, we will have the opportunity to unify the serialization formats of the three layers of Ethereum: execution layer, consensus layer, and smart contract call ABI.
I propose to use SSZ because SSZ:
1. Easy to decode: included in smart contracts (due to its 4-byte based design and fewer edge cases).
2. It has been widely used in the consensus layer.
3. Highly similar to existing ABI: tool adaptation is relatively simple.
There are 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 other optional minimal virtual machines), the hexadecimal Merkle Patricia tree will become the biggest bottleneck for proof block execution, even in average cases. Migrating to a binary tree based on a better hash function will significantly improve the efficiency of the prover while reducing the data cost of scenarios such as light clients.
When migrating, you should ensure 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, and both are upstream of resilience goals. Explicitly valuing simplicity requires a cultural shift. The benefits are often hard to quantify, while the costs of extra effort and giving up some of the cool features are immediate. However, the benefits become more pronounced over time — Bitcoin itself is a perfect example of this.
I propose to follow the example of tinygrad and set an explicit maximum line of code goal for Ethereum long-term specifications, so that Ethereum consensus-critical code approaches Bitcoin's simplicity. Code that handles Ethereum's historical rules will continue to exist, but should be placed outside the consensus critical path. At the same time, we should uphold the philosophy of choosing the simpler option, prioritize encapsulated complexity over systemic complexity, and make design choices that provide clear properties and guarantees.
