Vitalik's new article: How does Ethereum achieve a simplified architecture that benchmarks Bitcoin?

Original text: Simplifying the L1

Author: Vitalik

Compiled: lenaxin, ChainCatcher

Ethereum aims to become a world ledger: a platform for storing civilized assets and records, and is the basic layer of finance, governance, high-value data certification, etc. This requires two conditions: scalability and resilience. The Fusaka hard fork aims to increase the available space for layer two (L2) data by 10 times, and the currently proposed 2026 roadmap also proposes a similarly significant expansion of layer one (L1). At the same time, Ethereum has completed the merger and upgraded to the Proof of Stake mechanism, with its client diversity rapidly increasing, and work on verifiability of ZK Verifiability and anti-quantum computing capabilities is also advancing, and various applications are becoming more and more stable.

This article aims to focus on one aspect of resilience (and ultimately affect scalability), which is equally important but easily underestimated, namely the simplicity of the protocol.

One of the great advantages of Bitcoin is that its protocol is extremely concise and beautiful.

The blockchain consists of a series of blocks, each block is connected to the previous block through a hash value. The effectiveness of a block is verified by a proof of work mechanism, that is, verifying whether the first few digits of its hash value are zero. Each block contains several transactions, and the coins consumed by these transactions are either generated through mining or derived from the output of previous transactions. This is the core mechanism of the Bitcoin protocol. Even smart middle school students can fully understand this protocol, and programmers can even write it as a client for amateur projects.

Keeping the protocol simple provides key advantages for Bitcoin or Ethereum to become a globally recognized neutral base layer:

• A concise protocol is easier to analyze and can attract more participants to engage in protocol research, development and governance work, while reducing the risk of technology monopoly.
• Simplified protocol structure significantly reduces development investments that connect to new infrastructures such as clients, provers, log tools and other development tools.
• The simple design of the agreement effectively reduces long-term maintenance costs.
• The risk of serious vulnerabilities in protocol specifications and their implementations is significantly reduced, and it facilitates verification of system security.
• Reduce the social attack surface: Component streamlining makes the system easier to protect against the penetration of special interests and improves overall security.

Historically, Ethereum has often failed to implement the principle of simplicity in protocol design (partially due to my decision-making), which directly leads to high R&D costs, frequent safety hazards, and the closedness of R&D culture. The root of these problems is often the pursuit of short-term benefits that have been proven to be ineffective by practice. This article will explain how Ethereum can achieve protocol simplicity close to Bitcoin in the next five years.

Simplify the consensus layer

Simulate the finality of three timeslots in 3sf - mini (Ethereum test network code)

The new version of the consensus layer solution (formerly named "beam chain") aims to integrate research results in the fields of consensus theory, zero-knowledge proof (ZK-SNARK), pledge economics and other years, and build an optimal consensus mechanism for long-term development for Ethereum. Compared with the existing beacon chain, this solution has significantly simplified characteristics, which are specifically reflected in the following aspects:

• Three-slot finality architecture innovation : eliminates the conceptual division of independent slots and epochs, cancels complex components such as committee rotation mechanism and synchronous committees, and greatly simplifies protocol specifications. The core implementation only requires about 200 lines of code, which is nearly optimal in terms of security 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 solution while ensuring system security.
• Aggregation protocol upgrade : The STARK-based aggregation mechanism allows any node to play the aggregation role, avoiding the trust dependence on the aggregator and the waste of resource in duplicate bitfields. Although the complexity of the polymerization cryptography itself is high, its highly packaged properties significantly reduce systemic risks.
• P2P network architecture improvement : The above two optimizations provide the possibility for building a simpler and more efficient point-to-point network architecture.
• Verification process reconstruction : Redesign mechanisms such as verification node access, exit, withdrawal, key migration and laziness punishment. While reducing the amount of code, clarify the guarantee mechanism for core parameters (such as weak subjective cycles).
• Technical advantages : The relative decoupling characteristics of the consensus layer and the EVM execution layer provide greater technical space for continuous optimization. In contrast, similar improvements at the execution level face greater challenges.

Simplify the execution layer

The complexity of Ethereum Virtual Machines (EVMs) continues to grow, and many of these complex designs have proven unnecessary (in many cases my decision-making mistake): a 256-bit virtual machine over-optimized for a specific encryption algorithm that has now gradually lost its importance; and precompiled contracts over-designed for a single use scenario, which have extremely low actual usage rates.

