Vitalik Buterin Wants to Make Ethereum 'As Simple As Bitcoin' by 2030

Ethereum co-founder Vitalik Buterin believes that the long-term resilience and scalability of blockchain depend on making it simple, much like Bitcoin. In a blog post on May 3, he described how "Ethereum 5 years from now could become almost as simple as Bitcoin." Buterin wrote: "One of the greatest things about Bitcoin is the extremely simple protocol." According to Buterin, the minimalist design and simplicity of Bitcoin make it accessible, so even a high school student can grasp the concept and architecture of the protocol. Buterin argues that simplicity also brings other benefits, such as reducing the costs of creating new infrastructure and maintaining existing infrastructure, as well as lowering the risk of errors. Recent upgrades such as Proof of Stake (PoS) and the integration of Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) have made Ethereum stronger. However, ignoring the simplicity of the design has increased the costs of Ethereum. Buterin explained: "In the past, Ethereum often did not do this ( sometimes due to my own decisions ) and this contributed to many excessive development costs, all kinds of security risks, and narrowness in R&D culture, often to pursue benefits that have proven to be unrealistic." Simplifying the Ethereum consensus layer In November, Ethereum Foundation researcher Justin Drake proposed a consensus layer upgrade called 'Beam Chain'. Buterin believes that Beam Chain "is well-positioned to become much simpler" compared to its outdated predecessor, the current beacon chain. This is because the beam chain will allow the finality of the 3 slots to be redesigned, which will eliminate complex concepts such as separate slots, epochs, and synchronization committees, Buterin noted. He also emphasized that the fundamental implementation of the finality of the 3 slots could be achieved through about 200 lines of code, simplifying many things. The beacon chain will also reduce the number of active validators at any given time, which will help "utilize simpler implementations of the safer branch selection rule," Buterin wrote. The beam chain will also integrate STARK-based aggregation protocols, meaning anyone can be an aggregator. Buterin noted: "The inherent complexity of the composite encryption is considerable, but at least it has tightly packaged complexity, with much lower systemic risk for the protocol." Buterin added that reducing the number of active validators and combining STARK-based aggregators "is likely to enable a simpler and more powerful P2P architecture." He went on to say that there is an opportunity to rethink and simplify some aspects, from the validators coming in and out to inactive leakage. And this could be achieved by reducing the amount of code (LoC) and by creating "more easily readable guarantees." Buterin emphasized that the consensus layer is "relatively separate" from the execution activities of the Ethereum Virtual Machine (EVM), which provides a "relatively wide scope" for implementing improvements compared to the execution layer. Simplifying the Ethereum execution layer Last month, Buterin proposed replacing the EVM contract language with RISC-V to increase efficiency by up to 100 times. Buterin argued that adopting RISC-V would also enhance simplicity, as "the RISC-V specification is absurdly simple compared to the EVM." However, this means ensuring that backward compatibility for existing applications is maintained. Buterin wrote: "The first important thing to understand is: there is no single way to define what the "Ethereum codebase" is ( even in a single client )." According to Buterin, the orange area cannot be reduced. Buterin stated that the goal is to minimize the green area by moving the code to the yellow area, saying "the code is very valuable for understanding and interpreting the chain today or for building optimal blocks, but it is not part of the consensus." Buterin likened this process to how Apple achieves long-term backward compatibility through layers of compilation. He wrote: "The important thing is that the orange and yellow areas are packaged complexly, anyone who wants to understand the protocol can skip them, the deployment of Ethereum can skip them, and any errors in those areas do not pose a risk to consensus." This is why the complexity of the code in the orange and yellow areas has "far fewer drawbacks" compared to the complexity of the code in the green area. To reduce the area of greenery, Buterin proposed the following steps: Phase 1: New front-end compiler programs will be written in RISC-V. Phase 2: Developers will have the option to write contracts using RISC-V. Phase 3: All previous translations will be replaced by RISC-V implementations through a hard fork. Stage 4: Deploy the EVM interpreter in RISC-V and put it on the chain as a smart contract. Buterin stated that the above steps will ensure that Ethereum's consensus will "naturally" understand RISC-V. Standard protocol for simplification Buterin proposed sharing "a standard across different parts of the stack" as a way to simplify. For example, Buterin proposed using a unique erase code to sample available data, broadcast P2P, and store distributed history. This would minimize the total amount of code, increase efficiency, and ensure verifiability, he argued. Similarly, he proposed having a shared serialization format across three layers of Ethereum: the execution layer, the consensus layer, and a smart contract called the Application Binary Interface (ABI). Buterin proposed using SSZ, which is easy to decode and widely used. Finally, after the EVM is replaced by RISC-V or another simpler language, Buterin proposed switching from the Merkle Patricia hexary tree to a binary tree, for both the consensus layer and the execution layer. 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 personality Buterin concluded by suggesting that Ethereum, following the example of Tinygrad, adopts a clearly defined maximum code line goal. Buterin reiterated that the aim is to make "the code critical to Ethereum's consensus nearly as simple as Bitcoin." But more importantly, Ethereum needs to adopt a standard where simpler options are chosen whenever possible. This means prioritizing packaged complexity over systemic complexity. Buterin stated that the code handling the historical rules of Ethereum will continue to exist with his latest proposal. However, such code must be kept outside the critical consensus code or the green zone.