Pruning

Removes historical state data (account balances, smart contract storage) that is no longer needed for processing new blocks. This is the most common form of pruning, as the state trie grows continuously with usage. Nodes only retain the current state and a limited history, significantly reducing disk usage. For example, a pruned Ethereum node requires ~550GB, while an archive node requires over 12TB.

Deletes old block bodies (transaction lists) while keeping the block headers. The block header chain remains intact to maintain consensus and cryptographic security. This allows nodes to verify the chain's integrity and the current state root without storing every transaction ever made. It's a trade-off between storage and the ability to serve historical transaction data.

Bootstrapping methods that leverage pruning. Instead of replaying all transactions from genesis, a new node downloads the current state directly from peers. Fast Sync downloads block headers and the latest state. Snap Sync (Geth) is more efficient, transferring a snapshot of the state trie. Both methods result in a pruned node from the start.

Defines two primary node types. A Pruned (Full) Node stores only recent data, sufficient to validate new blocks and the current state. An Archive Node retains the complete historical record, including all states at every block. Archive nodes are essential for block explorers, analytics, and certain historical queries but require orders of magnitude more storage.

The future evolution of pruning. Stateless clients aim to validate blocks without storing any state locally, relying on witnesses. EIP-4444 (History Expiry) proposes that nodes stop serving historical block bodies and receipts older than one year, pushing them into a decentralized storage network. This radically reduces the perpetual storage burden on node operators.

Pruning lowers the barrier to running a full node by reducing hardware costs and sync times. Key considerations include:

• Storage: Drastically lower persistent requirements (e.g., from 12TB+ to ~500GB for Ethereum).
• Bandwidth: Initial sync can be faster but may use more bandwidth to fetch state snapshots.
• Functionality: Pruned nodes cannot service arbitrary historical data queries, which are handled by specialized archive services.

The network health of a pruning protocol depends on a sufficient number of archival nodes (full nodes retaining all history). Key trade-offs include:

• Decentralization: Pruning lowers node costs, increasing participation.
• Data Availability: Reliance on archival nodes creates a trust assumption for historical data.
• Sync Time: Pruned nodes sync faster but cannot bootstrap other nodes from genesis.

Pruning's primary benefit is drastically lowering the storage burden for full nodes. Instead of storing the entire blockchain history, nodes can delete old block data and state snapshots after they are finalized, often reducing storage needs by over 90%. This lowers the barrier to entry for running a node, promoting greater network decentralization.

By eliminating the need to download and verify the entire historical chain, pruning enables faster initial block download (IBD) and node synchronization. New nodes can join the network more quickly by syncing from a recent pruned checkpoint or state root, rather than processing every transaction from the genesis block.

With a smaller active dataset, node operations like state lookups and transaction validation can be faster. This reduces I/O overhead and memory pressure, leading to more efficient block propagation and processing. It's a critical scalability improvement for high-throughput networks.

Pruning creates a clear distinction between full nodes (pruned, validation-focused) and archival nodes (full history). Archival nodes remain essential for services like block explorers, analytics, and historical data queries, but the network's core security no longer depends on every participant storing all data.

Pruning involves key design choices:

• What to prune: Old blocks, spent transaction outputs (UTXO model), or historical state trie nodes (account model).
• Pruning triggers: Based on block depth, time, or storage thresholds.
• Data irreversibility: Pruned data is permanently deleted and must be retrieved from archival nodes if needed.

• Bitcoin Core: Prunes old blocks after a configurable number (default ~550 MB of recent blocks).
• Geth (Ethereum): Offers snapshot-based state pruning to remove old state trie nodes while preserving recent state.
• Solana: Employs aggressive ledger pruning to manage its high transaction volume, with validators storing only recent epochs of data.

State bloat is the continuous growth of a blockchain's stored data, primarily its state (account balances, smart contract storage) and historical blocks. This leads to increasing hardware requirements for node operators. Pruning is a direct countermeasure, selectively deleting non-essential historical data while preserving the current state and chain integrity.

An archive node is a full node that retains the complete historical data of the blockchain, including all past states. It is the antithesis of a pruned node. These nodes are essential for:

• Historical data queries and analytics
• Block explorers and indexers
• Auditing and forensic analysis While resource-intensive, they serve as the canonical source for data that pruned nodes discard.

Statelessness is a protocol-level design paradigm where validators can verify blocks without storing the entire current state. Instead, they rely on cryptographic proofs (like witnesses) for the specific state accessed by a transaction. This is a more radical solution than pruning, aiming to eliminate the state storage burden entirely for most nodes, making syncing nearly instantaneous.

Checkpoint sync (or weak subjectivity sync) is a bootstrapping method that allows a new node to start from a recent, cryptographically attested checkpoint (a trusted block header) instead of genesis. This drastically reduces sync time and data download. It often works in tandem with pruning, as nodes only need to download and store a pruned chain from that checkpoint forward.

Data Availability Sampling (DAS) is a technique, central to modular blockchain architectures, where light nodes perform random checks to verify that block data is fully published and available. It enables secure pruning at the base layer, as nodes can be confident that specific historical data can be retrieved from dedicated data availability layers when needed, rather than storing it forever.

Ethereum clients like Geth and Nethermind implement pruning by default. They operate in two modes:

• Full Sync: Downloads and prunes old state data, keeping only recent state.
• Archive Mode: Retains all historical state (requires ~12+ TB). Pruning in Ethereum typically removes state trie nodes that are no longer referenced after 128 blocks, while block body and receipt data can also be pruned based on age.