CLIs for upgrades regression following update to tm-rs 0.21

[adizere]

Crate

ibc-relayer

Summary of Bug

Following the update to tm-rs 0.21 (#1223), in particular this change mentioned here, the upgrade-chain functionality fails. The zero_custom_fields method can no longer enforce the trust threshold to be 0/0, because that is not a valid domain type construction of the TrustThresholdFraction type.

There is a possible workaround to make the upgrade-chain command work successfully, documented in this commit
informalsystems/ibc-rs@27c1a7e
This workaround achieves the following:

• construct a prost_types::Any directly from a raw ClientState
• the raw ClientState has not type checks, so we can enforce zero trust_level
• enables the upgrade-chain tx to succeed

The drawback of this solution is that it's partial: the upgrade client(s) CLIs still don't work, because they required reading and decoding the client state from the upgraded chain, and this state includes the zero value, which cannot be decoded.

hermes upgrade client ibc-1 07-tendermint-0
Jul 22 16:50:48.047 INFO [ibc-0 -> ibc-1:07-tendermint-0] upgrade Height: 0-2401
Jul 22 16:50:48.072 DEBUG [ibc-0 -> ibc-1:07-tendermint-0] MsgUpdateAnyClient from trusted height 0-231 to target height 0-2401
Error: failed while trying to upgrade client id 07-tendermint-0 hosted on chain id ibc-1 with error: failed while fetching from chain ibc-0 the upgraded client state: GRPC error: invalid raw client state: error converting message type into domain type: invalid client state trust threshold: trust threshold is too large (must be <= 1)

Two possible long-term solution:

• modify the tm-rs type TrustThresholdFraction to permit construction with zero field
• replicate the domain type TrustThresholdFraction in the relayer crate and handle its validation there, permitting construction with zero fields

As a short term solution, for 0.6.1, we are explicitly disabling the upgrade-chain and upgrade client functionality.

More details on the underlying problem

A successful governance proposal would have a zero trust level:

gaiad query gov proposal 1 --home data/ibc-0/
...
trust_level:
denominator: "0"
numerator: "0"

Using the changes from a0d9d4b, the chain accepts the upgrade proposal, but the upgraded trust level is not zero:

gaiad query gov proposal 1 --node http://127.0.0.1:26557
...
trust_level:
denominator: "3"
numerator: "1"

The trust_level field, like all the other fields specified in the zero_custom_fields method, are custom and differ from client to client (these are chosen by the relayer when that client was created). Since these are client-specific field, the upgrading chain must set them to zero, and must only change those fields that are chain-specific (chain id, unbonding period).

After discussing with @colin-axner, here are further details:

• the x/gov module stores the governance proposal, so when we query for it, we see the 1/3 trust level details
• the client state gets zeroed out when the chain stores it to the ibc store keeper, so effectively the stored trust level (and its proof) are for 0/0 trust level
• it seems that the on-chain handler for MsgUpgradeClient does not zero out the submitted client state, so if a relayer submits a client state with 1/3, the proof won't pass
• the upgrade client CLI subsequently fails with an error specifying that proof verification failed, log here.

Version

3c383cf

Acceptance Criteria

• re-enable upgrade-chain and upgrade client CLIs

---

For Admin Use

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