跨链协议IBC概述

跨链协议IBC概述

一.什么是IBC?

IBC是链间通信协议的缩写(Inter-Blockchain Communication Protocol)。通过数据包交换在多个不同的区块链网络之间转移数据和状态信息。最初的用途更多是通过IBC协议实现跨链通证转移。
IBC的目标是在两个独立的七层网络之间传递应用信息,所以需要链外的relay把数据包在链A和链B的网络之间做中继。链B收到链A的数据后必须能独立验证它所包含的证明信息,该证明代表了链A上的某个状态(及其对应操作)的真实性。为了让IBC协议能够工作,必须依赖基础的信任机制,要相信链A和链B里各自的共识算法,也要相信轻客户端验证,通过对区块头信息的验证,证明在区块链上曾经发生过的事情。

二.如何实现IBC?

1.连接的生命周期

1.1 建立连接

在两条链之间首先要建立“连接”,也就是彼此的初始信任关系;在连接建立的那一瞬间两条链要交换基础的信任数据(信任根)-- 对PoS网络来说就是两条链的验证人公钥集,信任根必须是可以由第三方独立验真的。

1.2 保持连接

在整个连接期间要持续不断获得对方的新区块头,基于信任根和连续的区块头,可以从连接建立时对方的区块高度,连续验证后续任意高度区块头的正确性;这些区块头是验证IBC数据包的信任基础。

1.3 断开连接

当出现分叉或安全事件的时候,要及时关闭连接;这可以通过链上治理或自动作弊检测来触发。

2.数据包、回执和超时处理

2.1 数据包

是由元数据(数据头)和不透明数据载荷(数据体)组成的报文。数据头包含类型、顺序号、源链ID、目标链ID、超时参数;数据体则包含需要区块链应用层来理解和处理的数据,也就是源链状态变化的证明。

2.2 回执

是“反向”数据包,B链收到并处理完来自A链的数据包后,会给A链发一个对应的回执。

2.3 超时处理

源链在发送数据包时,可以在数据头里指定一个由目标链上的区块高度或时间戳表示的超时参数;目标链对收到的超时数据包将不予处理,而源链如果在发送的数据包超时后还未收到回执,就会对数据包对应的链上状态做回滚操作。

3.严格排序的消息传送

要想让整套系统工作,数据包的传递必须保持严格的全局排序:
· 共识算法确保链上交易的处理遵循单一精准排序。
· IBC协议确保关于链上交易处理状态的消息在跨链传递的过程中遵循单一精准排序。
· IBC用通道机制实现排序控制:每条链为每个连接都维持发送和接收两个通道,每个通道维持一个计数器,发送通道的计数器为流出消息生成顺序号,接收通道的计数器则用于校验流入消息的顺序号。
· 严格的排序保证是对全局状态一致性进行推导的前提条件。

4.共识要求

IBC协议安全需要共识算法的最终性来防止双花,不同共识算法的最终性表现不一样:
· Tendermint和PBFT类共识算法满足即时最终性(最理想)
· 以太坊的Casper FFG共识算法提供快速最终性
· 比特币类共识算法(PoW, Tezos)提供概率最终性,需要应用层选择安全阈值

三.Cosmos IBC relayer

relayer软件包包含一个基本的中继器实现,供希望在启用IBC的链组之间中继数据包/数据的用户使用

中继器支持以下功能:

扫描二维码关注公众号,回复: 14609104 查看本文章
  • 创建/更新IBC Tendermint light客户
  • 创建IBC连接
  • 创建IBC转移渠道。
  • 启动跨链转移
  • 中继跨链转移交易,其确认和超时
  • 从状态中继
  • 从流事件中继
  • 发送IBC中断升级的UpgradePlan建议
  • 在交易对手链对IBC进行重大更改升级之后升级客户

中继器当前无法:

  • 使用用户选择的参数(例如UpgradePath)创建客户端
  • 提交IBC客户解冻建议
  • 监控并向客户提交不当行为
  • 使用除Tendermint之外的IBC light客户端,例如Solo Machine
  • 连接到未实现/未启用IBC的链
  • 使用不同的IBC实现连接到链(链未使用SDK的x/ibc模块)

四.IBC跨链转账流程

IBC是属于Cosmos-SDK中一个特殊的模块。之所以特殊,主要体现在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模块
在这里插入图片描述

  • Verify

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

五.IBC握手协议

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

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

IBC协议和TCP相关概念的对比
在这里插入图片描述

cosmos社区中讲解的一次完整IBC协议的握手和通信流程,如下图所示:
在这里插入图片描述

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

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

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

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

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

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

IBC采用了建立连接的方式进行跨链,不同于Polkadot的XCMP协议,XCMP协议中平行链可以直接进行跨链消息的转发

猜你喜欢

转载自blog.csdn.net/lk2684753/article/details/113849554