Vitalik Buterin Warns of Ethereum Protocol Expansion Crisis: Simplification and Garbage Collection Are Essential

Recently, a post by Vitalik Buterin on X platform has garnered much attention. He pointed out that for the long-term survival of blockchain protocols like Ethereum, the current development approach must be fundamentally reevaluated. He emphasized that simplicity of the protocol is as important as “trustlessness,” “test omission,” and “self-sovereignty,” and has been underestimated until now.

Complex Protocols Undermine Trust

Vitalik presented an intriguing hypothesis. Even if a protocol has hundreds of thousands of nodes, a Byzantine fault tolerance of 49%, and all nodes are quantum-resistant, if there is a single critical flaw, everything becomes meaningless. That flaw is the fact that the protocol is a massive, tangled structure intertwined with tens of thousands of lines of code and doctoral-level cryptographic techniques.

In such cases, the protocol inevitably fails trust testing. Users must blindly trust a small group of experts to understand the protocol’s properties. It also cannot pass “job change testing,” where new teams take over after the original developers leave, maintaining the same quality level. No matter how smart the developers are, they cannot perfectly inspect or understand such a complex system.

The Problem of Unrestrained Feature Addition in Ethereum Development

The fundamental issue Vitalik pointed out is the tendency to rapidly add new features to meet specific requirements in Ethereum protocol development. Each addition increases complexity and introduces entirely new types of interaction components or advanced cryptographic dependencies as core dependencies.

In the short term, this allows quick delivery of desired features to users. But in the long run, it causes serious side effects. Building a truly decentralized structure that transcends centuries, empires, and ideological rises and falls becomes increasingly difficult. Parts of the protocol, especially those intricately linked with other areas, become vulnerabilities that threaten the entire system’s collapse.

The Pitfall of Backward Compatibility: Why Only “Adding” Continues

Judging protocol changes solely by “how much they modify the existing protocol” naturally leads to a desire to maintain backward compatibility. As a result, modifications are fewer than additions, and over time, the protocol inevitably becomes bloated. This is the structural problem Ethereum faces today.

Vitalik argues that to break this vicious cycle, Ethereum development processes should incorporate clear “simplification” or “garbage collection” features.

Three Criteria for Protocol Simplification

Vitalik’s simplification strategy includes three core criteria:

First, minimize the total lines of code of the protocol. Less code means easier maintenance, faster auditing, and lower bug probability.

Second, eliminate unnecessary dependencies on fundamentally complex technical components. Not all advanced technologies are necessary; sometimes, simpler approaches can be more robust.

Third, add more immutable properties. For example, EIP-6780 removed the self-destruct function, which allowed only N storage slots per block to be changed, greatly simplifying client development. Embedding clear rules into the protocol can dramatically reduce complexity.

Garbage Collection Strategies: Partial Approach and Large-Scale Cleanup

Garbage collection can be performed in two ways:

Partial approach involves redesigning existing features to make them more concise and logical. Small-scale cleanup gradually reduces complexity.

Large-scale garbage collection entails fundamental changes. A typical example is the transition from proof-of-work (PoW) to proof-of-stake (PoS). This single change significantly simplifies the protocol’s structure and drastically reduces energy consumption.

Rosetta-style Backward Compatibility: Consideration for Future Developers

Vitalik’s most innovative approach is the “Rosetta-style backward compatibility.” In this method, complex but infrequently used features are removed from the core protocol but maintained through “downgrades” via smart contract code, preserving backward compatibility.

For instance, after fully upgrading to native account abstraction, there’s no longer a need to keep all transaction types as essential features, since users can implement them via smart contracts. Similarly, pre-compiled codes can be replaced with new formats like EVM or RISC-V. Ultimately, the virtual machine itself can fully transition from EVM to RISC-V.

This approach relieves new client developers from having to handle multiple versions of the Ethereum protocol.

Long-term Vision: Slow Change, Stronger Foundation

Ultimately, Vitalik’s proposal aims to slow down Ethereum’s pace of change in the long run. It seeks to regulate short-term feature additions and prevent unnecessary complexity from hindering protocol development.

This is a necessary condition for Ethereum to become a truly decentralized infrastructure. No matter how smart the developers are, if it becomes too complex to understand, it will inevitably lead to centralization by a few experts. Simplicity is the foundation of genuine autonomy and trust, and this insight from Vitalik should be deeply discussed within the Ethereum community.