Chain upgrade requirements for Hermes (meta issue)

[adizere]

Crate

ibc-relayer

Summary

Hermes requires some additional features to make chain upgrades more user-friendly.

Briefly, these features would be good to have:

• [x] #1287
  • switch between /cosmos.upgrade.v1beta1.SoftwareUpgradeProposal and /ibc.core.client.v1.UpgradeProposal at runtime, based on a --legacy flag passed to the tx raw upgrade chain CLI
• [ ] #1148
  • listen and parse newBlockEvents to catch the upgraded consensus state event, and react on that by upgrading all counterparty clients
• [ ] handle revision number changes upon chains upgrading: there are two sub-cases here:
  • [ ] correct client latest height upon chain id revision change
  • [ ] test that Hermes is able to re-establish connection to the chain post-upgrade, once the chain has a higher revision number, so for hermes these are new chains, e.g. ibc-0 node will be upgraded and restarted as ibc-1 (From @ancazamfir's comment)
• [x] #1662
• [x] #1288

These will be further documented in their own issue.

Problem Definition

The current workflow for upgrading a chain is:

1. submit chain upgrade proposal (either via hermes upgrade-chain or gaiad)
   • if the chain is on SDK 0.42.*, use Hermes (v0.6.0 works)
2. use Hermes to upgrade counterparty clients of all other chains (using #763)

If the chain is using SDK 0.43, we are now adding support for it (#948) but that should be backwards compatible with 0.42, so that users can use the same Hermes version to do chain upgrades regardless of the minor version; that is the first feature above.

Having the second feature "automatic client upgrade" will simplify the workflow and make the process more smooth. With this feature, Hermes will react on a specific event of the upgrading chain and trigger counterparty client upgrades.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate milestone (priority) applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[adizere]

Sharing context here from a discussion in our IBC weekly call:

• ideal timeline: anytime before ibc clients will need to be upgraded
• IBC clients on mainnets will need to undergo an upgrade because the IAVL in the SDK is abandoned → proof specs need to be updated (which the client stores)
  • Chains doing the upgrade will store the new proof spec (client's 'upgrade_path')