面向超级账本Fabric 的多通道分片技术研究

刘 洋，林致远，张玉玺，蒋 琳，吴宇琳

1.哈尔滨工业大学（深圳）计算机科学与技术学院，广东深圳518055

2.鹏城实验室，广东深圳518038

3.广东省安全智能新技术重点实验室，广东深圳518055

随着比特币和以太坊等加密货币的兴起，全球市场上出现了大量的区块链系统。区块链的分布式账本技术提供了一种以安全和可验证的方式进行交易的方法，而无需可信任的第三方。通俗来讲，区块链系统根据时间序列生成数据区块，并以顺序结构的形式组成一个链形式结构，同时采用密码学的方式实现不可篡改的分布式账本。

区块链系统按开放程度可以划分为公有链、私有链、联盟链三种类型。公有链，如比特币[1]和以太坊[2]，任何节点都可以加入，运行事务的逻辑与交易的数据对外透明，具有一定的数据安全及隐私泄露风险。同时公有链通常使用较为复杂的POW 共识算法，且事务只能串行执行，极大地限制了区块链系统的吞吐量；私有链中的节点则需要授权才可以进入，并且节点之间的地位不同，节点的操作权限也不同，中心化现象较为严重，只适用于特定的应用场景。此外，在无许可区块链中，节点不能立刻确定现有的加入在自身账本顶部的数据块是稳定的。只有当数据块在计入账本中足够长时间后，才会得到确认。因此，无许可区块链的吞吐量等性能非常有限，而联盟链的性能相对公有链有着很大的提升。

联盟链介于公有链与私有链之间，同时具备部分去中心化的特性。节点需要授权进入联盟链组织中，联盟链中各个对等节点之间权限相同。同时，联盟链更改了原有无许可区块链的交易流程，数据区块写入区块链账本后，该数据块便会被认为是最终确定的。这种交易流程大大提高了区块链的吞吐量性能，大多数商业应用也更青睐于许可区块链的解决方案。其中，Hyperledger Fabric[3]是一个具有代表性的联盟链平台，由于其广泛的商业应用而倍受关注，本文选择Fabric 区块链系统作为研究对象。

Hyperledger Fabric 作为目前最受欢迎的企业级许可区块链系统之一，目前正被用于许多不同的应用中，例如Everledger[4]和SecureKey[5]。通过限制参与共识过程的节点数量，达到在相对较短的时间内达成共识的效果。Fabric 系统针对传统公有链“排序-验证”架构下只能顺序执行交易的问题，提出了“执行-排序-验证”的新型事务处理架构（EOV 架构），提高了系统整体的吞吐量。在执行阶段，客户端将事务发送给背书节点进行模拟执行，背书节点在事务执行完毕后将执行结果返回给客户端。在排序阶段，客户端将事务发送给排序节点集群，排序节点按照事务的到达顺序达成共识，打包成区块，并将该区块广播给通道内的所有对等节点。在验证阶段，通道内所有对等节点将会对该区块内的事务进行验证，以确保满足背书策略，并在确保交易执行生成数据的读写集后，读集中变量的账本状态没有变化，同时块中交易会备注是否有效。最后，Peer 节点将最终区块提交到本地区块链结构中，有效的交易将会被追加到状态数据库中，并把事务的交易结果通知给客户端。

分片是提高区块链系统扩展性及吞吐量的方法之一。区块链内主要的分片可分为两类：一类是在各个分片中对交易进行处理后，整合在唯一账本内，形成最终一致性账本；另一类是不同的分片来记录不同的事务，相当于多条链并行处理。文献[15] 提出了基于Hyperledger Fabric 的通道扩展方案。但是这项工作并没有定量地分析以及对其他许可区块链系统的适用性并不清晰。文献[16] 提出在每个分片上运行一个基于实用拜占庭容错（practical Byzantine fault tolerance,PBFT）算法[17]的共识协议，并要求共识节点运行可信硬件，该方案的使用条件相对苛刻难以大规模使用。在现有的区块链的分片方案中，大部分方案需要额外消耗资源来组建分片委员会，此外，在跨分片的数据交易中现有的方案会产生较大的时延，从而影响整体的性能。

