Vitalik posted a proposal to simplify Ethereum L1, aiming for the protocol's simplicity to approach that of Bitcoin within five years
ChainCatcher message, Ethereum co-founder Vitalik Buterin published a blog post stating that Ethereum's goal is to become a "world ledger": a platform for storing civilizational assets and records, serving as the foundational layer for finance, governance, high-value data certification, and more. This requires two things: scalability and resilience. The aim of this post is to focus on an extremely important yet often underestimated aspect of resilience (which ultimately relates to scalability): the simplicity of the protocol. One of the best things about Bitcoin is its extremely simple and elegant protocol design, and maintaining the simplicity of the protocol helps Bitcoin or Ethereum become a trusted, neutral, and globally trusted infrastructure layer. In the past, Ethereum has often fallen short in this regard, and this article will discuss how Ethereum can become almost as simple as Bitcoin in the next five years.Simplifying the consensus layer: The new consensus layer (originally named "Beam Chain") aims to leverage all the experience we have accumulated over the past decade in consensus theory, ZK-SNARK development, proof-of-stake economics, and other areas to create a long-term optimal consensus layer for Ethereum. The advantage of this consensus layer is that it is much simpler than the existing beacon chain.Simplifying the execution layer: The complexity of the EVM is increasing, and much of this complexity has proven to be unnecessary (in many cases, it is my fault). It is suggested to replace the EVM with RISC-V or another virtual machine that can write Ethereum ZK provers.I suggest we learn from the approach of the project tinygrad and set a "maximum lines of code target" for Ethereum's long-term technical specifications, aiming to bring the key code related to consensus in Ethereum as close to Bitcoin's simplicity as possible. Code related to Ethereum's historical rule processing will still be retained but should avoid entering the consensus critical path. At the same time, we should also implement the following principles in our overall design philosophy: prioritize simpler solutions whenever possible, favor "encapsulated complexity" over "systemic complexity," and prioritize solutions with clear verifiable properties and guarantees in design decisions.