Trying to solve existing problems through scattered repairs is no longer feasible. Removing SELFDESTRUCT opcodes takes huge effort but only receives limited returns. The recent debate on EOF has further highlighted the difficulty of gradual modifications to virtual machines.

As an alternative, I recently proposed a more radical transformation path: instead of mid-scale (but still destructive) modifications to EVM in exchange for a 1.5x performance boost, it is better to directly transition to a completely new and significantly better virtual machine architecture to achieve a 100x performance jump. Like The Merge, we increase the strategic value of each change by reducing the number of disruptive changes. Specifically, it is recommended to use the virtual machine used by the RISC-V architecture or the Ethereum ZK proof program instead of the existing EVM. This transformation will bring:

• Revolutionary efficiency : In the ZK proof environment, smart contracts can run directly on the target architecture without interpreter overhead. Succinct data shows that performance can be improved by more than a hundred times in most scenarios.
• Extremely simplified architecture : RISC-V specification is extremely streamlined compared to EVM, and other candidates (such as Cairo) also have simplicity.
• The core advantages of inheriting EOF include code segmentation management, more friendly static analysis support, and greater code capacity limitations.
• Developer toolchain extension : Solidity and Vyper can support new architectures through new backend compilation; if RISC-V is selected, mainstream language developers can directly port existing code.
• Precompiled contract optimization : Most precompiled functions will no longer be necessary, and only highly optimized elliptic curve operations are retained (as quantum computing develops or will be eliminated).

The main challenge is that unlike EOF solutions that can be implemented immediately, new virtual machines will take longer to benefit developers. A short-term transition solution can be achieved by synchronously implementing some high-value EVM improvements (such as improving contract code size limits, optimizing DUP/SWAP instruction sets).

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

Backward compatibility policy for virtual machine migration

The biggest challenge in simplifying (or optimizing without adding complexity) any part of EVM is how to balance the implementation of the intended goals with maintaining backward compatibility with existing applications.​​

First of all, it is important to be clear: even for a single client, there is no unique standard for defining what is the "Ethereum code base".

The goal is to minimize the green area : that is, the logic required for the node to participate in the Ethereum consensus, including calculating the current state, proof generation and verification, FOCIL (Note: it is necessary to confirm whether it is a professional term abbreviation), and the "basic" block construction process.

The orange area cannot be reduced: if the execution layer function (whether it is a virtual machine, precompiled contract, or other mechanism) is removed from the protocol specification or its functionality changes, the client that needs to handle the historical block must retain the function; but this part can be ignored completely by new clients (including ZK-EVM or formal verification tools).

Added yellow area : refers to code that is of great value for the current on-chain data analysis or optimal block construction, but does not belong to the consensus mechanism. Typical cases such as Etherscan and some block builders support ERC-4337 user operations. If Ethereum core functions (such as external account EOA and various legacy transaction types supported by it) are replaced with on-chain RISC-V implementations, the consensus code will be greatly simplified, but dedicated nodes may still need to use the original code for parsing.

The complexity of the orange and yellow areas is encapsulation complexity , and anyone who wishes to understand the protocol can skip these parts, and the Ethereum implementation is also free to choose to ignore. Furthermore, code flaws in these areas do not raise consensus risks. This means that the complexity of the orange and yellow areas has a significantly lower negative impact on the overall system than the code complexity of the green areas.​

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

It is required that all newly developed precompiled contracts must contain a canonical on-chain RISC-V implementation. This step is designed to promote the ecology to gradually adapt to the RISC-V virtual machine environment (taking the EVM to RISC-V migration as an example, this solution is also applicable to the migration of EVM to Cairo or other better virtual machines):

1. Dual virtual machines parallel support : supports both RISC-V and EVM at the protocol level. Developers can freely choose the development language, and contracts written by different virtual machines can achieve seamless interaction.
2. Precompiled contracts are replaced in stages : except for elliptic curve operations and KECCAK hashing algorithms (due to their extreme optimization of performance requirements), all precompiled contracts are implemented by hard fork replacement with RISC-V.
3. The specific operation is : while removing the original precompiled contract, modify the code of this address (using DAO forking mode) from the empty state to the corresponding RISC-V implementation. Due to the high simplicity of the RISC-V architecture, even if only this step is completed, the overall complexity of the system will still be reduced.
4. EVM interpreter on-chain deployment : Implement the EVM interpreter based on RISC-V (ZK proves that the toolchain has driven such development) and deploy it on-chain as a smart contract. Years after the initial release, existing EVM contracts will be executed through the interpreter, completing a smooth transition to the new virtual machine.

