According to PANews, Ethereum co-founder Vitalik Buterin has published an article discussing the simplification of the Ethereum protocol and the reduction of node resource load. He highlights the EIP-6780 in the Dencun hard fork, which removed most of the functionality of the SELFDESTRUCT opcode, simplifying the protocol by eliminating complexity and adding new security guarantees. Vitalik refers to this as an important part of the ongoing 'Purge' process and provides three examples of other 'Purges': 1. Geth recently removed thousands of lines of code by dropping support for the pre-merge (PoW) network; 2. EIP-161 established the fact that we no longer need to worry about 'empty accounts,' introducing this concept as part of the response to the Shanghai DoS attack; 3. The 18-day storage window for blobs in Dencun means that Ethereum nodes only need about 500GB to store blob data, and this number will not increase over time.
Regarding precompiles, Vitalik points out that some precompiles are far less needed than anticipated and are a major source of consensus errors and pain points for new EVM implementations. Two methods can be used to remove these precompiles: 1. Simply remove the precompile, such as EIP-7266, which removes BLAKE2; 2. Replace the precompile with a piece of EVM code that performs the same operation (though inevitably at a higher gas cost). On the topic of history, Vitalik notes that a key issue to be addressed is who will store old history if not every node. In practice, large entities like block explorers will store it, but it is also possible and not difficult to create peer-to-peer network protocols for storing and transmitting this information, which are better suited for the task. Ethereum's blockchain is permanent, but requiring every node to permanently store all data is an overly 'heavy' implementation of permanence. A simple peer-to-peer old history torrent network is one approach, while a protocol more explicitly optimized for Ethereum use is another. EIP-4444 could greatly increase the decentralization of Ethereum nodes.
Regarding LOG reform, Vitalik suggests removing the bloom and simplifying the LOG opcode to only create a value and hash it into the state. Then, separate protocols using ZK-SNARKs and Incremental Verifiable Computation (IVC) can be built to generate provably correct 'log trees,' which represent easily searchable log tables for a given topic. Decentralized applications requiring logs can use these separate protocols. As for the transition to SSZ, Vitalik states that the Ethereum consensus layer has moved towards a cleaner, more efficient SimpleSerialize (SSZ), but the transition still needs to be completed and the execution layer moved to the same structure. Currently, there are three cryptographic data structures in Ethereum: SHA256 binary trees, SHA3 RLP hash lists, and hex Patricia trees. Once the transition to SSZ is complete, only two will remain: SHA256 binary trees and Verkle trees. In the longer term, binary Merkle trees using SNARK-friendly hash algorithms may replace SHA256 binary trees and Verkle trees once we become proficient enough with SNARK-based hashing.