From what I got from this post and my intuition, here is how pruning would work in Ethereum on a blockchain of length N:

  • the pruned client downloads all the N block headers, so that it may still calculate the proof-of-work of the chain;
  • the pruned client downloads the latest version of the state trie using DHT requests;
  • the pruned client sets a number of non-pruned blocks K, that should be low enough to save disk space, but high enough to guarantee resilience against chain reorganisations;
  • the pruned client downloads all the K last transaction Merkle trees;
  • the pruned client is now able to verify all incoming transactions, and when a new block is appended to the chain, the old Kth block is pruned (i.e. we only keep its header) and the next state trie is reconstructed.

The storage overhead would be greatly reduced with this technique, as the size s_pb of the pruned blockchain would be:

s_pb = N * s_head + s_state + K * s_trans

with s_head the size of a block header, s_state the size of a state trie and s_trans the size of a transaction Merkle tree.

Using this source, as of March 2020:

There are approximately N = 12,000,000 blocks. Each block header weighs about s_head = 500 bytes. I can't find any info on the size of the state trie, intuitively I would say that it is proportional to the number of non-zero accounts and contracts, but here I will just consider that it is equal to s_state = 10,000,000,000 bytes. I will set a conservative K = 1000. I will approximate the size of a transaction Merkle tree by the block size, which is around s_trans = 50,000 bytes. Using these figures, the size of the pruned blockchain would be around 16 GB:

s_pb = 12,000,000 * 500 + 10,000,000,000 + 1000 * 50,000
     = 6,000,000,000 + 10,000,000,000 + 50,000,000
     = 16,050,000,000

From my perspective, even a miner would be able to operate correctly without downloading the whole ledger with this technique. The only condition is that any chain reorganisation beyond the last K blocks remains almost as unlikely as a reorganisation from the genesis block. And if this condition is met, then I would say that pruned clients benefit from the same level of security as full or archive nodes. Am I correct in my reasoning?

Sorry if I made many approximations, I am new to the Ethereum ecosystem, feel free to correct me if you want.

Thank you for your help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.