Vitalik proposed simplifying Ethereum L1 in a post, aiming for the protocol's simplicity to be close to Bitcoin within five years.

ChainCatcher message, Ethereum co-founder Vitalik Buterin published a blog post stating that the goal of Ethereum is to become a “world ledger”: a platform for storing civilizational assets and records, the foundational layer for finance, governance, high-value data verification, etc. This requires two points: scalability and resilience. The aim of this post is to focus on an extremely important but often underestimated aspect of resilience (which ultimately relates to scalability): the simplicity of the protocol. One of the best aspects of 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. Simplified Consensus Layer: The new consensus layer (formerly known as “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 fields 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. Simplified 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 recommended 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 tinygrad project and set a “maximum lines of code goal” for Ethereum’s long-term technical specifications, aiming to make the key code related to consensus in Ethereum as close as possible to the simplicity of Bitcoin. The code that handles Ethereum’s historical rules will still be retained, but we should avoid it entering the consensus critical path. At the same time, we should also implement the following principles in our overall design philosophy: prioritize simpler solutions wherever possible, lean towards “encapsulated complexity” rather than “systemic complexity,” and prioritize adopting solutions with clear verifiable attributes and guarantees in design decisions.