趣链科技logo
/En

我们和跨链技术的缘分从一个客户需求开始:


在养老金行业的区块链应用中我们遇到了一个跨链的需求,一个客户使用趣链联盟链构建了一个养老金链,同时另一方客户则使用Fabric构建了另一个区块链服务,他们所做的业务分别位于养老金业务流程中的两个不同阶段,参与的机构和用户也不尽相同,为了从底层开始打通这两个区块链,让养老金的业务之间无缝互补并行更大规模的业务,同时促进两者的业务互补达到共赢的目的,我们开始了跨链的探索之旅。


大概在一年前我们整理过《关于跨链技术的思考》, 分析发现市场上的跨链平台都无法满足异构联盟链的跨链需求,因此也就自然地开始了自研跨链平台。


这一次我们就用户最关心的10个关于跨链平台的问题,来向大家传递BitXHub这款产品背后的设计思路,希望大家了解了架构的设计理念之后能够更好的使用BitXHub,也能更好的参与到跨链平台的演进之中。


1.跨链的本质是什么?


自从区块链这个行业兴起之后,不同时期,不同的组织机构针对不同的应用场景开发出了种类繁多的区块链平台,例如Ethereum,趣链区块链,Hyperledger Fabric等等。这些区块链平台的共识算法、智能合约执行引擎、密码体系等机制设计上的不同导致了这些链之间的很难通信,数据很难互认,导致了区块链特别是异构的区块链之间的跨链难题。


跨链难题的存在主要有两个原因:一是早期区块链设计自身就没有跨链的模块,也就是类似电脑不带网卡,二是现代某些区块链支持跨链但是只是支持特定协议的区块链跨链如Polkadot,Cosmos,它们对支持他们协议的同构平行链支持完善,但是对异构链支持不够。


结合区块链的应用模式,我们认为跨链需要解决的本质问题就是跨链交易的捕获、验证和路由问题。也就是跨链服务应该能够将跨链消息从一个区块链传递到另外一个区块链,同时能够让目的区块链正确验证跨链消息的合法性并执行相应的跨链动作。


2.为什么是“网关+中继”?


我们先来回顾一下常见的跨链方式:1)哈希锁定,安全性高但是场景有限;2)公证人机制:实现简单但是存在中心化作恶风险;3)中继链的机制,具备分布式治理的安全性,目前仅有公链的实现且对异构链支持不够友好。


如下图所示,结合现有的跨链解决方案和跨链的本质问题,我们设计了一种更加通用的链间通用传输协议IBTP,并配合网关+中继链的架构模式实现异构区块链跨链交互,网关解决跨链交易的获取和提交问题,中继链结合IBTP解决跨链交易的验证和路由问题。



对这个方案有人可能会疑惑,难道不能只有网关吗?目前在国内外也看到另一种类似的方案,就是不用中继链,直接使用类似的网关进行点对点的跨链通信,这种简化的方式在可信的环境下尚可应用,但是谈到跨链服务的多方治理,规则透明,数据的高可用层面远不及采用中继链的方式安全。


那既然这样能不能网关的功能和中继链合并呢?合并当然可以,但是会带来额外的维护成本,引入网关首先我们将链和链之间多对多的关系降低到一对多的问题,其次是功能解耦,我们从架构图中可以看到网关主要是负责和具体的应用链对接,每个应用链的交互模式不同,如果网关服务做到中继链中去,那么中继链中新增加一个应用链,我们的中继链就得去对接和系统级别升级,而使用网关去对接应用链可以保持中继链的核心功能解耦。


因此“网关+中继”的架构模式既能够保证整个平台的灵活性又能够提供较高的安全性。


3.典型的跨链流程是什么?


