This is the initial, experimental implementation of pruning, related to #1094. Node ledger pruning is designed to safely discard parts of the ledger. Now ledger size can be reduced from 23.8 GB to 7.5GB after vacuum. And from 18.8 GB to 5.2 GB after database rebuild.
Configuration and considerations
This version of ledger pruning is for experimental use only:
Enable optional ledger pruning with node CLI --debug_prune for manual pruning & node launch flag --enable_pruning for automatic node background actions.
Pruning rules can be configured in [node.experimental] config with “max_pruning_age” (Time in seconds to limit for blocks age after pruning. Also period for automatic node pruning task, default 1 day) & “max_pruning_depth” (Limit for full blocks in chain after pruning, default 0 - unlimited). By default all confirmed blocks older than 1 day can be pruned, except genesis block & last confirmed block in each account chain.
Last confirmed block in account chain & all unconfirmed blocks cannot be pruned from ledger. Pruning is relying on confirmation height, so confirmation height reset or too low online_weight_minimum config can cause issues.
Pruned blocks hashes are located in database table “pruned” & can be used by node internally. There is no specific RPC call to check pruned block existence, but we can add it if necessary.
RPC, CLI and other changes
Several RPC calls are modified to support pruned blocks related to main request block.
RPC “history”: if previous block is pruned, “amount” field is not returned for all blocks, “account” field is not returned for state blocks, also state block type/subtype is “unknown” . If source is pruned, then “account” field is not returned for receive/open legacy & for receive/open state blocks.
RPC “block_info”/“blocks_info”: if previous block is pruned, “amount” field is not returned. RPC “block_count”: for nodes with enabled pruning returns 2 new fields: “full” blocks & “prune...