Vitalik's new article: How does Ethereum achieve a simplified architecture comparable to Bitcoin?

Original: Simplifying the L1

Author: Vitalik

Compiled by: lenaxin, ChainCatcher

Ethereum aims to be the world’s ledger: a platform for storing civilizational assets and records, serving as the foundational layer for finance, governance, high-value data authentication, and more. This requires two conditions: scalability and resilience. The Fusaka hard fork aims to increase the available space for Layer 2 (L2) data by tenfold, and the currently proposed roadmap for 2026 also suggests a similar significant expansion for Layer 1 (L1). Meanwhile, Ethereum has completed its merge upgrade to a Proof of Stake mechanism, rapidly increasing client diversity, advancing work on zero-knowledge proof (ZK Verifiability) and quantum resistance, and various applications are becoming increasingly robust.

This article aims to focus on one aspect of resilience (which will ultimately also affect scalability) that is equally important yet often underestimated: the simplicity of the protocol.

One major advantage of Bitcoin is its extremely simple and elegant protocol.

The blockchain consists of a series of blocks, each connected to the previous block via a hash value. The validity of a block is verified through a proof-of-work mechanism, which checks whether the leading bits of its hash value are zero. Each block contains several transactions, and the coins spent in these transactions are either generated through mining or come from outputs of previous transactions. The core mechanism of the Bitcoin protocol lies here. Even a clever high school student can fully understand this protocol, and programmers can even write clients for it as a hobby project.

Maintaining the simplicity of the protocol provides a key advantage for Bitcoin or Ethereum to become globally recognized neutral foundational layers:

• A simple protocol is easier to analyze, attracting more participants to engage in protocol research, development, and governance, while reducing the risk of technical monopolies.
• A simplified protocol structure significantly reduces the development investment required to integrate with new infrastructure (such as clients, provers, logging tools, and other development tools).
• The simple design of the protocol effectively lowers long-term maintenance costs.
• The risk of serious vulnerabilities in the protocol specifications and their implementations is significantly reduced, making it easier to verify system security.
• Reducing the social attack surface: streamlined components make the system easier to protect against special interest infiltration, enhancing overall security.

Historically, Ethereum has often failed to adhere to the principle of simplicity in protocol design (partly due to my own decisions), which has directly led to high R&D costs, frequent security vulnerabilities, and a closed R&D culture. The root of these issues often lies in the pursuit of short-term gains that have been proven ineffective in practice. This article will elaborate on how Ethereum can achieve a level of protocol simplicity close to that of Bitcoin in the next five years.

Simplifying the Consensus Layer

Simulating three-slot finality in 3sf - mini (Ethereum test network codename)

The new consensus layer proposal (formerly named "Beam Chain") aims to integrate research findings from the past decade in consensus theory, zero-knowledge proofs (ZK-SNARK), staking economics, and more, to build an optimal consensus mechanism for Ethereum aimed at long-term development. Compared to the existing beacon chain, this proposal features significantly simplified characteristics, specifically reflected in the following aspects:

• Three-slot finality architecture innovation: Eliminates the conceptual division between independent slots and epochs, removes complex components such as committee rotation mechanisms and synchronized committees, significantly simplifying the protocol specifications. The core implementation requires only about 200 lines of code, achieving nearly optimal security levels compared to the Gasper protocol.
• Optimized validator management: By limiting the number of active validator nodes, the fork choice rule can adopt a more simplified implementation while ensuring system security.
• Aggregation protocol upgrade: The STARK-based aggregation mechanism allows any node to act as an aggregator, avoiding trust dependencies on aggregators and resource wastage from duplicate bitfields. Although the complexity of aggregation cryptography itself is high, its highly encapsulated nature significantly reduces systemic risk.
• P2P network architecture improvement: The above two optimizations provide the possibility to build a simpler and more efficient peer-to-peer network architecture.
• Verification process reconstruction: Redesigns mechanisms for validator node admission, exit, withdrawal, key migration, and lazy penalties, reducing code volume while clarifying the guarantee mechanisms for core parameters (such as weak subjectivity periods).
• Technical advantages: The relative decoupling of the consensus layer and the EVM execution layer provides greater technical space for continuous optimization. In contrast, similar improvements in the execution layer face greater challenges.

Simplifying the Execution Layer

The complexity of the Ethereum Virtual Machine (EVM) continues to grow, with many complex designs proving unnecessary (in many cases due to my decision-making errors): a 256-bit virtual machine overly optimized for specific cryptographic algorithms that have gradually lost importance; and over-designed precompiled contracts for single use cases that are rarely utilized.

Attempting to patch existing issues through scattered fixes is no longer feasible. Removing the SELFDESTRUCT opcode requires tremendous effort for limited gains, and recent debates about EOF further highlight the difficulties of making incremental modifications to the virtual machine.

