Concepts
Learn about the differences between a proxy light client and a Wasm light client.
Proxy light client
The 08-wasm
module is not a regular light client in the same sense as, for example, the 07-tendermint light client. 08-wasm
is instead a proxy light client module, and this means that the module acts a proxy to the actual implementations of light clients. The module will act as a wrapper for the actual light clients uploaded as Wasm byte code and will delegate all operations to them (i.e. 08-wasm
just passes through the requests to the Wasm light clients). Still, the 08-wasm
module implements all the required interfaces necessary to integrate with core IBC, so that 02-client can call into it as it would for any other light client module. These interfaces are ClientState
, ConsensusState
and ClientMessage
, and we will describe them in the context of 08-wasm
in the following sections. For more information about this set of interfaces, please read section Overview of the light client module developer guide.
ClientState
The 08-wasm
's ClientState
data structure contains three fields:
Data
contains the bytes of the Protobuf-encoded client state of the underlying light client implemented as a Wasm contract. For example, if the Wasm light client contract implements the GRANDPA light client algorithm, thenData
will contain the bytes for a GRANDPA client state.Checksum
is the sha256 hash of the Wasm contract's byte code. This hash is used as an identifier to call the right contract.LatestHeight
is the latest height of the counterparty state machine (i.e. the height of the blockchain), whose consensus state the light client tracks.
type ClientState struct {
// bytes encoding the client state of the underlying
// light client implemented as a Wasm contract
Data []byte
// sha256 hash of Wasm contract byte code
Checksum []byte
// latest height of the counterparty ledger
LatestHeight types.Height
}
See section ClientState
of the light client module developer guide for more information about the ClientState
interface.
ConsensusState
The 08-wasm
's ConsensusState
data structure maintains one field:
Data
contains the bytes of the Protobuf-encoded consensus state of the underlying light client implemented as a Wasm contract. For example, if the Wasm light client contract implements the GRANDPA light client algorithm, thenData
will contain the bytes for a GRANDPA consensus state.
type ConsensusState struct {
// bytes encoding the consensus state of the underlying light client
// implemented as a Wasm contract.
Data []byte
}
See section ConsensusState
of the light client module developer guide for more information about the ConsensusState
interface.
ClientMessage
ClientMessage
is used for performing updates to a ClientState
stored on chain. The 08-wasm
's ClientMessage
data structure maintains one field:
Data
contains the bytes of the Protobuf-encoded header(s) or misbehaviour for the underlying light client implemented as a Wasm contract. For example, if the Wasm light client contract implements the GRANDPA light client algorithm, thenData
will contain the bytes of either header or misbehaviour for a GRANDPA light client.
type ClientMessage struct {
// bytes encoding the header(s) or misbehaviour for the underlying light client
// implemented as a Wasm contract.
Data []byte
}
See section ClientMessage
of the light client module developer guide for more information about the ClientMessage
interface.
Wasm light client
The actual light client can be implemented in any language that compiles to Wasm and implements the interfaces of a CosmWasm contract. Even though in theory other languages could be used, in practice (at least for the time being) the most suitable language to use would be Rust, since there is already good support for it for developing CosmWasm smart contracts.
At the moment of writing there are two contracts available: one for Tendermint and one GRANDPA (which is being used in production in Composable Finance's Centauri bridge). And there are others in development (e.g. for Near).