Data Pruning

The leading Ethereum execution client, Geth, offers configurable pruning. Snapshot pruning removes old state data while keeping recent snapshots for fast access. Full archive nodes disable pruning entirely, storing all historical state. Operators use the --gcmode flag (e.g., archive, full, light) to control this, balancing storage needs with historical query capability.

Bitcoin Core allows pruning blocks down to a specified size, keeping only the UTXO set and block headers for verification. Using -prune=<N> (where N is MB, e.g., 550) enables this. Pruned nodes cannot serve historical blocks to other peers but maintain full security for validating new transactions, a trade-off for resource-constrained operators.

Optimistic and ZK Rollups inherently prune execution data by design. They post only state roots and compressed transaction data (calldata) to Ethereum L1. The full transaction history and intermediate states are typically stored off-chain by sequencers or data availability committees, making pruning a foundational part of their scalability proposition.

Pruning is a node-level operational choice, while state expiry is a protocol-level mechanism (e.g., proposed in Ethereum's Verkle trees roadmap). Expiry automatically makes old, unused state data inaccessible after a period, forcing protocols to provide proofs of continued need, fundamentally changing the pruning requirement.

Services like Infura, Alchemy, and Blockdaemon run full archive nodes, providing historical data APIs. This creates a market division: most users run pruned nodes for validation, while specialized providers maintain archives for dApps, explorers, and analytics that require full history, illustrating the ecosystem's reliance on varied pruning strategies.

Light clients (e.g., using Ethereum's Les protocol) are the ultimate form of pruning. They store only the current header chain and request specific state proofs on-demand. They rely on full nodes for data, representing a client-side pruning strategy that trades independence for minimal storage and bandwidth.

Data pruning primarily targets state data (account balances, smart contract storage) and old transaction receipts to combat state bloat. However, a full node that prunes too aggressively loses the ability to serve historical data for block explorers or verify the chain from genesis, creating a reliance on archive nodes.

Pruning enables more nodes to operate as light clients or pruned full nodes. These nodes rely on cryptographic proofs (like Merkle proofs) to verify current state without storing all history. Their security depends entirely on the honesty of the full nodes they connect to, introducing a trust assumption not present in a fully validating archival node.

To safely prune ancient history, networks like Ethereum use weak subjectivity checkpoints. New nodes sync from a recent, trusted block (the checkpoint) instead of genesis. This requires users to trust a social consensus on the checkpoint's validity, a trade-off for faster synchronization and reduced storage.

If too many nodes prune data, the network risks data availability problems. Attackers could publish a block with unavailable transaction data, making it impossible for pruned nodes to reconstruct the state and detect fraud. Data availability sampling (DAS) and erasure coding are solutions explored in modular blockchain designs to mitigate this.

Pruning is a storage optimization. Statelessness is a more advanced paradigm where validators don't store any state, verifying blocks using witness data (like Merkle proofs). This shifts the storage burden to block builders and clients, offering stronger security guarantees for validators but requiring more complex protocol changes.

A pruned chain sacrifices auditability. Investigating historical events (e.g., tracing fund flows after an exploit, proving compliance) requires querying a diminishing number of archive nodes. This centralizes a critical forensic function and can make certain on-chain analysis impossible if archival data becomes unavailable.

A specific type of data pruning focused on removing historical state data (account balances, smart contract storage) while preserving the current state. This is distinct from block pruning, which removes old block bodies. Geth and Erigon implement different state pruning strategies to manage Ethereum's growing state size.

A full node that retains all historical data indefinitely, serving as the antithesis to a pruned node. Archive nodes are required for services like block explorers, historical analytics, and certain indexers. They provide the complete dataset from which pruned nodes selectively remove information.

A client that downloads only block headers and requests specific data from full nodes as needed, relying on Merkle proofs for verification. While both light clients and pruned nodes reduce storage, their mechanisms differ: pruning removes data after validation, whereas a light client never stores most data in the first place.

A bootstrapping method where a node downloads a recent, trusted snapshot of the blockchain state (a checkpoint) instead of syncing from genesis. This dramatically reduces initial sync time and is often used in conjunction with pruning, as the node only needs to store and validate data from that checkpoint forward.

An implementation of fast sync specific to the Nethermind Ethereum client. It downloads blocks in parallel and performs state sync by downloading a recent state tree. This process inherently involves pruning, as it does not process every historical transaction, focusing only on reaching the current canonical state.

A node that validates all transactions and blocks, maintaining the full blockchain history up to its pruning configuration. A pruned full node is the standard operational mode for most participants, striking a balance between security (full validation) and practical storage requirements by discarding older, non-essential data.