Vitalik Buterin: Ethereum protocol development needs to introduce simplification and "garbage collection" features to avoid bloating

PANews January 18th News, Vitalik Buterin posted on X platform stating, "An important and long underestimated aspect of ‘trustlessness,’ ‘leaving the test,’ and ‘self-sovereignty’ is protocol simplicity.
Even if a protocol has hundreds of thousands of nodes, possesses 49% Byzantine fault tolerance, and nodes verify everything through quantum-resistant Pederas and Starks, but if the protocol is a massive chaos composed of hundreds of thousands of lines of code and five types of doctoral-level cryptography, then this protocol will ultimately fail in all three tests:
It is not trustless because users must trust a small subset of high-level officials to inform the protocol’s properties.
It cannot pass the ‘leave test’ because if the existing client team leaves, it is extremely difficult for a new team to reach the same quality level.
It does not have self-sovereignty because even the most technically capable people cannot check and understand it; it does not fully belong to the users.
At the same time, its security is also relatively low because each part of the protocol, especially when it interacts with other parts in complex ways, carries the risk of protocol collapse.
One concern I have about Ethereum protocol development is that we may be too eager to add new features to meet highly specific needs, even if these features make the protocol bloated or introduce entirely new types of interaction components or complex cryptography as key dependencies.
This may be beneficial for short-term feature gains but is highly destructive to maintaining long-term self-sovereignty and creating a centennial decentralized superstructure that transcends empire and ideological rise and fall.
The core issue is that if we judge protocol changes from the perspective of ‘how much they alter the existing protocol,’ then the desire to maintain backward compatibility means that the number of additions far exceeds the number of reductions, inevitably leading to protocol bloating over time.
To address this, Ethereum development needs a clear ‘simplification’ or ‘garbage collection’ function. ‘Simplification’ has three criteria:

1. Minimize the total lines of code of the protocol.
2. Avoid unnecessary dependencies on fundamentally complex technical components.
3. Increase more invariants: core properties that the protocol can rely on, such as EIP-6780 (removing selfdestruct), which limits each block to changing at most N storage slots, greatly simplifying client development.
   Garbage collection can be scattered or large-scale. The scattered approach attempts to simplify existing features, making them more concise and reasonable. 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 being part of the mandatory 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 phased out; existing precompiles can be replaced with EVM or RISC-V code; ultimately, the virtual machine can be changed from EVM to RISC-V.
   Finally, it is hoped that client developers will 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 efforts should be made to prevent those useless parts from becoming a permanent burden on the Ethereum protocol.