了解代理轻客户端与 Wasm 轻客户端之间的区别。

​
代理轻客户端

08-wasm 模块并不是常规意义上的轻客户端，例如 07-tendermint 轻客户端。相反，08-wasm 是一个_代理_轻客户端模块，这意味着该模块充当实际轻客户端实现的代理。该模块会作为实际轻客户端的包装器，这些轻客户端以上传的 Wasm 字节码形式存在，并将所有操作委托给它们执行（也就是说，08-wasm 只是将请求透传给 Wasm 轻客户端）。尽管如此，08-wasm 模块实现了与 IBC 核心集成所需的全部接口，因此 02-client 可以像调用其他轻客户端模块一样调用它。这些接口包括 LightClientModule、ClientState、ConsensusState 和 ClientMessage，我们将在后续章节中结合 08-wasm 进行说明。有关这一组接口的更多信息，请参阅轻客户端模块开发者指南概览章节。

​
LightClientModule

08-wasm 的 LightClientModule 数据结构包含两个字段：
  • keeper 是 08-wasm 模块的 keeper。
  • storeProvider 封装了 IBC 核心存储键，并为每个客户端提供独立的前缀存储访问能力，以便它们能够在各自隔离的命名空间中进行读写。
type LightClientModule struct {
    keeper        wasmkeeper.Keeper
  storeProvider exported.ClientStoreProvider
}
有关 LightClientModule 接口的更多信息，请参阅轻客户端模块开发者指南中的 LightClientModule 章节。

​
ClientState

08-wasm 的 ClientState 数据结构包含三个字段：
  • Data 包含底层轻客户端状态的 Protobuf 编码字节，该底层轻客户端以 Wasm 合约形式实现。例如，如果 Wasm 轻客户端合约实现的是 GRANDPA 轻客户端算法，那么 Data 将包含 GRANDPA client state 的字节。
  • Checksum 是 Wasm 合约字节码的 sha256 哈希。该哈希用作标识符，以便调用正确的合约。
  • LatestHeight 是对手方状态机的最新高度（即区块链高度），该轻客户端跟踪的正是其共识状态。
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
}
有关 ClientState 接口的更多信息，请参阅轻客户端模块开发者指南中的 ClientState 章节。

​
ConsensusState

08-wasm 的 ConsensusState 数据结构包含一个字段：
  • Data 包含底层轻客户端共识状态的 Protobuf 编码字节，该底层轻客户端以 Wasm 合约形式实现。例如，如果 Wasm 轻客户端合约实现的是 GRANDPA 轻客户端算法，那么 Data 将包含 GRANDPA consensus state 的字节。
type ConsensusState struct {
  / bytes encoding the consensus state of the underlying light client
  / implemented as a Wasm contract.
  Data []byte
}
有关 ConsensusState 接口的更多信息，请参阅轻客户端模块开发者指南中的 ConsensusState 章节。

​
ClientMessage

ClientMessage 用于更新链上存储的 ClientState。08-wasm 的 ClientMessage 数据结构包含一个字段：
  • Data 包含底层轻客户端的 Protobuf 编码字节，这些字节表示 header 或 misbehaviour，该底层轻客户端以 Wasm 合约形式实现。例如，如果 Wasm 轻客户端合约实现的是 GRANDPA 轻客户端算法，那么 Data 将包含 GRANDPA 轻客户端的 header 或 misbehaviour 的字节。
type ClientMessage struct {
  / bytes encoding the header(s)

or misbehaviour for the underlying light client
  / implemented as a Wasm contract.
  Data []byte
}
有关 ClientMessage 接口的更多信息，请参阅轻客户端模块开发者指南中的 ClientMessage 章节。

​
Wasm 轻客户端

实际的轻客户端可以使用任何能够编译为 Wasm 且实现 CosmWasm 合约接口的语言来编写。尽管理论上可以使用其他语言，但在实践中（至少目前如此），最适合的语言是 Rust，因为它已经具备良好的 CosmWasm 智能合约开发支持。 在撰写本文时，已有两个可用合约：一个用于 Tendermint，另一个用于 GRANDPA（已在 Composable Finance 的 Centauri bridge 中投入生产使用）。此外，还有其他实现正在开发中（例如 Near）。
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 LightClientModule, 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.

​
LightClientModule

The 08-wasm’s LightClientModule data structure contains two fields:
  • keeper is the 08-wasm module keeper.
  • storeProvider encapsulates the IBC core store key and provides access to isolated prefix stores for each client so they can read/write in separate namespaces.
type LightClientModule struct {
    keeper        wasmkeeper.Keeper
  storeProvider exported.ClientStoreProvider
}
See section LightClientModule of the light client module developer guide for more information about the LightClientModule interface.

​
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, then Data 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, then Data 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, then Data 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).