The client which is used on the settlement hub for a rollup chain is 01-dymint.
Following #13, the 01-dymint client doesn't check the consensus validity and assumes this check is done by the application logic.
The settlement hub holds the state of all the rollup chains and could verify whether a state was finalized.
Requirement
When the settlement receives a transaction that ends by updating the rollup state, we need to check that the state as reported in the transaction is actually the state as the settlement layer knows (that is instead of the consensus verification a light-client does in case of regular tendermint chain).
The problem is that light-client doesn't have access to the settlement module keepers to verify it.
Changes
Provide an interface for every 02-client method (as specified in ICS-02). The hook (if not empty) must be the first to be executed.
Initialize hooks
The hooks can be implemented in the application module and pass in the IBC keeper initialization
// ClientHooks defines an interface that implements callbacks
// for the client module methods as specified in ICS-02.
// First the callback is called and if no error, proceed to
// the method functionality
type ClientHooks interface {
OnCreateClient(
ctx sdk.Context,
clientState ClientState,
consensusState ConsensusState,
) error
OnUpdateClient(
ctx sdk.Context,
clientID string,
header Header,
) error
OnUpgradeClient(
ctx sdk.Context,
clientID string,
upgradedClient ClientState,
upgradedConsState ConsensusState,
proofUpgradeClient,
proofUpgradeConsState []byte,
) error
OnCheckMisbehaviourAndUpdateState(
ctx sdk.Context,
misbehaviour Misbehaviour,
) error
}
Overview
The client which is used on the settlement hub for a rollup chain is 01-dymint. Following #13, the 01-dymint client doesn't check the consensus validity and assumes this check is done by the application logic. The settlement hub holds the state of all the rollup chains and could verify whether a state was finalized.
Requirement
When the settlement receives a transaction that ends by updating the rollup state, we need to check that the state as reported in the transaction is actually the state as the settlement layer knows (that is instead of the consensus verification a light-client does in case of regular tendermint chain). The problem is that light-client doesn't have access to the settlement module keepers to verify it.
Changes
Provide an interface for every 02-client method (as specified in ICS-02). The hook (if not empty) must be the first to be executed.
Initialize hooks
The hooks can be implemented in the application module and pass in the IBC keeper initialization
Using 02-client hooks
Change
CreateClient()
example: