Ethereum co-founder Vitalik Buterin believes that, like Bitcoin, blockchain will simplify long-term resilience and scalability. In a blog post on May 3rd, he explained that “Ethereum in five years can be as simple as Bitcoin.” Butarin wrote:
“One of the best things about Bitcoin is how beautiful and simple the protocol is.”
According to Buterin, Bitcoin’s minimalist design and simplicity is accessible, allowing even high school students to grasp the concept and architecture of the protocol. They argued that simplicity also provided other benefits, such as reducing the cost of creating new infrastructure, reducing the cost of maintaining existing infrastructure, and reducing the risk of bugs.
Recent upgrades such as Proof-of-Stake (POS) and Zero Knowledge Concise Non-interactive Discussion (ZK-SNARK) integration have made Ethereum more robust. However, ignoring the simplicity of the design added the cost of Ethereum. Buterin explained:
“Historically, Ethereum has often not done this (sometimes due to my own decisions), which has contributed to many of our excessive development spending, security risks of all kinds, and isolating nature of R&D culture.
Simplifying the Ethereum Consensus Layer
In November, Ethereum Foundation researcher Justin Drake proposed a consensus layer upgrade called the “beam chain.” Buterin believes that beam chains are “goodly positioned as being much simpler” than their current beacon chain, their outdated predecessor.
This is because the beam chain allows for a redesign of the finality of the three slots, which eliminates complex concepts such as individual slots, epochs, and synchronization committees. He also emphasized that a basic implementation of 3-slot finality can be achieved through around 200 lines of code, making it much simpler.
Also, beamchains reduce the number of active valtters at once, and “it’s safer to use a simpler implementation of fork selection rules,” writes Buterin.
The beamchain also incorporates a Stark-based aggregation protocol. Buterin pointed out:
“The complexity of the collective encryption itself is important, but at least it is highly encapsulated complexity and has much lower systemic risk to the protocol.”
Buterin added that reducing active validators and incorporating Stark-based aggregators is likely to allow for a “simpler and robust” P2P architecture. He went on to say there is an opportunity to rethink and simplify some facets, from validator entries and exits to inactivity. And this can be achieved by reducing the line (LOC) count of the code and creating a “easy-to-read guarantee.”
Buterin emphasized that the consensus layer is “relatively disconnected” from the Ethereum Virtual Machine (EVM) run.
Simplify the Ethereum Running Layer
Last month, Buterin proposed replacing the EVM contract language with RISC-V to increase efficiency by up to 100 times. Buterin also argued that the adoption of RISC-V also “is absurdly simpler than EVMs, making it more simplicity.
However, this means that the backward compatibility of existing applications is preserved. Butarin wrote:
“The important thing to understand first is that there is no single way to describe what “Ethereum Codebase” is (even within a single client). ”
According to Buterin, the orange area cannot be reduced. According to Buterin, the goal is to minimize the green area by moving the code into the yellow area, indicating “the understanding and interpretation of today’s chains, or the construction of optimal blocks, is very valuable, but not part of the consensus.” Buterin likened this process to how Apple achieves long-term backward compatibility through the translation layer. He wrote:
“Importantly, the orange and yellow regions are encapsulated complexity, anyone trying to understand the protocol can skip them, Ethereum implementations can skip them, and bugs in those regions pose no risk of consensus.”
This is why the complexity of the code in the orange and yellow regions is “a much less drawback” compared to the complexity of the code in the green regions.
To reduce the green area, butaline suggested the following procedure:
Phase 1: New precompilation is written in RISC-V.
Phase 2: Developers have the option to write contracts in RISC-V.
Phase 3: All precompilations are replaced by RISC-V implementations via hard forks.
Phase 4: Implement EVM interpreters on RISC-V and push on-chain as a smart contract.
The above steps ensure that the Ethereum consensus only understands RISC-V “natively,” Butaline said.
The whole protocol standard for simplification
Buterin proposed sharing “one standard across different parts of the stack” as a path to simplification.
For example, Buterin proposed using a single erase code for data availability sampling, P2P broadcasting, and distributed historical storage. He argued that this would minimize the total line of codes, improve efficiency and ensure verifiability.
Similarly, he proposed having a single shared serialization format for three Ethereum layers: the execution layer, the consensus layer, and the Smart Contract Call Application Binary Interface (ABI). Buterin suggested using SSZ. SSZ is easy to decode and is widely used.
Finally, when EVM is replaced by RISC-V or another simple language, Buterin proposes switching from hexagonal Patricia Tree to binary tree, both in the consensus and execution layers. This transition can improve efficiency and reduce costs, while allowing all Ethereum layers to be accessed and interpreted using the same code, Buterin writes.
Changes in mind
Buterin concluded by following the example in TinyGrad, suggesting that Ethereum adopts an explicit maximum line of code targets. The goal, which Buterin reiterated, is to “create Ethereum consensus critical code” “as simple as Bitcoin.”
But even more importantly, Ethereum needs to adopt the spirit of choosing the simplest options possible. This means supporting encapsulated complexity over systemic complexity.
Buterin reassured that code dealing with Ethereum’s historical rules will continue to exist in his latest proposal. However, such codes should be kept outside the consensus critical code, or green area.