基于以上问题，本文首先提出了一种基于Fabric 管道的动态分片方案，针对区块链系统的事务吞吐量进行了改进尝试。针对当前Fabric 系统的事务吞吐量进行了系统性分析，并根据各部分的延迟大小确定了当前事务交易的瓶颈。其次，根据客户端事务发送的速率，对当前交易通道进行动态复制，并针对交易数据以及分片的通道进行一致性哈希来选择分片后的通道，进行并行背书以及验证。最后，将新区块提交到主账本内，确保Peer 节点之间账本的一致性，并更新世界状态。本文的贡献如下。

1）从实验和理论的角度分析了当前Fabric 的交易流程，并对Fabric 中各阶段的处理能力进行了实验分析，针对不同的生成区块参数数据进行了调整，主要针对原始Fabric 的吞吐量、延迟、事务成功率进行了一定的分析。

2）基于上述实验，提出了一个基于多通道的动态数据分片的实验方案，并以Hyperledger Fabric v2.4 版本为基础，使用该方案对当前交易流程进行改造，形成新的多通道扩展的Fabric结构。

3）将多通道扩展的Fabric 与传统Fabric 在Smallbank 基准测试和自定义工作负载下进行对比测试实验，以检验改进成果的正确性。实验结果显示，基于多通道的分片方案实现了更高的吞吐量以及较低的交易延迟。

1 相关工作介绍

目前有一些针对Hyperledger Fabric 的性能优化研究方案，如文献[6] 通过减少交易流程中的计算和I/O 开销，并针对缓存、并行运算等提出优化方案，将Fabric 事务的吞吐量提高到20 000 个事务/s。另有一些学者[7-8]研究了Fabric 系统的配置参数对吞吐量等性能的影响，并提出了改进意见。文献[9] 研究块大小、背书策略、通道、资源分配、状态数据库选择等配置参数对Fabric 性能的影响，并针对这些影响提供了MSP 缓存、并行VSCC 验证等优化方案。尽管上述方案对Fabric 的性能提升有所增益，但这些解决方案的核心仍然依赖于经典的共识算法，可扩展性增益却并不会很高。区块链分片技术是现有解决区块链性能问题的方案之一。分片技术是一种针对分布存储、计算和通信以节省资源和提高系统可伸缩性的技术，可以同时满足低延迟和高吞吐量的目标。

Elastico 第一个将分片应用到区块链的工作，该方案对区块链网络以及交易事务进行分片[10]，然而其无法处理跨分片事务，同时只能使用较小的分片大小。还有很多针对公有链的分片方案，如Monoxide[11]、RapidChain[12]、Omniledger[13]等工作，虽然提高了交易的性能，但却很难同时满足可扩展性与安全性的需求。此外，这些分片方案需要额外消耗资源来组建分片委员会。文献[12] 在RapidChain 中提出了一种基于委员会的内部共识算法，该方案通过对状态进行分片，从而对数据的存储方案进行了优化。然而，这种方案需要周期性的分片，每次分片都需要对数据进行迁移，增加了系统的负载。文献[14] 提出了一种轻量级的智能交易放置策略以减少跨分片交易的数量，该方案将已经产生关联或者即将产生关联的交易部署到相同的分片中，并维护分片之间的负载平衡。然而，该方案需要客户端来测量区块链网络的状态并运行事务放置算法，给客户端增加了压力。

而针对许可区块链系统，文献[15] 提出了基于Hyperledger Fabric 的通道扩展方案。然而，这项工作并没有定量地分析以及确定其方法的效益。由于该方案依赖于UTXO 模型，对其他许可区块链系统的适用性并不清晰。已证明的超级账本（Attested HyperLedger,AHL）[16]同样是针对Fabric 的分片方案，该方案在每个分片上均运行一个基于PBFT[17]的共识协议，并要求共识节点运行可信硬件，以防止拜占庭节点产生混淆。

2 准备知识

2.1 Hyperledger Fabric 系统架构

