Introduction
Vitalik recently published an article titled “Simplifying Ethereum L1,” advocating for the introduction of RISC-V, the promotion of STARK technology, and the implementation of mechanisms like 3-slot finality to reduce protocol complexity. The goal is to simplify Ethereum to a level close to Bitcoin within five years.
(Background: The Ethereum Foundation refused to disclose “Vitalik’s voting weight,” raising community concerns about governance transparency: it is fundamentally centralized.)
(Additional Background: Vitalik’s article on AI: The “Cyclic Model” reveals a reversal in the AI competition landscape between China and the U.S.)
Vitalik’s Vision for Ethereum
Ethereum co-founder Vitalik Buterin published an article today titled “Simplifying L1,” pointing out that for Ethereum to become “a world ledger of civilizational assets and records,” it needs scalability and resilience.
He emphasized a frequently underestimated factor in achieving resilience: “the simplicity of the protocol.” This can facilitate more developers’ participation in core development, reduce error risks, and lower operational costs, thereby strengthening the overall decentralized foundation.
Using Bitcoin as an example, he illustrated the many benefits of its simple protocol and reflected on how Ethereum’s past over-design and multitude of functionalities have led to maintenance difficulties, high entry barriers, and increased error susceptibility. He hopes to simplify Ethereum’s core protocol to a level close to Bitcoin’s within the next five years.
Simplifying the Consensus Layer: Embracing 3-slot Finality and STARK Technology
First, Vitalik aims to significantly simplify Ethereum’s “consensus system” by adopting a new method called “3-slot finality” to determine blocks, removing many complex configurations that can be implemented in as few as 200 lines of code, while also enhancing security.
Furthermore, he advocates for the use of STARK technology to compress verification information, allowing all nodes to participate without relying on a few, thus avoiding centralization. Lastly, he also suggests redesigning the mechanism for validators’ entry and exit to make the overall consensus protocol lighter and easier to validate.
Note: In Ethereum’s consensus layer (Beacon Chain), a slot is a “time unit,” with each slot lasting 12 seconds.
Simplifying the Execution Layer: Switching from EVM to RISC-V
Next, in the execution layer, Vitalik expressed dissatisfaction with EVM, believing its excessive optimization for specific cryptographic applications has become an unnecessary burden. He reiterated a previously proposed radical solution:
Replace EVM with the open-source instruction set RISC-V or a similarly concise VM, listing several advantages:
- Achieving a 100-fold efficiency boost in ZK environments
- Simple instruction set architecture that is easier for developers to grasp
- Increased contract size limits
- Support for multi-language development (not just Solidity)
He also admitted that this transition would take time and recommended implementing some lightweight upgrades to EVM (such as increasing contract size limits) in the short term.
Color-Coding Strategy
In practical implementation, Vitalik further proposed the “color-coding strategy,” which ensures that compatibility and user experience are not sacrificed during the transition. This strategy categorizes the functions within the Ethereum protocol into three tiers based on their importance and risk level, allowing existing applications to continue running while simplifying and maintaining the protocol:
- Green Zone: Critical consensus area that must be extremely simple
- This part of the code directly affects “which block is considered valid.”
- All nodes must execute this code without any errors.
- Thus, the goal here is simplicity, verifiability, and low error risk.
- Orange Zone: Historical compatibility area, reserved for specific implementations
- These exist to preserve past historical transactions, contracts, and old version functionalities.
- While new nodes may not need these features, they are still required for executing historical data of old contracts.
- Yellow Zone: Tool assistance area, not part of blockchain consensus, but aids user comprehension and developer usability
- For example: Etherscan displays account information by interpreting the operational details of ERC-4337, but this information does not affect the chain’s consensus.
- Some block builders or wallets may optimize based on this information.
Ultimately, Vitalik hopes to remove the currently complex EVM from Ethereum’s consensus core, replacing it with a smart contract interpreter written in RISC-V, deployed on-chain to run regular contracts. This way, Ethereum’s core will only need to understand the RISC-V virtual machine, significantly simplifying protocol logic; for applications that need to execute old contracts, this interpreter can parse past EVM instructions. This design allows Ethereum to simplify its main system while retaining compatibility.
Setting Clear Goals for Maximum Code Line Count
Additionally, Vitalik suggested that Ethereum should use the same set of standard tools and formats across different technical layers in future designs. This would make it easier for developers to get started and enhance the overall network’s performance and security.
At the same time, he called for Ethereum to establish a maximum protocol code line count goal, similar to the lightweight deep learning framework tinygrad, and to promote a design culture shift from “functionality-focused” to “minimalism.” Only through concise design can Ethereum truly become a globally trusted, decentralized, and maintainable infrastructure.
