面向复杂应用场景的联盟链多链协同方案

张 勇，姚中原，王 超，郭尚坤，郭晓涵，斯雪明

1.中原工学院前沿信息技术研究院，河南郑州450007

2.河南省网络密码技术重点实验室，河南郑州450007

3.河南省区块链数据共享国际联合实验室，河南郑州450007

区块链技术源于2008 年“中本聪”发表的一篇名为“Bitcoin: A Peer-to-Peer Electronic Cash System”的文章[1]，首次提出了区块链的概念。区块链是一种以哈希作为指针的链式结构，并结合密码学、共识算法、激励机制和智能合约等关键技术，确保区块链不可篡改、可追溯以及去中心化。

随着区块链技术的发展[2]，区块链已经应用于各种场景中解决问题[3-7]。然而，伴随系统业务场景的不断复杂化，复杂业务对区块链系统在事务协同、可扩展和性能方面都提出了严峻的挑战，这也进一步限制了区块链技术的应用场景与应用规模。

为应对日益复杂的业务场景，学者们研究出了一系列的多链模型，在多链模型的研究领域中，可根据区块链之间的关系将多链模型分为平行链模型与主子链模型。平行链模型中每条区块链结构相同，通过命名空间等方式进行隔离。主子链模型中区块链之间呈现树型分布，往往存在结构不同的区块链。其中，文献[8] 提出主从区块链方案（master-slave blockchain scheme,MSB）新范式，通过将传统区块链分为主节点层和从节点层来处理不同的运算，提升了挖矿和验证的效率。文献[9] 提出一种适用于中小型应用的轻量级区块链架构（lightweight blockchain architecture,LBA），对存储结构、共识方案及网络拓扑结构进行了优化，提高了区块链系统中的数据存储等效率。文献[10] 提出了一种基于信用投票共识的主从多链分层跨链模型，能够有效减少节点之间的算力竞争，防御权益粉碎等攻击手段。文献[11] 提出了一种主从多链区块链共识机制，通过设计2 层主从多链结构，并将信誉度评估引入权益证明共识机制中，相较于传统以太坊（ethereum,ETH）区块链，吞吐量（transactions per second,TPS）提升了约48%。文献[12] 设计了一种基于树形结构的适用于联盟链场景的主从多链架构，可实现不同数字资产的分类、并发处理和达到数据隔离的隐私需求。文献[13] 设计了一种分层分簇的联盟链网络，获得了更高的广播吞吐量和更低的广播时延。文献[14] 设计了一种没有中心化组件的多区块链协议Hydra，提高了交易吞吐量并有效防止了双花攻击。然而，平行链模型中往往将不同的业务合约部署在不同的区块链上，当由于业务之间不可避免地耦合，链下服务常需要与多条链发生交互，使得链下服务不得不维护多条链的节点地址与证书，加大了使用者对链证书维护成本；当业务量后期增加时，由于区块链节点冗余存储的特性，无法采用增加节点的方式进行扩容，只能重新构造一条新的区块链并部署合约，并需要链下服务进行相应业务的引流，加大开发成本，缺少统一的业务扩展解决方案。主子链模型在实际应用中，主链负责数据存储，子链负责逻辑运算，虽能通过分担运算的压力达到提升整体性能，适应实际中的多业务场景，但由于其数据都存储在主链上，存在无扩展性、存储单一的问题，使得主链成为约束整体性能的关键。除此之外，现有区块链模型虽然能防止合约内双花事件的产生，但是并没有对多合约之间进行事务管理，实际应用中，只能由用户在链下实现事务控制。

针对以上问题，本文提出了一个面向复杂应用场景的联盟链多链协同方案，并进行了实验和分析。实验结果表明，本方案的交易吞吐量能有较大的提高，同时支持动态业务扩展、统一身份认证、多合约事务操作及读写分离。本文主要工作包括：1）针对复杂应用场景，提出基于网关链的多链模型；2）通过解决动态业务扩展、统一身份认证、多合约事务操作及读写分离问题，提出多链协同方案；3）对提出的多链协同方案进行实验和分析，证明了该方案的可行性和有效性。

