From 0142477bc86b65c90833c293c58e1e88bc5c9b77 Mon Sep 17 00:00:00 2001 From: Carlos Rodriguez Date: Fri, 24 Sep 2021 12:52:13 +0200 Subject: [PATCH 1/4] docs: add steps to revive expired client with governance proposal --- docs/ibc/proposals.md | 45 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/docs/ibc/proposals.md b/docs/ibc/proposals.md index b3ce139c2a0..2c2ee6a0e78 100644 --- a/docs/ibc/proposals.md +++ b/docs/ibc/proposals.md @@ -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 revive 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 modifying the migration code. In this case the easiest thing to do is probably just to mint back the tokens during migration in the next hub upgrade. +- The client identifier of an active client for the same connection. +- The governance deposit. + +## Steps + +### Step 1 + +Check if the client is attached to the expected `chain-id`. For example, for an expired Tendermint client on 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: + +``` + tx gov submit-proposal update-client +``` + +The `` should be the client identifier of a currently active client which is relaying from the chain containing the expired client you are trying to revive. This means: whichever recommended/relayed channel is used right now could be reused to update the client. + +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. + +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. \ No newline at end of file From 2890f4e9ed994da3f5f25ee3bb965b82680c8ae2 Mon Sep 17 00:00:00 2001 From: Carlos Rodriguez Date: Mon, 27 Sep 2021 09:42:20 +0200 Subject: [PATCH 2/4] address review comments --- docs/ibc/proposals.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/ibc/proposals.md b/docs/ibc/proposals.md index 2c2ee6a0e78..11e1fb20c08 100644 --- a/docs/ibc/proposals.md +++ b/docs/ibc/proposals.md @@ -40,13 +40,13 @@ a substitute client *after* the subject has become frozen to avoid the substitut An active substitute client allows headers to be submitted during the voting period to prevent accidental expiry once the proposal passes. -# How to revive an expired client with a governance proposal +# 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 modifying the migration code. In this case the easiest thing to do is probably just to mint back the tokens during migration in the next hub upgrade. +- 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. - The governance deposit. @@ -54,7 +54,7 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](. ### Step 1 -Check if the client is attached to the expected `chain-id`. For example, for an expired Tendermint client on the Akash chain the client state looks like this on querying the client state: +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 @@ -75,7 +75,7 @@ If the chain has been updated to ibc-go >= v1.1.0, anyone can submit the governa tx gov submit-proposal update-client ``` -The `` should be the client identifier of a currently active client which is relaying from the chain containing the expired client you are trying to revive. This means: whichever recommended/relayed channel is used right now could be reused to update the client. +The `` 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. After this, it is just a question of who funds the governance deposit and if the chain in question votes yes. From 4b470229340a4bfedd7d6acc4c5c752be30b227d Mon Sep 17 00:00:00 2001 From: Carlos Rodriguez Date: Tue, 28 Sep 2021 09:07:55 +0200 Subject: [PATCH 3/4] address more review comments --- docs/ibc/proposals.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/ibc/proposals.md b/docs/ibc/proposals.md index 11e1fb20c08..5d65be6f377 100644 --- a/docs/ibc/proposals.md +++ b/docs/ibc/proposals.md @@ -47,7 +47,7 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](. ### 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. +- The client identifier of an active client for the same counterparty chain. - The governance deposit. ## Steps @@ -55,6 +55,7 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](. ### 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 @@ -65,6 +66,7 @@ Check if the client is attached to the expected `chain-id`. For example, for an 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 @@ -72,10 +74,10 @@ The client is attached to the expected Akash `chain-id` and the recovery paramet 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: ``` - tx gov submit-proposal update-client + tx gov submit-proposal update-client ``` -The `` 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. +The `` 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 actively used right now could be reused to update the client. After this, it is just a question of who funds the governance deposit and if the chain in question votes yes. From 533355162891025d315b5761fdff5ce5781c4508 Mon Sep 17 00:00:00 2001 From: Carlos Rodriguez Date: Thu, 30 Sep 2021 09:19:44 +0200 Subject: [PATCH 4/4] address more review comments --- docs/ibc/proposals.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/ibc/proposals.md b/docs/ibc/proposals.md index 5d65be6f377..c2cb34860b2 100644 --- a/docs/ibc/proposals.md +++ b/docs/ibc/proposals.md @@ -74,15 +74,15 @@ The client is attached to the expected Akash `chain-id` and the recovery paramet 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: ``` - tx gov submit-proposal update-client + tx gov submit-proposal update-client ``` -The `` 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 actively used right now could be reused to update the client. +The `` 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: use the active client that is currently being used to relay packets between the two chains as the replacement client. 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. +Please note that from v1.0.0 of ibc-go it will not be allowed for transactions to go to expired clients anymore, so please update to at least this version to prevent similar issues in the future. 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. \ No newline at end of file