Ethereum co-founder Vitalik Buterin believes that the blockchain’s long-term resilience and scalability hinge on making it simple, like Bitcoin. In a blog post on May 3, he described how “Ethereum 5 years from now can become close to as simple as Bitcoin.” Buterin wrote:
“One of the best things about Bitcoin is how beautifully simple the protocol is.”
According to Buterin, Bitcoin’s minimalist design and simplicity makes it accessible, so that even a high-school student can grasp the concept and architecture of the protocol. Simplicity, Buterin argued, also brings other benefits, like cutting the cost of creating new infrastructure and maintenance of existing infrastructure, as well as reducing the risk of bugs.
Recent upgrades like proof-of-stake (PoS) and Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) integration have made Ethereum more robust. However, neglecting simplicity of design has added to Ethereum’s costs. Buterin explained:
“Historically, Ethereum has often not done this (sometimes because of my own decisions), and this has contributed to much of our excessive development expenditure, all kinds of security risk, and insularity of R&D culture, often in pursuit of benefits that have proven illusory.”
Simplification of the Ethereum consensus layer
In November, Ethereum Foundation researcher Justin Drake proposed a consensus layer upgrade called the ‘Beam Chain.’ Buterin believes that the Beam Chain is “well-positioned to be much simpler” than its outdated predecessor, the current beacon chain.
This is because the beam chain will allow for 3-slot finality redesign, which will eliminate complex concepts like separate slots, epochs, and sync committees, Buterin noted. He also highlighted that a basic implementation of 3-slot finality can be achieved through about 200 lines of code, making it much simpler.
The beam chain will also reduce the number of active validators at a time, which would make it “safer to use simpler implementations of the fork choice rule,” Buterin wrote.
The beam chain will also incorporate STARK-based aggregation protocols, which means anyone can be an aggregator. Buterin noted:
“The complexity of the aggregation cryptography itself is significant, but it is at least highly encapsulated complexity, which has much lower systemic risk toward the protocol.”
Buterin added that the reduction of active validators and incorporation of STARK-based aggregators will “likely enable a simpler and more robust” P2P architecture. He went on to say that there is an opportunity to rethink and simplify several facets, from validator entry and exit to inactivity leak. And this can be achieved both by reducing line-of-code (LoC) count and by creating “more legible guarantees.”
Buterin highlighted that the consensus layer is “relatively disconnected” from Ethereum Virtual Machine (EVM) executions, which provides a “relatively wide latitude” to make improvements compared to the execution layer.
Simplification of the Ethereum execution layer
Last month, Buterin proposed replacing EVM contract language with RISC-V to boost efficiency by up to 100x. Buterin argued that the adoption of RISC-V will also increase simplicity, since the “RISC-V spec is absurdly simple compared to the EVM.”
However, this would mean ensuring that backwards compatibility for existing applications are preserved. Buterin wrote:
“The first thing that is important to understand is: there isn’t one single way to delineate what is the “Ethereum codebase” (even within a single client).”
According to Buterin, the orange area cannot be decreased. The goal, Buterin claimed, is to minimize the green area, by moving code to the yellow area, that indicates “code that is very valuable for understanding and interpreting the chain today, or for optimal block building, but is not part of consensus.” Buterin likened this process to how Apple achieves long-term backwards compatibility through translation layers. He wrote:
“Importantly, the orange and yellow areas are encapsulated complexity, anyone looking to understand the protocol can skip them, implementations of Ethereum are free to skip them, and any bugs in those areas do not pose consensus risks.”
This is why code complexity in the orange and yellow areas have “far fewer downsides” compared to code complexity in the green area.
To reduce the green area, Buterin proposed the following steps:
Phase 1: New precompiles will be written in RISC-V.
Phase 2: Developers will have the option to write contracts in RISC-V.
Phase 3: All precompiles will be replaced with RISC-V implementations through a hard fork.
Phase 4: Implement an EVM interpreter in RISC-V and push it onchain as a smart contract.
The above steps would ensure that Ethereum consensus would “natively” understand only RISC-V, Buterin stated.
Protocol-wide standards for simplification
Buterin proposed sharing “one standard across different parts of the stack” as a path towards simplification.
For instance, Buterin suggested using a single erasure code for data availability sampling, P2P broadcasting, and distributed history storage. This would minimize the total lines of code, increase efficiency and ensure verifiability, he argued.
Similarly, he proposed having a single shared serialization format across the three Ethereum layers: execution layer, consensus layer, and smart contract calling Application Binary Interface (ABI). Buterin suggested using SSZ, which is easy to decode and widely used.
Lastly, once the EVM has been replaced with RISC-V or another simple language, Buterin proposes switching to a binary tree from the hexary Merkle Patricia tree, both for the consensus and execution layers. This transition could improve efficiency and reduce costs while ensuring that all Ethereum layers can be accessed and interpreted using the same code, Buterin wrote.
A change in ethos
Buterin concluded by proposing that Ethereum, following the example of Tinygrad, adopt an explicit maximum line of code target. The goal, Buterin reiterated, is to make “Ethereum consensus-critical code close to as simple as Bitcoin.”
But more importantly, Ethereum needs to adopt an ethos where the simpler option is chosen wherever possible. This would mean favoring encapsulated complexity over systemic complexity.
Buterin reassured that code that deals with processing Ethereum’s historical rules will continue to exist with his latest proposal. However, such code should be kept outside the consensus-critical code, or the green area.
Mentioned in this article
