Vitalik has posted a proposal to simplify Ethereum L1, aiming to achieve a similar protocol simplicity to Bitcoin within five years.

On May 3rd, Vitalik Buterin, a co-founder of Ethereum, published a blog post stating that the goal of Ethereum is to become the "world computer": a platform for storing civilization assets and records, serving as a foundational layer for finance, governance, high-value data attestation, and more. This requires two key elements: scalability and resilience. The purpose of this post is to focus on resilience (which ultimately is also related to scalability), specifically on a highly important but often underestimated aspect: protocol simplicity. One of the greatest aspects of Bitcoin is its extremely elegant and simple protocol design; maintaining protocol simplicity helps Bitcoin or Ethereum become a trusted, neutral, and globally trusted infrastructure layer. Historically, Ethereum has often failed to meet this aspect. The following article will discuss how Ethereum could become nearly as simple as Bitcoin in the next five years. Simplifying the consensus layer: The new consensus layer (formerly known as the "Beam Chain") aims to leverage all the experience 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. Simplifying the execution layer: The complexity of the EVM is increasing, and much of this complexity has been proven to be unnecessary (often my fault in many cases). It is suggested to replace the EVM with RISC-V or another virtual machine that can run Ethereum ZK provers. I propose that we follow the approach of the tinygrad project and set a "maximum code line count target" for Ethereum's long-term technical specifications, aiming to make the key consensus-related code in Ethereum as close to Bitcoin's simplicity as possible. Code relating to Ethereum's historical rule processing will still be retained but should avoid entering the consensus critical path. Additionally, we should adhere to the following principles in the overall design philosophy: prefer simpler solutions whenever possible, lean towards "encapsulated complexity" rather than "systemic complexity," and prioritize solutions that have clear verifiability and guarantees in design decisions.