4

Why a validator node should always be an archive node? What are the risks and downsides of not doing so? I understand that it is probably interesting to have at least one archive node, but why all of them? If the blockchain data is kept (extrinsics and block headers), any state at any point of time can be reproduced if needed, right? So why to keep in DB the state for each block?

This question popped up when I tried to run a validator in pruning mode --pruning 256 and I got this error:

Error: Input("Validators should run with state pruning disabled (i.e. archive). You can ignore this check with '--unsafe-pruning.'"

NachoPal
  • 196
  • 4

1 Answers1

6

The reason why validator nodes run as archive nodes by default is partly because of legacy reasons - I believe pruning didn't work right before (although this is currently resolved).

The risks of using a pruned database is that database snapshots may be a bit tricky to restore (so if your database gets corrupted you may need to resync from the start). And also if the number of blocks for the pruning parameter is too small, consensus may not operate correctly (a value of 1000 or 10000 should be fine).

For running it as an archive node the obvious downside is storage space, but this also make backups from your own nodes and those you may find from others to have better compatibility.

wpank
  • 61
  • 1