Phased acyclic asynchronous upgrades over IBC

[cwgoes]

Desiderata

1. Single staking token (which can be present on multiple chains)
2. Single main chain designated at any one point in time
   1. Main chain only can mint tokens.
   2. Main chain is (socially) canonical source-of-truth.
3. Individual stakeholder choice as to which version to stake on
4. Asynchrony in stakeholder choice of when / where to migrate tokens & stake
5. Acyclic version graph (need not be a chain or tree)
6. Progressive upgrades, where security and risk can change continuously (instead of the binary choice provided by pass/fail on governance proposal-based upgrades)
7. Atomic switch-overs & intentional halts when necessary to retain sufficient security
8. No necessary internal state compatibility between versions (but requisite IBC-layer compatibility)

Requirements

1. Interchain collateralization protocol - ICS 16: Interchain collaterization protocol #27
2. Mutual comprehensibility between staking modules such that inflation can be minted for interchain-collateralized-security

Possible requirements

(would prefer to eliminate if possible)

1. Approval voting of possible upgrades for interchain-collateralization-protocol-compliance

Basic concept

Assume some set of state machine versions in simultaneous operation.

• Stakeholders maintain ranked-choice vote of preference.
• All stakeholders must always validate current main chain.
• All stakeholders must always validate all chains for which they are voting above the main chain.
• Any single stakeholder can start voting-for and validating a new version.
• Slashing conditions for validating other than as voted.
• Threshold-contingent switch of main chain as soon as enough votes switch to another.
  This switch will in fact switch state in a "transfer mode" of IBC (e.g. port all balances).
  This way the two versions need only maintain compatibility at the IBC interface layer.
  During transfer mode, no further upgrades can occur, both chains must be validated by all validators.
  Once transfer mode is done, state resets, voting / upgrades can occur again.
• Users can choose to risk funds on new version prior to main-chain-threshold-switch (over IBC).

Needs more concrete protocol details.

[cwgoes]

Out of scope for the time being.

[gjermundgaraba]

This issue was mistakenly reopened during some integration work, so closing again now.