Vitalik Proposes Simplifying Ethereum L1, Aiming for Bitcoin-like Protocol Simplicity in Five Years

ChainCatcher reports that Ethereum co-founder Vitalik Buterin published a blog post stating that Ethereum's goal is to become the "world's ledger": a platform for storing civilizational assets and records, serving as the foundational layer for finance, governance, and high-value data authentication. This requires two things: scalability and resilience. The aim of this post is to focus on a crucial yet often underestimated aspect of resilience (which ultimately also relates to scalability): the simplicity of the protocol. One of the best aspects of Bitcoin is its extremely simple and elegant protocol design. 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 (formerly known as "Beam Chain") aims to create a long-term optimal consensus layer for Ethereum by utilizing all the experience we have 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 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, 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 follow the approach of the tinygrad project and set a "maximum line of code target" for Ethereum's long-term technical specifications, aiming to make the critical code related to consensus in Ethereum as close as possible to the simplicity of Bitcoin. The code related to Ethereum's historical rule processing will still be retained but should be avoided from entering the consensus critical path. At the same time, we should also implement the following principles in the overall design philosophy: prioritize simpler solutions where possible, favor "encapsulated complexity" over "systemic complexity," and prioritize solutions with clear verifiable properties and guarantees in design decisions.