Pruned Node

The primary purpose of a pruned node is to drastically reduce storage requirements. Instead of storing the entire blockchain history, which can exceed terabytes for mature networks, a pruned node retains only:

• The most recent block headers (for proof-of-work).
• The Unspent Transaction Output (UTXO) set or the latest state trie.
• A configurable window of recent blocks (e.g., the last 550 blocks in Bitcoin). This allows nodes to run on consumer-grade hardware with limited disk space.

Despite pruning old data, a pruned node maintains full consensus and validation capabilities. It can:

• Independently verify the cryptographic integrity of new blocks and transactions.
• Enforce all network rules.
• Maintain the current state (e.g., account balances in Ethereum, the UTXO set in Bitcoin). It achieves this by storing a cryptographic commitment to the state (like a Merkle root) and the data needed to prove new transactions are valid against that state.

A key trade-off is the loss of self-sufficiency for historical queries. A pruned node cannot:

• Serve old blocks or transactions to other peers.
• Answer queries about historical account states or transaction history beyond its retained window.
• Perform deep blockchain analysis that requires scanning the entire chain. For these functions, a full archival node is required. Pruned nodes rely on the network's archival nodes for initial synchronization and historical data if needed.

During the Initial Block Download, a pruned node must still download and process the entire blockchain from genesis to verify the current state's integrity. However, after validating each block, it discards the transactional data, keeping only the essential state information. This process is computationally identical to a full node's IBD but results in a much smaller final on-disk footprint. The node is only considered 'pruned' after this initial synchronization is complete.

Pruned nodes strengthen network decentralization by lowering the barrier to entry for participants who wish to run fully validating nodes. They contribute to:

• Network Security: More independent validators increase the cost of attacking consensus.
• Censorship Resistance: Users can verify transactions without trusting third parties.
• Client Diversity: A healthy mix of pruned and archival nodes creates a more resilient network topology, though pruned nodes do not serve historical data to peers.

Bitcoin Core: Uses the -prune=N flag, where N is the minimum size in MB to keep for block files. It prunes transactional data but keeps block headers and the UTXO set.

Geth (Ethereum): Offers a 'snap' sync mode followed by pruning. It downloads the recent state, then prunes older state trie nodes that are no longer referenced, retaining only the latest state and a recent window of blocks.

Monero: Prunes old transaction data (ring signatures, range proofs) but keeps the key images needed to prevent double-spends, significantly reducing node size.

The core trade-off is between storage footprint and historical data access. Key differences:

• Storage: Pruned nodes require ~650 GB for Bitcoin and ~1 TB for Ethereum, while archival nodes require ~500+ GB and ~12+ TB, respectively.
• Function: A pruned node can validate new blocks and the current UTXO set/state. An archival node can also service arbitrary historical queries (e.g., "balance of address X at block 5,000,000").
• Use Case: Pruned for validation and current state; archival for deep analytics, auditing, and infrastructure services.

A pruned node permanently deletes old blockchain data after validation, retaining only the most recent state and a minimal set of block headers. This means it cannot serve historical queries, such as:

• Transaction data older than the pruning window
• Account balances or contract states from past blocks
• Proofs for events that occurred outside the retained data range This makes pruned nodes unsuitable for block explorers, analytics services, or applications requiring deep historical access.

While pruned nodes can validate new transactions and blocks, they cannot fully participate in blockchain data propagation. They are unable to:

• Serve historical blocks to synchronizing peers
• Act as a reliable archival seed node for the network
• Provide data for long-range light client proofs This reduces their utility in strengthening network resilience and data availability compared to full archival nodes.

Pruning creates a fundamental trade-off between resource efficiency and verification capability. A pruned node verifies the chain's current state cryptographically but cannot independently re-verify the entire history. It must trust that the chain it synced from was valid up to its pruning point. This is acceptable for most users but critical for services requiring absolute, self-verified historical integrity.

The ecosystem relies on a sufficient number of full archival nodes. Pruned nodes depend on these nodes during initial synchronization. If archival nodes become scarce, network health degrades as:

• New pruned nodes have fewer sources for a reliable sync
• The cost and time to bootstrap a new node increases
• Network decentralization suffers, creating potential centralization risks around remaining archival providers

Decentralized applications that require access to old events or state changes will fail or provide incomplete data when querying a pruned node. This affects:

• Analytics & Indexing Services: Cannot build complete historical datasets.
• Auditing Tools: May miss historical contract interactions.
• Some DeFi Protocols: That use historical price oracles or time-weighted calculations. Developers must ensure their infrastructure connects to archival nodes for these use cases.

The pruning window (e.g., last 1000 blocks) is a critical configuration. A smaller window maximizes storage savings but:

• Increases the risk of being unable to serve data for recent queries
• May complicate certain consensus actions if the node falls slightly behind
• Limits the ability to debug issues that require tracing back a few hundred blocks Choosing the window size requires balancing immediate resource constraints with anticipated application needs.

State pruning is the core process that defines a pruned node. It is the method of deleting old, spent transaction outputs (UTXOs) and historical state data after it is no longer needed for validating new blocks. Key techniques include:

• Pruning depth: Keeping only the last N blocks (e.g., Bitcoin Core default: ~550 blocks).
• Garbage collection: Removing orphaned data from the state trie. This reduces storage from terabytes to gigabytes while maintaining full validation capabilities.