Vitalik: How to make Ethereum as simple as Bitcoin in 5 years

Author: Vitalik Buterin; Translator: GaryMa Wu says blockchain

Abstract

Ethereum aims to be a global ledger, which requires scalability and resilience. This article focuses on the importance of protocol simplicity, and proposes to greatly reduce complexity by simplifying the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or similar virtual machines), reducing development costs, error risks, and attack surfaces. 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 Ethereum consensus key code close to the simplicity of Bitcoin, improve resilience and participation, and culturally value simplicity and set a maximum number of lines of code.

Ethereum aims to become a global ledger: a platform for storing assets and records of human civilization, serving in finance, governance, high-value data authentication and other fields. 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 and quantum resistance research are also progressing steadily, and the application ecosystem is becoming increasingly robust.

This article aims to focus on an equally important but underestimated resilience (and even scalability) factor: protocol simplicity.

The most amazing thing about the Bitcoin protocol is its elegant simplicity:

1. There is a chain of blocks, each of which is connected to the previous block through a hash.

2. The validity of the block is verified by proof of work (PoW), which is to check whether the first few bits of the hash value are zero.

3. Each block contains transactions, and the coins spent on transactions come either from mining rewards or from previous transaction outputs.

That's it! Even a smart high school student can fully understand the operation of the Bitcoin protocol, and a programmer can even write a client for it as a side project.

The simplicity of the protocol brings many key advantages to Bitcoin (and Ethereum) as a trusted, neutral global base layer:

1. Easy to understand : Reduce the complexity of the protocol, allowing more people to participate in protocol research, development and governance, and reduce the risk of dominance by the technical elite.

2. Reduce development costs: Simplifying the protocol greatly 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 protocol maintenance.

4. Reduce error risks: Reduce the possibility of catastrophic errors in protocol specifications and implementations, and make it easier to verify that such errors do not exist. 5. Reduce the attack surface: Reduce the complexity of the protocol and reduce the risk of being attacked by special interest groups. Historically, Ethereum (sometimes due to my personal decisions) has often failed to keep it simple, resulting in excessive development costs, increased security risks, and a closed R&D culture, and the benefits of these complex pursuits have often proved to be illusory. This article will explore how Ethereum, five years later, is close to the simplicity of Bitcoin.

Simplified 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 other fields. Compared with 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 committees). A basic implementation of 3-slot finality takes only ~200 lines of code and is close to optimal security compared to Gasper. 2. Reduced number of active validators: Allows for simpler fork choice rule implementations, increasing security. 3. STARK-based aggregation protocols: Anyone can become an aggregator without having to trust an aggregator or pay high fees for duplicate bitfields. Aggregate cryptography is more complex, but its complexity is highly encapsulated, with lower systemic risk.

4. Simplify P2P architecture: The above factors may support a simpler and more robust peer-to-peer network architecture.

5. Redesign the validator mechanism: Including mechanisms such as entry, exit, withdrawal, key conversion, inactivity leak, simplifying the number of lines of code and providing clearer guarantees (such as weak subjectivity cycle).

The advantage of the consensus layer is that it is relatively independent of the EVM execution layer, so there is a large space for continuous improvement. The greater challenge is how to achieve similar simplification at the execution layer.

Simplify the Execution Layer

The EVM has been growing in complexity, and much of the complexity has proven unnecessary (partially due to my own poor decisions): the 256-bit VM was over-optimized for specific forms of cryptography that are now becoming obsolete, and precompiles were optimized for single use cases that are rarely used.

Addressing these issues one by one has limited success. For example, removing the SELFDESTRUCT opcode was a huge effort with only small gains. The recent debate over EOF (EVM Object Format) also demonstrated similar challenges. I recently proposed a more radical proposal: instead of making moderately large (but still disruptive) changes to the EVM in exchange for a 1.5x gain, we can 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 change more meaningful. Specifically, I propose replacing the EVM with RISC-V, or another VM used by the Ethereum ZK prover. This will result in: 1. Significant efficiency improvements: Smart contract execution (in the prover) runs directly without the overhead of an interpreter. Succinct's data shows performance improvements of more than 100x in many scenarios.

2. Significant improvement in simplicity: RISC-V specification is extremely simple compared to EVM, and alternatives (such as Cairo) are equally simple.

3. Motivation 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 you choose RISC-V, 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 remain (even these will disappear once quantum computers become common). The main disadvantage is that, unlike the ready-to-go EOF, the benefits of the new virtual machine will take a long time to benefit developers. We can alleviate this problem by implementing high-value EVM improvements in the short term (such as increasing the contract code size limit and supporting DUP/SWAP17–32). This will result in a simpler virtual machine. The core challenge is: what to do with the existing EVM?

Backward compatibility strategy for virtual machine transition

The biggest challenge in simplifying (or improving without increasing complexity) EVM is how to balance the target implementation with backward compatibility of existing applications.

First of all, it needs to be clear: the Ethereum code base (even within a single client) is not defined in only one way.

The goal is to minimizeGreen area: The logic required for nodes to participate in Ethereum consensus, including calculating the current state, proofs, verification, FOCIL (fork selection rule), and "normal" block construction.

Orange areaCannot 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 still need to retain the relevant code. However, new clients, ZK-EVM, or formal provers can completely ignore the orange area.

Newly added Yellow area: 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 of the orange and yellow areas is encapsulation complexity, people who understand the protocol can skip these parts, Ethereum implementations can ignore them, and errors in these areas will not cause consensus risks. Therefore, the code complexity in the orange and yellow areas is far 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 of the Ipsilon team, I propose the following virtual machine 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 virtual machine):

1. Require new precompilation to provide on-chain RISC-V implementation : Let the ecosystem gradually adapt to the RISC-V virtual machine.

2. Introduce 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 precompilation through hard fork, and change the code of this address (similar to 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. Implement an EVM interpreter in RISC-V: On-chain as a smart contract (already done because of the ZK prover). Existing EVM contracts run through this interpreter several years after the initial release.

After completing step 4, 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 useless 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 code

We need erasure codes in three scenarios:

1. Data availability sampling: The client verifies that the block has been published.

2. Faster P2P broadcast: 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 the 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 part of the fragments for a certain scenario, these data can be used in other scenarios.

3. Ensure verifiability : The fragments of 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 and vertical random linear codes operate in the same domain.

Uniform serialization format

Ethereum's serialization format is currently only partially solidified, because 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 solidification 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 have the opportunity to unify the serialization format of the three layers of Ethereum: execution layer, consensus layer, and smart contract call ABI.

I propose to use  SSZbecause SSZ:

1. Easy to decode: including in smart contracts (due to its 4-byte based design and fewer edge cases).

2. 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 largest bottleneck for proof block execution, even in the average case. Migrating to binary trees based on better hash functions will significantly improve prover efficiency while reducing data costs for scenarios such as light clients.

When migrating, ensure that the consensus layer uses the same tree structure. This will make Ethereum’s consensus layer and execution layer accessible and parsable from 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 difficult to quantify, while the costs of extra effort and giving up some of the cool features are immediate. However, the benefits become more significant over time — — Bitcoin itself is a perfect example.

I propose to follow tinygrad's lead and set an explicit maximum lines of code goalfor Ethereum's long-term specifications, bringing Ethereum consensus-critical code close to Bitcoin's simplicity. Code that handles Ethereum's historical rules will continue to exist, but should be kept off the consensus critical path. At the same time, we should uphold the philosophy of choosing the simpler option, prioritizing encapsulated complexity over systemic complexity, and making design choices that provide clear properties and guarantees.