1 预备部分

1.1 TCC 事务方案

TCC 的概念由学者Helland[15]于2007 首次提出。TCC 方案将事务提交分为Try、Confirm、Cancel 三个操作，在服务中分别以三种接口的形式存在[16]。Try 操作检查资源是否满足要求，例如检查余额是否满足扣费要求，若符合条件，则对资源进行锁定，防止其余服务操作该资源。当Try 阶段操作都成功，则执行Confirm 操作，进行逻辑处理并提交处理结果，如图1 所示。当Try 阶段操作存在失败，则执行Cancel 回滚操作，将锁定的资源进行释放，如图2 所示。

图1 分布式事务成功Figure 1 Distributed transaction success

图2 分布式事务失败Figure 2 Distributed transaction failure

1.2 智能合约

1995 年，密码学家Szabo[17]首次提出智能合约（smart contract）的概念，并把它定义为“一套数字化形式定义的承诺，包括合约参与方可以在上面执行这些承诺的协议”[18-19]。在实际应用中，智能合约是一段部署在区块链上的程序。相较于普通的计算机程序，智能合约具有不可改变、确定性、去中性化、自治性等特点。换句话说，无论谁触发合约中预设的条件，智能合约总会沿着确定性的方向执行。具有上述特点的智能合约在数字支付、金融资产处置、云计算、物联网、共享经济等方面有着广阔的应用场景[20]。

1.3 基于属性的访问控制

基于属性的访问控制（ABAC）将属性作为访问判定的最小粒度，具有足够的灵活性和可扩展性[21]。ABAC 中包括请求者、被请求资源、访问方法和条件四种基本元素，每个元素使用属性进行描述，与基于身份的访问控制（IBAC）的区别是并不需要关心访问者的身份，只关心访问者具有的属性。当请求者对某个资源进行访问时，请求者是否具有访问权限的判定是请求者所具有的属性，被请求资源的访问条件判定是请求者是否包含被请求资源具有的属性。简单来说，请求者必须拥有被请求资源的属性才能进行访问。

1.4 应用网关

应用网关主要位于网络的边缘并作为外部服务请求的统一入口，主要提供身份认证与安全检测、请求路由管理、服务组合、请求分派和维护、负载均衡等功能[22]。应用网关对公共功能（例如身份认证）的统一处理，既可提升效率又可以减少业务服务的冗余处理。应用网关是一种无状态服务，可以在用户请求量大的情况下，采用横向扩展的方式承接更多的用户请求。

2 基于网关链的多链模型

2.1 多链模型

针对复杂性的业务场景，本文提出基于网关链的多链模型，从子链管理、业务分片、事务性管理、链上链下数据存储四部分进行优化整合，使得该模型具有可扩展、高性能等特点。本方案多链模型如图3 所示，现给出如下定义。

图3 方案模型Figure 3 Scheme model

网关链(Gateway Chain)：系统中生成的第一条链，负责整个区块链网络中的身份认证、请求转发和逻辑链管理，主要由联盟链或私有链构成。

逻辑链(Logic Chain)：部署实际业务合约，执行业务逻辑的区块链，主要由联盟链或私有链构成。

链下存储模块(GSDB/TXDB)：缓存链上状态与交易信息的模块，用于加快查询速度。

模型在网关链将对请求进行认证授权与动态路由，如果认证合法，则将请求动态路由到指定的业务链进行处理。逻辑链针对实际应用场景的具体业务逻辑，提供了事务性的操作接口，确保并发场景下的事务一致性，并返回确定性结果。链下存储模块采用NOSQL 数据库对链上数据进行缓存，以加快查询速度。同时增加一致性组件进行实时的验证链上链下数据是否一致，当发现链下数据被篡改时，能够及时恢复至正常数据。

2.2 模型中的业务流程