我们设计的跨链服务尽量减少业务人员对跨链底层的感知,让跨链调用和普通跨合约调用保持一致。执行跨链调用之前需要执行一些准备工作,包括应用链注册,验证规则注册以及跨链双方的业务链上依据我们的跨链合约撰写规则(https://github.com/meshplus/bitxhub/wiki/跨链合约编写文档) 设置好相应的跨链合约,接下来使用SDK调用业务链的具体合约方法,这和调用普通的跨链服务没有什么区别,最简跨链调用流程如下:


  • SDK调用具体的业务链A的合约方法;
  • 合约方法被执行,抛出跨链事件T1;
  • 业务链A的跨链网关监听到T1, 将其转换成IBTP结构,提交到中继链BitXHub上;
  • BitXHub依据相关规则对T1进行验证以及路由;
  • 业务链B的跨链网关接受到T1并根据IBTP结构进行解析,转换成业务链B可识别的交易Tb;
  • B的跨链网关将Tb提交到业务链B上进行执行。


4.怎么保证跨链数据的真实性?


如何验证跨链数据的安全性以及有效性是跨链服务中需要主要解决的问题,在BitXHub的设计中,结合IBTP中的Proof和对应的验证策略保障,这样既可以对异构链支持的灵活性,同时可以保障跨链数据的可信验证。


如下图所示,对所有的跨链交易IBTP需要其提供相关的真实性证明内容序列化到Proof字段里,然后该IBTP消息被传递到中继链时,中继链使用注册的该Proof的验证规则对IBTP进行验证。



举个例子,我们知道Fabric是基于背书策略进行交易的确认的,跨链交易可以将相应的背书结果封装到Proof里面,最后BitXHub的验证引擎依据Fabric之前注册进来的背书验证规则对Proof内容进行验证,从而保障相应跨链交易的真实性。


只要Proof和规则对的上,所有异构的区块链理论上都能够通过该模型验证跨链数据的安全性。


5.跨链交易安全吗?隐私该怎么办?


很多朋友一看到我们的跨链有个中继链就非常担心跨链交易的安全性问题,其实在设计之初我们就考虑到了这个问题。参考上面问题4中的IBTP的结构图,可以看到传递到中继链的跨链交易核心数据是存储在Payload里面的。那么保护也就是正对该Payload的保护,针对跨链针对的跨使用环境的不同设计三种级别的数据的隐私保护手段:


  • 通过特殊序列化规则对跨链数据进行序列化,这种适合较安全互信的环境;
  • 通过中继链两个跨链网关使用DH协商加密秘钥,对跨链核心字段Payload进行加密;
  • 采用隐私交易的方式,跨链交易完整Payload仅在指定的中继节点上存储,其他节点上相关字段仅保存Payload的哈希值。


6.应用链需要改造吗?工作量大吗?


如果链平台级别可改造那么100%可以解决跨链的问题,然而我们不可能要求所有的业务链进行系统层级的改造,这既不科学也不经济。我们一开始就是秉持着易接入性的原则进行架构设计的。BitXHub中主要通过跨链网关来帮助应用链代理跨链系统之间的网络通信、交易格式转换,使用中继链辅助跨链交易的验证。


针对跨链网关的设计,我们采用插件的机制,将网关的核心功能和与具体应用链对接的功能进行解耦,对于新的应用链仅需按照跨链网关的规则实现好与其对接的部分即可。


7.如何保障跨链交易的事务性?


在BitXHub的跨链系统中,整个跨链交易主要会在发起跨链的应用链A、中继链以及目的应用链B之间存在交互,他们之间的交易原子性和分布式事务所面临事务的问题类似。


传统分布式事务经典的实现模式是二阶段提交和三阶段提交,这两种实现方式复杂但是能够保障事务的实时一致性。这种实现需要有中心化的资源管理器,不适用这种分散式的跨链服务。在我们的采用中继链的跨链方案中,中继链保存了所有的跨链交易内容,依据中继链的特性我们采用了最终一致性的跨链事务机制,借助中继链的跨链事件表构建事务补偿机制。这种方式能够尽可能提高系统运行效率,同时保障跨链的安全性。


8.跨链效率怎么样?


从跨链平台的架构来看,单条跨链交易的时间分为应用链A的发起交易确认时间+中继链的验证时间以及应用链B的确认时间,这里我们设计上可控的是中继链的时间优化,针对跨链交易的特殊性我们做了效率上的一系列优化方式:


  • 采用高性能的规则验证引擎,基于WASM构建验证引擎;
  • 对于不同链之间以及不同合约之间的跨链交易的签名验证、规则执行等通过并行处理;
  • 由于跨链交易的特殊性,跨链交易的存储也采用文件形式存储,加快存储效率;
  • 企业版提供趣链自研高性能RBFT和NoxBFT共识算法,可达数万级别的TPS。


9.IBTP和IBC的区别是什么?


IBTP目前在BitXHub项目中主要指代一种跨链数据格式,通用的链间传输格式。IBTP以一种最简洁的方式定义了跨链消息的必要元素,包括用于路由的来源和目的链ID,用于控制交易顺序的索引信息,跨链合约调用的编码信息,用于验证的交易证明信息以及协议的版本。IBTP格式屏蔽了具体应用链之间的差异,同时支撑跨链交易的转换、验证、路由、调用核心机制。


IBC是Cosmos项目提出的一整套跨链传输协议,包括了跨链消息通信中的数据中继,数据隐私合规,可用性,流控,认证等等一些列的规定。BitXHub在设计之初采用了更加简洁的IBTP的主要原因在于当时IBC还不够完善,IBC最初仅对资金类跨链服务进行了细化和实现,不符合联盟链对合约跨链的业务需求。


我们认为关于具体通信协议的争论其实是无意义的,当前跨链技术最重要的是解决问题是能不能work的问题。我们也相信未来链间通用的跨链协议一定会慢慢趋同,甚至会和网络通信协议一样最终形成共识。到那个时候跨链协议本身就不再重要,更加重要的是如何提供一个更加安全、高效、稳定的跨链服务,这也是BitXHub致力于努力的方向。


10.跨链未来在哪里?


我们预测随着跨链需求的越来越成熟,跨链相应的标准也会逐步完善和稳定,最终区块链之间会形成类似TCP/IP的跨链协议。我们也无需进行无谓的跨链协议之争,最终市场认可的应该还是怎么样的跨链实现更适合相应的跨链场景。大胆预测一下,未来的跨链产品应该如同今日的路由器,对于不同的场景可以选择不同的跨链服务进行连接。例如在公网的场景下和在局域网的场景下我们选择的网络路由器设备的安全性、性能等各个方面会有不同的侧重点。跨链服务也类似。但是有一点可以确认,随着区块链业务的不断丰富,在整个区块链行业中一定会形成万链互联的可信互链网形态。


加入我们


我们提供了高质量的区块链跨链交流社群,社群内不仅可以与区块链行业大咖、区块链技术专家零距离交流。欢迎各位朋友踊跃加入,让我们一起探讨和感受跨链的魅力。进群请添加小助手桔子微信:18458407117(备注:0420)。