Hyperledger Fabric 是一个许可的区块链架构，其由IBM 和Digital Asset 提交给Linux基金会，是目前最受欢迎的企业级区块链框架之一[18]。Fabric 采用了松耦合的设计，将共识机制、节点运行、身份验证等组件模块化，使之在应用过程中可以方便地根据应用场景来选择相应的模块。Hyperledger Fabric 系统中的节点类型主要分为三类。

1）Peer。该类型节点主要针对智能合约的执行、交易提案的背书批准以及数据块的最终验证。Peer 节点会存储账本以及智能合约，负责链代码及其生命周期的执行，是区块链网络的基本元素。

2）Orderer。该类型节点会对Peer 节点背书后的事务进行排序并生成数据块。因为Fabric用确定性共识算法，所以Peer 节点所验证的区块都是最终的和正确的。账本不会像其他分布式以及无需许可的区块链中那样产生分叉[3]。

3）Client。客户端属于轻量型的网络节点，通常使用Hyperledger Fabric SDK 来绑定某个Peer 节点并与区块链网络进行通信。

Hyperledger Fabric 采用“执行-排序-验证”三步架构达到共识，与原有无许可区块链“排序-执行”的交易模式不同，数据区块写入区块链账本后，该数据块便会被认为是最终确定的。同时，执行和验证阶段可以并行化处理事务，这种交易流程大大提高了区块链的吞吐量性能，大多数商业应用也更青睐于Hyperledger Fabric 区块链系统的解决方案。其具体的执行流程主要包括以下三个方面，如图1 所示。

图1 Fabric 交易流程图Figure 1 Fabric transaction flow chart

1）执行阶段。在此阶段，客户通过封装了gRPC 服务和签名服务的Fabric SDK，将事务提案发送给背书策略指定的一个或多个背书节点。背书节点会根据客户端所指定命令，参数运行对用的链码，并生成对应的读集与写集。在背书执行阶段并不会更新账本数据。背书节点执行完链码后，对事物提案进行签名，并返回给客户端节点。客户端会根据背书策略检查接收到的提案，当结果相同回应提案数量满足背书策略时，便会打包并发送给Orderer 节点集群。

2）排序阶段。在此阶段，Orderer 节点集群将根据共识协议生成交易事务，目前Fabric 主要包括Solo、Kafka 和Raft 三种公式协议。本文所基于的Hyperledger Fabric v2.4 使用Raft协议。Raft 协议中的有序簇分为跟随者和引导者。身份为跟随者的订购者通过gRPC 服务将收到的交易转发给领导者。在排序阶段并不会不检查交易的具体内容，因为数据是被封装在envelope 中。Orderer 集群在接收到一定数量的事务或者达到时间限制，会将一批事务按顺序打包到一个块中。Raft 共识保证跟随者的日志与领导者的日志一致，从而实现有限状态机的复制。这样，每个对等体都可以从排序器集群中的任何节点获得生成的块。

3）验证阶段。在这个阶段，各个Peer 节点收到Order 发送的块后，会按照块中事务的顺序依次对事务的读集与写集进行验证。当一个事务满足背书策略并且其读取集合中所有密钥的版本都是最新版本时，此时事务满足MVCC 条件，便会将该事务标记为有效，反之则将之标记为无效事务。Peer 节点会将所有事务添加到区块链账本中，但对于无效的事务，Peer 节点不会将之更新到状态数据库中。

2.2 分片技术

分片技术被认为是提高区块链性能及可扩展性最有前景的链上方案之一，有着不牺牲中心化程度便能提高区块链性能的特性。这种技术通过将区块链分成多个部分来实现，每个部分都可以独立处理交易和存储数据。分片技术最早被应用在数据库之中，将大型数据库进行更细致的划分，使得更易于数据的管理与扩展。

区块链的分片技术主要分为两种类型，分别是针对网络的分片与针对数据的分片。针对网络的分片旨在通过将网络节点划分为多个组来提高网络传输效率，而针对数据的分片则通过将数据存储在不同的节点上，每个节点可同时对多个分组的交易并发处理，提高数据处理能力。区块链的分片技术主要面临着以下挑战。首先是针对分片内，由于节点减少或者账本存储数据减少等因素，会出现针对Pow 的51% 攻击以及针对PBFT 的女巫攻击。另外，针对跨分片的交易，可能会出现双花问题，以及跨片交易的可靠性和交易效率问题对当前网络的吞吐量影响较大。联盟链在进行分片后，通常不需要再进行配置，分片中的记账权往往在少数确定的节点中，因此，联盟链的分片安全性较高。

