Long‐Running Network Migrations

I've identified all state changes that impact consensus, and have proposed how a long-running network migration could handle state divergences across networks. This model implies that validators from the old network would run validators for the new network, and would agree on the apphash for every block of the old network while the changes are taking place (essentially replicating all old network data). The new network could set its genesis height to equal the old networks height. It is not critical that the new network remains in lock-step height with the old network- it only matters that the new network agrees on the current height of the old network while the migration takes place.

Database Deployments/Drops

The old network should disable all deploys and drops. The new network can allow deploys and drops as usual.

User Database CRUD

The old network should allow insert/update/delete as normal. The changeset for each dataset from the old network will be given to the new network. There are two options for handling changeset conflicts. All conflicts are identified by primary key:

	Option A (Favors old network)	Option B (Favors new network)
INSERT	All inserts from the old network will be forcefully applied to the new network, and any conflicting columns will be overwritten	Inserts from the old network will attempt to be applied to the new network, and any conflicts will be ignored, in favor of whatever already exists on the new network.
UPDATE	The updated row in the old network will be treated as an insert on the new network, and will overwrite any records on the new network.	The new network will check the pre-change value of the proposed update from the old network's changeset. If the new network's record for that primary key matches the pre-change value in the changeset, it will apply the change. If the values are not equal, it will discard the change, in favor of what data exists on the new network
DELETE	The record will be forcefully deleted on the new network, regardless of content.	Similar to update, if the record matches the pre-change value in the changeset, it will be deleted. Otherwise, no change will be applied.

Account Store

All spends from the old network should be replicated to the new network. If a spend from the old network causes a users balance to go below 0, it should simply set it to 0. On the new network, any nonce that is properly incremented should be accepted as the new nonce. Old nonces (that are too low) replicated from the old network should be ignored, and the spend should still be applied.

NOTE: this implies that network upgrades should either involve a chain ID change, or their should be a network version included in each signature, to protect against replaying transactions from the new network on the old network.

Vote Store

All in-progress votes should be transferred from the old network to the new network at the moment the new network is live. All voting should simultaneously halt on the old network.

Event Store

Since event store is an off-chain db, it doesn't really matter, however nodes should simply not write to the event store for the old network.

Chain Store

No changes need to be made to the chain store, since it only tracks height and app-hash