Pruning State

To reduce hardware requirements and improve the overall latency of the node, operators are encouraged to prune their state (unless they are archivers or historical nodes).

As will be explained in the following sections, pruning should be configured from the start, i.e. late changes to the pruning configuration may not be optimal for the node's health.

Consensus Pruning

To configure pruning of the consensus data amend your node's configuration with:

# ... sections not relevant are omitted ...
consensus:
    # ... sections not relevant are omitted ...
    prune:
        strategy: "keep_n"
        num_kept:  <n>

where <n> is the number of blocks and state versions that will be kept.

Suggested Pruning Configuration

For normal node operation, the minimum requirements is n=250_000. However, it is recommended to set it to n=400_000. Assuming blocks are produced every 6 seconds, the latter corresponds to preserving 1 month of the consensus data.

Operators that are not resouce-restrained and want to contribute to the overall network health are encouraged to set n=5_000_000 (approximately 1 year of data).

Late Pruning

Due to the LSM Tree design of the underlying databases, enabling pruning after your node has been runing for a while, or possibly changing configuration to retain less data, may may not work as expected.

To change pruning configuration operators must follow this steps:

1. Gracefuly shutdown the node (validators should take special care).
2. Configure pruning as described in Consensus Pruning.
3. Run offline pruning (TODO insert link).
4. Run the compaction command.
5. Start the node again.

Paratime Pruning

To configure pruning of the paratime data ammend your node's configuration with:

# ... sections not relevant are omitted ...
runtime:
    # ... sections not relevant are omitted ...
    prune:
        strategy: "keep_last"
        num_kept:  <n>

where <n> is the number of paratime's state versions that will be kept.

Suggested Pruning Configuration

Paratime state is much larger than the consensus state. As a consequence, as the number of versions in the state database grows, pruning becomes slower and slower. For this reason paratime state pruning must be configured from the start or not configured at all.

To configure pruning it is recommended to set n=250_000. The maximum value is n=400_000. If you need to preserve more data (e.g. nodes serving historical state) you will have to keep the entire state from the genesis.