3 多通道分片的Fabric 架构

3.1 多通道扩展分析与系统模型术

在Hyperledger Fabric 中，每个通道都有一个完全独立的账本。在之前的工作中[3]，通道被定义为完全独立的区块链和完全独立的世界状态，包括命名空间，与系统的其他状态无关。当节点拥有多个通道的使用权限时，应用程序和智能合约便可以在通道之间进行通信，以便在通道间访问账本信息。当节点同时属于多个通道，并且可以满足各个通道的背书策略时，便可在多个通道之间进行通信。这就是验证策略：客户端需要验证该策略，以便相信他们有权限处理通道中发生的事务。当通道A 希望与通道B 进行交易时，通道A 的对等节点可以同样有效地实现通道B 的客户端，因此通道A 的对等节点在接收到通道B 的请求时，便可验证B的验证策略是否满足。

基于以上所描述特性，我们设计了一个动态的区块链生态系统，在这个生态系统中，新的通道可以根据需要动态创建，并且可以随着时间的推移而进化，以满足可伸缩性的需求。在原有的Fabric 架构中，多个通道之间无法对同一类交易进行并发的处理，因为多个通道之间存在命名空间的隔离。在这个方案中，在特定情况下消除了多通道间的命名空间隔离，可以让同一类交易并发进行背书。对现有的通道状态进行复制，但并不复制已有的账本数据，产生一个新的通道编号为i，每个通道Ci包含初始通道的所有用户U，并共享用户组U所给定的业务逻辑，以及可跨通道的分布式账本L。将不相交的数据分散到不同的通道中，各通道可以并行地进行数据背书和数据的验证，保持各个通道的小规模系统吞吐量，从而提高总体的吞吐量。通道的水平扩展结构如图2 所示。

图2 Fabric 多通道事务交易流程图Figure 2 Fabric multi-channel transaction flow chart

本系统基于许可的区块链通信模型，用户需要显式注册才能成为系统的成员，并通过异步网络进行通信。用户的角色与现有大多数许可的区块链一致，主要包括客户端、对等节点。利用区块链提供的软件开发工具包（software development kit,SDK）服务，以交易的形式提交请求。验证器可以验证客户端的事务并将其提交到区块链上，以便处理相应的请求。同时，假设有一个成员管理服务用于维护成员的信息，这样成员就可以按需检索信息。注册表提供了相互识别成员的方法，并作为新成员的发现机制。用户u注册后，将获得一个用于链接用户身份的证书、相应的公钥与私钥，以及一些关于用户的附加信息。

基于多通道分片的Fabric，交易流程主要分为以下几部分：首先在初始阶段，联盟中的各组织会创建一个初始的通道；之后在客户端将交易数据发送到主通道进行背书之前，节点会查询当前通道的数据处理能力，倘若当前通道数据负载较高，则会向管理员节点申请创建新的通道，并将事务发送到新的通道上进行背书；背书时事务的签名等信息会消除复制通道的命名信息，只保留主通道的名称，并将背书结果发送到排序节点集合；最后将会对交易进行验证并保存到主通道的账本内，分片的通道并不会保存主通道的账本以保持事务的高并发状态。针对各个节点发送的交易数据，采用一致性哈希方法。首先，按照分片出的通道进行哈希映射，存储在哈希环结构上；接下来，对节点发送数据再次进行哈希来进行通道的选择；一定时间后，再修改通道的哈希环结构，从而保护数据的安全性。

3.2 多通道管理流程设计

通道是一个联盟中的成员彼此进行通信的主要机制，同时提供了一个联盟成员之间进行私有通信和私有数据的机制。通道提供了与其他通道以及整个网络的隐私性。

