Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing significant reductions in complexity by simplifying the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or a similar virtual machine), thereby reducing development costs, error risks, and attack surfaces. It suggests a smooth transition through backwards compatibility strategies (such as an on-chain EVM interpreter), and unifying erasure coding, serialization formats (SSZ), and tree structures for further simplification. The goal is to bring Ethereum's consensus critical 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 human civilization's assets and records, 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, and the currently proposed roadmap for 2026 also plans to bring a similar significant enhancement to the L1 layer. Meanwhile, Ethereum has completed the transition to proof of stake (PoS), client diversity is rapidly increasing, 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 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:
There is a chain made up of blocks, with each block linked to the previous block through a hash.
The validity of the block is verified through Proof of Work (PoW), which checks whether the leading bits of the hash value are zero.
Each block contains transactions, and the coins spent in transactions must either come 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 (and Ethereum) to become a trusted, neutral global base layer:
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.
Reduce development costs: Simplifying the protocol significantly lowers the costs of creating new infrastructure (such as new clients, provers, developer tools, etc.).
Reduce maintenance burden: Lower the cost of maintaining long-term agreements.
Reduce the risk of errors: Decrease the likelihood of catastrophic errors occurring in the protocol specifications and implementations, while facilitating the verification of the absence of such errors.
Reduce the attack surface: minimize the complex components of the protocol to lower the risk of being targeted 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 culture of research and development, while the benefits pursued by this complexity have often proven to be illusory. This article will explore how Ethereum, five years from now, can approach the simplicity of Bitcoin.
Simplified Consensus Layer
The new consensus layer design (historically referred to as the "Beacon Chain") aims to leverage the experiences of the past decade in consensus theory, ZK-SNARK development, staking economics, and other areas to create a long-term optimal and simpler consensus layer. Compared to the existing Beacon Chain, the new design significantly simplifies:
3-slot finality design: Remove concepts such as slots, epochs, and committee reorganization, as well as related efficient processing mechanisms (such as synchronous committees). The basic implementation of 3-slot finality requires only about 200 lines of code, and its security is close to optimal compared to Gasper.
Reduce the number of active validators: Allow the use of simpler fork selection rules to enhance security.
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.
Simplified P2P Architecture: The above factors may support a simpler and more robust peer-to-peer network architecture.
Redesign the validator mechanism: including mechanisms for entry, exit, withdrawal, key conversion, inactivity leak, etc., to simplify the number of code lines and provide clearer guarantees (such as weak subjectivity periods).
The advantage of the consensus layer lies in its relative independence from the EVM execution layer, which allows 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 EVM is increasing, and much of this complexity has proven unnecessary (partly due to my personal decision-making errors): the 256-bit virtual machine overly optimizes a specific form of cryptography that is gradually becoming outdated, and precompiles are optimized for a single use case but are rarely used.
Addressing these issues one by one has limited effectiveness. For example, removing the SELFDESTRUCT opcode requires a tremendous effort but yields only minor benefits. Recent discussions regarding EOF (EVM Object Format) have also revealed 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 return, we should transition to a better, simpler virtual machine to achieve a 100x return. 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 would bring:
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.
Significant improvement in simplicity: The RISC-V specification is extremely simple compared to EVM, and alternatives (such as Cairo) are equally concise.
Motivation for supporting EOF: such as code partitioning, friendlier static analysis, larger code size limits, etc.
More developer options: 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 code to this virtual machine.
Remove most precompiled: only highly optimized elliptic curve operations may be retained (these will also disappear after quantum computers become mainstream).
The main drawback is that, unlike the ready-to-use EOF, the benefits of the new virtual machine take a longer time to benefit 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 transitions
The biggest challenge in simplifying (or improving without increasing complexity) the EVM lies in how to balance achieving objectives with backward compatibility for existing applications.
First, it is important to clarify: 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 constructing "normal" blocks.
The orange area cannot be reduced: If the protocol specification removes or changes certain execution layer functions (such as the virtual machine, precompiles, etc.), clients processing historical blocks must still retain the relevant code. However, new clients, ZK-EVM, or formal verifiers can completely ignore the orange area.
New 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 functions (such as EOA and its supported legacy transaction types) with an 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 the orange and yellow areas is encapsulated complexity, which can be skipped by those who understand the protocol; Ethereum can ignore them, and errors in these areas will not trigger consensus risks. Therefore, the code complexity of the orange and yellow areas is much less harmful than that of 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 a recent article from the Ipsilon team, I propose the following virtual machine change process (using EVM to RISC-V as an example, but it can also be applied to EVM to Cairo or RISC-V to a more optimal virtual machine):
Require the new precompiled version to provide an on-chain RISC-V implementation: Allow the ecosystem to gradually adapt to the RISC-V virtual machine.
Introduce RISC-V as a developer option: The protocol supports both RISC-V and EVM, allowing contracts from both virtual machines to interact freely.
Replace most precompiled: Replace other precompiles with RISC-V, except for elliptic curve operations and KECCAK (due to the need for extreme speed). Remove the precompiled 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 significantly simplifies the protocol.
Implementing an EVM interpreter in RISC-V: as smart contracts go on-chain (because ZK provers need to be completed). 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 building, 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
A third way to reduce the overall complexity of the protocol (which is also the easiest to underestimate) 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 often of no benefit, yet this pattern still frequently occurs, primarily due to a lack of communication between different parts of the protocol roadmap. Here are a few concrete examples of simplifying Ethereum through shared components.
Unified Erasure Code
We need erasure codes in three scenarios:
Data availability sampling: Clients verify that the block has been published.
Faster P2P Broadcasting: Nodes can accept blocks after receiving n/2 fragments, achieving a balance between latency and redundancy.
Distributed Historical Storage: Ethereum historical data is shard-stored, where each group of n/2 fragments can recover the remaining fragments, reducing the risk of loss of a single fragment.
If the same error correction code (whether Reed-Solomon, random linear codes, etc.) is used in three scenarios, the following advantages will be obtained:
Minimize code volume: Reduce the total number of lines of code.
Improve efficiency: If a node downloads partial fragments for a certain scenario, this data can be used for other scenarios.
Ensure Verifiability: All segments of the scenarios can be verified against the root.
If different erasure codes are used, compatibility should at least be ensured, such as the horizontal Reed-Solomon code for data availability sampling operating in the same domain as vertical random linear codes.
Unified Serialization Format
The serialization format of Ethereum is currently only partially solidified, as data can be re-serialized and broadcasted in any format. An 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 further increase for the following reasons:
Complete Account Abstraction (EIP-7701): The full content of transactions is visible to the virtual machine.
Higher gas limits: Execution layer data needs to be placed into 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:
Easy to decode: included within smart contracts (due to its 4-byte design and fewer edge cases).
Widely used in the consensus layer.
Highly similar to the existing ABI: Tool adaptation is relatively simple.
Efforts have been made 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 in proving 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 data costs in scenarios such as light clients.
During migration, it is important to 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 objectives. A clear emphasis on simplicity requires a certain cultural shift. The benefits are often difficult to quantify, while the costs of additional 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 tinygrad and set a clear maximum line count goal for the long-term standardization of Ethereum, bringing the critical consensus code of Ethereum closer to the simplicity of Bitcoin. The code handling Ethereum's historical rules will continue to exist but should be placed outside of the critical consensus path. At the same time, we should adhere to the principle of choosing simpler solutions, prioritizing the encapsulation of complexity over systemic complexity, and making design choices that provide clear attributes and guarantees.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Vitalik's Blog: How to Make Ethereum in 5 Years as Simple as Bitcoin
Author | Vitalik Buterin
Compiled by | GaryMa Wu said blockchain
Original link:
Abstract
Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing significant reductions in complexity by simplifying the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or a similar virtual machine), thereby reducing development costs, error risks, and attack surfaces. It suggests a smooth transition through backwards compatibility strategies (such as an on-chain EVM interpreter), and unifying erasure coding, serialization formats (SSZ), and tree structures for further simplification. The goal is to bring Ethereum's consensus critical 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 human civilization's assets and records, 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, and the currently proposed roadmap for 2026 also plans to bring a similar significant enhancement to the L1 layer. Meanwhile, Ethereum has completed the transition to proof of stake (PoS), client diversity is rapidly increasing, 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 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:
There is a chain made up of blocks, with each block linked to the previous block through a hash.
The validity of the block is verified through Proof of Work (PoW), which checks whether the leading bits of the hash value are zero.
Each block contains transactions, and the coins spent in transactions must either come 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 (and Ethereum) to become a trusted, neutral global base layer:
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.
Reduce development costs: Simplifying the protocol significantly lowers the costs of creating new infrastructure (such as new clients, provers, developer tools, etc.).
Reduce maintenance burden: Lower the cost of maintaining long-term agreements.
Reduce the risk of errors: Decrease the likelihood of catastrophic errors occurring in the protocol specifications and implementations, while facilitating the verification of the absence of such errors.
Reduce the attack surface: minimize the complex components of the protocol to lower the risk of being targeted 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 culture of research and development, while the benefits pursued by this complexity have often proven to be illusory. This article will explore how Ethereum, five years from now, can approach the simplicity of Bitcoin.
Simplified Consensus Layer
The new consensus layer design (historically referred to as the "Beacon Chain") aims to leverage the experiences of the past decade in consensus theory, ZK-SNARK development, staking economics, and other areas to create a long-term optimal and simpler consensus layer. Compared to the existing Beacon Chain, the new design significantly simplifies:
3-slot finality design: Remove concepts such as slots, epochs, and committee reorganization, as well as related efficient processing mechanisms (such as synchronous committees). The basic implementation of 3-slot finality requires only about 200 lines of code, and its security is close to optimal compared to Gasper.
Reduce the number of active validators: Allow the use of simpler fork selection rules to enhance security.
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.
Simplified P2P Architecture: The above factors may support a simpler and more robust peer-to-peer network architecture.
Redesign the validator mechanism: including mechanisms for entry, exit, withdrawal, key conversion, inactivity leak, etc., to simplify the number of code lines and provide clearer guarantees (such as weak subjectivity periods).
The advantage of the consensus layer lies in its relative independence from the EVM execution layer, which allows 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 EVM is increasing, and much of this complexity has proven unnecessary (partly due to my personal decision-making errors): the 256-bit virtual machine overly optimizes a specific form of cryptography that is gradually becoming outdated, and precompiles are optimized for a single use case but are rarely used.
Addressing these issues one by one has limited effectiveness. For example, removing the SELFDESTRUCT opcode requires a tremendous effort but yields only minor benefits. Recent discussions regarding EOF (EVM Object Format) have also revealed 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 return, we should transition to a better, simpler virtual machine to achieve a 100x return. 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 would bring:
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.
Significant improvement in simplicity: The RISC-V specification is extremely simple compared to EVM, and alternatives (such as Cairo) are equally concise.
Motivation for supporting EOF: such as code partitioning, friendlier static analysis, larger code size limits, etc.
More developer options: 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 code to this virtual machine.
Remove most precompiled: only highly optimized elliptic curve operations may be retained (these will also disappear after quantum computers become mainstream).
The main drawback is that, unlike the ready-to-use EOF, the benefits of the new virtual machine take a longer time to benefit 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 transitions
The biggest challenge in simplifying (or improving without increasing complexity) the EVM lies in how to balance achieving objectives with backward compatibility for existing applications.
First, it is important to clarify: 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 constructing "normal" blocks.
The orange area cannot be reduced: If the protocol specification removes or changes certain execution layer functions (such as the virtual machine, precompiles, etc.), clients processing historical blocks must still retain the relevant code. However, new clients, ZK-EVM, or formal verifiers can completely ignore the orange area.
New 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 functions (such as EOA and its supported legacy transaction types) with an 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 the orange and yellow areas is encapsulated complexity, which can be skipped by those who understand the protocol; Ethereum can ignore them, and errors in these areas will not trigger consensus risks. Therefore, the code complexity of the orange and yellow areas is much less harmful than that of 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 a recent article from the Ipsilon team, I propose the following virtual machine change process (using EVM to RISC-V as an example, but it can also be applied to EVM to Cairo or RISC-V to a more optimal virtual machine):
Require the new precompiled version to provide an on-chain RISC-V implementation: Allow the ecosystem to gradually adapt to the RISC-V virtual machine.
Introduce RISC-V as a developer option: The protocol supports both RISC-V and EVM, allowing contracts from both virtual machines to interact freely.
Replace most precompiled: Replace other precompiles with RISC-V, except for elliptic curve operations and KECCAK (due to the need for extreme speed). Remove the precompiled 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 significantly simplifies the protocol.
Implementing an EVM interpreter in RISC-V: as smart contracts go on-chain (because ZK provers need to be completed). 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 building, 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
A third way to reduce the overall complexity of the protocol (which is also the easiest to underestimate) 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 often of no benefit, yet this pattern still frequently occurs, primarily due to a lack of communication between different parts of the protocol roadmap. Here are a few concrete examples of simplifying Ethereum through shared components.
Unified Erasure Code
We need erasure codes in three scenarios:
Data availability sampling: Clients verify that the block has been published.
Faster P2P Broadcasting: Nodes can accept blocks after receiving n/2 fragments, achieving a balance between latency and redundancy.
Distributed Historical Storage: Ethereum historical data is shard-stored, where each group of n/2 fragments can recover the remaining fragments, reducing the risk of loss of a single fragment.
If the same error correction code (whether Reed-Solomon, random linear codes, etc.) is used in three scenarios, the following advantages will be obtained:
Minimize code volume: Reduce the total number of lines of code.
Improve efficiency: If a node downloads partial fragments for a certain scenario, this data can be used for other scenarios.
Ensure Verifiability: All segments of the scenarios can be verified against the root.
If different erasure codes are used, compatibility should at least be ensured, such as the horizontal Reed-Solomon code for data availability sampling operating in the same domain as vertical random linear codes.
Unified Serialization Format
The serialization format of Ethereum is currently only partially solidified, as data can be re-serialized and broadcasted in any format. An 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 further increase for the following reasons:
Complete Account Abstraction (EIP-7701): The full content of transactions is visible to the virtual machine.
Higher gas limits: Execution layer data needs to be placed into 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:
Easy to decode: included within smart contracts (due to its 4-byte design and fewer edge cases).
Widely used in the consensus layer.
Highly similar to the existing ABI: Tool adaptation is relatively simple.
Efforts have been made 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 in proving 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 data costs in scenarios such as light clients.
During migration, it is important to 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 objectives. A clear emphasis on simplicity requires a certain cultural shift. The benefits are often difficult to quantify, while the costs of additional 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 tinygrad and set a clear maximum line count goal for the long-term standardization of Ethereum, bringing the critical consensus code of Ethereum closer to the simplicity of Bitcoin. The code handling Ethereum's historical rules will continue to exist but should be placed outside of the critical consensus path. At the same time, we should adhere to the principle of choosing simpler solutions, prioritizing the encapsulation of complexity over systemic complexity, and making design choices that provide clear attributes and guarantees.