Vitalik Buterin Advocates for Simplifying Ethereum
Vitalik Buterin, co-founder of Ethereum, has expressed his belief that like Bitcoin, blockchain technology can enhance long-term durability and scalability. In a blog post on May 3, he mentioned that “Ethereum in five years can be as simple as Bitcoin.” He stated:
“One of the best things about Bitcoin is how beautiful and simple the protocol is.”
Buterin noted that Bitcoin’s minimalist approach is accessible enough for high school students to understand its structure and concept. He suggested that this simplicity also leads to various advantages, such as lowering the costs of developing new infrastructure, maintaining existing systems, and minimizing the risk of errors.
Recent upgrades, like Proof-of-Stake (POS) and Zero Knowledge Concise Non-interactive Discussion (ZK-SNARK) integration, have made Ethereum more resilient. However, Buterin indicated that neglecting simplicity has increased costs for Ethereum. He remarked:
“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, researcher Justin Drake from the Ethereum Foundation proposed an upgrade for the consensus layer called the “beam chain.” Buterin thinks beam chains are “appropriately positioned as much simpler” than their current beacon chain. This redesign aims to streamline the finality of the three slots, eliminating complex concepts like individual slots and synchronization committees. He mentioned that a basic implementation could be done with roughly 200 lines of code, making it significantly simpler.
Additionally, beamchains would reduce the number of active validators at any given time, and “it’s safer to use a simpler implementation of fork selection rules,” according to Buterin.
The beamchain also features 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.”
He believes that fewer active validators and the introduction of Stark-based aggregators will likely lead to a “simpler and robust” P2P architecture. Buterin thinks there’s a chance to rethink various aspects, like validator entries and exits, which could reduce the amount of code required while improving readability.
He stressed that the consensus layer is “relatively disconnected” from the Ethereum Virtual Machine (EVM) operation.
Simplifying the Ethereum Running Layer
Recently, Buterin suggested replacing the EVM contract language with RISC-V to enhance efficiency by up to 100 times. He also asserted that adopting RISC-V would be “absurdly simpler than EVMs,” promoting greater simplicity.
This doesn’t compromise the backward compatibility of existing applications. Buterin said:
“The important thing to understand first is that there is no single way to describe what ‘Ethereum Codebase’ is (even within a single client).”
He explained that certain complexities—representing the “orange area”—cannot be minimized, while the goal should be to shrink the “green area” by transitioning code into the “yellow area,” indicating elements essential for understanding current chains and block construction that aren’t part of the consensus. He compared this to Apple’s approach to long-term compatibility through translation layers, writing:
“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.”
Thus, the complexity in orange and yellow is “a much less drawback” compared to that in green.
To lessen the green area’s complexity, Buterin proposed several steps:
- New precompilation written in RISC-V.
- Developers can write contracts in RISC-V.
- All precompilations are replaced by RISC-V implementations via hard forks.
- Implement EVM interpreters on RISC-V and incorporate them on-chain as smart contracts.
These steps ensure that Ethereum’s consensus comprehends RISC-V “natively,” according to Buterin.
Protocol Standardization for Simplification
Buterin suggested sharing “one standard across different parts of the stack” as a route toward simplification. For example, he proposed a unified erase code for data availability sampling, P2P broadcasting, and distributed historical storage. This would reduce the total line of code, boost efficiency, and ensure verification.
Moreover, he recommended having a single serialization format for three layers of Ethereum: the execution layer, the consensus layer, and the Smart Contract Call Application Binary Interface (ABI) using SSZ. SSZ is not only easy to decode but also widely used.
Once EVM is exchanged for RISC-V or another simple language, Buterin proposes shifting from a hexagonal Patricia Tree to a binary tree in both the consensus and execution layers. This could enhance efficiency and lower costs, allowing all layers to be accessed and interpreted using the same code.
Future Changes
Buterin wrapped up by referencing TinyGrad and advocating for Ethereum to adopt explicit maximum line code targets. He reiterated that the aim is to create “Ethereum consensus critical code” as “simple as Bitcoin.”
Even more crucially, Ethereum should embrace the philosophy of choosing the simplest options available. This involves supporting encapsulated complexity rather than systemic complexity.
Buterin asserted that code pertaining to Ethereum’s historical rules will remain in his latest proposal but should be excluded from the consensus-critical code.
