Document IBC upgrade support for genesis dump/restart

[colin-axner]

Summary

Currently IBC only supports IBC breaking change upgrades via the x/upgrade module. We should add additional support via the genesis dump state/restart mechanism.

Problem Definition

If the x/upgrade has a bug that prevents it from being used, genesis dump/restart would be required. In this case, the chain-id would need to be incremented, effectively breaking all existing IBC channels. To avoid this, the chain would need to halt and wait for the core devs to push a fix which fixes the code at the halting height and then the chain would likely want to use the upgrade module to swap binaries to something more stable.

While this scenario is unlikely, if it did ever occur, I'm sure it would cause a lot of people headaches.

Proposal

Support genesis dump/restart. Revision numbers are already handled, so we just need to rework the current design to be a little more modular and not rely solely on the x/upgrade module. Ideally we could isolate the IBC specific code into it's own proposal. Then upgrade proposals which want to do an IBC upgrade, would include the IBC proposal as well (gov proposals can have multiple changes in one).

I'll defer to @AdityaSripal on the specific design, but I think it's worthwhile to ensure IBC upgrades aren't dependent on bug-free code (by limiting the amount of code the IBC upgrades rely on)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[colin-axner]

We discussed this today. The current mechanism supports genesis dump state restart, but it must happen in place of the upgrade migration.

Pass an x/upgrade software upgrade proposal, let nodes panic, export genesis, change desired fields (chain-id), reset state, boot up nodes.

We should

• test this
• add documentation

[colin-axner]

Currently not supported:

Error: error validating genesis file /home/bartleby/.gm/network2/config/genesis.json: invalid client consensus state timestamp:<seconds:1623670799 nanos:385043798 > root:<> next_validators_hash:"Y\2631\031K\317\231.\336\300\233\204\265\264?(\335\326\003\323\331%\2432`\351\035\371\007\257\251\272"  clientID 07-tendermint-1 index 8: root cannot be empty: invalid consensus state [cosmos/[email protected]/modules/light-clients/07-tendermint/types/consensus_state.go:46]

We need to loosen genesis validation since there may exist consensus states with empty roots (due to upgrades)

[AdityaSripal]

I'd rather we just use a sentinel root value in upgrade consensus state and keep that check. Rather than remembering to put it wherever needed.

[colin-axner]

I tested this and an upgrade + genesis restart worked fine. A genesis restart without an upgrade did not work with the relayers since the data gets reset. The trusted header could no longer be queried. When I get time I'll add documentation for this upgrade path