Ethereum co-founder Vitalik Buterin believes that the resilience and scalability of the long-term blockchain depend on making simple, such as Bitcoin. In a blog after On 3 May he described how “Ethereum 5 years can now be as easy as Bitcoin.” Buterin wrote:
“One of the best things from Bitcoin is how beautiful the protocol is.”
According to Buterin, the minimalist design and the simplicity of Bitcoin make it accessible, so that even a high school student can understand the concept and architecture of the protocol. Simplicity, BUTERIN argued, also offers other benefits, such as reducing the costs for creating new infrastructure and maintenance of existing infrastructure, as well as reducing the risk of bugs.
Recent upgrades such as proof-of-stake (POS) and zero knowledge, concise non-interactive argument of knowledge (ZK-Snark) have made Ethereum more robust. However, neglecting the simplicity of the design has added the costs of Ethereum. Buterin explained:
“Historically, Ethereum has often not done this (sometimes because of my own decisions), and this has contributed to many of our excessive developmental spending, all types of safety risks and insularity of the R&D culture, often in the pursuit of benefits that Illusos have proved to be.”
Simplification of the Ethereum -Consensus layer
In November Ethereum Foundation -researcher Justin Drake set a consensus layer -upgrade for the ‘Beam Chain’. Buterin believes that the bundle chain is “well positioned to be much easier” than are outdated predecessor, the current beacon chain.
This is because the bundle chain makes the redesign of 3-slot finality possible, those complex concepts such as individual slots, periods and synchronization committees will eliminate, Buterin noted. He also emphasized that a basic implementation of 3-slot final can be achieved by around 200 code rules, making it much easier.
The bundle chain will also reduce the number of active validators at the same time, making it “safer to use simpler implementations of the fork choice rule,” wrote Buterin.
The bundle chain will also contain grim -based aggregation protocols, which means that everyone can be an aggregator. Buterin noticed:
“The complexity of the aggregation -cryptography itself is considerable, but it is at least highly encapsulated complexity, which has a much lower systemic risk for the protocol.”
Buterin added that the reduction of active validators and recording of large groups-based aggregators “probably makes a simpler and robust” P2P architecture possible. He further said that there is an opportunity to reconsider and simplify different facets, from validator input and exit to inactivity leak. And this can be achieved, both by reducing the number of code (locomotive) and by creating “more readable guarantees”.
Buterin emphasized that the consensus layer is “relatively disconnected” from Ethereum Virtual Machine (EVM) versions, which offers a “relatively wide latitude” to make improvements compared to the version layer.
Simplification of the execution layer of Ethereum
Last month, Buterin suggested replacing the EVM contract language with RISC-V to stimulate efficiency by a maximum of 100x. Buterin argued that the approval of RISC-V will also increase simplicity, because the “RISC-V specification is absurdly easy compared to the EVM.”
However, this would mean that backward compatibility is stored for existing applications. Buterin wrote:
“The first thing that is important to understand is: there is no way to define what the” Ethereum -Codebase “is (even within a single client).”
According to Buterin, the orange area cannot be reduced. The goal, claimed Buterin, is to minimize the green area by moving code to the yellow area, which indicates: “Code that is very valuable for understanding and interpreting the chain today, or for optimum block construction, but is not part of consensus.” Buterin compared this process with how Apple reaches backward compatibility in the long term via translation layers. He wrote:
“It is important that the orange and yellow areas are complexity encapsulated, anyone who wants to understand the protocol can skip, implementations of Ethereum are free to skip them, and all bugs in those areas do not form consensus risks.”
This is why code complexity in the orange and yellow areas have “far fewer disadvantages” compared to code complexity in the green area.
To reduce the green area, Buterin suggested the following steps:
Phase 1: New precompiles are written in RISC-V.
Phase 2: Developers have the option to write contracts in RISC-V.
Phase 3: All precompiles are replaced by RISC-V implementations via a hard fork.
Phase 4: Implement an EVM-Tolk in RISC-V and push it on a smart contract.
The above steps would cause Ethereum consensus to understand “native” only RISC-V, BUTERIN said.
Protocol-wide standards for simplification
Buterin suggested sharing “one standard over different parts of the stack” as a path to simplification.
For example, Buterin suggested using a single erasal code for sample of data availability, P2P broadcast and distributed history storage. This would minimize the total code lines, increase efficiency and guarantee verifiability, he argued.
Similarly, he suggested having a single shared serialization on the three Ethereum layers: implementation layer, consensus layer and smart contract -calling Application Binary Interface (ABI). Buterin suggested using SSZ, which is easy to decode and is used a lot.
Finally, as soon as the EVM has been replaced by RISC-V or another simple language, Buterin proposes to switch to a binary tree of the sixth Merkle Patricia Tree, both for the consensus and the implementation layers. This transition can improve efficiency and reduce costs and ensure that all Ethereum layers are accessible and interpreted with the same code, Buterin wrote.
A change in Ethos
Buterin concluded by proposing that Ethereum is, according to the example of Tinygrad, an explicit maximum line of code objective. The goal, repeated Buterin, is to make “Ethereum-Consensus-critical code as easy as Bitcoin.”
But even more important, Ethereum has to take on an ethos where the simpler option is chosen where possible. This would mean that encapsulated complexity is over systemic complexity.
Buterin assured that code that deals with the processing of the historical rules of Ethereum will continue to exist with his last proposal. However, such a code must be stored outside the consensus -critical code or the green area.