Vitalik Buterin the co-founder of Ethereum shared insights on the next steps in the protocols simplification and easing the burden on node resources, also known as Purge.

The Purge essentially aims to safeguard the protocol by optimizing data storage. At the same time, it also seeks to address design decisions that were made due to technology constraints in the past. The primary objective is to streamline the protocol, eliminate technical obligations, and reduce participation costs in the network by clearing outdated historical data.

EIP-6780s Role in Purge

EIP-6780 is a crucial proposal before Ethereum reaches the Purge. It focuses on reducing the functionality of the SELFDESTRUCT opcode within the protocol. The proposal was implemented during the Dencun hard fork in a bid to simplify Ethereum and enhance its security guarantees.

Buterin stressed the importance of this process in removing unnecessary complexity as well as addressing technical debt. This is not only expected to streamline Ethereums functionality but also address any accumulated technical issues. EIP-6780 serves as an example of this goal.

While Dencun also paved the way for blobs, Buterin is also eyeing another crucial proposal to hit the floor, the EIP-4444, which seeks to prune the historical data in clients older than one year. The Ethereum co-founder highlighted the challenge of storing old history for the second-largest blockchain. While entities like block explorers may handle it, he suggests optimizing peer-to-peer protocols to store and share this data, offering a viable solution.

The Ethereum blockchain is permanent, but requiring literally every node to store all of the data forever is a very “overkill” way of achieving that permanence.

Other Areas That Warrant Purging

According to Buterin, reducing the amount of storage needed to run an Ethereum node can greatly expand participation. Also, EIP-4444 reduces node sync time, streamlining workflows for operators and potentially enhancing Ethereums decentralization.

Hence, EIP-4444 can greatly increase Ethereum’s node decentralization. Potentially, if each node stores small percentages of the history by default, we could even have roughly as many copies of each specific piece of history being stored across the network as we do today.

Another aspect is Precompiles, some of which are very successful, but others are underutilized and the demand for them was found to be lower than expected. These underused precompiles trigger consensus bugs and difficulty for new EVM implementations. Buterin suggests two ways to address this issue: removing precompilation, and replacing them with an EVM code segment that executes the same action.

With regards to LOG reform, Buterin suggests removing bloom filters and focusing solely on producing a hashed state value. The plan includes utilizing ZK-SNARKs and incrementally verifiable computation (IVC) to construct verified log trees.

Another aspect that warrants attention is the ongoing transition of Ethereum to SimpleSerialize (SSZ). While the Ethereum consensus layer has moved to the cleaner and more efficient SSZ, the same cannot be said for the execution layer, which needs to be moved over to the same structure.

After transitioning to SSZ, only two structures will remain: SHA256 binary trees and Verkle trees. Eventually, as SNARK hashing improves, Buterin noted that both may be replaced by binary Merkle trees using SNARK-friendly hashes, unifying Ethereums data structures.