Special thanks to Fede, Danno Ferrin, Justin Drake, Ladislaus, and Tim Beiko for their feedback and review.

The goal of Ethereum is to become a global ledger - a platform that carries human assets and records, and is the underlying layer for applications such as finance, governance, and high-value data verification. To achieve this goal, it must have both scalability and resilience. The Fusaka hard fork plan will increase the L2 data availability space by 10 times, whileThe proposed 2026 roadmapAlso includes a similar scale of L1 data expansion. Meanwhile, ‘The Merge’ has upgraded Ethereum to a proof of stake (PoS) consensus mechanism,The diversity of clients is rapidly increasing, ZK (Zero-Knowledge Proof) verifiability and resistance to quantum attacks are also steadily progressing, and the application ecosystem is increasinglyMature and robust.

The goal of this article is to emphasize an equally critical but often underestimatedResilience (and ultimately scalability)Elements:
Simplicity of the protocol.

One of the most praised aspects of Bitcoin is its protocol design, which is extremely elegant and simple:

The system is a blockchain, consisting of a series of blocks. Each block is linked to the previous one through a hash. The validity of each block is verified through Proof of Work (PoW), which means… you just need to check if the leading digits of its hash are zeros. Each block contains transactions, which either spend the coins obtained through mining, or spend the coins output from previous transactions. That’s basically it.
Even a smart high school student has the ability to fully understand the operation principles of the Bitcoin protocol. And a programmer can even develop a Bitcoin client as a hobby project.

Keeping the protocol simple brings a series of key advantages, potentially making Bitcoin and EthereumTrusted neutralityThe foundational layer of global trust:

• Make the protocol logic easier to understand, expand the group that can participate in protocol research, development, and governance, lower the technical barriers, and avoid the dominance of a ‘technological bureaucratic class’ in the protocol.
• Significantly reduce the development cost of new infrastructure integrated with protocols (such as new clients, new verifiers, new logging tools, etc.).
• Reduce the long-term maintenance cost of the protocol.
• Reducing the risk of catastrophic vulnerabilities, whether in protocol specifications or implementation code; it also makes it easier to verify that the protocol does not contain such vulnerabilities.
• Reduce the social attack surface: the fewer the components, the fewer places that can be exploited and controlled by specific stakeholders.

In the past, Ethereum has not performed well in this regard (sometimes even because of my personal decisions), which has led to our excessive development expenses,@vbuterin/selfdestruct”>Various security risks and the closed nature of R&D culture, and these efforts often only bring illusory returns.
This article will explain how Ethereum could achieve a level of simplicity close to Bitcoin’s in five years.

Simplified Consensus Layer

3-slot finality（3槽终结性）模拟图 — 3sf-mini

The new consensus layer design (formerly known as ‘beam chain’) aims to integrate the experience we have accumulated in consensus theory, ZK-SNARK development, staking economics, and other areas over the past decade, to create a long-term optimal Ethereum consensus layer. This new consensus layer, compared to the existing Beacon Chain, is expected to achieve higher simplicity. This is particularly evident in:

• 3-slot finality restructure
  This design eliminates the distinction between ‘slot’ and ‘epoch’, committee shuffling, and other protocol specification details related to these mechanisms (such as synchronous committees). A basic version of 3-slot finality,Only about 200 lines of code are neededIt can be achieved. Compared to the current Gasper protocol, 3-slot finality also has close to optimal security.
• The number of active validators has decreased
  Makes it safer and more feasible to adopt a simpler fork choice rule.
• Aggregation protocol based on STARK
  Means that anyone can become an aggregator without worrying about trusting the aggregator, excessive fees for repeated bit fields, etc. Although the aggregation encryption itself has a certain complexity, thisHighly encapsulated complexityThe overall systematic risk of the protocol is much lower.
• The two points above are also likely to support a simpler and more robust peer-to-peer (p2p) architecture.
• We have the opportunity to rethink the mechanisms of validator entry, exit, withdrawal, key switching, inertia penalty, etc., and simplify them— not just reducing the number of lines of code (LoC), but also providing clearer mechanism guarantees, such as a more explicit ‘weak subjectivity’ deadline.

The advantage of the consensus layer is that it is relatively decoupled from EVM execution, so we have a lot of room to continue pushing these improvements forward.
More challenging is: how to achieve the same simplification at the execution layer.

Simplify Execution Layer

The complexity of the Ethereum Virtual Machine (EVM) is continuously increasing, and much of this complexity has been proven unnecessary (often also related to my personal decisions): we have a 256-bit virtual machine that is overly optimized for very specific cryptographic forms, which are now gradually being marginalized; and some precompiled contracts overly focus on very few single use cases.

