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

BlockBeats News, on May 3, Ethereum co-founder Vitalik Buterin published a blog post saying that Ethereum's goal is to become a "world ledger": a platform for storing civilized assets and records, a foundational layer for finance, governance, high-value data certification, etc. This requires two things: scalability and elasticity. The goal of this post is to focus on one of the most important, but easily underestimated, aspects of resiliency (and ultimately scalability): the simplicity of the protocol. One of the best things about Bitcoin is that its protocol design is extremely simple and elegant, and keeping the protocol simple helps Bitcoin or Ethereum become a trusted, neutral, and globally trusted infrastructure layer. In the past, Ethereum has often not done enough in this regard, and the next part of 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 (formerly known as Beam Chain) aims to create a long-term optimal consensus layer for Ethereum, using all of our experience over the past decade in consensus theory, ZK-SNARK development, proof-of-stake economics, and other areas. The advantage of this consensus layer is that it is much more concise than existing beacon chains. Simplifying the execution layer: The increasing complexity of the EVM, much of which has proven unnecessary (and in many cases my fault), suggests replacing the EVM with RISC-V, or using another virtual machine that can write an Ethereum ZK prover. I suggest that we follow the example of the project Tinygrad and set a "maximum number of lines of code" goal for Ethereum's long-term technical specifications, with the goal of bringing the key consensus-related code in Ethereum as close to the simplicity of Bitcoin as possible. Code that involves the processing of Ethereum's historical rules will still be retained, but should be avoided into the consensus critical path. At the same time, we should also implement the following principles in our overall design philosophy: prioritize simpler solutions where possible, favor "packaged complexity" rather than "systemic complexity", and prioritize solutions with clear verifiable attributes and guarantees in design decisions.