概述
简介
了解09-localhost 轻客户端模块。
09-localhost 轻客户端模块实现了一个无状态的 localhost 环回客户端,能够在同一个状态机内发送和接收 IBC 数据包。
背景
在多链环境中,应用开发者通常会通过 IBC 开发跨链应用。从他们的视角来看,无论交互对象是同一条链上的多个模块,还是不同链上的模块,都不应有差别。localhost 客户端模块通过开发者熟悉的 IBC 应用层语义,为单链上的不同应用交互提供了统一接口。实现
存在一个 localhost 轻客户端模块,可通过客户端标识符09-localhost 调用。该轻客户端是无状态的,因此 ClientState 会在需要时按需构造。
作为补充,一个哨兵 ConnectionEnd 会存储在 core IBC 状态中,其连接标识符为 connection-localhost。这使得 IBC 应用可以直接在这个哨兵连接之上创建通道,从而利用 09-localhost 的环回能力。
在握手过程中或处理数据包时,对通道状态进行的状态验证复杂度会降低,因为 09-localhost 客户端只需比较标准化键路径下存储的字节即可。
Localhost 与_常规_客户端的区别
localhost 客户端的目标,是像 IBC 应用层支持跨链交互那样,为单链上的应用交互提供一种统一方式。不过,为了实现这一统一接口,其底层实现与“常规” IBC 客户端存在一些差异(不包括06-solomachine 和 09-localhost 本身)。
下表列出了一些重要差异:
| 常规客户端 | Localhost | |
|---|---|---|
| 客户端数量 | 同一客户端_类型_会有多个实例,分别对应不同对手方 | 只有一个哨兵客户端,客户端标识符为 09-localhost |
| 客户端创建 | 由 Relayer 创建(无权限限制) | 由 core IBC 中的 02-client 子模块隐式提供 |
| 客户端更新 | Relayer 使用 MsgUpdateClient 提交头信息 | 不需要客户端更新,因为 localhost 实现是无状态的 |
| 连接数量 | 存在多个连接,每个客户端对应 1 个(或多个)连接 | 只有一个哨兵连接,连接标识符为 connection-localhost |
| 连接创建 | 通过连接握手创建,并依赖底层客户端 | 哨兵 ConnectionEnd 在 core IBC 的 03-connection 子模块的 InitGenesis 处理器中创建并写入存储 |
| 对手方 | 底层客户端,表示另一条链 | 同一条链上标识符为 09-localhost 的客户端 |
VerifyMembership 和 VerifyNonMembership | 使用共识状态根执行证明验证 | 通过 core IBC 存储中的键值查找执行状态验证 |
ClientState 存储 | ClientState 会被存储,并且可通过 VerifyMembership 直接证明 | 由于是无状态的,因此 ClientState 无法通过 VerifyMembership 直接证明 |
Overview
Synopsis
Learn about the 09-localhost light client module. The 09-localhost light client module implements a stateless localhost loopback client with the ability to send and receive IBC packets to and from the same state machine.Context
In a multichain environment, application developers will be used to developing cross-chain applications through IBC. From their point of view, whether or not they are interacting with multiple modules on the same chain or on different chains should not matter. The localhost client module enables a unified interface to interact with different applications on a single chain, using the familiar IBC application layer semantics.Implementation
There exists a localhost light client module which can be invoked with the client identifier09-localhost. The light
client is stateless, so the ClientState is constructed on demand when required.
To supplement this, a sentinel ConnectionEnd is stored in core IBC state with the connection
identifier connection-localhost. This enables IBC applications to create channels directly on top of the sentinel
connection which leverage the 09-localhost loopback functionality.
State verification for channel state in handshakes or processing packets is reduced in
complexity, the 09-localhost client can simply compare bytes stored under the standardized key paths.
Localhost vs regular client
The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of differences under the hood compared to a ‘regular’ IBC client (excluding06-solomachine and 09-localhost itself).
The table below lists some important differences:
| Regular client | Localhost | |
|---|---|---|
| Number of clients | Many instances of a client type corresponding to different counterparties | A single sentinel client with the client identifier 09-localhost |
| Client creation | Relayer (permissionless) | Implicitly made available by the 02-client submodule in core IBC |
| Client updates | Relayer submits headers using MsgUpdateClient | No client updates are required as the localhost implementation is stateless |
| Number of connections | Many connections, 1 (or more) per client | A single sentinel connection with the connection identifier connection-localhost |
| Connection creation | Connection handshake, provided underlying client | Sentinel ConnectionEnd is created and set in store in the InitGenesis handler of the 03-connection submodule in core IBC |
| Counterparty | Underlying client, representing another chain | Client with identifier 09-localhost in same chain |
VerifyMembership and VerifyNonMembership | Performs proof verification using consensus state roots | Performs state verification using key-value lookups in the core IBC store |
ClientState storage | ClientState stored and directly provable with VerifyMembership | Stateless, so ClientState is not provable directly with VerifyMembership |