Vitalik's Blog: How to Make Ethereum in 5 Years as Simple as Bitcoin

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 through 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. It suggests a smooth transition through backward-compatible strategies (such as an on-chain EVM interpreter) and unifying error-correcting codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus key code closer to Bitcoin's simplicity, enhancing resilience and participation, with a cultural emphasis on simplicity and setting a maximum line count target.

The goal of Ethereum is to become a global ledger: a platform for storing the assets and records of human civilization, 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 will increase the available space for L2 data by 10 times, while the currently proposed roadmap for 2026 also aims to bring a similar significant enhancement to 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): the simplicity of the protocol.

The most impressive aspect of the Bitcoin protocol is its elegant simplicity:

1. There is a chain made up of blocks, with each block linked to the previous one through a hash.

2. The validity of the block is verified through Proof of Work (PoW), which checks if the leading digits of the hash value are zero.

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

That's all! 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 hobby project.

The simplicity of the protocol brings many key advantages for Bitcoin (as well as Ethereum) to become a trusted, neutral global foundation layer:

1. Easy to Understand: Reduce the complexity of the protocol, allowing more people to participate in protocol research, development, and governance, thereby reducing the risks dominated by a technical elite.

2. Reduce Development Costs: Simplifying the protocol significantly lowers 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: Minimize the likelihood of catastrophic errors occurring in protocol specifications and implementations, while also facilitating the verification of the absence of such errors.

5. Reduce Attack Surface: Minimize the complex components of the protocol to lower 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 high development costs, increased security risks, and a closed research and development culture, while the gains from this pursuit of complexity have often proven to be illusory. This article will explore how Ethereum, five years from now, approaches the simplicity of Bitcoin.

Simplified Consensus Layer

The new consensus layer design (historically referred to as the "Beacon Chain") aims to leverage the experience gained over the past decade in consensus theory, ZK-SNARK development, staking economics, and other areas 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: Remove concepts such as slots, epochs, committee reorganization, and related efficient processing mechanisms (e.g., synchronized committees). The basic implementation of 3-slot finality requires only about 200 lines of code and has security that is close to optimal compared to Gasper.

2. Reduce the number of active validators: Allow the implementation of simpler fork selection 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. Simplified P2P Architecture: The above factors may support a simpler and more robust peer-to-peer network architecture.

5. Redesigning the Validator Mechanism: This includes mechanisms for entry, exit, withdrawal, key conversion, and inactivity leak, simplifying the number of code lines 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, allowing for greater room for continuous improvement. The bigger challenge is how to achieve a similar simplification in the execution layer.

Simplified Execution Layer

The complexity of the EVM is increasing, and much of this complexity has proven to be unnecessary (partly due to my personal decision-making errors): the 256-bit virtual machine overly optimizes specific cryptographic forms that are gradually becoming outdated, and precompiles are optimized for single use cases but are rarely used.

Addressing these issues one by one has limited effects. For instance, removing the SELFDESTRUCT opcode requires a tremendous effort but yields only minor benefits. Recent debates regarding EOF (EVM Object Format) also reveal similar challenges.

I recently proposed a more radical plan: instead of making medium-scale (but still disruptive) changes to the EVM for a 1.5x gain, we should transition to a better, simpler virtual machine for a 100x gain. 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 ZK provers. This will bring:

1. Significant improvement in efficiency: Smart contract execution (in the prover) runs directly without interpreter overhead. Data from Succinct shows that performance can be improved by over 100 times in many scenarios.

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

3. Motivation for Supporting EOF: Such as code partitioning, friendlier static analysis, larger code size limits, etc.

4. More Developer Choices: Solidity and Vyper can add backends to compile to the new virtual machine. If RISC-V is chosen, mainstream language developers can also easily port their code to this virtual machine.

5. Remove Most Precompiled: Only highly optimized elliptic curve operations may be retained (these will disappear once quantum computers become mainstream).

The main drawback is that, unlike the ready-to-use EOF, the benefits of the new virtual machine will take a long time to reach developers. We can alleviate this issue by implementing high-value EVM improvements in the short term (such as increasing contract code size limits and 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 is how to balance the achievement of goals with backward compatibility for existing applications.

First, it is important to clarify that the Ethereum codebase (even within a single client) does not have only one definition.

The goal is to minimize the green area as much as possible: the logic required for nodes to participate in Ethereum consensus, including calculating the current state, proof, verification, FOCIL (Fork Choice Rule), and the construction of "normal" blocks.

Orange area cannot be reduced: If the protocol specification removes or changes a certain execution layer function (such as virtual machines, precompiles, etc.), the client processing historical blocks still needs 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 functionalities (such as EOA and its supported legacy transaction types) with an on-chain RISC-V implementation, the consensus code would 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. Those who understand the protocol can skip these parts, and Ethereum can ignore them. Errors in these areas do not pose a consensus risk. Therefore, the code complexity of the orange and yellow areas is much less harmful than that of the green area.

The idea of moving the 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 (taking 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. Request for new precompiled to provide on-chain RISC-V implementation: 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 the two virtual machines to interact freely.

3. Replace Most Precompiled: Except for elliptic curve operations and KECCAK (due to the need for extreme speed), replace other precompiles with RISC-V. 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 simplifies the protocol significantly.

4. Implementing EVM Interpreter in RISC-V: As smart contracts are on-chain (due to the requirement for ZK provers). After several years of initial release, existing EVM contracts run through this interpreter.

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 specifications. Ethereum consensus will natively only understand RISC-V.

Simplification through Shared Protocol Components

The third way to reduce the overall complexity of the protocol (and the one that is most easily underestimated) 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 usually of no benefit, but this pattern still frequently occurs, 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 error-correcting 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, achieving a balance between latency and redundancy.

3. Distributed Historical Storage: Ethereum historical data is stored in shards, where each group of n/2 segments can recover the remaining segments, reducing the risk of loss for a single segment.

If the same error correction code (whether Reed-Solomon, random linear codes, etc.) is used in three different scenarios, the following advantages will be obtained:

1. Minimize code volume: Reduce the total number of lines of code.

2. Improve Efficiency: If a node downloads partial segments for a certain scenario, this data can be used for other scenarios.

3. Ensure Verifiability: All segments of the scenario can be verified against the root.

If different error-correcting codes are used, compatibility should at least be ensured, for example, the horizontal Reed-Solomon code for data availability sampling and the vertical random linear code operate in the same field.

Unified Serialization Format

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

1. Complete Account Abstraction (EIP-7701): The full content of transactions 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 the three layers of Ethereum: execution layer, consensus layer, and smart contract call ABI.

I propose using SSZ, because SSZ:

1. Easy to decode: included in the smart contract (due to its design based on 4 bytes and fewer edge cases).

2. Widely used in the consensus layer.

3. 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 greatest bottleneck in proving block execution, even in average cases. Migrating to a binary tree based on a better hash function will significantly improve prover efficiency while reducing data costs in scenarios such as light clients.

When migrating, ensure that the consensus layer uses the same tree structure. This will allow the Ethereum 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, as both are upstream of resilience goals. A clear emphasis on simplicity requires a certain cultural shift. Its benefits are often difficult to quantify, while the costs of extra effort and giving up certain flashy features are immediate. However, over time, the benefits will become increasingly significant — Bitcoin itself is an excellent example.

I propose to follow the example of tinygrad and set a clear maximum line count target for Ethereum's long-term specifications, bringing the key consensus code of Ethereum closer to the simplicity of Bitcoin. The code handling historical rules of Ethereum 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.