Adjust governance unfreezing of IBC clients to use a substitute to update from

[colin-axner]

Summary

IBC currently supports a mechanism to unfreeze a client via a governance proposal. The requirements for a successful unfreezing are subtle but strict. We currently have to deal with 2 requirements.

1. Unfreezing after misbehaviour requires the evidence used to freeze the client to be expired by the time the voting period ends, otherwise the client could be trivially refrozen
2. A client can only be unfrozen if the trusting period > voting period otherwise the client will be expired after the vote passes.

I'm worried about the usability of the second requirement.

Problem Definition

Requiring trusting period and voting period to be compatible is problematic since they each depend on configurations set by different chains. Chain A could change its voting period at any time, and the trusting period chosen depends on the unbonding period set by Chain B. The trusting period shouldn't change, but if Chain A increased its voting period, this could render a client unrecoverable.

The initial intention of this feature was to allow governance to easily unfreeze any client which sets AllowUnfreezeAfter... to true. This was to mimic a manual unfreezing where the chain does an upgrade and unfreeze the client during migration. This is not met because of the above 2 requirements.

Proposal

Modify the governance proposal to take in a client identifier instead of a header. The client identifier must link to a client with the exact same base parameters (chain-id, unbonding period, trusting period, etc). This client will be used as a substitute while the frozen client is on trial. The substitute can be continually updated to avoid being expired. If the vote succeeds, the frozen client would be unfrozen, its latest height updated to that of the substitute and the consensus states of the substitute copied over. The substitute can then be optionally frozen. I'm unsure of the desired behaviour here.

The UI for this interaction is pretty good. If a proposal is in the works to unfreeze a client. The proposer should create a new client with the initial header they would have used in the old method. Then they should maintain this client to avoid it being expired. Then governance would vote on an existing client, not on a header which can be hard to verify for the average user.

If this proposal is accepted it would be implemented in two phases.
phase 1: update/modify the existing ADR for this feature to reflect the above proposal
phase 2: implement the ADR changes

I would begin this work in January, aim to include it in IBC 1.0.1 and before transfer are enabled.

---

For Admin Use

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

[zmanian]

This is subtle and a good catch. I like it a lot.