Vitalik releases instructions on next steps for Ethereum protocol simplification and node resource load reduction (Purge)
Vitalik Buterin, co-founder of Ethereum, published "Purge" instructions on the next steps to simplify the Ethereum protocol and reduce the load of node resources.
Vitalik said EIP-6780 in the Dencun hard fork removes much of the functionality of the SELFDESTRUCT opcode, simplifying the protocol by removing complexity and adding new security guarantees. Therefore Vitalik marked it as an important part of the "Purge". Regarding other "Purges" that are happening, Vitalik gave three examples: 1. Geth recently dropped support for the pre-merger (PoW) network , thousands of lines of code were removed. ;2.EIP-161 formalizes the fact that we no longer need to have code to worry about "empty accounts", the proposal introduced this concept as part of the fix for the Shanghai DoS attack;3.Blobs in Dencun The 18-day storage window means that Ethereum nodes only need about 500GB to store blob data, and this amount will not increase over time. The first two points significantly improve the work experience for client developers, while the last point significantly improves the work experience for node operators.
In addition, regarding what other areas may need to be "purged", Vitalik listed precompilation, history logging (EIP-4444), LOG reform, and moving to SSZ.
Regarding precompilation, Vitalik pointed out: "The demand for partial precompilation is much lower than expected, and these precompiled functions are a huge source of consensus errors and a huge pain point for new EVM implementations. There are two ways to remove these precompilations: 1. Only Need to remove precompilation, for example EIP-7266 will remove BLAKE2; 2. Replace precompilation with a piece of EVM code that performs the same operation (although inevitably at a higher gas cost)."
Regarding history, Vitalik noted: “A key question that needs to be addressed is: if old history is not stored by every node, who will store it? In fact, large entities such as block explorers will. However, it is also possible and not difficult to make peer-to-peer network protocols to store and deliver this information, which are better suited for this task. The Ethereum blockchain is permanent, but requiring each node to store all data permanently is a A very 'over' approach to permanent implementation. A simple peer-to-peer legacy torrent network is one approach. A protocol more explicitly optimized for use by Ethereum is another. EIP-4444 could greatly improve Ethereum nodes' Degree of decentralization. If each node stored only a small portion of history by default, then in theory the number of stored copies of each particular piece of history could be roughly the same as today on the network."
Regarding LOG reform, Vitalik noted: "We can remove bloom and simplify the LOG opcode so that it just creates a value and hashes it into the state. We can then build it using ZK-SNARKs and incremental Separate protocols for Verification Computation (IVC) to generate provably correct 'log trees' that represent easily searchable log tables of a given topic. Applications that require logs and wish to be decentralized can use these separate protocols. "
Regarding the move to SSZ, Vitalik said: “The Ethereum consensus layer has moved to the cleaner and more efficient SimpleSerialize (SSZ), however the transition still needs to be completed and the execution layer moved to the same structure. Today, there are three cryptography in Ethereum Data structures: SHA256 binary trees, SHA3 RLP hash lists, and hex Patricia trees. Once we complete the transition to SSZ, there will only be two left: SHA256 binary trees and Verkle trees. In the longer future, once we are good enough For hashing using SNARKs, it is possible to replace SHA256 binary trees and Verkle trees with binary Merkle trees that use a hashing algorithm suitable for SNARKs."
