Node Pruning

Overview

Node pruning removes selected historical data from a local Node Database. Clients can prune old states, receipts, transaction indexes, block bodies, or other records according to their architecture. The objective is to keep disk usage manageable without sacrificing the node’s ability to validate the current chain and process new blocks.

A pruned full node is not necessarily a light or nonvalidating node. It can verify blocks and maintain current state while deleting data that can be reconstructed or obtained elsewhere. An archive node, by contrast, preserves historical states for past-block queries and analysis. The exact retained window and reconstruction capability vary by client and configuration.

Pruning changes service capabilities. Historical balance queries, traces, explorer indexes, and old receipt lookups may fail after data is removed. It can also complicate incident investigation and restoration if operators assume the node contains a complete history. Applications should query node capabilities explicitly and route historical workloads to suitable archive infrastructure.

Operators should monitor disk savings, pruning progress, database compaction, and synchronization impact. Pruning should use supported client mechanisms rather than manual file deletion. Before enabling it, teams should define backup and Node Recovery requirements, because a pruned database may need a snapshot or resynchronization after corruption. The retained data should still be validated against current canonical and finalized roots.

A sound implementation treats Node Pruning as a network-specific concept. node pruning reduces storage while preserving current validation, but it intentionally removes historical query and recovery capabilities. For Node Pruning, versioned rules, reproducible test data, and retained evidence help prevent assumptions from one protocol or release being applied to another.