Pruned Node

Overview

A pruned node reduces storage by discarding historical data after validating it and advancing the current chain state. It can continue enforcing consensus and validating new blocks without keeping a complete archival copy.

Exact retention differs by protocol and client. Some nodes keep headers and recent blocks, while state-pruned systems may retain snapshots or current state but cannot answer arbitrary historical queries. Reindexing can require downloading and validating history again. Operators should document pruning mode, retained window, backup strategy, and RPC limitations. A pruned full node can provide stronger consensus assurance than a remote explorer, but it is not an archive node. Applications needing old receipts, traces, proofs, or address history must use suitable archival infrastructure and reconcile provider results. Timeouts and retries need idempotent behavior, while recovery should rescan canonical history instead of assuming that an unavailable response means no transaction occurred. Monitoring should correlate transport and service metrics with node synchronization, chain progress, block propagation, and finality.

Protective controls should include least privilege, protected credentials, dependency updates, and tested failover. Logs need network identifiers and request correlation, but sensitive keys, tokens, and user data should be minimized and redacted. Connection success measures service availability, not whether the underlying node follows the canonical chain or can provide the required history. Service availability and blockchain settlement must be measured separately.

Practical implication: Pruned nodes preserve current validation while sacrificing historical query depth, so archival requirements need separate infrastructure.

A pruned node validates blockchain history but deletes selected older block or state data after retaining what current operation requires.