Vitalik Analysis: How to Make Ethereum as Easy as Bitcoin in 5 Years

Ethereum aims to be a global ledger and requires scalability and resilience. This paper focuses on the importance of protocol simplicity and proposes to significantly reduce complexity by simplifying the consensus layer (3-slot finality, STARK aggregation) and execution layer (replace EVM with RISC-V or similar virtual machines), reducing development costs, error risks and attack surfaces. It is recommended to smooth the transition through backward compatibility strategies such as on-chain EVM interpreters and unify erasure coding, serialization format (SSZ), and tree structure for further simplification. The goal is to bring the Ethereum consensus key code closer to Bitcoin's simplicity, improve resilience and participation, and cultural emphasis is required and the goal of setting the maximum number of lines of code is set.

Fusaka Hard Fork plans to increase the available space for L2 data by 10 times, and the currently proposed 2026 roadmap is also planned to bring a similar significant improvement to L1 tier. At the same time, Ethereum has completed the transition to Proof of Stake (PoS), client diversity has rapidly improved, zero-knowledge (ZK) verification and quantum resistance research are also steadily advancing, and the application ecosystem is becoming increasingly stable.

This article aims to focus on an equally important but easily underestimated element of resilience (or even scalability): the simplicity of the protocol.

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

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

2. The validity of the block is verified by Proof of Work (PoW), that is, check whether the first few digits of the hash value are zero.

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

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

The simplicity of the protocol brings many key advantages to Bitcoin (and Ethereum) becoming a credible, neutral global foundation:

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 being dominated by the technical elite.

2. Reduce development costs : Simplify the protocol to significantly reduce 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 the risk of errors : Reduce the possibility of catastrophic errors in protocol specifications and implementations, while facilitating 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 (sometimes due to my personal decisions) has often failed to keep it simple, resulting in excessive development costs, increased security risks and closed R&D culture, and the benefits pursued by these complexities have often proven to be illusory. This article will explore how Ethereum approaches Bitcoin’s simplicity in five years.

Simplify the consensus layer

The new consensus layer design (historically known as the "beacon chain") aims to build a long-term optimal and simpler consensus layer using the past decade's experience in consensus theory, ZK-SNARK development, staking economy and other fields. Compared with the existing beacon chain, the new design is significantly simplified:

1. 3-slot final design : concepts such as removal of slots, cycles (epoch), committee reorganization, and related efficient processing mechanisms (such as synchronous committees). The basic implementation of 3-slot finality requires only about 200 lines of code, and compared to Gasper, the security is close to the best.

2. Reduce the number of active validators : Allows simpler fork selection rules to implement, enhancing security.

3. STARK-based aggregation protocol : Anyone can become an aggregator without trusting the aggregator or paying high fees for duplicate bit domains. Aggregation cryptography is more complex, but its complexity is highly encapsulated and has lower systemic risks.

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 entry, exit, withdrawal, key conversion, inactivity leak and other mechanisms to simplify the number of lines of code and provide clearer guarantees (such as weak subjectivity cycles).

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 bigger challenge is how to achieve similar simplification at the execution layer.

Simplify the execution layer

EVM is growing in complexity, and many of the complexities prove unnecessary (partially due to my personal decision-making mistake): 256-bit virtual machines are over-optimized for specific cryptographic forms that are now obsolete, and precompiled for a single use case optimization is rarely used.

Solving these problems one by one has limited results. For example, removing the SELFDESTRUCT opcode takes a lot of effort but only brings less benefits. Recent debates about EOF (EVM Object Format) also show similar challenges.

I recently proposed a more radical approach: instead of making medium-sized (but still destructive) changes to EVM in exchange for 1.5x gains, transitioning to a better, simpler virtual machine to achieve 100x gains. Similar to The Merge, we reduce the number of disruptive changes, but make each change more meaningful. Specifically, I recommend replacing EVM with RISC-V, or another virtual machine used by the Ethereum ZK prover. This will bring:

1. Significantly improve efficiency : Smart contract execution (in the prover) does not require interpreter overhead and runs directly. Succinct data shows that performance can be improved by more than 100 times in many scenarios.

2. Significant improvement in simplicity : The RISC-V specification is extremely simple than EVM, and the alternatives (such as Cairo) are as simple as possible.

3. Motivation to support EOF : such as code partitioning, more friendly static analysis, larger code size limitations, 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 easily port code to the virtual machine.

5. Remove most precompilations : only highly optimized elliptic curve operations may be retained (even these will disappear after quantum computers become popular).

The main disadvantage is that unlike the ready EOF, the benefits of new virtual machines will take longer to benefit developers. We can mitigate this problem 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 deal with existing EVMs?

Backward compatibility policy for virtual machine transitions

The biggest challenge of simplifying (or improving without adding complexity) the EVM is how to balance the goal achievement of backward compatibility with existing applications.

First of all, it is important to be clear: the Ethereum code base (even within a single client) does not have only one way to define it.

The goal is to minimize the green area : the logic required by nodes to participate in the Ethereum consensus, including computing the current state, proof, verification, FOCIL (fork selection rule) and "normal" block construction.