​​Simplify through shared protocol components

After step 4 is completed, many "EVM implementation solutions" will still be retained and will be used to optimize scenarios such as block construction, developer tools and on-chain data analysis, but these implementations will no longer be part of the core consensus specification. At that time, the Ethereum consensus mechanism will only support RISC-V architecture .

Simplified through shared protocol components​

The third way to reduce the overall complexity of a protocol (and the most easily underestimated way) is to share unified standards between different protocol stack levels as much as possible. Generally speaking, it is neither necessary nor profitable to implement the same function in different modules, but such design patterns are still common, mainly due to the lack of effective coordination among the various parts of the protocol roadmap. The following are examples of specific scenarios in which Ethereum can be simplified by hardening components across layers.

Unified shared erasure coding scheme

Three types of application scenarios for erasure coding:

1. Data availability sampling : When the client verifys whether the block has been published, it must use erasure code to ensure data integrity.
2. Efficient P2P broadcasting : When nodes receive n/2 of n shards, they can confirm blocks to achieve the optimal balance between delay reduction and redundancy.
3. Distributed historical storage : Ethereum historical data is divided into multiple data blocks, satisfying:

• Each data block can be independently verified
• The remaining n/2 data blocks can be restored in any packet

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

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

1. The code is streamlined ;
2. Efficiency improvement : When a node needs to download sharded data (rather than a complete block) due to a certain scenario, the data can be directly used in other scenarios to avoid repeated transmission;
3. Data blocks in all scenarios can be uniformly verified by root hash

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

Unified serialization format

The current serialization format of Ethereum is still in a semi-normalized state - the data can be reserialized to any format and propagated. The only exception is transaction signature hashing. This scenario requires a standardized format to ensure hash consistency. However, in the future, the degree of standardization of the serialization format will be further strengthened, mainly including:

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

When the above transformation occurs, 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 calls ABI

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

• Efficient decoding , and scenarios including smart contracts can be quickly decoded, thanks to its 4-byte-based design and fewer boundary conditions processing
• The consensus layer is widely used and has achieved deep integration in the consensus layer
• Highly similar to existing ABI , making it easy to adapt and upgrade the toolchain

Currently, relevant technical teams have promoted the comprehensive migration of SSZ. It is recommended to continue this technical route in the subsequent upgrade plan and expand it based on existing results.

Unified shared tree structure

When migrating from EVM to RISC-V (or other streamlined virtual machine architecture), the six-fork Merkle Patricia tree will become the biggest performance bottleneck for block execution proof (even in conventional scenarios). The shift to a binary tree structure based on better hash functions will significantly improve proof efficiency and reduce the data storage cost of light nodes and other application scenarios.

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

Evolution path from status quo to goal

Simplicity is similar to decentralization in many aspects, both of which are the basic prerequisites for achieving system resilience. It requires a cultural change to clearly regard simplicity as the core value: its benefits are often difficult to manifest immediately, while the short-term benefits brought about by pursuing complex functions are obvious. However, as time goes by, the advantage of simplicity will become more and more significant—the development history of Bitcoin is a strong confirmation of this view.

I suggest that the Ethereum protocol design refers to the practical experience of the TinyGrad project , set a clear upper limit of code lines for the long-term Ethereum specification, and strive to make the simplicity of the key code of the Ethereum consensus close to the Bitcoin level. Specifically, the relevant codes that deal with Ethereum historical rules can continue to be retained, but must be strictly isolated from the critical path of consensus to ensure that they do not have an impact on the core consensus logic; at the same time, the design concept of "priority to simpler solutions" should be implemented in the selection of technical solutions, priority should be given to encapsulating complexity rather than diffusing systematic complexity, and ensure that all design decisions can provide clear and verifiable characteristics and guarantees, thus forming a technical culture oriented towards simplicity as a whole.