概要
了解如何构建 IBC 轻客户端模块，并实现与 IBC 核心集成所需的接口。 IBC 使用轻客户端，在主权区块链之间提供尽可能减少信任依赖的互操作性。轻客户端依据一组严格规则运行，这些规则为状态更新提供安全保证，并支持通过 merkle 证明验证远程区块链状态。 以下内容旨在提供一份 IBC 轻客户端模块开发者指南的高层概览。对 IBC 轻客户端的访问由核心 IBCMsgServer 控制，它使用 02-client 子模块提供的抽象来调用轻客户端模块。轻客户端模块开发者只需要实现 ibc-go 中 modules/core/exported 包定义的一组接口。
轻客户端模块开发者应重点关注三个主要接口：
LightClientModule用于管理某一类型的多个轻客户端实例的模块。ClientState封装轻客户端实现及其语义。ConsensusState跟踪用于验证客户端更新、检测误行为以及验证对手链状态证明的共识数据。ClientMessage用于提交客户端更新所需的区块头，以及通过冲突区块头提交误行为证据。
07-tendermint 轻客户端模块可能会作为参考示例被提及。
概念与术语
LightClientModule
LightClientModule 是由 IBC 核心定义的一个接口，用于支持模块化的轻客户端实现。所有轻客户端实现都 必须 实现 LightClientModule interface，以便 IBC 核心能够将调用转发到轻客户端模块。
例如，一个轻客户端模块可能需要：
- 创建客户端
- 更新客户端
- 恢复和升级客户端
- 验证成员关系与非成员关系
LightClientModule 部分中更细粒度地说明。
更多信息请参阅 07-tendermint 的 LightClientModule definition。
ClientState
ClientState 用于定义封装不透明轻客户端状态的数据结构。ClientState 包含验证 ClientMessage 以及对对手链状态执行成员关系和非成员关系证明验证所需的全部信息。这包括与远程状态机、轻客户端类型以及具体轻客户端实例相关的属性。
例如：
- 用于客户端更新的约束。
- 用于误行为检测的约束。
- 用于状态验证的约束。
- 用于客户端升级的约束。
ClientState 类型 必须 实现 core/modules/exported/client.go 中定义的 ClientState 接口。
该接口包含的方法将在本指南的 ClientState 部分中更细粒度地说明。
更多信息请参阅 07-tendermint 轻客户端模块的 ClientState definition，其中包含链 ID、状态、最新高度、解绑期和证明规范等信息。
ConsensusState
ConsensusState 用于定义封装某一特定时间点共识数据的数据结构，也就是状态机的唯一高度或序列号。每个高度都必须存在一个受信任的 ConsensusState。ConsensusState 通常包含可信根、验证者集合信息和时间戳。
例如，07-tendermint 轻客户端模块的 ConsensusState 定义了一个可信根，ClientState 使用它来验证成员关系和非成员关系承诺证明；同时它还包含下一个验证者集合哈希，用于验证客户端更新中的区块头是否可信。
轻客户端模块中维护的 ConsensusState 类型 必须 实现 modules/core/exported/client.go 中定义的 ConsensusState 接口。
该接口包含的方法将在本指南的 ConsensusState 部分中更细粒度地说明。
Height
Height 定义了一个单调递增的序列号，用于为通过客户端更新持久化的共识状态数据提供顺序。
IBC 轻客户端模块开发者应使用 02-client 子模块提供的具体类型。该类型实现了 modules/core/exported/client.go 中定义的 Height 接口所要求的行为。
ClientMessage
ClientMessage 指的是用于对链上存储的 ClientState 执行更新的接口类型 ClientMessage。
它可以是任何一种具体类型，只要在通过验证后会导致 IBC 客户端状态发生变化。
以下情况被视为有效的更新场景：
- 一个区块头，在验证通过后会在唯一高度插入一个新的
ConsensusState。 - 一批区块头，在验证通过后会为
N个唯一高度插入N个ConsensusState实例。 - 由两个冲突区块头提供的误行为证据。
Synopsis
Learn how to build IBC light client modules and fulfill the interfaces required to integrate with core IBC.Pre-requisite readings
MsgServer which utilizes the abstractions set by the 02-client submodule to call into a light client module. A light client module developer is only required to implement a set of interfaces as defined in the modules/core/exported package of ibc-go.
A light client module developer should be concerned with three main interfaces:
LightClientModulea module which manages many light client instances of a certain type.ClientStateencapsulates the light client implementation and its semantics.ConsensusStatetracks consensus data used for verification of client updates, misbehaviour detection and proof verification of counterparty state.ClientMessageused for submitting block headers for client updates and submission of misbehaviour evidence using conflicting headers.
07-tendermint light client module may be referred to as a reference example.
Concepts and vocabulary
LightClientModule
LightClientModule is an interface defined by core IBC which allows for modular light client implementations. All light client implementations must implement the LightClientModule interface so that core IBC may redirect calls to the light client module.
For example a light client module may need to:
- create clients
- update clients
- recover and upgrade clients
- verify membership and non-membership
LightClientModule section of this guide.
Please refer to the 07-tendermint’s LightClientModule definition for more information.
ClientState
ClientState is a term used to define the data structure which encapsulates opaque light client state. The ClientState contains all the information needed to verify a ClientMessage and perform membership and non-membership proof verification of counterparty state. This includes properties that refer to the remote state machine, the light client type and the specific light client instance.
For example:
- Constraints used for client updates.
- Constraints used for misbehaviour detection.
- Constraints used for state verification.
- Constraints used for client upgrades.
ClientState type maintained within the light client module must implement the ClientState interface defined in core/modules/exported/client.go.
The methods which make up this interface are detailed at a more granular level in the ClientState section of this guide.
Please refer to the 07-tendermint light client module’s ClientState definition containing information such as chain ID, status, latest height, unbonding period and proof specifications.
ConsensusState
ConsensusState is a term used to define the data structure which encapsulates consensus data at a particular point in time, i.e. a unique height or sequence number of a state machine. There must exist a single trusted ConsensusState for each height. ConsensusState generally contains a trusted root, validator set information and timestamp.
For example, the ConsensusState of the 07-tendermint light client module defines a trusted root which is used by the ClientState to perform verification of membership and non-membership commitment proofs, as well as the next validator set hash used for verifying headers can be trusted in client updates.
The ConsensusState type maintained within the light client module must implement the ConsensusState interface defined in modules/core/exported/client.go.
The methods which make up this interface are detailed at a more granular level in the ConsensusState section of this guide.
Height
Height defines a monotonically increasing sequence number which provides ordering of consensus state data persisted through client updates.
IBC light client module developers are expected to use the concrete type provided by the 02-client submodule. This implements the expectations required by the Height interface defined in modules/core/exported/client.go.
ClientMessage
ClientMessage refers to the interface type ClientMessage used for performing updates to a ClientState stored on chain.
This may be any concrete type which produces a change in state to the IBC client when verified.
The following are considered as valid update scenarios:
- A block header which when verified inserts a new
ConsensusStateat a unique height. - A batch of block headers which when verified inserts
NConsensusStateinstances forNunique heights. - Evidence of misbehaviour provided by two conflicting block headers.