BitXHub跨链中继大揭秘

BitXHub的中继链整体架构设计如图1所示，一共分为4层：

第一层是物理层，中继链采用跨平台的设计方式，能在普通物理机、云主机或者嵌入式设备上运行。

第二层是基础层，这一层包含了区块链本身需要具备的模块，比如网络、存储、共识和虚拟机等等；考虑到中继链需要对跨链交易进行相关的验证，而这些逻辑在类似EVM的虚拟机中是难以实现的（比如一些特殊的验签算法或逻辑），中继链整合了支持Webassembly的虚拟机。

第三层是跨链相关的服务层，它是在基础层之上构建的跨链服务模块，其中：应用链管理主要负责应用链注册、审核和冻结等操作；验证引擎构建于Webassembly虚拟机之上，主要提供跨链交易存在性和有效性的验证功能；执行模块包括跨链交易的合法性检查、验证和路由的工作；事务管理负责跨链交易在整个系统处理的一致性；隐私保护通过加密以及隐私交易等机制保证跨链数据的隐私性。

第四层是接口层，中继链提供GRPC和Restful两种接口服务以及统一的跨链通用传输协议IBTP。

整体交易流程

如图2所示，BitXHub中继链对于跨链交易处理的整体流程。

首先，跨链网关通过中继链提供的SDK或者Restful接口发送跨链交易到中继链，中继链接口层接受到跨链交易后，会进行交易基本字段检查，包括时间戳、Nonce和From地址等字段的合法性检查。

其次，检查通过的跨链交易会通过核心接口层转发到共识模块的交易池中，交易池中的交易会被定时打包成一个交易列表并通过共识确定。经过共识的区块会进入执行模块，执行模块通过跨链交易处理合约进行跨链交易的统一处理。跨链交易处理合约首先检查跨链交易对应应用链的权限、序号是否准确等信息，然后通过验证规则管理合约获取跨链交易对应的验证规则地址，最后根据前面获得的信息调用验证引擎验证跨链交易的合法性。

最后，执行模块执行完整个区块的交易，把合法的跨链交易转发到路由模块。路由模块根据跨链交易中记录的目的链信息进行分类并路由到相应的跨链网关。

以上就是中继链对跨链交易执行的主要流程，除此之外，整个跨链的流程还包括应用链管理和验证规则注册管理等流程。

应用链管理

应用链管理是实现应用链跨链的辅助服务，中继链对应用链的管理主要包括注册、更新、审核和注销四个操作。

应用链管理员：应用链内各联盟机构指定的运维管理员，负责应用链在中继链上的注册、更新操作，同时维护跨链网关。加入中继链之前，应用链管理员为跨链网关生成一个公私钥对，并在注册时携带公钥信息。

中继链管理员：参与中继链链级别的权限管理工作，包括系统和内置合约升级、应用链的审核和注销，验证规则的审核和注销等操作。

>应用链注册

图3展示了应用链注册的流程。应用链注册需要的信息包括：

1.验证者信息：提供验证所需的相关信息，验证引擎通过验证跨链交易是否由一定数量的验证者签名来确保跨链交易的存在性。需要注意的是，Fabric中该字段除了需要包含验证者信息，还需要提供相关的背书策略。

2.共识算法类型，不同共识算法判断一个跨链交易的最终性也是不一样的。比如RAFT算法，需要一半以上验证者的签名，而RAFT算法，需要f+1个签名。

3.链类型，记录应用链的链类型，如果应用链没有注册验证规则，那么执行模块会根据链类型使用默认的验证规则去验证跨链交易，目前中继链有默认的Fabric验证规则。

4.链名字、链描述，管理员给链取的名字和具体描述信息。

5.跨链网关公钥信息，将跨链网关的公钥信息记录在中继链上，方便不同跨链网关之间进行密钥协商来保护跨链数据的隐私性。

应用链注册后还未审核通过时，不允许更新应用链信息，而且发送的跨链交易与发送给它的跨链交易都会被视为无效交易。应用链注册时所用身份信息（一开始生成的公私钥对）会被作为识别跨链交易的唯一标示，所以跨链网关发送跨链交易的时候也需要使用这一个公私钥对。应用链成功发送注册信息到中继链后，可以通知中继链管理员进行审核。

>应用链审核

中继链管理员对应用链注册的信息进行核对，特别是验证者信息与公钥信息。中继链管理员审核不通过时需要带上审核建议供应用链管理员查看注册不成功的原因。中继链规定了需要一半以上的中继链管理员审核通过后，才可同意应用链的加入。