As an alternative, I recently proposed a more radical transformation path: rather than making medium-scale (but still disruptive) modifications to the EVM for a 1.5x performance boost, it is better to transition directly to a completely new and significantly superior virtual machine architecture to achieve a hundredfold performance leap. Similar to The Merge, we aim to reduce the number of disruptive changes while enhancing the strategic value of each change. Specifically, I recommend adopting the RISC-V architecture or the virtual machine used by Ethereum's ZK proof programs to replace the existing EVM. This transformation will bring:

• Revolutionary efficiency improvement: In a ZK proof environment, smart contracts can run directly on the target architecture without interpreter overhead. Succinct data shows that performance can improve by over a hundred times in most scenarios.
• Extreme simplification of architecture: The RISC-V specification is much more streamlined compared to the EVM, and other candidate solutions (such as Cairo) also possess simplicity features.
• Inheriting the core advantages of EOF: Including code segmentation management, friendlier static analysis support, and larger code capacity limits.
• Expansion of developer toolchains: Solidity and Vyper can support the new architecture through additional backend compilation; if RISC-V is chosen, mainstream language developers can directly port existing code.
• Optimization of precompiled contracts: Most precompiled functions will no longer be necessary, retaining only highly optimized elliptic curve operations (which may be phased out as quantum computing develops).

The main challenge is that, unlike the immediately implementable EOF solution, the new virtual machine will take longer to benefit developers. A short-term transition plan can be implemented by synchronously introducing some high-value EVM improvements (such as increasing contract code size limits and optimizing the DUP/SWAP instruction set).

This transformation will significantly simplify the virtual machine architecture. The core question is: how to properly handle the existing EVM ecosystem?

Backward Compatibility Strategy for Virtual Machine Migration​

The biggest challenge in simplifying (or optimizing without increasing complexity) any part of the EVM lies in balancing the achievement of expected goals with maintaining backward compatibility for existing applications.

First, it is essential to clarify that there is no single standard for defining what constitutes the "Ethereum codebase," even for a single client.

The goal is to minimize the green area: the logic that nodes need to run to participate in Ethereum consensus, including computing the current state, proof generation and verification, FOCIL (note: need to confirm if this is a professional term abbreviation), and the "basic" block construction process.

The orange area cannot be reduced: if the execution layer functions (whether virtual machine, precompiled contracts, or other mechanisms) are removed from the protocol specifications or their functions change, clients that need to handle historical blocks must retain that functionality; however, new clients (including ZK-EVM or formal verification tools) can completely ignore this part.

The newly added yellow area refers to code that is highly valuable for parsing current on-chain data or optimal block construction but does not belong to the consensus mechanism. Typical examples include Etherscan and some block builders' support for ERC-4337 user operations. If Ethereum's core functions (such as external accounts EOA and various legacy transaction types they support) are replaced with on-chain RISC-V implementations, the consensus code will be significantly simplified, but dedicated nodes may still need to use the original code for parsing.

The complexity of the orange and yellow areas belongs to encapsulation complexity; anyone wishing to understand the protocol can skip these parts, and Ethereum implementation solutions can freely choose to ignore them. Moreover, defects in the code in these areas will not trigger consensus risks. This means that, compared to the code complexity of the green area, the complexity of the orange and yellow areas has a significantly lower negative impact on the overall system.

The idea of migrating code from the green area to the yellow area is similar to Apple's long-term backward compatibility technical solution achieved through the Rosetta translation layer.

It is required that all newly developed precompiled contracts must include standardized on-chain RISC-V implementations. This step aims to gradually adapt the ecosystem to the RISC-V virtual machine environment (the same approach applies to the migration from EVM to Cairo or other superior virtual machines):

1. Dual virtual machine parallel support: Natively support both RISC-V and EVM virtual machines at the protocol level. Developers can freely choose their development language, and contracts written for different virtual machines can achieve seamless interaction.
2. Phased replacement of precompiled contracts: All precompiled contracts, except for elliptic curve operations and the KECCAK hash algorithm (due to their extreme performance optimization requirements), will be replaced with RISC-V implementations through hard forks.
3. Specific operations: While removing the original precompiled contracts, the code at that address (using the DAO fork model) will be modified from an empty state to the corresponding RISC-V implementation. Due to the high simplicity of the RISC-V architecture, even completing this step will still reduce the overall complexity of the system.
4. On-chain deployment of the EVM interpreter: Based on RISC-V, implement an EVM interpreter (the ZK proof toolchain has already promoted such development) and deploy it as a smart contract on-chain. After several years of the initial version's release, existing EVM contracts will be executed through this interpreter, thus completing a smooth transition to the new virtual machine.

​​Simplifying through Shared Protocol Components

