Go 开源说第十期：BitXHub——区块链跨链协作平台-技术圈

点击蓝字

关注我们

本文由“GO开源说”第十期《BitXHub——区块链跨链协作平台》直播内容修改整理而成，视频内容较长，本文内容有所删减和重构。

当前的区块链应用和底层技术平台呈现出百花齐放的状态，但主流区块链应用中的每条链大多仍是一个独立的、垂直的封闭体系。在业务形式日益复杂的商业应用场景下，链与链之间缺乏统一的互联互通机制，这极大限制了区块链上数字资产价值的流动性，跨链需求由此而来。

BitXHub平台由中继链、应用链以及跨链网关三种角色组成，并链原生集成W3C标准的DID，依据场景导向可灵活组织部署架构，具有通用跨链传输协议、异构交易验证引擎、多层级路由三大核心功能特性，保证跨链交易过程的安全性、灵活性与可靠性。BitXHub于2020年3月份开源核心代码组件，希望与广大开发者携手共建万链互联生态。

项目开源地址：GitHub: https://github.com/meshplus/bitxhub

BitXHub系统架构

BitXHub的技术架构如下图，自下而上分为物理层、基础层、跨链服务层、接口层四个部分。

第一层是物理层，中继链的设计为了满足不同场景下用户物理环境需求，支持在普通物理机、云主机或者嵌入式设备上稳定运行，兼顾多场景适用性。

第二层是基础层，这一层包含了联盟链本身需要具备的模块，比如网络模块、存储模块、共识模块、虚拟机、隐私安全模块。

第三层是跨链相关的服务层，包括应用链管理模块、执行模块、事务管理模块、验证引擎模块和隐私保护模块，各模块互相协作完成中继跨链流程。

第四层是接口层，中继链对外提供gRPC和Restful两种接口服务，支持不同场景下用户的使用。

接下来为大家分享 BitXHub核心模块的工作原理，主要包括：跨链交易并行执行设计方案、如何使用GO插件机制适配多种共识算法以及BitXHub中的多模块化实践。

跨链交易并行处理

背景

在区块链中，每个区块中包含一个交易列表，但是一般都是串行执行，因为串行执行虽然能够保证每个节点得到账本保持一致。

在中继链上，交易能够分为跨链交易和普通交易。普通交易负责中继链上原生的一些事务处理，数量较少，执行的速度较快；另一部分是跨链交易，这是中继链上主要的交易类型，跨链交易由于涉及到验证规则的验证，在执行速度上是比较慢的。

为了加速中继链上的交易执行，我们想到可以对无依赖关系的交易进行并行化的处理，这些交易对于账本的改动并不重合，可以提升中继链处理交易的效率。

我们对于中继链上的交易进行分类，并对链上的主要交易类型——跨链交易进行额外的加速策略。

分组策略

对于一个区块中的交易列表：

首先区分这些交易中普通交易和跨链交易。

按照区块中交易的顺序，没有被普通交易隔断的跨链交易可以分为一组，碰到普通交易之后必须开始重新分组。这是因为普通交易中可能包含应用链管理、验证规则管理等类型的交易，如果这些类型的交易为执行的话，可能会影响到后续跨链交易的执行。

跨链交易分组

对于上述的每一个跨链交易分组，还可以进一步细分这些跨链交易。因为跨链交易中可能是从不同的应用链上发送过来的，这些不同应用链上发出的跨链交易本身在中继链上的处理是不会相互影响的，所以这些跨链交易可以被继续细分。

交易执行

在上述两个步骤中，能够得到多个分组，但是对于这些分组，并不能简单的全部并行执行。能够进行并行处理的部分是跨链交易的部分，普通交易还是无法并行执行。当交易列表中存在普通交易时，必须恢复到串行执行，碰到跨链交易的分组，可以按照发起链分成的细分组来并行处理。

共识算法插件模块

Go语言的插件系统基于C语言动态库实现的，通过采用Go语言提供的插件模式，实现BitXHub对共识插件的动态链接加载。动态链接的机制可以为我们提供更多的灵活性，主程序可以在编译后动态加载共享库实现热插拔的插件系统。

1. 查找插件路径是否存在（编译后的.so文件）；

2. 通过Go语言plugin模块加载插件文件，plugin.Open返回结构体中包含方法符号表；

3. 查找插件是否实现NewNode方法符号，直接利用了结构体中的符号表，如果没有对应的符号表会返回错误；

4. 类型断言方法的入参和出参；

5. 调用NewNode方法，这一步返回真正的共识算法模块实例；

多模块选择加载

BitXHub中某些模块有多种实现，比如交易执行模块有串行执行器和并行执行器，账本模块有带历史数据的账本实现和不带历史数据的账本实现。如果仅仅是这种多种实现的情况，直接在BitXHub代码中进行实现即可，BitXHub启动时根据配置文件进行选择。但是我们碰到了一个特别的需求，某些特性（比如并行执行器）仅在商业版BitXHub中提供，并不开放源代码。因此直接在开源的BitXHub中实现代码是不可能的；同时，商业版和开源版的大部分代码是一样的，在内部再维护一份商业版本的BitXHub也是不太现实的。因此，我们选择仅仅把商业版本特性闭源，利用go语言的特性将开源的BitXHub和闭源的商业版本模块结合，即可编译出商业版本的BitXHub二进制文件。

以串行执行器和并行执行器为例，并行执行器模块如何编译到BitXHub中呢？BitXHub代码中存在一个.template文件专门import用于闭源的模块，如果编译商业版本，Makefile便会根据该文件生成.go文件将这两个模块的包引入（这种go语言中带下划线的import方式可以显式的调用包的init方法）；同时，BitXHub中存在一个goent.diff，里面记录了那些闭源的特性模块使用的具体版本，编译商业版本时会根据该文件修改go.mod。这样闭源特性相关模块就编译进BitXHub了。

另外，我们开发了一个单独的Agency模块，该模块有register和get方法，register方法用于注册不同类型的执行器的构造方法，get方法根据传入的类型得到对应的执行器的构造方法。

串行执行器和并行执行器都在init方法中调用agency中的register方法进行各自类型和构造方法的注册。当BitXHub启动时，所有包的init方法会先于main方法运行，这样两个执行器的类型和构造方法就被注册进agency模块了，当main函数运行时，BitXHub根据配置文件得到需要加载的执行器类型，并从agency模块中得到对应的构造函数，就可以构造出对应的执行器进行使用了。