We have already discussed the second, third and fourth stages of the Ethereum upgrade, namely the Surge, the Scourge and the Verge. Each of the stages focuses on specific aspects of development, and with different end goals. They also address various issues on the Ethereum network, while slowly making it more scalable than ever.

For the penultimate stage of the Ethereum upgrade, we will discuss The Purge, what it does to the Ethereum network, how it will work, and what we can expect for it.

The Purge explained

As the name implies, The Purge will be focused on reducing, or “purging,” excess historical data stored on the blockchain. Reducing the amount of historical data will help to make the validation process more efficient for validators under the proof-of-stake consensus mechanism.

The Purge involves a series of processes that remove old and excess network history and simplify the network over time. Aside from reducing the historical data storage, this stage also significantly lowers the hard disk requirements for node operators and the technical debt of the Ethereum protocol.the

Since not all nodes have to permanently store all of the historical blocks, clients will stop storing historical data that is more than one year old. This simply means a significant decrease in hardware requirements for nodes as well as the bandwidth of the network.

This will help minimize network congestion and allow more transactions to be processed on the blockchain. According to Buterin, by the end of this phase, Ethereum should be able to process 100,000 transactions per second.

“The purge: trying to actually cut down the amount of space you have to have on your hard drive, trying to simplify the Ethereum protocol over time and not requiring nodes to store history,” said Buterin.

How does it work?

The Purge also aims to introduce history expiration (EIP-4444), meaning that not all node operators will be required to store all previous blocks data. Instead, clients will stop serving historical data on the p2p network that is more than one year old. This proposal sets history prune epochs to 82125 epochs (one year).

This upgrade will also provide nodes the option to locally prune this historical data. Once a node client has synced the tip of the chain, historical data won’t be necessary for validating blocks and is only retrieved with an explicit request over JSON-RPC or when a peer attempts to sync the chain.

With the implementation of this proposal, new nodes will use a different syncing mechanism, since the historical data will no longer be available. Instead, they will start syncing with a method labeled as “checkpoint sync”. It will sync the chain from the most recently finalized checkpoint block instead of the genesis block.

A specialized “full sync” client will be built that will allow anyone who still wants to get the entire Ehtereum data from the genesis block.

Pruning history reduces the disk requirements and also allows clients to remove code that processes different versions of historical blocks.

In combination with all previous stages of the roadmap, this should reduce network congestion and enable the Ethereum blockchain to execute many more transactions.

Initial Thoughts

Once released, the Purge is expected to significantly reduce the amount of space required to store ETH on a hard drive. It will eventually eliminate the use of nodes in storing Ethereum history, freeing up space, a constant headache for developers.

Nodes are responsible for verifying the miners’ work and ensuring that consensus rules are followed, but the Ethereum blockchain is approaching one terabyte of storage so it’s impractical for a regular person to run a node. This issue will soon be addressed with the Purge.