It is believed by Ethereum co-founder Vitalik Buterin that the blockchain’s long-term resilience and scalability depend on achieving simplicity comparable to Bitcoin. In a blog post published on May 3, he explained that “Ethereum 5 years from now can become close to as simple as Bitcoin,” as stated by Buterin.
One of the best things about Bitcoin is how beautifully simple the protocol is.
It is believed by Buterin that Ethereum’s resilience can be strengthened by simplifying the network through the reduction of consensus-critical code.
It was noted by Buterin that Bitcoin’s streamlined structure and minimalistic approach make it easily understandable, even for a high-school student, allowing them to comprehend its protocol and design. He argued that simplicity offers additional advantages, such as lowering the expenses involved in developing and maintaining infrastructure, while also minimizing the likelihood of software bugs.
Recent enhancements, including the implementation of proof-of-stake (PoS) and the integration of Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK), have strengthened Ethereum’s capabilities. However, it was pointed out by Buterin that overlooking design simplicity has contributed to increased operational costs for Ethereum.
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.
Streamlining Ethereum’s Consensus Layer for Greater Efficiency
In November, a consensus layer enhancement known as the ‘Beam Chain’ was proposed by Ethereum Foundation researcher Justin Drake. It is believed by Buterin that the Beam Chain holds strong potential to be significantly more straightforward than the existing beacon chain, which is now considered outdated.
This is attributed to the beam chain’s support for a 3-slot finality redesign, which would remove intricate elements such as distinct slots, epochs, and sync committees, as noted by Buterin. He further emphasized that a basic version of 3-slot finality could be implemented using roughly 200 lines of code, greatly enhancing its simplicity.
It was mentioned by Buterin that the beam chain would also decrease the number of active validators simultaneously, which would allow for the safer application of more simplified versions of the fork choice rule.
STARK-based aggregation protocols will also be integrated into the beam chain, allowing aggregation to be performed by any participant, as noted by Buterin.
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.
It was added by Buterin that the decrease in active validators combined with the use of STARK-based aggregators would “likely enable a simpler and more robust” peer-to-peer architecture. He further stated that this presents an opportunity to reconsider and streamline various components, including validator onboarding and offboarding processes as well as inactivity leak mechanisms. These improvements, he explained, can be accomplished by minimizing the line-of-code (LoC) count and introducing “more legible guarantees.”
It was emphasized by Buterin that the consensus layer remains “relatively disconnected” from Ethereum Virtual Machine (EVM) executions, offering a “relatively wide latitude” for implementing enhancements in contrast to the more tightly coupled execution layer.
Streamlining Ethereum’s Execution Layer for Enhanced Efficiency
It was proposed by Buterin last month that the EVM contract language be replaced with RISC-V to enhance efficiency by as much as 100 times. He asserted that the use of RISC-V would also contribute to greater simplicity, noting that the “RISC-V spec is absurdly simple compared to the EVM.”
However, this would require that backward compatibility for current applications be maintained, as noted by Buterin.
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).
It was explained by Buterin that the orange area must remain unchanged. The objective, he stated, is to reduce the green area by shifting code into the yellow area, which represents “code that is very valuable for understanding and interpreting the chain today, or for optimal block building, but is not part of consensus.” This approach was compared by Buterin to Apple’s method of maintaining long-term backward compatibility through the use of translation layers.
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 the reason code complexity within the orange and yellow zones is considered to have “significantly fewer drawbacks” than complexity found in the green zone.
To minimize the green area, a phased approach was proposed by Buterin:
Phase 1: New precompiles are to be developed using RISC-V.
Phase 2: Developers would be given the ability to write smart contracts in RISC-V.
Phase 3: All existing precompiles would be replaced with RISC-V versions via a hard fork.
Phase 4: An EVM interpreter would be implemented in RISC-V and deployed onchain as a smart contract.
These measures, according to Buterin, would ensure that Ethereum consensus would come to “natively” recognize only RISC-V.
Network-Wide Standards Aimed at Simplifying the Ethereum Protocol
A unified standard across various components of the stack was proposed by Buterin as a means to achieve greater simplification.
For example, it was suggested by Buterin that a unified erasure code be utilized for data availability sampling, peer-to-peer broadcasting, and distributed history storage. He argued that this approach would reduce the overall lines of code, enhance efficiency, and guarantee verifiability.
Likewise, the implementation of a unified serialization format across Ethereum’s three layers—the execution layer, consensus layer, and smart contract calling Application Binary Interface (ABI)—was proposed by Buterin. He recommended the use of SSZ, noting its simplicity in decoding and broad adoption.
Finally, it was proposed by Buterin that after the EVM is replaced with RISC-V or another simplified language, the current hexary Merkle Patricia tree should be substituted with a binary tree for both the consensus and execution layers. This change, according to him, could enhance efficiency, lower costs, and allow all layers of Ethereum to be accessed and interpreted through a unified codebase.
A Shift in Philosophy
In conclusion, it was proposed by Buterin that Ethereum adopt a defined maximum line-of-code limit, inspired by the approach used in Tinygrad. He reiterated that the primary objective is to make “Ethereum consensus-critical code close to as simple as Bitcoin.”
More significantly, it was emphasized that Ethereum should embrace a mindset in which the simpler alternative is consistently preferred whenever feasible. This would involve prioritizing localized or encapsulated complexity rather than allowing complexity to spread throughout the entire system.
Buterin assured that code responsible for handling Ethereum’s historical rules would still be maintained under his latest proposal. However, he emphasized that such code should remain outside the consensus-critical section, referred to as the green area.