The orange area cannot be reduced: if the protocol specification removes or changes a certain execution layer function (such as virtual machines, precompilers, etc.), the client processing the historical blocks still needs to retain the relevant code. But new clients, ZK-EVM, or formal proofers can completely ignore the orange area.

New yellow area : Very valuable for understanding the current chain or optimizing the block construction, but not consensus logic.

Etherscan and some block builders support ERC-4337 user operations. If we replace certain Ethereum functions (such as EOA and its supported old transaction types) with 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 orange and yellow regions is encapsulation complexity , and those who understand the protocol can skip these parts, and Ethereum implementations can ignore them, and errors in these regions do not raise consensus risks.

The code complexity of orange and yellow areas is much less harmful than that of green areas.

The idea of ​​moving the code from the green area to the yellow area is similar to Apple's strategy to ensure long-term backward compatibility through the Rosetta translation layer.

Inspired by recent articles from the Ipsilon team, I proposed the following virtual machine change process (taking EVM to RISC-V as an example, but can also be used for EVM to Cairo or RISC-V to better virtual machines):

1. Require new precompilers to provide on-chain RISC-V implementations : to gradually adapt the ecosystem to RISC-V virtual machines.

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 precompilers : except for elliptic curve operation and KECCAK (due to extreme speed required), replace other precompilers with RISC-V implementation. Remove precompilation by hard forking while changing the code for that address (like DAO fork) from empty to RISC-V implementation. The RISC-V virtual machines are extremely simple and even stop here, it will simplify the protocol.

4. Implement the EVM interpreter in RISC-V : Winding as a smart contract (because the ZK prover needs to be done). Years after initial release, existing EVM contracts run through this interpreter.

After completing Step 4, many "EVM implementations" will still be used to optimize block building, developer tools, and chain analysis, but are no longer part of the key consensus specification. The Ethereum consensus will understand only RISC-V.

Simplify through shared protocol components

The third way to reduce the overall complexity of the protocol (and most easily underestimated) is to share unified standards as much as possible in different parts of the protocol stack. It is usually useless for different protocols to do the same thing in different scenarios, but this model still appears often, mainly because of the lack of communication between different parts of the protocol roadmap. Here are a few specific examples of simplifying Ethereum with shared components.

Unified erasure code

We need erasure code in three scenarios:

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

2. Faster P2P broadcast : The node can accept blocks after receiving n/2 clips, achieving a balance between delay and redundancy.

3. Distributed historical storage : Ethereum historical data is sharded storage, and each group of n/2 fragments can recover the remaining fragments, reducing the risk of loss of a single fragment.

If you use the same erasure code in three scenarios (whether Reed-Solomon, random linear code, etc.), you will get the following advantages:

1. Minimize the number of code : reduce the total number of lines of code.

2. Improve efficiency : If a node downloads some fragments for a certain scenario, these data can be used in other scenarios.

3. Ensure verifiability : All scene segments can be verified by root.

If different erasure codes are used, at least compatibility should be ensured, such as horizontal Reed-Solomon codes for data availability sampling operate in the same domain as vertical random linear codes.

Unified serialization format

Ethereum's serialization format is currently only partially solidified, as the data can be reserialized and broadcasted in any format. The exception is transaction signature hashing, which requires a standardized format to be hashed. In the future, the degree of solidification of serialized formats will be further improved due to the following reasons:

1. Complete Account Abstraction (EIP-7701) : The transaction is visible to the virtual machine.

2. Higher Gas limit : Execution layer data needs to be placed in data blocks (blobs).

At that time, we have the opportunity to unify the serialization formats of Ethereum at three levels: execution layer, consensus layer, and smart contract calling ABI.

I propose using SSZ because SSZ:

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

2. It has been widely used in the consensus layer.

3. Highly similar to 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

When migrating from EVM to RISC-V (or other optional minimum virtual machine), the hexadecimal Merkle Patricia tree will be the biggest bottleneck in proof block execution, even on average. Migrating to a binary tree based on a better hash function will significantly improve the efficiency of the proofreader and reduce the data cost in scenarios such as light clients.

When migrating, make sure that the consensus layer uses the same tree structure. This will enable Ethereum's consensus layer and execution layer to be accessed and parsed through the same code.

From now to future

Simplicity is similar to decentralization in many ways, both of which are upstream of resilience goals. It takes a certain cultural change to clarify the importance of simplicity. The benefits are often difficult to quantify, while the cost of additional effort and abandoning certain dazzling functions is immediate. However, over time, the gains will become more significant – Bitcoin itself is a great example.

I propose to follow tinygrad to set a clear maximum number of lines of code for Ethereum long-term specifications, so that the Ethereum consensus key code is close to the simplicity of Bitcoin. Code that handles Ethereum's historical rules will continue to exist, but should be placed outside the critical path of consensus. At the same time, we should adhere to the concept of choosing a simpler solution, prioritize packaging complexity over systematic complexity, and make design choices that provide clear attributes and guarantees.

The above is the detailed content of Vitalik Analysis: How to Make Ethereum as Easy as Bitcoin in 5 Years. For more information, please follow other related articles on the PHP Chinese website!