After step four is completed, numerous "EVM implementation solutions" will still be retained and used for optimizing block construction, developer tools, and on-chain data analysis, but these implementations will no longer be part of the core consensus specifications. At that time, the Ethereum consensus mechanism will "natively" only support the RISC-V architecture.

Achieving Simplification through Shared Protocol Components​

The third method (and the one most easily underestimated) to reduce the overall complexity of the protocol is to share unified standards as much as possible across different protocol stack layers. Generally speaking, using different protocols to achieve the same functionality in different modules is neither necessary nor beneficial, yet such design patterns still exist widely, mainly due to the lack of effective coordination between different parts of the protocol roadmap. Below are specific scenarios where Ethereum can be simplified by strengthening component cross-layer reuse.

Unified Shared Erasure Code Scheme

Three application scenarios for erasure codes:

1. Data availability sampling: Clients need to use erasure codes to verify whether blocks have been published, ensuring data integrity.
2. Efficient P2P broadcasting: Nodes can confirm a block when they receive n/2 of n shards, achieving an optimal balance between latency reduction and redundancy.
3. Distributed historical storage: Ethereum's historical data is divided into multiple data blocks, satisfying:

• Each data block can be independently verified.
• Any group of n/2 data blocks can recover the remaining n/2 data blocks.

This design significantly reduces the risk of single-point data loss.

If the same erasure code (such as Reed-Solomon codes, random linear codes, etc.) is used in the following three scenarios, it will bring significant advantages:

1. Code simplification;
2. Efficiency improvement: When nodes need to download shard data (rather than complete blocks) for a particular scenario, that data can be directly used for other scenarios, avoiding redundant transmission;
3. All data blocks in all scenarios can be uniformly verified through root hashes.

If different erasure codes are used, compatibility requirements must be met: for example, both horizontal Reed-Solomon codes and vertical random linear codes can be used in data availability sampling (DAS) shards, but both encodings must operate over the same finite field.

Unified Serialization Format​

The current serialization format of Ethereum is still in a semi-standardized state—data can be re-serialized into any format and propagated, with the only exception being transaction signature hashes, which must use a standardized format to ensure hash consistency. However, in the future, the degree of standardization of serialization formats will be further strengthened, mainly due to:

• Account abstraction (EIP-7701): The complete transaction content will be fully visible to the virtual machine (VM).
• High Gas limit scenarios: As the block Gas limit increases, execution layer data needs to be stored in blob structures.

When these transformations occur, we can take this opportunity to unify the serialization standards of three key levels of Ethereum: (i) execution layer (ii) consensus layer (iii) smart contract call ABI.

It is recommended to adopt the SSZ serialization format, which has the following advantages:

• Efficient decoding, allowing for quick decoding in scenarios including smart contracts, thanks to its 4-byte-based design and fewer boundary condition handling.
• Widespread application in the consensus layer, already deeply integrated into the consensus layer.
• Highly similar to existing ABI, facilitating toolchain adaptation and upgrades.

Relevant technical teams are already advancing the comprehensive migration of SSZ. It is recommended to continue this technical route in future upgrade planning and expand based on existing achievements.

Unified Shared Tree Structure

After migrating from EVM to RISC-V (or other streamlined virtual machine architectures), the six-way Merkle Patricia tree will become the biggest performance bottleneck for block execution proofs (even in regular scenarios). Transitioning to a binary tree structure based on better hash functions will significantly improve proof efficiency and reduce data storage costs for light nodes and other application scenarios.

When implementing this migration, the same tree structure should be used to achieve unification between the consensus layer and the execution layer. This will ensure that the entire Ethereum stack (including the consensus layer and execution layer) uses the same set of code logic for data access and parsing.

Evolution Path from Current State to Goals

Simplicity shares similarities with decentralization in many aspects, as both are foundational prerequisites for achieving system resilience. Clearly defining simplicity as a core value requires a cultural shift: its benefits are often not immediately apparent, while the short-term gains from pursuing complex functionalities are evident. However, over time, the advantages of simplicity will become increasingly significant—the development history of Bitcoin is a strong testament to this viewpoint.

I propose that Ethereum's protocol design reference the practical experience of the TinyGrad project, setting a clear line count limit goal for long-term Ethereum specifications, striving to bring the simplicity of Ethereum's consensus critical code closer to that of Bitcoin. Specifically, code related to handling Ethereum's historical rules can continue to be retained but must be strictly isolated from the critical consensus path to ensure it does not impact the core consensus logic; at the same time, the design philosophy of "prioritizing simpler solutions" should be implemented in technical solution choices, prioritizing encapsulation of complexity rather than spreading systemic complexity, and ensuring that all design decisions provide clear and verifiable features and guarantees, thus forming a technology culture oriented towards simplicity overall.