什么是IBC

IBC是Inter-Blockchain Communication（跨链通信）的缩写。IBC是一个端到端的、面向连接的、有状态的协议，用于可靠、有序和认证的分布式账本上的模块之间的通信。

IBC协议采用分层设计，主要分为2层：

• IBC/TAO：TAO指的是：transport, authorization, organization，该协议处理分布式账本之间的数据之间的传输，认证，排序。

• IBC/APP：基于TAO构建的上层应用层，定义了从传输层发送过来的数据的处理方式，如可分割代币转移(ICS-20),NFT代币转移(ICS-721)，interchain accounts（链间账户 ICS-27)

实现IBC协议的大多数工作集中在TAO层，一旦TAO层实现，则很容易在TAO层之上实现不同的APP层协议。

和TCP/IP协议类似，IBC的特殊性在于它可以将应用层（application layer）从传输层和网络层（TAO, transport, authorization, organization）中剥离出来。这意味着IBC定义了数据是如何跨链被发送和接受的。不过它并没有明确具体的数据以及这些数据是如何组织的。这使得IBC从其他一些需要在应用层实现大量标准化的跨链解决方案中脱引而出。

下图展示了IBC工作流程：

上图中有三个关键点需要注意:

• 链之间依赖relayer通信，relayer相当于IBC协议中的物理层连接，relayer会扫描运行IBC协议的链，并负责向其他链报告最新的状态。

• 多个relayer可以为多个channel传输数据

• relayer使用每个链上的light client来交易发送过来的消息

IBC/TAO 网络传输层

IBC/TAO层的主要作用为：在两链之间以reliable，ordered and authenticated方式传递数据包。

• reliable：是指源链仅发送一个packet，目标链仅接收一次，二者无需信任任何第三方。

• ordered：是指目标链接收packet的顺序与源链发送packet的顺序一致。

• authenticated：每个channel分配给特定这智能合约，只有分配到channel的智能合约可以通过这个channel发送packet，任何其他智能合约无法使用该channel发送packet。

IBC/TAO主要包含以下三个模块：

• 链上轻客户端（on-chain light client）

• 连接（connection）

• 通道（channel）

Light Client

轻客户端是 IBC/TAO的基础，轻客户端有一个为一个client ID作为标识，light client会追踪其他区块链的共识状态，并且会基于共识状态交易对方区块链发送过来数据的合法性。relayer只负责消息的传递，消息的合法性是依赖于轻客户端做验证，所以IBC的安全性并不依赖于第三方服务比如relayer。

Connection

有了light client 就可以在light client是建立connection，connection算是一个连接两个分布式账本的通道，一个light client可以接受任意数量的connection。

connection通过四次握手完成，所有操作都是由relayer发起交易来触发，A链发起连接到B链过程如下：

• connOpenInit：在A链上会创建并存储INIT状态。

• connOpenTry：B链若验证A链上该connection状态为INIT，则在B链上创建并存储TRYOPEN状态。

• connOpenAck：A链若验证B链上该connection状态为TRYOPEN，则将A链上该connection的状态由INIT更新为OPEN。

• connOpenConfirm：B链若验证A链上该connection状态已由INIT更新为OPEN，则将B链上该connection状态由TRYOPEN更新为OPEN。

Channel

connection和light client构成了IBC中传输层的主要组件。但是，IBC中的应用程序之间的通信是通过channel进行的，channel在应用程序模块与另一条链上的相应应用程序模块之间进行路由。这些应用程序由端口标识符命名，例如 ICS-20 token传输的transfer。

channel通过四次握手完成，所有操作都是由relayer发起交易来触发，A链发起连接到B链过程如下：

• chanOpenInit：在A链上会创建并存储INIT状态。

• chanOpenTry：B链若验证A链上该channel为INIT状态，则在B链上创建并存储TRYOPEN状态。

• chanOpenAck：A链若验证B链上该channel为TRYOPEN状态，则将A链上该channel的状态由INIT更新为OPEN。

• chanOpenConfirm：B链若验证A链上该channel状态已由INIT更新为OPEN，则将B链上该channel状态由TRYOPEN更新为OPEN。

IBC/APP 应用层

跨链转账

在IBC的技术上可以构建跨链token转移的应用，在token进行转移的时候最重要的是确定要转移的token是不是属于当前链，下面流程图展示了如何区分token是是否是属于当前链：

• 如果token是当前链的native token，那么当前链是token的源链

• 如果token是当前链通过channel从其他链接受的token，那么当前链不是token的源链，否者当前链是token的源链

