A crucial and long-underestimated aspect of "trustlessness," "passing the abstention test," and "autonomy" is the simplicity of the protocol. Even if a protocol has hundreds of thousands of nodes, is highly decentralized, possesses 49% Byzantine fault tolerance, and all nodes are fully verified using quantum-safe Peerda and Stark algorithms, if the protocol is a bloated system comprised of hundreds of thousands of lines of code and five PhD-level cryptographic techniques, it will ultimately fail the following three tests: * It is not trustless, because you must trust a small group of "senior experts" to tell you the properties of the protocol. * It fails the "leaving test," because if the existing client team leaves, it will be difficult for a new team to achieve the same level of quality. * It is not autonomous, because even the most skilled technicians cannot inspect and understand it; it does not truly belong to you. Furthermore, its security is lower, because every part of the protocol, especially those that can interact with other parts in complex ways, is at risk of protocol collapse. One concern I have about Ethereum protocol development is that we might be too eager to add new features to meet specific needs, even if these features bloat the protocol or introduce entirely new interactive components or complex cryptographic techniques as key dependencies. This might provide short-term functional improvements, but it would severely damage the protocol's long-term autonomy and the construction of a decentralized superstructure that transcends the rise and fall of empires and ideological shifts, lasting for centuries. The core issue is that if protocol changes are measured by "how much they modify the existing protocol," then to maintain backward compatibility, far more features will be added than removed, and the protocol will inevitably become bloated over time. To address this… Ethereum's development process needs a clear "simplification"/"garbage collection" mechanism. "Simplification" includes three metrics: * Minimize the number of lines of code in the protocol. An ideal protocol should be contained within one page, or at least a few pages. * Avoid unnecessary dependencies on overly complex underlying technical components. For example, a protocol whose security relies entirely on hashing (or even better: only one hash function) is better than one that relies on both hashing and lattices. Introducing homology is the worst approach because (sorry to the truly talented and hardworking geeks who figured it out) nobody understands it. * Add more _invariants_: Core properties that the protocol can rely on, such as EIP-6780 (self-destruct removal), which adds properties that can be modified up to N storage slots, each of which can be modified up to N times, significantly simplifying client development; EIP-7825 (gas cap per transaction) increases the cap on the cost of processing a single transaction, greatly aiding Zero-Knowledge Proof Virtual Machine (ZK-EVM) and parallel execution. Garbage collection can be piecemeal or large-scale. A piecemeal approach attempts to simplify existing functionality, making it simpler and more reasonable. For example, Glamsterdam's gas cost reform changed many previously arbitrary gas costs to depend on a few parameters explicitly related to resource consumption. A large-scale garbage collection replaces PoW with PoS. Another large-scale garbage collection is likely to occur within the Lean consensus, allowing for the simultaneous fixing of numerous bugs. Another approach is "Rosetta-style backward compatibility," where complex but infrequently used features remain available but are "downgraded" from the mandatory protocol and incorporated into smart contract code, thus sparing new client developers the trouble of handling them. For example: * After upgrading to a fully native account abstraction, all old transaction types can be deprecated, and EOA can be converted into a smart contract wallet whose code can handle all these transaction types. * We can replace existing pre-compiled versions with EVM or newer RISC-V code (except for those *truly* needed). * We can eventually change the virtual machine from EVM to RISC-V (or another simpler virtual machine); EVM can be converted into smart contracts within the new virtual machine. Finally, we hope that client developers will no longer need to handle all older versions of the Ethereum protocol. This can be left to older client versions running in Docker containers. In the long term, I hope the pace of Ethereum's evolution will slow down. I believe this *must* happen for various reasons. These first fifteen years should be viewed, to some extent, as a growth phase. We explored many ideas and learned which worked, which were useful, and which were not. We should strive to avoid those useless parts becoming a permanent drag on the Ethereum protocol. In conclusion...