多链模型中的业务流程如图4 所示。1）用户将数据上链请求发送至网关链。2）网关链根据上链请求中的签名信息进行统一身份认证，认证无误后将请求透传给路由合约；若认证失败，则返回给用户一个认证失败消息。路由合约在收到上链请求后，对请求中的业务ID 等信息进行解析，获取对应的逻辑链路由标识信息，然后按照逻辑链路由规则将请求派发给对应的逻辑链；若解析失败，则返回给用户一个拒绝消息。3）逻辑链的代理合约作为统一的数据接口，在收到上链请求后，首先对所需交互的业务合约发起事务控制，锁定需要操作的资源，然后将请求中的所需要对资源的操作发送给业务合约，若业务合约均执行成功，则解除事务控制并返回上链执行成功的消息；反之，若有一个业务合约执行失败，则执行事务回滚操作并返回上链执行失败的消息。4）当业务合约执行成功后，链下存储模块将接收到对应业务合约的状态更新事件，然后将事件中相关的状态缓存到数据库中。

图4 业务流程Figure 4 Business flow

3 多链协同方案

如图5 所示，为统一管理多链身份、保证多合约间事务性与链上链下一致性，本文提出了一个多链协同方案，该方案包括身份认证及权限控制、路由匹配、代理合约及事务性保证、链下存储及一致性保证四个模块，具体的模块详述如下。

图5 多链协同方案Figure 5 Gateway multi-chain model

3.1 身份认证及权限控制

在身份认证及权限控制方面，采用基于属性的访问控制的智能合约实现，替代原有基于节点证书的访问控制策略。在此基础上，仅要求用户拥有网关链节点证书以及被请求资源所拥有的属性即可进行访问，满足更细粒度场景需要，简化身份管理难度，大大增加身份管理的灵活度。访问控制智能合约中的授权算法如下：

Algorithm 1Authorization

3.2 路由匹配

路由匹配由路由智能合约实现，包括请求派发、管理逻辑链及负载均衡的功能。通过路由更改接口对路由表进行动态调整，实现对逻辑链的动态分片及负载均衡。若同一个业务由多条不同分工的逻辑链协作完成，可根据分工的不同配置路由范围参数，例如将UID 范围1∼100 的请求派发给逻辑链1，将UID 范围101∼200 的请求派发给逻辑链2，以此实现逻辑链的分片。当现有逻辑链无法承担当前业务需求时，可采用更改路由配置的方式将请求引流到新的逻辑链，减少单链压力，实现业务的动态扩展。当派发请求给逻辑链时，实际上派发的目标是逻辑链节点，而逻辑链往往由多个节点组成，每个节点的性能存在差异，为实现派发请求时逻辑链节点的负载均衡，采用加权轮询法，对节点设置权重，根据权重进行轮询派发。

路由智能合约中对逻辑链调用的实现依托于当前智能合约丰富的语义基础，用户将逻辑链路由的相关信息（例如逻辑链节点证书信息与路由匹配标识）注册到路由合约后，路由合约即可动态创建逻辑链客户端对象，实现对逻辑链的请求派发。路由合约对请求派发的过程中，并不需要对请求消息进行数据处理与存储，即该过程不需要网关链节点间的共识，以承接更大的访问量。路由智能合约中的数据结构采用前缀树实现，路由匹配算法如下：

Algorithm 2Route matching

路由匹配算法通过传入逻辑链标识（chainID）与智能合约集（chaincodes）两个参数，然后返回智能合约对象集。其中，逻辑链标识代表请求的哪一条目标逻辑链，智能合约集代表需要调用目标逻辑链中的哪些业务合约，智能合约对象集代表用于发起智能合约调用的对象的集合。首先，根据逻辑链标识查找到对应逻辑链的智能合约前缀树，智能合约前缀树保存了智能合约与智能合约对象的路由关系；然后，通过智能合约前缀树查找到用于调用智能合约集所需要的智能合约对象集，经判断智能合约集均符合条件；最后，返回智能合约对象集。

3.3 代理合约及事务性保证

