Vitalik Buterin aims to simplify Ethereum to match Bitcoin’s ease of use by 2030.

Vitalik Buterin, a co-founder of Ethereum, asserts that the future strength and scalability of the blockchain depend on its simplicity, akin to Bitcoin. In a recent blog entry, he articulated how “Ethereum could evolve in five years to be nearly as straightforward as Bitcoin.” Buterin expressed admiration for Bitcoin, noting:

“One of the best aspects of Bitcoin is its elegant simplicity.”

As per Buterin, the straightforward design of Bitcoin allows even high school students to comprehend its architecture and fundamentals. He suggested that this simplicity not only enhances understanding but also lowers costs associated with building new systems and maintaining existing ones, while simultaneously decreasing bug-related risks.

While updates such as proof-of-stake (PoS) and the integration of Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) have bolstered Ethereum’s capabilities, overlooking design simplicity has raised costs for the platform. Buterin commented:

“Historically, Ethereum has often missed this (partly due to my own choices), leading to excessive development costs, various security vulnerabilities, and a research and development culture that often chased illusory benefits.”

Simplifying the Ethereum consensus layer

In November, researcher Justin Drake from the Ethereum Foundation proposed a consensus layer upgrade called ‘Beam Chain.’ Buterin believes that the Beam Chain is “well-suited to be much simpler” than the currently used beacon chain.

This new system aims to facilitate a 3-slot finality redesign, which aims to eliminate complicated ideas such as separate slots, epochs, and synchronization committees, according to Buterin. He pointed out that basic implementation of 3-slot finality could be done in approximately 200 lines of code, showcasing its potential for simplicity.

The beam chain will also cut the number of active validators, making it “safer to implement simpler versions of the fork choice rule,” Buterin noted.

This new framework will also utilize STARK-based aggregation protocols, allowing everyone to become an aggregator. Buterin added:

“While the complexity of the aggregation cryptography is considerable, it remains encapsulated, thereby reducing systemic risks to the protocol.”

Buterin stated that the reduced number of active validators and the inclusion of STARK-based aggregators should “likely foster a more straightforward and robust” P2P architecture. He emphasized the opportunity to rethink and simplify various aspects, from how validators enter or exit to addressing inactivity leaks, which can be achieved by cutting down line-of-code (LoC) counts and establishing “clearer guarantees.”

He noted that the consensus layer is “relatively separate” from the Ethereum Virtual Machine (EVM), granting considerable flexibility for enhancements compared to the execution layer.

Simplifying the Ethereum execution layer

Buterin shared a suggestion last month about replacing the EVM contract language with RISC-V to enhance efficiency up to 100 times. He contended that adopting RISC-V would simplify the process, as the “RISC-V specification is remarkably straightforward compared to the EVM.”

Nonetheless, it’s crucial to maintain backward compatibility for existing applications. Buterin remarked:

“An essential point to understand is that there isn’t a singular way to define what constitutes the ‘Ethereum codebase’ (even within one client).”

Buterin indicated that the orange area remains constant. His objective is to lessen the green area by shifting code to the yellow area, which signifies “code that is crucial for understanding and interpreting the chain today, or for optimal block building, but lies outside of consensus.” He compared this process to Apple’s strategy for long-term backward compatibility through translation layers. He stated:

“Importantly, the orange and yellow areas are encapsulated complexities, allowing anyone attempting to comprehend the protocol to bypass them, and implementations of Ethereum can choose to ignore them, with no bugs in those areas posing consensus threats.”

This illustrates why complexities in the orange and yellow areas have “far fewer drawbacks” than those found in the green area.

To decrease the green area, Buterin suggested implementing the following phases:

Phase 1: New precompiles will be developed in RISC-V.

Phase 2: Developers can create contracts using RISC-V.

Phase 3: All precompiles will transition to RISC-V through a hard fork.

Phase 4: Introduce an EVM interpreter in RISC-V and deploy it on-chain as a smart contract.

These actions would ensure that Ethereum consensus would predominantly recognize RISC-V, according to Buterin.

Establishing protocol-wide standards for simplification

Buterin recommended maintaining “a single standard across various segments of the stack” as a means to achieve simplification.

For example, he proposed using one erasure code for data availability sampling, P2P broadcasting, and distributed history storage. He believed this would reduce the total lines of code, enhance efficiency, and guarantee verifiability.

He also suggested adopting a single shared serialization format across the three Ethereum layers: execution layer, consensus layer, and smart contract Application Binary Interface (ABI). Buterin favored using SSZ, as it is user-friendly and widely accepted.

Finally, once the EVM is replaced by RISC-V or a similar straightforward language, Buterin proposed switching to a binary tree in place of the hexary Merkle Patricia tree for both consensus and execution layers. This change could enhance efficiency and lower costs while ensuring that all Ethereum layers remain consistent and interpretable using the same code, wrote Buterin.

Shifting the ethos

Buterin concluded by advocating for Ethereum to adopt an explicit maximum line of code target, inspired by the model of Tinygrad. The aim, as emphasized by Buterin, is to simplify “Ethereum consensus-critical code to be as uncomplicated as Bitcoin.”

Moreover, Ethereum should embrace a philosophy that favors simpler solutions whenever feasible, prioritizing encapsulated complexity over systemic complexity.

Buterin assured that code related to processing Ethereum’s historical rules would continue to exist with his proposal. However, this code should be kept separate from the consensus-critical code or the green area.