技术 | Cosmos跨链协议IBC的来龙去脉

导 读

Coos是由Tendermint团队构建的开源社区项目，它是一个由独立的称为Zone的区块链组成的支持跨链交互的异构多链系统，和Polkadot一样，也由中继技术实现。Coos提供一套能够完整搭建区块链的SDK，作为一个跨链系统，其中最为关键的就是跨链协议相关的设计，今天我们就来详细分析一下IBC协议的具体内容。

IBC初探

IBC是属于Coos-SDK中一个特殊的模块。之所以特殊，主要体现在IBC提供了区块链之间的跨链能力。

从总体的流程来说，IBC的技术并没有很复杂，应该来说协议本身不应太过复杂，这对于协议的使用者来说约束更小，更加灵活。

现在比如说A链上的Alice上需要发送10个ATOM代币到B链上的Bob上，会经过下面的四个步骤。

▲Tracking

A链上的IBC模块会不断的同步B链上的区块头信息，B链上的IBC同理。通过这种方式，双方能够实现跟踪对方区块链上的验证者集合的变化，本质上来说，就是A链、B链相互维护了一个对方的轻节点。

▲Bonding

当使用IBC初始化一笔跨链转账之后，A链上的10个ATOM事实上处于锁定的状态。

▲Proof中继

一份证明A链上已经锁定10ATOM的“证据”会被路由到B链上的IBC模块。

▲验证

B链结合A链的轻节点信息，对这份“证据”验证通过之后，B链上会“铸造”10份ATOM Voucher（抵用券），这些Voucher可以进行后续的流通使用。当然这些Voucher也可以通过同样的跨链方式返回到A链，A链上的ATOM代币相应执行解锁的操作。

IBC握手流程

IBC协议是Coos中最核心的接口协议，能够实现区块链间跨链消息的可信、可靠转发，并有效进行流量控制、多路复用等功能。

在Coos中，每个功能都是高度模块化的，每个功能通过加载不同的模块来实现，IBC也是如此。在IBC设计时，借鉴了传输层的TCP协议，也是希望成为区块链领域的“TCP协议”。不仅如此，在IBC的各个方面也能看到TCP的身影，首先我们来看IBC中的一些基本概念。Coos IBC采用了有连接的、可靠的跨链消息传输。

在此基础上提出了以下几个关键定义：

Client

Connection

Channel

下图是IBC协议和TCP相关概念的对比。

可以看到连接、端口都是TCP协议中的规范，但是其中的内涵发生了变化，为了适应跨链场景下的使用。同时增加了通道和客户端等新的内容，能够支持跨链中的有序发送和跨链交易的验证。

接下来我们来看一下一次完整IBC协议的握手和通信流程。

一笔跨链交易的连接流程如上图，和TCP协议类似，IBC的建立需要建立多次的握手过程，并增加了一步初始化客户端的操作，这对于跨链来说很关键的一环。

▲链内客户端

跨链双方需要在链上初始化一个对方链的轻客户端，这个Client实质上是另一个区块链的轻客户端，而且必须满足Coos规定的一套Client接口。之所以要在IBC建立之前初始化这个轻客户端，是因为Coos需要保证在本链上能够验证来自来源链的跨链交易是能够验证的，否则无法保证在本链上执行该交易的有效性和合法性。

为了方便后续后续更多不同种类的区块链接入，这个轻客户端规定了一套通用的接口，不同类的区块链通过实现该 Client来达到接入的效果。现阶段Coos能够支持 Tendermint Client和Solo Client，也就是同构链之间原生支持跨链。这也决定了不是使用Coos构建的区块链想要接入Coos Hub进行跨链的话，必须通过一个额外的“转接桥”，实现起来也更加复杂了。

▲握手连接

在轻客户端的基础上建立握手连接，握手连接基本上分别为三个部分。

• 启动跨链的用户向链A发起OpenInit请求，等待Relayer 接收到该请求。
• Relayer进行路由跨链消息包的工作，如果收到 OpenInit的请求，Relayer 会构造一个的OpenTry 的请求发送到链B上。
• 链B收到OpenTry请求之后，如果同意的话，会对该消息进行确认（生成OpenACK数据包，并按照之前的方式由Relayer 转发给链A。
• 链A通过OpenACK数据包判断此次握手是否成功，如果成功，对此次握手发送**的OpenConfirm 数据包返回链B。如果握手失败，此次连接也就是建立失败了。

上面的步骤不仅是指Connection的建立过程，Channel的建立也是遵循同样的流程，只是数据包的名称和内容会有不同，像建立Connection的时候发送的便是 ConnOpenInit请求，建立的Channel的时候便是ChanOpenInit 请求，之后的请求依次类推。

需要说明的是，Connection和Channel在跨链扮演的角色和功能并不相同，按照Coos的设计，Connection和Client一起负责跨链交易的“合法性”——包括跨链交易确实在目的链上发生，以及跨链交易只提交了一次。而Channel用来保证跨链交易的有序性，每笔交易按照 Sequence Number来进行发送。

虽然在Coos设计中有提到可以实现无序的Channel，但是默认实现上是采用了有序的模式。如果按照TCP协议簇来类比的话，有序Channel和TCP类似，无序Channel类似于UDP，无序Channel按照UDP来讲的话，在某些不太关注跨链消息包顺序的场景下也是适用的。同时Coos设计中也考虑到Channel的消息发送能力，允许一条Connection上建立多个Channel，在不同的跨链应用场景中，可以使用不同的Channel发送消息，从而隔离不同业务。

▲发送跨链数据包

完成上述的一系列握手之后，应用层便可以在Channel上发送自己的数据了。Coos规定了发送跨链交易的一些必要字段，如下图：

其中Sequence和SourcePort字段都是承担其字面意思的功能，也是必须指定的字段，而TimeoutHeight和TimeoutTimestamp是Coos提供的一种超时机制。如果某个区块高度或者某个时间这笔跨链交易还没有完成的话，用户能够指定将这笔交易回退（比如是跨链转账的话，可以防止资金长时间冻结）。而Data字段是留给用户进行自定义，以应对可能的各种复杂的跨链场景。

总 结

通过上面对IBC的分析，我们可以看到IBC采用了建立连接的方式进行跨链，不同于Polkadot的XCMP协议，XCMP协议中平行链可以直接进行跨链消息的转发。

而且Coos并没有过分关注Zone作恶的情况，只是通过维护Zone的轻客户端的方式验证跨链交易的有效性，这种方式下是相信Zone不会出现集体作恶的情况，也就是Zone安全性由自身负责。不同于Polkadot设计上中继链维护全局的安全性，Coos IBC的设计上是减少了跨链系统的维护成本和降低了设计实现难度的。

作者简介

陶勇星

来自数据网格实验室BitXHub团队主要负责区块链账本互操作技术相关研究工作