EPIC: key refactor migration

[tac0turtle]

In the storage working group we discussed how the migration of IAVL will work in the future when we do merge the node key refactor.

the paths I suggested in the call were:

1

This path includes having the old tree format and the new format and assumes the upgrade will not be handled in a coordinated way.

The state sync snapshot, using the old format, would be downloaded. Imported into the old tree because the format is in a post-order format, but the new design requires pre-order. The old tree will export in pre-order form and then import into the new tree. This will allow a node to update using state sync.

2

This approach assumes either a coordinated upgrade or ability to download a snapshot. This approach will export the old version using preorder and import it into the tree. This approach is simple, but it only applies to current state, historical state should be handled

Historical State:

historical state should be handled outside of current state upgrade. This would be up to the application and an issue will land in there to coordinate how to best handle this and potentially leave it up to the operator.

[cool-develope]

We can migrate through the following steps (assume the available version range is [fromVersion, toVersion]):

• Import and Export the snapshot for the fromVersion
• Get changesets and update the tree for the forwarding versions using func (t *ImmutableTree) TraverseStateChanges(startVersion, endVersion int64, fn func(version int64, changeSet *ChangeSet) error) error

[tac0turtle]

closing this as it has been implemented