Original: Simplifying the L1

Author: Vitalik

Translation: lenaxin, ChainCatcher

Ethereum aims to become the world’s ledger: a platform for storing civilizational assets and records, serving as the foundational layer for finance, governance, high-value data certification, 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 proposed 2026 roadmap 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 focuses on one aspect of resilience (which will ultimately 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 first few digits 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 in this. 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 interface 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: a streamlined component structure makes 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 risks, and a closed R&D culture. The root of these problems often lies in the pursuit of short-term gains that have been proven ineffective in practice. This article will explain how Ethereum can achieve 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 achievements 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 concept of independent slots and epochs, removes complex components such as committee rotation mechanisms and synchronized committees, greatly simplifying the protocol specifications. The core implementation requires only about 200 lines of code, achieving near-optimal security levels compared to the Gasper protocol.
• Verification node management optimization: by limiting the number of active verification 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: redesigning mechanisms for verification node admission, exit, withdrawal, key migration, and lazy penalties, while reducing code volume and clarifying the assurance mechanisms for core parameters (such as weak subjective 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, which have gradually lost importance; and over-designed precompiled contracts for a single use case, which have very low actual usage rates.

Attempting to patch existing problems in a piecemeal manner is no longer feasible. Removing the SELFDESTRUCT opcode requires enormous effort but yields limited benefits, 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 improvement, it would be better to transition directly to a 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.
• Developer toolchain expansion: 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.
• Precompiled contract optimization: most precompiled functions will no longer be necessary, retaining only highly optimized elliptic curve operations (which may be phased out with the development of quantum computing).

The main challenge lies in: unlike the immediately implementable EOF solution, the new virtual machine will take longer to benefit developers. Some high-value EVM improvements (such as increasing contract code size limits and optimizing the DUP/SWAP instruction set) can be implemented in parallel as a short-term transition solution.

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 is how to balance achieving the 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 process 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 functionalities (such as external accounts EOA and various supported legacy transaction types) 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, code defects 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 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 RISC-V, as well as 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 will be replaced with RISC-V implementations through hard forks, except for elliptic curve operations and the KECCAK hash algorithm (due to their extreme performance optimization requirements).
3. The specific operation is: while removing the original precompiled contracts, modify the code at that address (using the DAO fork model) 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 the 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 release, existing EVM contracts will be executed through this interpreter, thus completing a smooth transition to the new virtual machine.

​​Achieving simplification 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 support only the RISC-V architecture.

Achieving Simplification Through Shared Protocol Components​

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

Unified Shared Erasure Code Solution

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 upon receiving n/2 of n shards, achieving an optimal balance between latency reduction and redundancy.
3. Distributed historical storage: Ethereum 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 certain scenario, this data can be directly used for other scenarios, avoiding redundant transmission;
3. 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): 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 changes occur, we can take this opportunity to unify the serialization standards of three key layers 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: scenarios including smart contracts can be quickly decoded, thanks to its 4-byte-based design and fewer boundary condition handling.
• Widely used in the consensus layer, already deeply integrated into the consensus layer.
• Highly similar to the 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

When migrating from EVM to RISC-V (or other streamlined virtual machine architectures), the six-way Merkle Patricia tree will become the largest performance bottleneck for block execution proofs (even in regular scenarios). Transitioning to a binary tree structure based on a better hash function 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 Goal

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 obvious. 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 to set a clear code line limit goal for long-term Ethereum specifications, aiming to bring the simplicity of Ethereum's consensus critical code closer to that of Bitcoin. Specifically, the code related to handling Ethereum's historical rules can continue to be retained but must be strictly isolated from the core 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 selection, prioritizing encapsulation of complexity rather than spreading systemic complexity, and ensuring that all design decisions provide clear and verifiable features and guarantees, thereby forming a technology culture oriented towards simplicity overall.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。