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

导 读


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


IBC初探


IBC是属于Cosmos-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协议是Cosmos中最核心的接口协议,能够实现区块链间跨链消息的可信、可靠转发,并有效进行流量控制、多路复用等功能。

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

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

Client

Connection

Channel

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

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

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

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

▲ 链内客户端

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

为了方便后续后续更多不同种类的区块链接入,这个轻客户端规定了一套通用的接口,不同类型的区块链通过实现该 Client来达到接入的效果。现阶段Cosmos能够支持 Tendermint Client和Solo Client,也就是同构链之间原生支持跨链。这也决定了不是使用Cosmos构建的区块链想要接入Cosmos 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在跨链扮演的角色和功能并不相同,按照Cosmos的设计,Connection和Client一起负责跨链交易的“合法性”——包括跨链交易确实在目的链上发生,以及跨链交易只提交了一次。而Channel用来保证跨链交易的有序性,每笔交易按照 Sequence Number来进行发送。

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

▲ 发送跨链数据包

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

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


总 结


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

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

作者简介

陶勇星

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

写评论,请先登录