Vitalik Buterin: Ethereum protocol development needs to introduce simplification and "garbage collection" features to avoid bloating Vitalik Buterin stated in an article on the X platform that an important and long underestimated aspect of "lack of trust," "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 are fully verified by quantum resistant peerdas and starks, if the protocol is a massive mess consisting of hundreds of thousands of lines of code and five doctoral level cryptography, it will ultimately fail in all three tests: It does not have untrustworthiness, as users must trust a small group of senior 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 does not possess self sovereignty because even the most technically capable person cannot check and understand it, so it does not entirely belong to the user. At the same time, its security is also low because there is a risk of protocol collapse in every part of the protocol, especially when it can interact with other parts in a complex way. My concern regarding the development of the Ethereum protocol is that we may be too eager to add new features to meet highly specific requirements, even if these features make the protocol bloated or add new types of interaction components or complex cryptography as key dependencies. This may be beneficial for functional gain in the short term, but it is highly destructive for maintaining long-term self sovereignty and creating a century old decentralized superstructure that transcends the rise and fall of empires and ideologies. The core issue is that if protocol changes are evaluated from the perspective of 'how much modification has been made to existing protocols', the desire to maintain backward compatibility means that the number of increases far exceeds the number of decreases, and the protocol will inevitably become bloated over time. In order to address this situation, the Ethereum development process requires a clear "simplification" or "garbage collection" feature, with three metrics for "simplification": 1. Minimize the total number of code lines for the protocol. 2. Avoid unnecessary dependencies on fundamentally complex technical components. 3. Add more invariants: The core attributes that the protocol can rely on, such as EIP-6780 (removing self destruct), which adds the attribute that each block can only change up to N storage slots, greatly simplifying client development. Garbage collection can be scattered or large-scale. Scattered methods attempt to simplify existing functions, making them more concise and reasonable. An example of large-scale garbage collection is using PoS instead of PoW. Another approach is' Rosetta style backward compatibility ', where complex but rarely used features are still available but' downgraded 'to smart contract code rather than being part of mandatory protocols, so that new client developers do not have to deal with them. For example, after upgrading to a fully native account abstraction, all old transaction types can be eliminated; Replace existing precompilation with EVM or RISC-V code; Finally, change the virtual machine from EVM to RISC-V. Finally, we hope that client developers no longer need to handle all old versions of the Ethereum protocol. In the long run, the speed of change in Ethereum can slow down, and efforts should be made to avoid those useless parts becoming a permanent drag on the Ethereum protocol.