在Fabric 网络建立完成后，使用网络中的联盟X1 为内部的组织创建的一个初始化应用通道Channel1，假设当前组织包括Org1 和Org2。这个通道通过通道配置来进行管理，完全独立于网络配置。该通道的通道配置由Org1 和Org2 进行管理，它们在Channel1 上具有同等的权利。当两个组织的节点加入通道后，便可在该通道内共享私有数据，同时两个组织的管理员会对当前通道的配置信息进行备份，以便进行多通道的水平扩展操作。

在对通道的动态扩展的研究中，需要对节点参与的各个通道负载进行监控，从而实现在现有通道资源紧张的时刻，进行新通道的动态创建，以及对多分片通道的动态选择。因此在原有节点内部，增加了通道负载分析插件，并采用一致性哈希的方式，将通道分散在哈希环结构中，并对数据进行哈希后，一次访问环中的通道，直到遇到空闲的通道。若所有通道此时的吞吐量均超过设定的阈值，则客户端会向对等节点进行通道创建的申请，管理员节点会检测当前通道的数量，若符合条件，则会对主通道进行复制，得到一个新的通道并为新的通道进行编号命名，以便区分。数据传输流程如图3 所示。

图3 多通道分片数据交易流程Figure 3 Multi-channel fragmented data transaction process

1）当客户端节点发送数据时，客户端节点首先会询问Peer 节点当前通道状态，并返回第一个空闲的通道名称。若客户端未指定分片通道，则节点会对发送事务进行哈希随机选择一个分片的通道进行通信。

2）客户端将向该条通道进行数据发送，并指定背书节点。当事务到达背书节点后，会在当前通道内对客户端指令进行模拟执行。由于是在不同的通道内，所以该通道的链码空间与其他节点的空间相隔离。

3）当背书结束后，各个通道将背书结果发送给排序节点，此时对多通道数据进行融合。在排序节点内，将识别原通道的命名空间，并去除通道分片的标识记录，在主通道内将所有数据进行打包。

4）最终传送给主通道内的各个节点进行验证。算法步骤如算法1 所示。

算法1面向超级账本Fabric 的多通道事务分发算法

输入交易集Trans={t1,t2,···,tn},通道数C=n选择背书节点Peer={p1,p2}

输出上链结果Result

4 实验结果分析

本节将对改进的方案进行全面的实验评估。将描述实验环境及设备配置，以及所采用的工作负载环境，包括使用链码及测试环境。之后将介绍改进的成果，主要是每秒成果事务的吞吐量与事务延迟两个方面，并与原Fabric 架构以及现有Fabric 分片方案的吞吐量及时延进行了横向的对比。

表1 实验环境及系统参数配置Table 1 Experiment and system configuration

工作负载：为了与现有工作进行横向对比，使用与Fabric++相同的工作负载SmallBank作为实验中的测试链码。SmallBank 是BlockBench 中定义的非常适合测试区块链系统的标准基准。该工作负载模拟了一个典型的资产转移场景，主要包含6 种交易类型。首先是“CreatAccount”，该方法可创建N个用户，并为每个用户生成1 个支票账户和1 个储蓄账户，并进行随机的初始化操作。“TransactSavings”“DepositChecking”“SendPayment”“WriteCheck”“Agrammerge”这几个方法为在储蓄账户和支票账户之间的修改操作。“Balance”方法为会读取用户的支票和储蓄账户。在一次实验过程中，将以一定的概率进行随机读写测试，及以Pw的概率出发读取事件，以及以1-Pw的概率来出发4 个写方法中的其中一个。同时，在初始阶段采用Zipfian 分布对生成的N个用户进行选择，并通过设置skew 值来配置访问数据的数据分布情况。

测试方法：针对上述工作负载，分别采用了Caliper 测试工具及自行构建基准架构的方法进行实验。实验发现，Caliper 在发送率提高时，将会有更大的失败率无法将交易发送出去。因此，采用基于go v1.18.2 版本自行构建基准测试，首先将交易事务传入Channel 中，之后创建了1 个Worker Pool，创建了1 000 个Worker，并让所有Worker 异步进行工作，从交易管道中拿取交易进行发送。通过调用Gateway 包，对交易进行“执行-排序-验证”三个阶段进行监控，监控各阶段的延时情况与失败原因。每次实验将运行5 次上述测试方法，并对结果取平均值。

