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.
Buterin noted that Bitcoin’s streamlined structure and minimalistic approach make it easy for even a high-school student to understand 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, Buterin pointed out that overlooking design simplicity has increased Ethereum’s operational costs.
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, Ethereum Foundation researcher Justin Drake proposed a consensus layer enhancement known as the ‘Beam Chain.’ Buterin believes that the Beam Chain has strong potential to simplify the existing beacon chain, which many now consider outdated.
Buterin attributed this 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. He further emphasized that developers could implement a basic version of 3-slot finality using roughly 200 lines of code, greatly enhancing its simplicity.
Buterin mentioned that the beam chain would also reduce the number of active validators at the same time, allowing developers to apply safer, more simplified versions of the fork choice rule.
Buterin noted that the beam chain will also integrate STARK-based aggregation protocols, allowing any participant to perform aggregation.
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.
A Buterin added that decreasing the number of active validators combined with using 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. He explained that developers can accomplish these improvements by minimizing the line-of-code (LoC) count and introducing “more legible guarantees.”
Buterin emphasized that the consensus layer remains “relatively disconnected” from Ethereum Virtual Machine (EVM) executions, offering developers a “relatively wide latitude” to implement enhancements compared to the more tightly coupled execution layer.
Streamlining Ethereum’s Execution Layer for Enhanced Efficiency
Last month, Buterin proposed replacing the EVM contract language with RISC-V to enhance efficiency by as much as 100 times. He asserted that using RISC-V would further simplify the system, 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).
Buterin explained that developers must keep the orange area 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.” Buterin compared this approach to Apple’s method of maintaining long-term backward compatibility by using 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 why developers consider code complexity within the orange and yellow zones to have “significantly fewer drawbacks” than the complexity found in the green zone.
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
Buterin proposed a unified standard across various components of the stack to achieve greater simplification.
For example, Buterin suggested using one shared erasure code for tasks like data sampling, peer-to-peer sharing, and saving blockchain history. He said this would lower the total amount of code, make the system work better, and help ensure that everything can be verified.
Similarly, Buterin suggested using a single, simple format for handling data across Ethereum’s three parts—the execution layer, consensus layer, and smart contract interface (ABI). He recommended SSZ because it’s easy to decode and already widely used.
Finally, Buterin proposed that after replacing the EVM with RISC-V or another simplified language, developers should substitute the current hexary Merkle Patricia tree with a binary tree for both the consensus and execution layers. He explained that this change could enhance efficiency, lower costs, and enable developers to access and interpret all layers of Ethereum through a unified codebase.
A Shift in Philosophy
In conclusion, Buterin proposed 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.”
Experts stressed that Ethereum should always choose the simpler option whenever possible. They suggested keeping complex parts limited to small areas instead of letting them affect the whole system.
Buterin assured that his latest proposal would still maintain the code responsible for handling Ethereum’s historical rules. However, he emphasized that developers should keep such code outside the consensus-critical section, known as the green area.
