Vitalik Buterin has rolled out new 'Purge' protocols intended to refine the Ethereum framework and ease the resource burden on nodes.

Co-founder of Ethereum, Vitalik Buterin, has dropped new 'Purge' guidelines that present a framework for streamlining the Ethereum protocol and reducing node resource demands.

As noted in a recent blog post during the Ethereum Dencun hard fork, EIP-6780 effectively removed a large segment of the functions tied to the SELFDESTRUCT opcode. This move was part of an effort to simplify the protocol by cutting down on complexity and enhancing security measures. Vitalik Buterin pointed out this as a critical element of the 'Purge.'

On the topic of other ongoing 'Purges,' Vitalik Buterin cited three vivid examples. First up is Geth, which has discontinued support for the pre-merger (PoW) network, resulting in the removal of thousands of lines of outdated code. Additionally, EIP-161 formalizes the process of resolving issues related to 'empty accounts,' which arose from the need to address the Shanghai DoS attack. Lastly, the implementation of an 18-day storage window for blobs in Dencun is geared to keep Ethereum nodes at an approximate 50GB capacity for blob data, with no expectation of growth in this requirement over time.

The first two points mark significant advancements for client developers, while the final point represents a noteworthy enhancement for those operating nodes. 

Four Key Focus Areas for Enhancement: Precompiles, EIP-4444, LOG Overhaul, and SSZ

Addressing other components that may necessitate 'purging,' Vitalik Buterin identified Precompiles, history logging (EIP-4444), LOG reform, and the shift to Simple Serialize (SSZ). 

According to Vitalik Buterin Although there's been a lower-than-expected demand for partial precompilation, precompiled functions continue to be a major source of consensus problems and obstacles for new Ethereum Virtual Machine (EVM) implementations. There are two strategies to tackle this: one is to completely eliminate precompilation, as implemented in EIP-7266, which does away with BLAKE2, and the other is to replace precompilation with a segment of EVM code that performs identical tasks.

In terms of EIP-4444 and its implications for history storage, Vitalik Buterin raised a significant concern: if old history is not retained by every node, who will maintain it? He suggested that larger entities such as block explorers could take on this role. However, it’s also plausible, and not overly complicated, to create peer-to-peer (P2P) protocols aimed at storing and circulating this data more efficiently. He also proposed that utilizing P2P networks along with optimized protocols tailored for Ethereum could serve this purpose effectively.

Another specifically tailored protocol for Ethereum 's utilization is under consideration as well—EIP-4444 has the capacity to considerably enhance the decentralization of Ethereum nodes. 

Concerning the LOG reform, Vitalik Buterin proposed the removal of bloom filters and the simplification of the LOG opcode to produce just one value hashed into the state. The next phase would involve the formulation of distinct protocols that incorporate ZK-SNARKs and incremental verifiable computation (IVC) to establish accurate ‘log trees.’ As explained in the article, 'These log trees would operate as searchable tables encompassing all logs related to a specific topic, thus giving decentralized applications the capability to efficiently leverage these separate protocols.'  

He also pointed out that Ethereum's shift to SSZ is a work in progress, and adjustments need to be made in the execution layer to align with this structure. Presently, three distinct encrypted data structures are operational: SHA256 binary trees, SHA3 RLP hashed lists, and hexary Patricia trees. After the transition to SSZ is completed, the ecosystem will only consist of two: SHA256 binary trees and Verkle trees. 

Following the completion of the SSZ transition, the setup will retain just two structural types: SHA256 binary trees and Verkle trees . With ongoing advancements in 'SNARKing hashes,' there's a potential to substitute both SHA256 binary trees and Verkle trees with binary Merkle trees that leverage hash algorithms fitted for SNARKs.