Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add steps to revive expired client with governance proposal #438

Merged
merged 5 commits into from
Oct 4, 2021
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions docs/ibc/proposals.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,3 +39,48 @@ The substitute client is used as a "stand in" while the subject is on trial. It
a substitute client *after* the subject has become frozen to avoid the substitute from also becoming frozen.
An active substitute client allows headers to be submitted during the voting period to prevent accidental expiry
once the proposal passes.

# How to recover an expired client with a governance proposal

See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](../architecture/adr-026-ibc-client-recovery-mechanisms.md)

### Preconditions
- The chain is updated with ibc-go >= v1.1.0.
- Recovery parameters are set to `true` for the Tendermint light client (this determines if a governance proposal can be used). If the recovery parameters are set to `false`, recovery will require custom migration code.
- The client identifier of an active client for the same connection.
crodriguezvega marked this conversation as resolved.
Show resolved Hide resolved
- The governance deposit.

## Steps

### Step 1

Check if the client is attached to the expected `chain-id`. For example, for an expired Tendermint client representing the Akash chain the client state looks like this on querying the client state:
```
{
client_id: 07-tendermint-146
client_state:
'@type': /ibc.lightclients.tendermint.v1.ClientState
allow_update_after_expiry: true
allow_update_after_misbehaviour: true
chain_id: akashnet-2
}
```
The client is attached to the expected Akash `chain-id` and the recovery parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) are set to `true`.

### Step 2

If the chain has been updated to ibc-go >= v1.1.0, anyone can submit the governance proposal to recover the client by executing this via cli:

```
<binary> tx gov submit-proposal update-client <client_id> <active-counterparty-client in connection>
crodriguezvega marked this conversation as resolved.
Show resolved Hide resolved
```

The `<active-counterparty-client in connection>` should be a client identifier on the same chain as the expired or frozen client. This client identifier should connect to the same chain as the expired or frozen client. This means: whichever recommended/relayed channel is used right now could be reused to update the client.
crodriguezvega marked this conversation as resolved.
Show resolved Hide resolved
crodriguezvega marked this conversation as resolved.
Show resolved Hide resolved

After this, it is just a question of who funds the governance deposit and if the chain in question votes yes.

## Important considerations

Please note that v1.0.0 of ibc-go will not allow transactions to go to expired clients anymore, so please update to at least this version to prevent similar issues in the future.
crodriguezvega marked this conversation as resolved.
Show resolved Hide resolved

Please also note that if the client on the other end of the transaction is also expired, that client will also need to update. This process updates only one client.