在实际场景中，多个业务之间的协作在所难免，也就需要一种机制来使多个合约之间协作时能确保事务一致性。如图6 所示，本文采用了基于代理合约的方案，确保逻辑链中的业务合约之间的事务一致性，同时将代理合约作为逻辑链唯一对外的智能合约，统一对外的接口规范，即用户仅需知晓代理合约的接口详情，实现对其余业务合约的接口详情的隐藏。

图6 代理智能合约解决方案Figure 6 Proxy smart contract solution

基于链内智能合约可以相互调用的基础，代理合约可通过合约调用接口对业务合约进行相关操作，并结合TCC 事务方案解决业务合约间事务一致性问题。代理合约中使用的TCC方案，包括Try、Confirm、Cancel 三个事务性操作，Try 需要向被调用的业务合约发起资源检查和资源锁定操作，Confirm 将在Try 都成功的基础上执行事务提交操作，Cancel 将在有一个Try 失败的基础上进行事务回滚操作。基于TCC 方案的事务一致性算法如下：

Algorithm 3Transaction consistency

为确保代理合约调用的规范性，需约束业务合约实现的方法接口。要求业务合约在实现Confirm 接口的基础上，再实现Try 和Cancel 两个接口，可采用以接口名加操作后缀的方式。以转账接口TransferAsset 为例，需要再实现TransferAsset_Try 和TransferAsset_Cancel 两个接口，其中TransferAsset 默认为Confirm 操作。

3.4 链下存储及一致性保证

针对读写操作混合于一体的区块链网络，本文提出在区块链场景下读写分离的方案，其中读写操作分别由链下存储模块和逻辑链承担。如图7 所示，链下存储模块包括数据库、同步组件（Sync）和一致性组件(Consistency)。数据库包括存储世界状态的数据库（GSDB）和存储交易详情的数据库（TXDB）。同步组件负责将最新区块所包含的信息同步到链下数据库。一致性组件通过对比链上信息与数据库信息的差异性，并在存在差异的情况下通过恢复链上信息到数据库来确保链上链下数据的一致性。在实际应用场景中，可采用一条逻辑链对应一个分布式数据库的配置方式来减少存储模块的复用，同时增加可移植性。

图7 链下存储模块Figure 7 Off-chain storage module

3.4.1 同步组件

同步组件通过主动拉取区块与被动接收区块事件来维护最新区块状态，在初始化时采用主动拉取的方式获取当前链上所有区块，初始化完成后，为防止区块事件通知的延迟与丢包，采用定时主动拉取与被动接收区块事件协同的方式获取最新区块。为避免重复获取相关区块，减少区块同步的冗余，同步组件中将维护一个已同步区块的位图信息。最后，对获取到的区块进行反序列化，按照区块格式解析出所需交易信息与状态信息，并转储到相应数据库。主动同步算法如下：

Algorithm 4Active sync

3.4.2 一致性组件

一致性组件的功能是确保链下数据被篡改后能够及时发现并恢复。链下数据检查的方式分为定时随机检测与增量检测。定时随机检测在指定间隔时间内随机抽选部分链下状态与链上状态进行比较，若出现被篡改的情况，则在恢复被篡改数据后进行覆盖检测；增量检测将检查链上链下数据是否一致，若出现被篡改、缺失、多余的数据条目，则相应采取恢复、插入及删除操作。增量检测的策略是从后往前遍历区块，以确保链下存储最新状态，同时采用基于通道通信的多协程分层检测机制，将区块获取、区块解析、交易解析、数据一致性检测流程并行处理，提升检测速度。随机检测的算法如下：

Algorithm 5Random detection

4 实验和分析

4.1 性能测试

本方案采用Hyperledger Fabric 作为测试环境，Hyperledger Fabric 通道作为测试区块链，智能合约由Go 语言编写。本实验的硬件配置如下：CPU 为11th Gen IntelⓇCoreTMi5-1135G7@2.40 GHz，RAM 为16 GB，操作系统为VMware Workstation 16 Pro 上安装的Ubuntu20.04。

