On May 3rd, Ethereum co-founder Vitalik Buterin published a blog post stating that Ethereum's goal is to become the "world ledger": a platform for storing civilization's assets and records, and a foundational layer for finance, governance, and high-value data certification. This requires two points: scalability and resilience. The goal of this post is to focus on a crucial yet often underestimated aspect of resilience (which ultimately relates to scalability): protocol simplicity. One of Bitcoin's greatest strengths is its extremely concise and elegant protocol design, and maintaining protocol simplicity helps Bitcoin or Ethereum become a trusted, neutral, and globally trusted infrastructure layer. In the past, Ethereum often fell short in this aspect. This article will discuss how Ethereum can become almost as concise as Bitcoin in the next five years. Simplifying the consensus layer: the new consensus layer (previously named "Beam chain") aims to create a long-term optimal consensus layer for Ethereum by utilizing all the experience accumulated over the past decade in consensus theory, ZK-SNARK development, proof-of-stake economics, and other fields. The advantage of this consensus layer is that it is much more concise than the existing beacon chain.
Simplifying the execution layer: EVM's complexity has been increasing, and most of this complexity has been proven unnecessary (in many cases, it was my mistake). It is suggested to replace EVM with RISC-V or other virtual machines that can write Ethereum ZK proofs.
I suggest we learn from the tinygrad project's approach and set a "maximum code line number target" for Ethereum's long-term technical specifications, with the goal of making the consensus-related key code in Ethereum as close to Bitcoin's simplicity as possible. Code involving Ethereum's historical rule handling will still be retained but should be avoided in the consensus critical path. At the same time, we should also implement the following principles in the overall design philosophy: prioritize simpler solutions when possible, prefer "encapsulated complexity" over "systemic complexity", and prioritize design decisions with clear, verifiable attributes and guarantees.
