Pruned Node

A pruned node is a full node that operates with reduced storage requirements by deleting historical block data after it has been processed and validated. It keeps the block headers and the Unspent Transaction Output (UTXO) set or latest state trie, allowing it to fully validate new blocks and transactions without storing the entire blockchain history.

• Primary Goal: Enable participation in network consensus (validation) on hardware with limited disk space.
• Key Difference from Archive Node: An archive (full) node stores the complete history, while a pruned node does not.

From a security perspective, a pruned node maintains the same trustless validation capability as a full archive node for current and future network activity. It independently verifies all consensus rules and cryptographic proofs.

• No Trust Compromise: It does not rely on other nodes for historical data validation; it performed the validation itself when the data was first received.
• Limitation: Cannot serve historical block data to other peers, reducing its contribution to network data availability. It cannot answer queries about old transactions or states it has pruned.

The operational benefit of significant storage savings (e.g., reducing a multi-terabyte requirement to tens of gigabytes) comes with specific functional trade-offs.

• Ideal For: Individual users, developers, or light-service operators who need to validate payments or smart contracts but do not require historical chain analysis.
• Not Suitable For: Block explorers, historical analytics platforms, or services that need to query arbitrary past transactions. These require an archive node.
• Initial Sync: Still requires downloading the full chain history during synchronization before pruning can occur, which can be bandwidth and time-intensive.

Pruning is not a single method; implementation varies by client. Common parameters control how much recent data is retained.

• Retention Window: Clients often keep a rolling buffer of the most recent N blocks (e.g., last 550 blocks in Bitcoin Core) to ensure data for reorganizations.
• Prunable Data: Includes spent transaction outputs (STXOs), old smart contract storage tries, and historical receipts. The cryptographic commitment to this data (in block headers) is kept forever.
• Configuration: Typically set via command-line flags (e.g., -prune= in Geth, prune= in Bitcoin Core) specifying the target storage size.

A high proportion of pruned nodes in a network affects the overall data redundancy and censorship resistance of historical information.

• Reduced Historical Availability: Fewer nodes can serve the full history, making it harder for new nodes to perform initial sync from diverse sources and potentially centralizing historical data.
• Archival Incentives: Networks may implement incentives (e.g., staking requirements for archive nodes) or dedicated infrastructure (like Ethereum's Portal Network) to ensure historical data remains widely available despite pruning.

It is crucial to distinguish pruned nodes from light clients (SPV clients). Both are resource-efficient but have fundamentally different security models.

• Pruned Node: Validates all consensus rules. Requires significant initial sync. Does not trust other nodes for current state validity.
• Light Client: Downloads only block headers. Trusts that the block headers are valid and that merkle proofs provided by full nodes are correct. Much lower resource use from the start.
• Developer Choice: Choose a pruned node for strong security with storage limits; choose a light client for mobile/wallet integration where some trust is acceptable.

A full node downloads, validates, and stores the entire blockchain history, including every transaction and block header. It is the authoritative source for verifying the chain's state without trusting third parties. Key functions include:

• Block Validation: Independently checks all consensus rules.
• Data Serving: Can serve historical data to other nodes and wallets.
• Network Health: Contributes to decentralization and network resilience.

An archival node is a type of full node that retains the complete historical state of the blockchain, enabling queries about any account balance or smart contract at any point in the past. This is resource-intensive but essential for:

• Block Explorers: Providing detailed historical transaction data.
• Analytics & Auditing: Enabling complex chain analysis.
• State-Dependent Services: Supporting services that need to reconstruct past states.

A light client (or SPV client) downloads only block headers, relying on full nodes to provide specific transaction data upon request. It verifies proofs that transactions are included in the chain but does not validate the entire blockchain. This is ideal for:

• Mobile Wallets: Minimizing storage and bandwidth.
• Fast Synchronization: Connecting to the network in seconds.
• Trust-Minimized Verification: Using cryptographic proofs instead of trusting a single server.

State pruning is the process of deleting obsolete data from a node's storage, such as spent transaction outputs (UTXOs in Bitcoin) or historical contract storage trie nodes in Ethereum. This is the core mechanism that enables pruned nodes. It involves:

• Garbage Collection: Removing data no longer needed to validate new blocks.
• State Trie Management: Pruning parts of the Merkle Patricia Trie that are inaccessible.
• Storage Optimization: Drastically reducing disk requirements while maintaining full validation capability.

Initial Block Download (IBD) is the process where a new node synchronizes with the network by downloading and verifying all blocks from genesis to the current tip. For a pruned node, IBD involves:

• Full Validation: Processing every historical block and transaction.
• Pruning Execution: Discarding prunable data as it syncs.
• Post-IBD Operation: Once synced, the node operates with a minimal recent-state dataset, only storing new data as it arrives.

Checkpoint sync (or snap sync, warp sync) is an accelerated synchronization method where a node downloads a recent, trusted snapshot of the blockchain state, bypassing the full historical IBD. It is often used in conjunction with pruning to:

• Reduce Sync Time: Go from hours/days to minutes.
• Lower Bandwidth: Avoid downloading all historical transaction data.
• Start from a Trusted State: Begin from a recent consensus-verified checkpoint provided by the network.