Attempting to gradually patch up these practical problems is not feasible.Remove @vbuterinThe SELFDESTRUCT instruction consumes a huge amount of energy, but the results are limited. The recent debate about EOF (EVM Object Format) further demonstrates the difficulty of making similar changes to the virtual machine.

Therefore, as an alternative, I recently proposed a more radical idea: instead of making incremental (but still destructive) changes for a 1.5x improvement, it is better to directly migrate to a brand new, far superior, and simpler virtual machine, aiming for a 100x return. Just like ‘The Merge,’ we reduce the number of transformations, but each one is significant. Specifically, I suggest replacing the existing EVM with RISC-V (or another virtual machine that will be used by Ethereum’s ZK prover). This way, we will achieve:

• Significant efficiency improvement: because smart contracts can run directly in the prover without the overhead of an interpreter. Succinct data indicates that performance can be improved by over 100 times in many scenarios.
• Ultimate simplicity: compared to the EVM, RISC-V specificationExtremely simple. Other alternative solutions (such as Cairo) are equally concise.
• Inheriting the expected advantages of EOF: such as code segmentation, more friendly static analysis, larger code capacity limit, etc.
• Developers have more choices: Solidity and Vyper can be compiled to the new virtual machine backend. If RISC-V is chosen, mainstream language developers can also easily port their code.
• Significantly reduce the need for precompilation: possibly retaining only a few highly optimized elliptic curve operations (although these will no longer exist once quantum computing becomes popular).

The main drawback of this approach is that, unlike EOF (immediately deployable), the new virtual machine takes longer to benefit developers. To mitigate this, we can introduce some small but high-value EVM improvements in the short term.Increase the contract code size limit、Increase DUP/SWAP17-32 instructions, etc.)

Ultimately, this will give us a greatly simplified virtual machine. But the biggest question is: what about the existing EVM?

VM transitional backward compatibility strategy

When meaningfully simplifying (or even just improving without adding complexity) any part of the Ethereum Virtual Machine (EVM), the biggest challenge is: how to maintain backward compatibility with existing applications while achieving the goal.

First of all, it should be clear that there is no single way to define the scope of the “Ethereum codebase” (even within the same client).

The goal is to minimize the scope of the green area as much as possible: that is, the logic that nodes must run to participate in Ethereum consensus, including computing the current state, proof, validation, FOCIL (First-Order Consensus Integrity Layer), basic block construction, etc.

The orange area cannot be reduced: if a certain execution layer feature (whether it’s a virtual machine, precompilation, or other mechanism) is removed from the protocol specification, or its functionality is changed, the client concerned with processing historical blocks must still retain it - but importantly, new clients (such as ZK-EVMs or formal verifiers) can completely ignore the orange area.

The new category is the yellow area: this type of code is very important for understanding and parsing the current chain state, and for building the best blocks, but it is not part of the consensus. An example is Etherscan(And someBlock Builder) Support for ERC-4337 user operations. If we use on-chain RISC-V implementation to replace certain large functions of Ethereum (such as EOA accounts and their support for various old transaction types), then despite the significant simplification of the consensus code, some professional nodes may still continue to use the original code to parse these functions.

It is important that the orange and yellow areas belong to “Gate”Encapsulation ComplexityAnybody who wishes to understand the protocol can skip them, Ethereum clients can also choose not to implement them, and bugs in these areas will not pose a consensus risk. This means that the code complexity and negative impact brought by the orange and yellow areas are much smaller than the green area.

Transfer the code from the green zone to the yellow zone, this approach is similar to Apple Inc.Translate through the Rosetta translation layerTo ensure long-term compatibility.

I proposed (borrowed from@ipsilon/eof-ethereums-gateway-to-risc-v”> Ipsilon team’s recent views) The following virtual machine migration process (using EVM migration to RISC-V as an example, but also applicable to EVM migration to Cairo, and even future migration to a more optimal VM):

1. All new precompiles must be written in standard on-chain RISC-V implementation, so that the ecosystem can start getting familiar with and using RISC-V as the virtual machine.
2. Introducing RISC-V as an option for contract development parallel to EVM for developers. The protocol natively supports both RISC-V and EVM, allowing contracts written in both languages to interact freely.
3. Replace all precompiles (except elliptic curve operations and KECCAK) with RISC-V implementation. We remove these precompiles through a hard fork and at the same time change the code at the corresponding address (DAO fork-style) to be a RISC-V implementation. Because the RISC-V VM is extremely concise, even just doing this simplifies the overall structure.
4. Implement an EVM interpreter written in RISC-V and deploy it as a smart contract on the chain. After several years of initial release, existing EVM contracts will be processed through this interpreter.

