Updating the version of the blockchain database should result in a clean re-index

[TheQuantumPhysicist]

Backwards compatibility should be handled by version numbers in the blockchain storage. Currently, there's nothing done for that, but a version number exists that can be used. What should happen is: If the hard-coded version number of the database is not equal to the currently stored version in the database on disk, a full re-index of the database should happen. The full re-index can be seen in two different ways:

• We wipe everything in the database and sync from scratch using p2p. This can be an initial solution that prevents the node from crashing due to invalid data in the database.
• To avoid having to re-download everything, we have to define the "re-index" operation. What it does is, it attempts to get all the blocks from the database, and tries to submit them to chainstate.

Technically speaking, reading the database with an incompatible version isn't always safe. Hence, we should also have a mechanism in place that can detect whether a re-index is possible from the current data in the database. The minimum set of data we need to do a full re-index is:

1. The blocks
2. The height vs blocks (so that they can be submitted in order)
3. Any configuration needed to reconfigure the node (such as, whether the transaction index is enabled, etc).

Any information that will be read from the database should only be read when we're sure it's valid. Checksums can be used (by, for example, re-hashing blocks and comparing them to the values in height vs blocks map) to ensure that the data is valid.

Notice that a similar process should be there for wallets, but for wallets it's much more complicated because we MUST salvage data from wallets, unlike for the blockchain storage, where we could just resync from peers.