History Pruning

A full archival node stores the complete blockchain history, including every transaction and state change. A pruned node discards older, non-essential data after a certain block depth, keeping only recent blocks and the current UTXO set or state trie. This drastically reduces storage requirements, allowing nodes to run on consumer hardware while still validating new transactions and blocks.

Bitcoin Core implements pruning by discarding old block data while retaining the Unspent Transaction Output (UTXO) set. Once a block is buried deep enough in the chain (default: 288 blocks), its raw transaction data can be deleted. The node cannot serve historical blocks to peers but continues to validate new blocks using the compact UTXO set, which is all that's needed to verify future transactions.

Ethereum clients like Geth and Erigon perform multiple types of pruning:

• State Pruning: Removes obsolete state trie nodes that are no longer referenced by the latest canonical chain.
• History Pruning: Discards historical block bodies and receipts after a set retention period. Advanced modes like snap sync and archive mode offer different trade-offs between sync speed, storage, and historical data availability.

Pruning involves key trade-offs:

• Storage Efficiency vs. Historical Service: Pruned nodes cannot serve the full history to the network, potentially reducing data redundancy.
• Initial Sync Speed: Pruning often happens during or after sync, requiring significant temporary storage.
• Verification Limits: A pruned node cannot re-verify the chain from genesis without re-downloading data. The network relies on a sufficient number of archival nodes to preserve history and verify pruned node assumptions.

Pruning enables lighter client paradigms. Light clients trust recent block headers from full nodes and fetch specific data on-demand, requiring minimal storage. Some networks use hard-coded checkpoints (trusted block hashes) to allow new nodes to sync quickly from a recent, verified state, effectively 'pruning' the need to validate all prior history.

To manage blockchain bloat, ecosystems often offload historical data from consensus nodes:

• External Indexers & APIs: Services like The Graph index and serve historical event data.
• Decentralized Storage: Networks like Arweave or Filecoin can store full chain history in a decentralized manner.
• Erasure Coding: Some designs, like Mina Protocol's recursive proofs, compress the entire chain state into a constant-sized cryptographic proof.

History pruning is a node-level operation that deletes historical blockchain data (like old transaction details and state) while preserving the current state and the minimal data required to validate new blocks. This is distinct from a state prune, which only removes obsolete state entries. The primary goal is to manage the blockchain's storage footprint, which grows indefinitely without pruning.

Pruning introduces a fundamental security trade-off. A pruned node cannot serve historical data, reducing its utility for the network. Key considerations include:

• Reduced Self-Verification: Users cannot independently verify the entire chain history.
• Trust Assumptions: Must rely on archive nodes or external indexers for historical data.
• Network Health: If too many nodes prune, the network's data redundancy and resilience decrease.

For node operators, pruning is a critical operational decision affecting performance and cost.

• Storage Savings: Can reduce storage needs by over 90% compared to a full archive node.
• Sync Speed: Initial synchronization (fast sync) is often faster as less data is downloaded.
• Resource Trade-off: Saves disk space at the cost of losing the ability to query old blocks or re-execute historical transactions locally.

Ethereum's Geth client implements pruning via its garbage collection mechanism. Key parameters:

• --gcmode=archive: Keeps all history (Archive Node).
• --gcmode=full: Default. Prunes old state trie nodes but keeps all block history.
• --gcmode=light: Prunes aggressively, operating as a light client. The snap sync protocol works in tandem with pruning to achieve faster initial sync by downloading snapshots of recent state.

Understanding the node type is crucial for infrastructure planning.

Pruned (Full) Node:

• Storage: ~500GB - 1TB (Ethereum).
• Data Kept: Current state, recent ~128 blocks of history.
• Can Serve: Latest state, new transactions.

Archive Node:

• Storage: ~12TB+ (Ethereum).
• Data Kept: Full history from genesis.
• Can Serve: Any historical query, trace, or state. Archive nodes are essential for block explorers, analytics, and certain dApp backends.

Pruning interacts with several other blockchain scaling and infrastructure concepts.

• State Expiry: A proposed protocol-level mechanism to automatically prune old state, moving the burden from node operators to the protocol.
• Erigon's "Staged Sync": An alternative client implementation that stores data more efficiently, reducing the initial need for aggressive pruning.
• External Indexers (e.g., The Graph): Provide historical data APIs, allowing dApps to function without requiring every node to be an archive node.