4.1 背书阶段时延分析

在多通道Fabric 区块链网络中，背书阶段各个背书节点将会并行执行背书任务，并将结果发送给排序节点，而排序阶段会对每个通道的数据进行合并整合。因此，多通道分片的排序阶段与原区块链网络在相同负载下的时延将会相同。但由于通道的数量增加，各个节点中不同的通道将会抢占CPU 资源，因此背书阶段的时延将会增加。

设定当前的区块链网络的链路传输时延设为Ds，数据传输带宽为Bbit/s，设定节点对数据的处理能力为αbit/s。单通道的背书阶段主要由三部分组成，分别是：

1）交易提案发送给背书节点的通信传输时延L1，当交易提案的大小为xbit 时，其大小满足

2）背书节点数据流量解析时延L2，当背书节点接受数据大小为x时以βbit/s 的处理能力进行处理时，该阶段延迟大小满足

3）背书结果返回时延L3，背书节点将大小为δbit 的背书结果发送给客户端，延迟大小满足

与单通道区块链网络相比，L2阶段背书节点解析数据流量时延将随着通道的数量增加而扩展。当通道数量增加到N时，水平扩展结构的背书过程处理时延M2为

4.2 实验评估与结果分析

图4 所示为当前Fabric 的事务处理能力，确认时间以s 为单位。首先针对不同区块的大小对当前系统的时延和吞吐量分别进行测试，配置系统参数，并对实验结果进行分析。可以发现，Fabric 的吞吐量与区块大小成正比，但由于网络上事务负载的增加和更大的块大小会导致区块链的硬分叉。因此，为了实现更高的吞吐量而增加Fabric 的块大小，将损害区块链的安全性和去中心化，这类方案是不实际的。所以在接下来的实验验证以及对比实验中，将对区块的大小进行限定。

图4 Fabric 事务处理能力Figure 4 Fabric transaction processing capability

接下来，将对通道数量进行一个动态扩展，通道数量配置为[1,2,4,6,8,10]，并比较在多通道扩展情况下的延迟与吞吐量情况。图5 展示了针对多通道扩展结构下10 万个交易的平均时延情况，设定了当前区块大小为最多支持200 个交易，出块时间设置为1 s。此外，当1 s内没有数据会进行等待。可以发现，随着通道数目的增加，Fabric 的吞吐量逐渐增大，同时由于当前处于同一服务器内CPU 资源的竞争，延迟时间也逐渐提高。本方案与文献[16,19] 基于区块链网络、数据、状态的分片的方案在相同配置下进行了吞吐量及时延等的一系列对比，如图6 所示。从图中数据可以发现，本方案虽有着一定的优势，但时延相对较高，说明本方案所占用的处理器计算资源与存储资源更高。

图5 Fabric 多通道分片事务处理能力Figure 5 Fabric multi-channel slice transaction processing capability

图6 多通道分片方案与现有分片方案对比Figure 6 Comparison of multi-channel sharding scheme and existing sharding scheme

从上面的两个结果可以明显看出，基于多通道分片的框架可以使吞吐量和延迟保持稳定，TPS 最高可达2 500 以上。使用多通道并行化事务处理，可以对更多的事务进行背书及验证，从而提高了可伸缩性。确认时间的加快也意味着可伸缩性的提高。

5 结语

本文重点研究了基于多通道分片的Fabric 系统扩展方案，以提高区块链系统的交易性能。超级账本Fabric 更改了原有无许可区块链的交易流程，数据区块写入区块链账本后，该数据块便会被认为是最终确定的。这种交易流程虽然大大提高了区块链的吞吐量性能，但与主流交易系统相比，其性能仍有待提高。因此，本文提出了通道动态扩展的分片方案，主要针对交易的背书阶段进行并行处理，提高系统整体的性能，同时可以保证安全性与去中心化的特性。实验结果表明，本文多通道动态扩展方案相较原系统有着较大的性能提升，但同时也消耗了更多的计算以及存储资源。接下来将考虑针对排序以及验证阶段的分片扩展进行分片扩展设计，并进行详细的实验分析与评估工作。