区分当前链是否为token的源链就可以进行token转移了，因为token从源链到目标链，和token从目标链到源链的逻辑是不相同的。下图展示了两者的区别：

• token从目标链转移到目标链

  • 托管token

  • 目标链mint新的token

• token从目标链转移回源链

  • 目标链burn token

  • 源链释放托管的token

当token从一个链转到另一个链后，它的denom（token的标识符类似ethereum中的symbol）会产生变化，比如在Ethereum的跨链桥方案中，eth从Ethereum跨到bsc链上时就会变成eth.e或者其他的名称（和你使用的跨链桥有关，不同的桥跨链后的资产名称是不一样的）。那么在IBC方案中并没有中心化的桥提供服务，那么跨链后的资产名称如何命名？

如上图所示，链A（channel-2）与链B（channel-40）之间的已经建好了channel，当token从A链转到B链时，token在B链的denom为{Port}/{Channel}/{denom}，channel建立好后，会绑定port，transfer 模块将绑定到一个名为 transfer 的端口。如果链A发送 100 个ATOM token，则链B将收到 100 个 ATOM token 并附加链B的channel前缀port/channel-id。所以链 B 会将这 100 个 ATOM 代币铸造为transfer/channel-40/atom。

案例

接下来演示IRIS的native token uiris经过cosmos hub转移到KAVA链的过程。

Native Token On IRIS

• denom: uiris

IBC Token On COSMOS

• Denom: ibc/hash(transfer/channel-20/uiris)

• DenomTrace

  • BaseDenom: uiris

  • Path: transfer/channel-20

IBC Token On KAVA

• Denom: ibc/hash(transfer/channel-30/transfer/channel-20/uiris)

• DenomTrace

  • BaseDenom: uiris

  • Path: transfer/channel-30/transfer/channel-20

IRIS->COSMOS-KAVA

上图流程如下：

• uiris是IRIS的native token所以直接将uiris托管在IRIS链中

• cosmos链在channel-20通道中mint ibc token transfer/channel-20/uiris，并将ibc token从channel-21通道发送给KAVA

• cosmos检查transfer/channel-20/uris并不是通过channel-21通道接受的token，所以在channel-21中托管ibc token

• Kava收到cosmos的消息，在channel-30中mint ibc token

KAVA->COSMOS->IRIS

上述过程的逆操作，可看上图中的注释。

interchain account

跨链账户允许区块链使用IBC安全地控制另一个区块链上的账户。

跨链账户最重要的两个特点如下：

• 通过IBC在另一个链上创建一个新的跨链账户

• 通过IBC可以控制远程的跨链账户

Host Chain：跨链账户在Host Chain上注册生成。Host Chain监听来自controller chain的 IBC 数据包（创建interchain account的数据包）。

controller chain：该链可以在Host Chain上注册跨链账户，完成后可以控制跨链账户（通过发送IBC packet给Host Chain来控制）。controller chain必须具有至少一个跨链帐户身份验证模块（Authentication Module）才能充当controller chain。

Authentication Module（身份验证模块）：controller chain上的自定义IBC应用程序模块，使用跨链账户模块 API 构建自定义逻辑，用于创建和管理跨链账户。controller chain需要身份验证模块才能利用链间帐户模块功能。

跨链账户（ICA）：Host Chain上的账户。跨链账户具有普通账户的所有功能。但是，controller chain的身份验证模块不会使用私钥对交易进行签名，而是将IBC数据包发送到Host Chain，以指示跨链帐户应该执行哪些交易。

总结

IBC协议一共分为四层分别是：应用层，channel，connection，light client。 应用层处理来自channel的数据报，并将处理完成后的数据交给channel发送给对方链。目前用的比较多的应用就是跨链token转移和链间账户。

channel建立在connection上，一个connection上可以拥有多个channel，每个channel的id是自增的，channel和模块进行绑定。

connection建立在light client的基础上，一个 light client上可以有多个connection，connection的id也是自增的。

每个链都会拥有另一条链的light client，light client跟踪其他链的共识状态，以及根据对方链的light client的共识状态验证对方的数据包的合法性。

relayer不对数据包进行任何验证，因此不需要被信任，但relayer在 IBC 中具有特别重要的作用，除了通过提交数据包以保持IBC网络的活跃性。他们负责提交init消息以创建新light client，并在每个链上保持light client状态的更新，以确保light client可以验证传递过来的数据包的合法性。relayer还负责发送connection和channel握手数据包，在链之间建立connection和channel。此外，如果连接另一端的链尝试分叉或尝试其他类型的恶意行为，relayer可以提交不当行为的证据。