You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* (modules/core/keeper) [\#1284](https://github.com/cosmos/ibc-go/pull/1284) Add sanity check for the keepers passed into `ibckeeper.NewKeeper`. `ibckeeper.NewKeeper` now panics if any of the keepers passed in is empty.
53
53
* (transfer) [\#1414](https://github.com/cosmos/ibc-go/pull/1414) Emitting Sender address from `fungible_token_packet` events in `OnRecvPacket` and `OnAcknowledgementPacket`.
54
54
* (modules/core/04-channel) [\#1464](https://github.com/cosmos/ibc-go/pull/1464) Emit a channel close event when an ordered channel is closed.
55
+
* (modules/light-clients/07-tendermint) [\#1118](https://github.com/cosmos/ibc-go/pull/1118) Deprecating `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehaviour`. See ADR-026 for context.
Copy file name to clipboardexpand all lines: docs/architecture/adr-026-ibc-client-recovery-mechanisms.md
+6-7
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,7 @@
6
6
- 2020/08/06: Revisions per review & to reference version
7
7
- 2021/01/15: Revision to support substitute clients for unfreezing
8
8
- 2021/05/20: Revision to simplify consensus state copying, remove initial height
9
+
- 2022/04/08: Revision to deprecate AllowUpdateAfterExpiry and AllowUpdateAfterMisbehaviour
9
10
10
11
## Status
11
12
@@ -35,21 +36,20 @@ Two-thirds of the validator set (the quorum for governance, module participation
35
36
We elect not to deal with chains which have actually halted, which is necessarily Byzantine behaviour and in which case token recovery is not likely possible anyways (in-flight packets cannot be timed-out, but the relative impact of that is minor).
36
37
37
38
1. Require Tendermint light clients (ICS 07) to be created with the following additional flags
1.`allow_update_after_expiry` (boolean, default true). Note that this flag has been deprecated, it remains to signal intent but checks against this value will not be enforced.
39
40
1. Require Tendermint light clients (ICS 07) to expose the following additional internal query functions
40
41
1.`Expired() boolean`, which returns whether or not the client has passed the trusting period since the last update (in which case no headers can be validated)
41
42
1. Require Tendermint light clients (ICS 07) & solo machine clients (ICS 06) to be created with the following additional flags
1.`allow_update_after_misbehaviour` (boolean, default true). Note that this flag has been deprecated, it remains to signal intent but checks against this value will not be enforced.
43
44
1. Require Tendermint light clients (ICS 07) to expose the following additional state mutation functions
44
45
1.`Unfreeze()`, which unfreezes a light client after misbehaviour and clears any frozen height previously set
45
46
1. Add a new governance proposal type, `ClientUpdateProposal`, in the `x/ibc` module
46
47
1. Extend the base `Proposal` with two client identifiers (`string`).
47
48
1. The first client identifier is the proposed client to be updated. This client must be either frozen or expired.
48
49
1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identitical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period.
49
-
1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute, if and only if:
50
-
1.`allow_governance_override_after_expiry` is true and the client has expired (`Expired()` returns true)
51
-
1.`allow_governance_override_after_misbehaviour` is true and the client has been frozen (`Frozen()` returns true)
52
-
1. In this case, additionally, the client is unfrozen by calling `Unfreeze()`
50
+
1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute.
51
+
52
+
Previously, `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehaviour` were used to signal the recovery options for an expired or frozen client, and governance proposals were not allowed to overwrite the client if these parameters were set to false. However, this has now been deprecated because a code migration can overwrite the client and consensus states regardless of the value of these parameters. If governance would vote to overwrite a client or consensus state, it is likely that governance would also be willing to perform a code migration to do the same.
53
53
54
54
55
55
Note that clients frozen due to misbehaviour must wait for the evidence to expire to avoid becoming refrozen.
@@ -62,7 +62,6 @@ This ADR does not address planned upgrades, which are handled separately as per
62
62
63
63
- Establishes a mechanism for client recovery in the case of expiry
64
64
- Establishes a mechanism for client recovery in the case of misbehaviour
65
-
- Clients can elect to disallow this recovery mechanism if they do not wish to allow for it
66
65
- Constructing an ClientUpdate Proposal is as difficult as creating a new client
Copy file name to clipboardexpand all lines: docs/ibc/proposals.md
+1-2
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,6 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](.
46
46
47
47
### Preconditions
48
48
- The chain is updated with ibc-go >= v1.1.0.
49
-
- 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.
50
49
- The client identifier of an active client for the same counterparty chain.
51
50
- The governance deposit.
52
51
@@ -67,7 +66,7 @@ Check if the client is attached to the expected `chain-id`. For example, for an
67
66
}
68
67
```
69
68
70
-
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`.
69
+
The client is attached to the expected Akash `chain-id`. Note that although the parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) exist to signal intent, these parameters have been deprecated and will not enforce any checks on the revival of client. See ADR-026 for more context on this deprecation.
Copy file name to clipboardexpand all lines: docs/ibc/proto-docs.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -4023,8 +4023,8 @@ and a possible frozen height.
4023
4023
|`latest_height`|[ibc.core.client.v1.Height](#ibc.core.client.v1.Height)|| Latest height the client was updated to |
4024
4024
|`proof_specs`|[ics23.ProofSpec](#ics23.ProofSpec)| repeated | Proof specifications used in verifying counterparty state |
4025
4025
|`upgrade_path`|[string](#string)| repeated | Path at which next upgraded client will be committed. Each element corresponds to the key for a single CommitmentProof in the chained proof. NOTE: ClientState must stored under `{upgradePath}/{upgradeHeight}/clientState` ConsensusState must be stored under `{upgradepath}/{upgradeHeight}/consensusState` For SDK chains using the default upgrade module, upgrade_path should be []string{"upgrade", "upgradedIBCState"}` |
4026
-
|`allow_update_after_expiry`|[bool](#bool)||This flag, when set to true, will allow governance to recover a client which has expired|
4027
-
|`allow_update_after_misbehaviour`|[bool](#bool)||This flag, when set to true, will allow governance to unfreeze a client whose chain has experienced a misbehaviour event|
4026
+
|`allow_update_after_expiry`|[bool](#bool)||**Deprecated.** allow_update_after_expiry is deprecated|
4027
+
|`allow_update_after_misbehaviour`|[bool](#bool)||**Deprecated.** allow_update_after_misbehaviour is deprecated|
0 commit comments