Skip to main content
It is possible to update the client with the state of the substitute client through a governance proposal. This type of governance proposal is typically used to recover an expired or frozen client, as it can recover the entire state and therefore all existing channels built on top of the client. CheckSubstituteAndUpdateState should be implemented to handle the proposal.

​
Implementing CheckSubstituteAndUpdateState

In the ClientStateinterface, we find: 
/ CheckSubstituteAndUpdateState must verify that the provided substitute may be used to update the subject client.
/ The light client must set the updated client and consensus states within the clientStore for the subject client.
CheckSubstituteAndUpdateState(
  ctx sdk.Context, 
  cdc codec.BinaryCodec, 
  subjectClientStore, 
  substituteClientStore sdk.KVStore, 
  substituteClient ClientState)

error
Prior to updating, this function must verify that:
  • the substitute client is the same type as the subject client. For a reference implementation, please see the Tendermint light client.
  • the provided substitute may be used to update the subject client. This may mean that certain parameters must remain unaltered. For example, a valid substitute Tendermint light client must NOT change the chain ID, trust level, max clock drift, unbonding period, proof specs or upgrade path. Please note that AllowUpdateAfterMisbehaviour and AllowUpdateAfterExpiry have been deprecated (see ADR 026 for more information).
After these checks are performed, the function must set the updated client and consensus states within the client store for the subject client. Please refer to the Tendermint light client implementation for reference.