应用链更新和注销操作与上面的操作流程相差不大，这里就不做赘述。但是需要注意的是应用链验证节点更换、新增或者共识算法更换时，可以由应用链管理员进行应用链更新操作。应用链更新时，中继链不接受该应用链相关的跨链交易。

验证规则管理

验证规则是供验证引擎对跨链交易验证存在性和有效性所用的。这些验证规则我们可以理解为区块链里面的智能合约（运行在Webassembly虚拟机中），他们也有生命周期：比如部署、冻结、注销、审核等功能。但是每个链的异构性导致每个链的验证规则也是不一样的，中继链无法为每个链提供统一的验证规则，因此就需要应用链加入中继链时，由应用链管理员进行相应验证规则的部署、注册。

>验证规则部署、注册和审核

图4展示了验证规则的部署、注册和审核过程。

首先，应用链开发人员需要根据链的特点进行验证规则的开发，比如在Fabric中，验证规则需要根据应用链注册时提供的验证者信息和背书策略实现跨链交易存在性验证逻辑，来保证跨链交易确实是从该Fabric链中发出的。除此之外，在有回调的跨链请求中，验证规则还需要负责调用有效性的验证。比如跨链请求中指定到链B中地址为0x123456合约中调用Get方法获取数据，那么中继链在接受包含这个结果的跨链交易时，需要通过验证规则验证这个结果是否是由链B中调用了0x123456合约中Get方法产生的。

验证规则开发完之后，由应用链管理员进行部署，部署成功的验证规则会返回一个验证规则地址（类似于合约地址）。部署成功的验证规则只是一个记录在中继链上能由Webassembly进行执行的逻辑代码，此时还不能用于跨链交易的验证。

应用链管理员需要进行验证规则注册，这一步主要的目的是将验证规则地址和应用链进行绑定。只有绑定了验证规则的应用链，在验证跨链交易的时候，验证引擎才知道选用哪个验证规则来对跨链交易进行验证。

中继链管理员同步到验证规则注册请求后，会从中继链中获取相关的验证规则代码进行检查和审核。

>验证规则更新

应用链验证节点新增、更换时，或者验证策略变动时，需要由应用链管理员进行验证规则的更新。验证规则更新操作和前面的步骤类似，先进行验证规则的部署操作再进行更新操作。

跨链交易执行

与普通交易不同，跨链交易除了需要进行一些必须的验签等操作外，还需要进行额外的存在性、有效性、有序性验证等操作。

跨链交易的执行主要包含两个步骤：检查、验证。

>检查阶段

图5中步骤1-4展示的是检查阶段。跨链交易的检查阶段在跨链交易处理内置合约中完成，主要的检查工作包括：

1.产生该跨链交易的应用链是否存在、是否经过审核，是否被冻结了，跨链交易标识的目的链是否存在等等。

2.检查产生该跨链交易的应用链是否注册了验证规则，或者验证规则是否被冻结了。

3.检查跨链交易的序号是否有序。这里的跨链交易可能有两种类型：一种是来源链抛出的跨链交易，那么需要检查抛出跨链交易的有序性，另一种是目的链返回的包含跨链执行结果的跨链交易，这种也需要保证目的链执行返回的序号。

4.前面步骤都没问题，跨链交易处理合约通过验证规则管理合约获取相应的验证规则地址；需要注意的是，中继链内置了fabric的验证规则，如果应用链是fabric，那么可以使用内置的验证规则。

>验证阶段

检查通过的跨链交易进入验证阶段，验证阶段由验证引擎进行执行，主要验证跨链交易的存在性和有效性；

图5步骤6-7展示的是验证阶段流程。跨链交易处理合约将跨链交易、验证者信息、验证规则地址三个信息输入到验证引擎中，然后验证引擎进行以下三个步骤的执行完成跨链交易的验证：

1.交易解析，解析跨链交易，将跨链交易中相关的证明数据提取出来，并检查数据格式是否有误。

2.规则匹配，在Webassembly虚拟机中寻找对应的验证规则。这里的验证规则可能是运行于Webassembly虚拟机上的，也可能是内置合约。

3.规则执行，将证明数据、验证者信息（Fabric中，还需要背书策略）作为参数来运行验证规则。

验证通过的跨链交易即完成了整个跨链交易的执行过程。而最后，跨链交易会被转发到路由模块，由路由模块进行分类同步到相应的跨链网关。

上面对中继链的整体架构、流程以及核心的三个流程做了较为详细的讲解，但是碍于篇幅的限制，其中涉及到的技术细节，比如验证引擎的实现，共识插件机制的实现等留到后面的文章再展开说明。