本实验的主要目的是测试该多链协同模型的交易吞吐量，并与单链模型进行对比。实验中采用一条逻辑链对应单个节点的配置，即在多链协同模型下增加一个节点就新增一条逻辑链。由于交易上链过程中主链并不参与共识，则主链节点个数对交易吞吐量的影响忽略不计。在测试中，将单链模型的节点与多链模型中的节点个数依次从1 节点增加为6 节点，测试的交易数据大小为16 kB，测试出两种模型在不同节点数目下的交易吞吐量结果如图8 所示。从图中可以得知，在相同硬件配置环境下，多链协同模型的交易吞吐量随着节点数的增加而逐步增加，受硬件配置环境的制约，其增幅趋于平缓。同时单链模型受共识性能的影响，交易吞吐量随着节点数的增加而下降。可以看到，采用多链协同模型下的交易吞吐量要高于传统单链模型下的交易吞吐量。

图8 交易吞吐量Figure 8 Transactions per second

4.2 可扩展性分析

1）网关链可扩展性。多链协同模型中网关链负责身份认证和路由转发，当身份配置信息或路由配置信息产生变更时，网关链节点才需要进行共识。当网关链中某一节点收到上链请求消息时，由于区块链节点存储冗余的特性，节点拥有全量的身份信息与路由信息，其自身可实现对消息来源的身份认证与路由派发，该过程对上链请求的相关操作不需要进行共识。由以上分析可知，网关链可承受的上链请求量与网关链节点的数目呈正相关，在多逻辑链的情况下，网关链通过扩展节点数量并不会成为整个系统的性能瓶颈。但是，由于要求逻辑链无条件信任网关链的身份认证结果，这种信任关系容易在单一机构内完成，不易在多个机构间实现。

2）逻辑链可扩展性。当某条逻辑链的数据量达到存储上限后，系统管理员可将该逻辑链的路由状态设置为可读模式，然后通过增加逻辑链并更改路由配置的方式，将之后的上链数据引流到新的逻辑链，实现对逻辑链存储的扩展。当某条逻辑链不足以承担上链数据时，可将部分上链数据重新引流到新增的逻辑链，从而提升对系统整体的吞吐量。

4.3 读写性能分析

在本方案中，逻辑链采用了读写分离的方案处理读写操作。当产生并发的读写操作时，写操作事件在逻辑链中执行，读操作事件在链下数据库中查询结果，该方案减少了读操作对逻辑链的操作，避免了读写并发所引起的逻辑链数据库事务性操作，提升了逻辑链的读写性能。其次，用户可根据实际业务场景对链下数据库进行选型，提升系统的读性能。

4.4 方案比较

针对本文提出的联盟链多链协同方案，通过与其他同类型的多链方案对比，结果如表1所示。

表1 方案对比Table 1 Schemes comparison

首先从身份管理角度来看，文献[10,24] 都是采用子链进行自主管理身份，导致多子链间的身份管理难度较大，本方案与文献[23] 均采用了统一的身份管理，简化身份管理难度。其次，从适用多业务场景的情况来看，文献[23] 仅适用于特定的应用场景。最后，从支持读写分离与支持合约间事务性来看，上述文献均未设计相关的方案，无法保证多业务合约协同下的事务一致性。通过与上述文献中的方案对比，本文提出的联盟链多链协同方案采用统一的身份管理，并结合读写分离与合约间事务性很好地满足了多业务场景的应用需求。

5 结语

近年来，日益复杂的应用场景对现有区块链模型提出了新的挑战。本文针对几种区块链多链模型进行了研究和总结，通过分析得出现有区块链多链模型在面对复杂应用场景时仍在权限管理、业务拓展、读写集中和多合约间弱事务性方面存在不足。在此基础上，提出了基于网关链的多链模型与多链协同方案，并通过实验和分析证实，该方案在可扩展和交易吞吐量等方面均有明显提升。但本文提出的多链协同方案依旧存在一些不足，下一步的工作将针对逻辑链间的事务性以及链下存储的安全性进行优化，并将其应用到实际业务场景中。