Vitalik Buterin Calls for Simplification and "Garbage Collection" in Ethereum Protocol Development

PANews January 18, 2025 — Vitalik Buterin posted on X, stating that an important and long-undervalued aspect of "trustlessness," "passing the 'exit test'," and "self-sovereignty" is protocol simplicity. Even if a protocol has hundreds of thousands of nodes, 49% Byzantine fault tolerance, and nodes fully validate everything using quantum-resistant peerdas and starks, if the protocol is a large, messy system composed of hundreds of thousands of lines of code and five doctoral-level cryptographic components, it will ultimately fail all three tests: 1. It lacks trustlessness, as users must trust a small group of high-level priests to explain the protocol's properties. 2. It cannot pass the "exit test," because if the current client team leaves, it will be extremely difficult for new teams to reach the same quality level. 3. It lacks self-sovereignty, because even the most technically capable individuals cannot inspect and understand it, meaning it does not fully belong to the users. At the same time, its security is also low, as each part of the protocol, especially when it can interact with other parts in complex ways, carries a risk of protocol failure. One of my concerns about Ethereum protocol development is that we may be adding new features too quickly to meet highly specific needs, even if these features bloat the protocol or introduce entirely new types of interactive components or complex cryptography as key dependencies. This may be beneficial in the short term for feature gains, but it is highly destructive to maintaining long-term self-sovereignty and creating a decentralized superstructure that can outlast empires and ideological shifts. The core issue is that if protocol changes are judged by "how much they alter the existing protocol," the desire to maintain backward compatibility means that additions far outnumber removals, inevitably leading to protocol bloat over time. To address this, the Ethereum development process needs a clear "simplification" or "garbage collection" function. "Simplification" has three criteria: 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 the protocol can rely on. For example, EIP-6780 (removing selfdestruct) added the property that a maximum of N storage slots can be changed per block, greatly simplifying client development. Garbage collection can be either piecemeal or large-scale. The piecemeal approach attempts to simplify existing features to make them more concise and logical. A large-scale garbage collection example 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 being mandatory parts of the protocol, so new client developers do not have to handle them. For example, after upgrading to fully native account abstraction, all old transaction types can be deprecated; replacing existing precompiles with EVM or RISC-V code; and eventually changing the virtual machine from EVM to RISC-V. Finally, I hope client developers no longer need to handle all old versions of the Ethereum protocol. In the long run, Ethereum's rate of change should slow down, and we should strive to avoid letting useless parts become a permanent burden on the Ethereum protocol.