Vitalik published an article discussing the future development of the Ethereum protocol, The Purge, with the goal of reducing storage requirements and the complexity of the Ethereum protocol

Vitalik released the future development of the Ethereum protocol (Part V: The Purge), with the following key goals: Reduce client storage requirements by reducing or eliminating the need for each node to permanently store all history or even state; Reduce the complexity of the protocol by eliminating unnecessary features. The article mentioned that Ethereum has begun to get rid of the model where all nodes permanently store all history. Consensus blocks (that is, the part related to proof-of-stake consensus) are only stored for about 6 months. Blobs are only stored for about 18 days. EIP-4444 aims to introduce a one-year storage period for historical blocks and receipts. The long-term goal is to have a coordinated period (probably about 18 days) during which each node is responsible for storing everything, and then the peer-to-peer network of Ethereum nodes stores old data in a distributed manner. In addition to the need for clients to store history, client storage requirements will continue to grow, about 50 GB per year, because the state continues to grow: account balances and random numbers, contract code, and contract storage. Users can pay a one-time fee to burden current and future Ethereum clients forever. There are two things that need to be done to reduce the complexity of the protocol: Stop changing and making the protocol rigid; Be able to actually remove features and reduce complexity. In addition, Vitalik mentioned that a more radical way to reduce complexity is to keep the protocol as it is, but move most of it from protocol functions to contract code; a more moderate way is to keep the relationship between the beacon chain and the current Ethereum execution environment unchanged, and choose RISC-V, Cairo or other VMs as the new "Official Ethereum VM", and then force all EVM contracts to be converted to the new VM code that interprets the logic of the original code (by compiling or interpreting). In theory, this can even be done with the "target VM" as the EOF version.