After completing step 4, there will still be many ‘EVM implementations’ continuing to be used for optimizing block construction, development tools, and on-chain analysis, but they will no longer be part of the key consensus specifications. At that time, the Ethereum consensus will ‘natively’ only understand RISC-V.

Simplify by sharing protocol components

The third, and perhaps most underestimated, simplification method is to share a unified standard across various parts of the protocol stack as much as possible. Usually, there is no reason to use different protocols for the same purpose in different scenarios, but this situation still occurs frequently in reality, mainly due to a lack of communication between different parts of the protocol roadmap. Here are some specific examples of simplifying Ethereum through ‘maximizing component sharing’:

A unified erasure code

We need to correct the deletion code in three scenarios:

• Data availability sampling - The client verifies whether the block has been published
• Faster P2P broadcasting - Nodes can accept blocks after receiving n/2 out of n blocks, thus establishing the optimal balance between reducing latency and redundancy.
• Distributed History Storage - Every piece of history of Ethereum is stored in many blocks, so (i) these blocks can be independently verified, and (ii) half of blocks in each group can recover the remaining half, significantly reducing the risk of any single block loss.

If we use the same erasure code (whether it is Reed-Solomon, random linear code, or other) in three use cases, we will gain some important advantages:

1. Minimize total lines of code
2. Improve efficiency because if each node must download various parts of a block for one use case (instead of the entire block), the data can be used for another use case
3. Ensure Verifiability: All three blocks in the context can be verified based on the root

If different error correction codes are indeed required, ‘compatibility’ should be ensured at least: for example, in the DAS scenario, Reed-Solomon is used horizontally and random linear code is used vertically, but both are based on the same mathematical field.

A unified serialization format

Currently, the serialization format of Ethereum is strictly speaking, only “semi-standardized”, as data can be re-serialized and broadcasted in any format. The only exception is the transaction signature hash, where a standardized format is required for hash calculation.
But the standardization of future serialization formats will be further improved, for two reasons:

• Comprehensive Account Abstraction (EIP-7701): The virtual machine will be able to see the complete transaction content
• Gas limit increase: Execute block data needs to be packaged into blob

At that time, we have the opportunity to unify the serialization solutions required for the current three aspects: 1) execution layer; 2) consensus layer; 3) smart contract invocation ABI.

I suggest adopting SSZ(Simple Serialize), because SSZ has the following advantages:

• Easy to decode: including inside smart contracts (based on 4-byte design, few boundary cases)
• Widely used in consensus
• Highly similar to the existing ABI: low toolchain migration cost

Currently more components have beenMigrationTo SSZWorkWhen planning for future upgrades, we should fully consider and utilize these developments.

A unified tree structure

Once we migrate from EVM to RISC-V (or other minimalist VM), the hexadecimal Merkle Patricia tree will become the biggest bottleneck for proving block execution, even in average scenarios. Migrating to a hash functionBinary Tree, will greatly improve the efficiency of the verifier and reduce the data cost of light nodes and other scenarios.

When completing the tree structure migration, we should also ensure that the consensus layer uses the same tree structure to ensure that the entire Ethereum - both the consensus and execution layers - can be accessed and parsed using the same set of code.

From now to the future

Simplification and decentralization have many similarities. Both are upstream requirements necessary to achieve the higher goal of system resilience. Emphasizing simplification explicitly requires a cultural shift. The benefits of simplification are often hard to see in the early stages, but the opportunity costs and additional workload of rejecting those “shiny new features” are immediately evident. However, over time, the long-term value of simplification becomes increasingly evident—Bitcoin itself is an excellent example.

I suggest weLearn from the approach of tinygradTo set a clear code line limit goal for Ethereum’s long-term specification, the goal is to make Ethereum’s consensus critical code as close to Bitcoin’s minimalist style as possible. Code dealing with Ethereum’s historical rules will still exist but should be isolated from the consensus critical path. At the same time, we should form a universal design principle: choose simpler solutions whenever possible, prioritize encapsulated complexity over systemic complexity, and lean towards design decisions that provide clear verifiable properties and guarantees.

Disclaimer:

1. This article is reprinted from [vitalik]. All copyrights belong to the original author [vitalikAll. If you have any objections to this reprint, please contactGate LearnThe team will handle it in a timely manner.
2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The Gate Learn team translates articles into other languages. Copying, distributing, or plagiarizing translated articles is prohibited unless otherwise specified.