Ethereum co-founder Vitalik Buterin believes that the long-term resilience and scalability of blockchain depends on making it simple, like Bitcoin. In a blog post on May 3, he described how "Ethereum 5 years from now could become almost as simple as Bitcoin." Buterin wrote:

“One of the greatest things about Bitcoin is that the protocol is extremely simple.”

According to Buterin, the minimalist design and simplicity of Bitcoin make it accessible, so even a high school student can grasp the concept and architecture of the protocol. Buterin argued that simplicity also brings other benefits, such as reducing the cost of creating new infrastructure and maintaining existing infrastructure, as well as reducing the risk of errors.

Recent upgrades such as proof of stake (PoS) and integrating Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) have made Ethereum more powerful. However, overlooking the simplicity of the design has added to Ethereum's costs. Buterin explained:

“Previously, Ethereum often did not do this (sometimes due to my own decisions), and this contributed to excessive development costs, all kinds of security risks, and narrowness in R&D culture, often in pursuit of benefits that have proven to be unrealistic.”

Simplifying the Ethereum consensus layer

In November, Ethereum Foundation researcher Justin Drake proposed a consensus layer upgrade called 'Beam Chain'. Buterin believes that Beam Chain "is well-positioned to become much simpler" than its outdated predecessor, the current beacon chain.

This is because the beam chain will allow for the redesign of the finality of 3 slots, which will eliminate complex concepts such as separate slots, epochs, and synchronization committees, Buterin noted. He also emphasized that implementing the basic finality of 3 slots could be achieved through about 200 lines of code, greatly simplifying things.

The beam chain will also reduce the number of active validators at any given time, which will help "utilize simpler implementations of the safer branching rule," Buterin wrote.

The beam chain will also incorporate STARK-based aggregate protocols, meaning anyone can be an aggregator. Buterin noted:

“The complexity of the aggregate cryptography itself is considerable, but at least it has tightly packaged complexity, with much lower systemic risk to the protocol.”

Buterin added that reducing the number of active validators and incorporating STARK-based aggregators "is likely to allow for a simpler and more powerful P2P architecture." He continued to say that there is an opportunity to rethink and simplify some aspects, from validator in and out to inactive leakages. And this can be achieved by reducing the number of lines of code (LoC) and by creating "more readable guarantees."

Buterin emphasized that the consensus layer is "relatively separate" from the execution activities of the Ethereum Virtual Machine (EVM), which provides a "relatively wide scope" for implementing improvements compared to the execution layer.

Simplifying the Ethereum execution layer

Last month, Buterin proposed replacing the EVM contract language with RISC-V to increase efficiency by up to 100 times. Buterin argued that adopting RISC-V would also increase simplicity, as "the RISC-V specification is absurdly simple compared to EVM."

However, this means ensuring backward compatibility for existing applications is maintained. Buterin wrote:

“The first important thing to understand is: there is no single way to delineate what the 'Ethereum codebase' is (even within a single client).”

According to Buterin, the orange area cannot be reduced. Buterin stated that the goal is to minimize the green area by moving code to the yellow area, stating, "the code is very valuable for understanding and interpreting today's chain or for building an optimal block, but is not part of consensus." Buterin likened this process to how Apple achieved long-term backward compatibility through layers of compilation. He wrote:

“It is important that the orange and yellow areas are packed complexly, anyone wanting to understand the protocol can skip them, the Ethereum implementation can skip them, and any errors in those areas do not pose a risk to consensus.”

This is why the complexity of the code in the orange and yellow areas has "many fewer drawbacks" compared to the complexity of the code in the green area.

To reduce the green area, Buterin proposed the following steps:

  • Phase 1: New precompiled programs will be written in RISC-V.

  • Phase 2: Developers will have the option to write contracts in RISC-V.

  • Phase 3: All precompiled versions will be replaced with RISC-V implementations through a hard fork.

  • Phase 4: Implement the EVM interpreter in RISC-V and deploy it on-chain as a smart contract.

Buterin stated that the above steps will ensure that the consensus of Ethereum will "naturally" understand RISC-V.

Protocol-wide standards for simplification

Buterin proposed sharing “a standard across different parts of the stack” as a pathway towards simplification.

For example, Buterin proposed using a single erase code to sample available data, broadcast P2P, and store distributed history. This would minimize the total number of lines of code, increase efficiency, and ensure verifiability, he argued.

Similarly, he proposed having a single shared serialization format across the three layers of Ethereum: the execution layer, the consensus layer, and the smart contract called the Application Binary Interface (ABI). Buterin suggested using SSZ, which is easy to decode and widely used.

Ultimately, after the EVM is replaced with RISC-V or another simpler language, Buterin proposed switching from a Merkle Patricia hexary tree to a binary tree for both the consensus layer and the execution layer. This transition could improve efficiency and reduce costs while still ensuring that all Ethereum layers can be accessed and interpreted using the same code, Buterin wrote.

A change in character

Buterin concluded by proposing that Ethereum, following the example of Tinygrad, adopt a clear maximum lines of code goal. Buterin reiterated that the goal is to make "code critical to Ethereum's consensus almost as simple as Bitcoin."

But more importantly, Ethereum needs to adopt a standard where the simpler option is chosen whenever possible. This means prioritizing packaged complexity over systemic complexity.

Buterin asserted that the code governing the historical rules of Ethereum will continue to exist with his latest proposal. However, such code must be kept outside the critical consensus code or the green area.