IBC
可以认为是连接cosmos
生态中各个链之间的高速公路,那么,什么是IBC
?IBC
是如何实现区块链之间的互操作性的?我将介绍IBC
的架构和主要组成部分,包括IBC/TAO
和IBC/APP
。在IBC
协议的基础是可以建立跨链应用例如:跨链转账,链间账户等。最后,我将举例说明如何实现跨链代币转移。
什么是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
- BaseDenom:
IBC Token On KAVA
- Denom:
ibc/hash(transfer/channel-30/transfer/channel-20/uiris)
- DenomTrace
- BaseDenom:
uiris
- Path:
transfer/channel-30/transfer/channel-20
- BaseDenom:
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
可以提交不当行为的证据。