Vitalik Buterin: Ethereum protocol development needs to introduce simplification and "garbage collection" functions to avoid bloat.

PANews reported on January 18 that Vitalik Buterin posted on the X platform that an important and long-underestimated aspect of "trustlessness," "leaving tests," and "self-sovereignty" is protocol simplicity.

Even if a protocol has hundreds of thousands of nodes, 49% Byzantine fault tolerance, and the nodes fully verify everything through quantum-resistant peerdas and starks, if the protocol is a massive mess of hundreds of thousands of lines of code and five PhD-level cryptographic techniques, then the protocol will ultimately fail in all three tests:

It is not trustless because users must trust a small group of high-ranking clergy to inform them of the protocol's properties.

It cannot pass the "leave test" because if the existing client team leaves, it is extremely difficult for the new team to achieve the same level of quality.

It lacks self-sovereignty because even the most technically skilled person cannot inspect or understand it, so it does not entirely belong to the user.

At the same time, its security is also low because each part of the protocol, especially when it can interact with other parts in complex ways, is at risk of protocol collapse.

One concern I have about the development of the Ethereum protocol is that we may be too eager to add new features to meet highly specific needs, even if these features bloat the protocol or add entirely new types of interactive components or complex cryptography as key dependencies. This may be beneficial for feature gains in the short term, but it is highly destructive to maintaining long-term self-sovereignty and creating a decentralized superstructure that transcends the rise and fall of empires and ideologies for centuries to come.

The core issue is that if protocol changes are judged solely by "how much they modify the existing protocol," then the desire to maintain backward compatibility means far more additions than reductions, inevitably leading to bloat over time. To address this, the Ethereum development process needs a clear "simplification" or "garbage collection" function. "Simplification" has three metrics:

1. Minimize the total number of lines of code in the protocol.

2. Avoid unnecessary dependencies on fundamentally complex technical components.

3. Add more invariants: Core properties that the protocol can rely on, such as EIP-6780 (removing selfdestruct), which adds the property that a maximum of N storage slots can be changed per block, greatly simplifying client development.

Garbage collection can be piecemeal or large-scale. Piecemeal approaches attempt to simplify existing functionality, making it more concise and logical. An example of large-scale garbage collection is replacing PoW with PoS.

Another approach is "Rosetta-style backward compatibility," where complex but rarely used features remain available, but are "downgraded" to smart contract code rather than part of the mandatory protocol, so new client developers don't have to deal with them. For example, after upgrading to a fully native account abstraction, all older transaction types can be deprecated; existing pre-compiled code can be replaced with EVM or RISC-V code; and eventually, the virtual machine can be changed from EVM to RISC-V.

Finally, it is hoped that client developers will no longer need to deal with all the old versions of the Ethereum protocol. In the long run, the pace of change to Ethereum can be slowed down, and efforts should be made to prevent useless parts from becoming a permanent drag on the Ethereum protocol.