Abstract

Ethereum aims to become a global ledger and requires 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 execution layer (replacing EVM with RISC-V or similar virtual machine), thereby reducing development costs, error risks, and attack surface. It suggests a smooth transition through backward compatibility strategies (such as on-chain EVM interpreter) and unifying erasure coding, serialization formats (SSZ), and tree structures for further simplification. The goal is to make Ethereum consensus critical code closer to Bitcoin's simplicity, enhancing resilience and participation, which requires a cultural emphasis on simplicity and setting maximum code line number targets.

Ethereum's goal is to become a global ledger: a platform for storing and recording human civilization's assets, serving fields like finance, governance, and high-value data certification. This requires support in two aspects: scalability and resilience. The Fusaka hard fork plan will increase L2 data availability space tenfold, and the proposed 2026 roadmap also plans significant improvements for the L1 layer. Meanwhile, Ethereum has completed the transition to Proof of Stake (PoS), client diversity is rapidly improving, zero-knowledge (ZK) verification and quantum resistance research are steadily progressing, and the application ecosystem is becoming increasingly robust.

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

What makes the Bitcoin protocol most admirable is its elegant simplicity:

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

2. Block validity is verified through Proof of Work (PoW), by checking if the first few bits of the hash are zero.

3. Each block contains transactions, with coins spent either from mining rewards or previous transaction outputs.

That's it! Even a clever high school student can fully understand how the Bitcoin protocol works, and a programmer could even write a client as a hobby project. The protocol's simplicity brings many key advantages to Bitcoin (and Ethereum) as a trusted, neutral global base layer:

1. Easy to Understand: Reducing protocol complexity allows more people to participate in protocol research, development, and governance, reducing the risk of technical elite dominance.

2. Reduced Development Costs: Simplifying the protocol significantly lowers the cost of creating new infrastructure (such as new clients, provers, developer tools, etc.).

3. Reduced Maintenance Burden: Lowering the long-term cost of protocol maintenance.

4. Reduced Error Risk: Decreasing the possibility of catastrophic errors in protocol specifications and implementations, while making it easier to verify their absence.

5. Narrowed Attack Surface: Reducing complex protocol components, lowering the risk of attacks by special interest groups.

Historically, Ethereum (sometimes due to my personal decisions) often failed to maintain simplicity, leading to high development costs, increased security risks, and a closed R&D culture, with the perceived benefits of this complexity often proving 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 called the "Beacon Chain") aims to leverage experiences from the past decade in consensus theory, ZK-SNARK development, staking economics, etc., 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 like slots, epochs, committee reshuffling, and related efficient processing mechanisms (such as sync committees). The basic implementation of 3-slot finality requires only about 200 lines of code and is nearly optimal in security compared to Gasper.

2. Reducing Active Validator Numbers: Allowing implementation of simpler fork choice rules, enhancing security.

3. STARK-based Aggregation Protocol: Anyone can become an aggregator without trusting the aggregator or paying high fees for redundant bit domains. While cryptographic aggregation complexity is high, its complexity is highly encapsulated, with low systemic risks.

4. Simplified P2P Architecture: The above factors may support a simpler, more robust peer-to-peer network architecture.

5. Redesigned Validator Mechanism: Including entry, exit, withdrawal, key conversion, inactivity leak mechanisms, simplifying code lines and providing clearer guarantees (such as weak subjectivity periods).

The advantage of the consensus layer is its relative independence from the EVM execution layer, thus providing significant room for continuous improvement. The greater challenge lies in achieving similar simplification in the execution layer.

Simplifying the Execution Layer

EVM's complexity has been increasing, and much of this complexity has proven unnecessary (partly due to my personal decision errors): the 256-bit virtual machine over-optimized certain cryptographic forms now gradually becoming obsolete, and precompiles optimized for single use cases are rarely used.

Addressing these issues one by one has limited effect. For example, removing the SELFDESTRUCT opcode required enormous effort but brought only marginal benefits. Recent debates about EOF (EVM Object Format) also demonstrate similar challenges.

I recently proposed a more radical solution: instead of making medium-scale (but still disruptive) changes to EVM for 1.5x gains, transition to a more optimal, simpler virtual machine for 100x gains. Similar to "The Merge", we reduce the number of disruptive changes but make each change more meaningful. Specifically, I suggest replacing EVM with RISC-V or another virtual machine used by Ethereum ZK provers. This will bring:

1. Significant Efficiency Improvement: Smart contract execution (in provers) runs directly without interpreter overhead. Succinct's data shows performance improvements of over 100 times in many scenarios.

2. Substantial Simplicity Enhancement: RISC-V specification is extremely simple compared to EVM, and alternative solutions (like Cairo) are equally concise.

3. Motivation for EOF: Such as code partitioning, more developer-friendly 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 easily port code to this virtual machine.

5. Removal of Most Precompiles: Possibly retaining only highly optimized elliptic curve operations (which will also disappear after quantum computer popularization).

The main drawback is that, unlike EOF which is ready, the new virtual machine's benefits will take longer to benefit developers. We can mitigate this by implementing high-value short-term EVM improvements (such as increasing contract code size limits, supporting DUP/SWAP17–32).

This will bring 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 balancing target implementation with backward compatibility of existing applications.

· First, it must be clear: the Ethereum codebase (even within a single client) is not defined in only one way.

· The goal is to minimize the green area: the logic required for nodes to participate in Ethereum consensus, including computing current state, proving, validating, 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 virtual machine, precompiles, etc.), clients processing historical blocks still need to retain related code. However, new clients, ZK-EVMs, or formal proof systems can completely ignore the orange area.

· The newly added yellow area: Extremely valuable for understanding the current chain or optimizing block construction, but not part of consensus logic. For example, Etherscan and some block builders support ERC-4337 user operations. If we replace some Ethereum functions with on-chain RISC-V implementation (such as EOA and its supported legacy transaction types), the consensus code will be significantly simplified, but specialized nodes may continue to use the original code for parsing. · The complexity of orange and yellow areas is encapsulated complexity. People who understand the protocol can skip these parts, Ethereum implementations can ignore them, and errors in these areas do not pose consensus risks. Therefore, the code complexity in orange and yellow areas is far less harmful than 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 Ipsilon team's recent article, I propose the following virtual machine change process (using EVM to RISC-V as an example, but also applicable to EVM to Cairo or RISC-V to a more optimal virtual machine): 1. Require new precompiles 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 simultaneously supports RISC-V and EVM, with contracts from both virtual machines able to interact freely. 3. Replace most precompiles: Replace other precompiles with RISC-V implementation except for elliptic curve operations and KECCAK (due to the need for extreme speed). Remove precompiles through a hard fork, simultaneously 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: Deployed as a smart contract on-chain (as ZK provers have already been performed). Existing EVM contracts will run through this interpreter years after the initial release. 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. (The translation continues in the same manner for the rest of the text.)