区块链是一种分布式账本技术, 具有去中心化、防篡改、匿名性等优点^[1], 在金融^[2]、教育^[3]、能源^[4]等诸多行业有着广泛的应用. HyperLedger Fabric (后文简称Fabric)^[5]是Linux基金会主导、IBM开发的一个模块化、可扩展的开源联盟链系统. 目前, 已经有许多政府和商业组织使用Fabric去支持联盟业务^[6].

在文献[7-9]中的性能测试实验表明, Fabric的性能比传统联盟区块链更优秀, 吞吐量能达到三千多 TPS (每秒交易数), 但是其与实际的中心化交易系统几万甚至几十万的TPS存在较大差距. Fabric的性能无法支撑现代金融、物联网等领域的应用, 因此需要进一步的优化.

分片是一种能够有效提升区块链性能的技术^[10]. 目前在公有链或者联盟链上的分片方法^[11-13]无法很好地应用于Fabric, 有以下两点原因.

1) 传统联盟链采用两阶段交易模型“排序-执行”, Fabric采用三阶段交易模型“执行-排序-验证”. 交易的处理逻辑存在较大差别, 导致分片后交易处理逻辑需要重新设计.

2) 很多区块链分片方法的分片粒度比较粗, 或基于智能合约或基于账户数据. 如图1所示, 因为区块链上的数据存在热点访问, 分片粒度较粗容易导致负载不均衡问题.

在Fabric中, 智能合约分为逻辑代码和状态数据两部分, 状态数据被存储在key-value类型数据库中. 如图1所示, 为了有效解决智能合约热点访问问题. 本文将同一智能合约的键值数据分配到不同分片, 实现更细粒度的分片.

细粒度分片虽然有效解决了智能合约的热点访问问题, 但是容易引发更多的跨片交易, 影响分片改善性能的效果. 本文观察发现客户发送交易读写的数据存在时间局部性, 故提出启发式的交易提案路由表, 减小跨片交易的代价.

综上, 本文使用细粒度的键值状态分片方法改造Fabric, 在优化Fabric性能的基础上, 解决智能合约热点访问问题和减小高跨片交易占比对分片性能的影响, 为使用Fabric搭建联盟链的组织或企业提供一种改善Fabric扩容能力的方案. 本文主要贡献如下.

1) 实现Fabric细粒度键值状态分片, 引入跨片排序节点和两阶段提交保证跨片交易的一致性和原子性, 优化Fabric性能并解决智能合约热点访问问题.

2) 提出启发式的交易提案路由表方案, 降低跨片交易跨片访问带来的时延, 减小高跨片交易占比对分片性能的影响.

3) 在Fabric仿真系统上实现本文的分片方案并进行性能测试. 实验结果表明, 细粒度键值分片Fabric的性能比智能合约分片Fabric更好, 并且有效解决了热点问题. 在跨片交易占比高时, 使用交易提案路由表可以有效阻止分片Fabric性能下降.

1 相关研究

目前有许多优化Fabric性能的研究工作. Yuan等人^[14]提出使用广义随机 Petri 网 (GSPN) 来分析Fabric系统的性能, 通过分析不同配置对系统性能的影响提出一种配置选择方法来最大化系统吞吐量. Gorenflo等人^[15]提出了一系列优化措施, 例如分离交易元数据并只对交易ID排序、缓存区块解析、分离验证节点的背书功能和提交功能避免硬件资源竞争等, 从而减少Fabric排序阶段和验证阶段的I/O开销和计算开销. Sharma等人^[16]提出在排序阶段构建交易依赖图, 通过分析依赖图丢弃部分交易, 重排序交易以最大化交易成功数. Ruan等人^[17]在前者基础上全面分析交易冲突, 提出更细粒度的冲突处理. Hang等人^[18]提出一种基于模糊逻辑的交易流量控制方法来提升Fabric交易处理性能.

以上对Fabric的研究通过优化参数配置、减少资源开销和交易冲突等方式优化Fabric性能, 但是无法有效地利用新增的服务器去提升性能, 不能改善Fabric的横向扩容能力. 横向扩容能力是指当服务器数量增加后, 系统的吞吐量按比例增长的能力. 分片将区块链网络分割成多个区域, 每个区域作为一个分片. 交易根据特定规则发送到不同分片, 实现交易的并行处理. 在实际应用中, 可以利用新增服务器资源

创建分片, 提升总体吞吐量. 因此引入分片技术能够改善Fabric的横向扩容能力. 目前有一些引入分片改造Fabirc的研究工作. Androulaki等人^[19]提出了基于通道的分片设计, 其将每个通道(在Fabric中, 一个通道管理一条区块链)作为一个分片, 通道之间通过预言机来发现通道和验证数据有效性. 但是该工作没有通过定量实验证明方案的有效性. Thakkar等人^[9]提出了稀疏节点的概念, 该节点会有选择性地提交区块中的部分交易, 从而避免组织内多个节点间冗余工作的问题. 让每个稀疏节点通过过滤交易来执行和验证区块中的部分交易, 实现交易分片. 其在验证阶段采用了依赖分析和数据同步的方式保证并发交易的隔离性, 分片间的同步消息复杂度是O(N²)的, 效率较低.

以上Fabric分片研究集中于设计和实现一个Fabric分片系统, 但都没有考虑智能合约热点访问和跨片交易对分片性能的影响, 且存在缺乏实验分析、效率不高等缺点.

在公链分片领域有许多工作研究如何减少公链分片系统中的热点访问和跨片交易. Hong等人^[20]设计了一个分层次的分片系统, 通过让一些分片持有多个分片数据的方式将跨片交易转化为片内交易. Huang等人^[21]通过构建账户交易状态图并使用图分割算法重分配账户状态来实现分片的负载均衡. Li等人^[22]为重分配账户的迁移设计了高效安全的迁移协议. 以上公链分片研究都集中于公链领域, 无法支持Fabric这种三阶段交易模型的联盟链系统. 而且重分配的方法会要求额外的角色, 因为状态的迁移会打破状态与分片的映射关系, 需要额外的节点存储映射索引、管理元数据和计算重分片策略.

2 相关知识

Fabirc是一个联盟链系统, 由多个组织维护一个通道, 通道内各组织持有一致的区块链账本和世界状态. 每个组织的节点需要持有各自组织的证书颁发机构(CA)所颁发的身份证书来参与到联盟链的工作中. Fabric引入三阶段交易流程“执行-排序-验证” (EOV), 其与传统的两阶段交易流程“排序-执行” (OE)区别如图2所示. 以图2为例简单介绍Fabric的交易处理流程, 关于Fabric的详细知识可参考文献[5].

Fabric中有两种类型的节点, 一是Peer节点, 其参与背书和验证两个工作. 二是Orderer节点, 其参与排序工作.

智能合约执行: 客户端会根据想要调用智能合约的背书策略, 向多个组织的Peer发送交易提案, 提案里包含身份证书和调用智能合约的参数. Peer收到交易提案, 会进行合约执行. Fabric使用了MVCC (多版本并发控制)技术, 合约执行过程中会查询状态数据库生成读集合与写集合, 读集合里包含了合约调用过程中查询的对象的当前版本号, 写集合则包含了要修改的对象的新值. 此阶段不会将写集合更新到账本, 所以也称为“模拟执行”. 最后Peer会对这份结果进行数字签名, 代表组织为这份提案背书. 背书结果会被返回给客户端.

背书搜集: 客户端在搜集到满足背书策略数量的背书后, 会比较读写集结果, 然后将读写集合和有效的多个背书签名打包生成交易, 发送给排序组织的Orderer节点. Fabric通过背书策略来限制节点作恶行为, 所以排序服务可以使用非拜占庭的共识算法.

排序服务: 排序组织的Orderer节点收到交易后, 运行共识算法(目前v2版本Fabric默认共识为Raft^[23])对一定数量的交易顺序达成一致并生成区块. 将区块发送给各个组织的主节点Peer (由Gossip算法选举). 主节点通过Gossip算法在组织内部做进一步的分发.

验证提交: Peer收到交易后, 首先校验交易数据格式, 然后判断交易为配置更新交易还是智能合约调用交易. 若为后者, 则进入验证阶段: 先并发地验证各个交易地背书策略是否满足; 然后顺序地进行交易的MVCC检查, 具体是检查读集合中键的版本号与当前状态库中是否一致, 上述检查都通过的交易视为有效. 最后Peer将区块附加有效交易位图后保存到本地账本, 按顺序更新有效交易到状态数据库. 客户端可以通过Peer得知交易上链结果.

3 方案设计

在细粒度的键值状态分片下, 每个分片Peer的状态数据库只保存部分的键值状态数据, 区块链文件中的区块也只包含修改对应状态的交易. 设计Fabric的键值状态分片, 存在以下几个问题.

1) 如何计算一个键值状态数据应该分配到哪个分片, 即分片Peer如何判断一个交易所请求的数据存在于本地还是其他分片上.

2) 跨片交易在模拟执行阶段需要读取的数据不存在本地该如何处理.

3) 交易是一种分布式事务. Fabric利用排序服务保证分布式事务的最终一致性. 在排序阶段对于跨片交易该如何处理从而保证一致性.

4) 跨片交易对状态的操作应保证原子性, 即跨片交易对各个分片数据的操作应都成功或都失败. 各分片间如何对跨片交易的验证结果达成一致.

5) 细粒度分片导致的一个显然结果是交易跨片的概率增大. 对跨片交易达成一致的代价会导致性能下降, 该如何缓解这个缺陷.

本节后续部分对以上问题按顺序做出分析并提供解决方案.

3.1 状态数据的分片

在前文介绍过, Fabric中的状态数据以键值对的形式进行存储. 本节讨论如何计算键值对数据的目标分片. 数据分片的方案应当满足以下两个目标.

定义1. 平衡性: 不同分片之间的负载大小应该尽可能保持相近, 即分片负载维持平衡.

定义2. 单调性: 如果增加新的分片参与状态分片, 应该保证已分配数据能够被映射到新的分片或者原来的分片, 而不是被映射到其他分片.

本架构采用跳跃一致性哈希算法进行键值数据的划分, 其满足平衡性和单调性. 文献[24]中的实验证明, 跳跃一致性哈希算法相比经典的一致性哈希算法性能更好, 缺点是新增或者删除分片只能从分片序列的尾部进行, 而不能从中间删除. 考虑到Fabric的Peer拥有备份节点, 一般不会出现某一分片的Peer集体崩溃的情况, 所以不会出现删除中间分片的情况, 分片架构可用性不受影响.

算法1. 键值数据划分算法

输入: 数据键key; 分片数量N

输出: 目标分片序号X

1　 X←−1, j←0 ; // 初始化

2　设置随机种子random.seed(key);

3　 while (j<N) do

4　　 X←j;

5　　 r←random.next();

6　　 $\scriptstyle {{j} \leftarrow\lfloor({X}+1) / {r}\rfloor }$ ;

7　 return X;

键值数据划分算法的伪代码如算法1所示. 跳跃一致性哈希算通过线性同余算法(LCG)生成的伪随机数来决定key的映射关系. key会被作为种子生成伪随机序列, 从而保证了给定一个哈希桶数N时, 用同一个key作为输入, 算法的输出是确定的. 通过概率分析使得j的增加跳步进行, 算法时间复杂度从O(N)优化至O(ln(N)).

3.2 跨片交易的模拟执行

对于跨片交易, 可能出现智能合约执行过程中需要读的键不在本地状态库中的情况, 这时候需要进行跨片查询.

以图3为例, 客户端发送给PeerB合约执行请求, 调用智能合约中的函数T. 函数T在模拟执行过程中会读键A和键B的数据, 通过算法1计算键值数据所属的分片. 键B的数据存在PeerB的本地状态数据库中, 所以可以直接读取; 键A的数据存在另一个分片中, 所以PeerB通过RPC请求获取PeeA状态数据库中键A的值和版本号. 最终PeerB汇总生成读集合. 对于写集合, 因为是模拟执行不会直接写入数据库, 则直接根据智能合约执行过程生成.

3.3 跨片交易的排序

区块链作为分布式系统实现最终一致性的原理是复制状态机. 区块内部交易顺序在区块打包时固定, 区块链共识算法保证区块按序接收, 从而实现全局交易的按序接收. 分散的节点们初始状态相同, 并经过同样顺序的接受交易并更新状态, 最终达成一致的状态. 在分片Fabric中, 也需要通过以上的机制, 来实现分布式交易的一致性.

根据交易是否会跨片, 可以将交易分为跨片交易和片内交易. 为了解决并发交易读写冲突的问题, 需要一个在所有交易上的偏序关系, 其满足以下两个特性.

定义3. 片内可比较: 所有本分片涉及的交易之间有全序关系.

定义4. 冲突跨片可比较: 可能发生冲突的跨片交易之间有全序关系. 也就是说, 多笔交易的读写数据如果有重复, 应该能互相比较确认先后顺序.

为了满足上述两个特性, 在排序组织中根据功能不同设置以下两种类型的Orderer. 整个排序阶段的交易处理流程如图4所示.

算法2. 跨片交易拆分算法

输入: 跨片交易Tx

输出: 子交易关联表SubTxMap[分片号→子交易]

1. 初始化SubTxSet;

2. for readKV in Tx.ReadSet do //遍历读集合

3.　shardNum←计算readKV.Key的分片号;

4.　 if SubTxMap未存在 shardNum 键 then

5.　　SubTxMap[shardNum] ←SubTx;

6.　SubTxMap[shardNum].ReadSet增加readKV;

7. for writeKV in Tx.WriteSet do //遍历写集合

8.　重复相似步骤;

9. return SubTxMap;

跨片Orderer: 客户端的交易首先发送给跨片Orderer. 跨片Orderer通过扫描读写集判断交易是否跨片. 若为跨片交易, 则进行交易拆分. 如果一个交易的读写集数据涉及多个分片的状态数据, 那么这笔交易会被拆分成多笔子交易, 每笔子交易的读写集中只包含某一分片的状态数据. 跨片交易拆分算法见算法2. 跨片Orderer拆分的子交易会在跨片Orderer排序后发送给各个分片. 以上保证了冲突跨片可比较.

分片Orderer: 分片Orderer群运行Raft共识算法, 负责对涉及该分片的交易做排序并且打包出块. 总共会处理两种类型的交易, 一是片内交易, 二是跨片交易的子交易. 对于收到的片内交易, 按照时间先后进行排序; 对于收到的跨片子交易, 则会维持跨片Orderer的排序基础上, 将其插入排序缓存队列. 这样打包到区块里的交易就同时满足了片内可比较和冲突跨片可比较.

3.4 跨片交易的验证

在Peer收到交易后, 需要对交易进行验证, 验证后有效的交易才会提交到账本. 跨分片交易的验证提交, 其本质是分布式事务. 本文参考两阶段提交的工作模式, 设计了跨片交易的验证, 其流程参考图5.

首先, 每个分片会将子交易的读集合中键的版本号与数据库中对应键的版本号进行比对, 如果所有键的版本号相同, 则意味该分片中原交易涉及的数据状态与模拟执行阶段时保持一致, 验证标记为true, 否则标记为false.

然后, 各个分片的Peer会将子交易的验证结果提交给排序组织中通过Raft算法选举出的Leader节点, 由其搜集所有子交易的验证结果.

最后, Leader节点确认交易结果, 将最终结果返回给各个分片, 分片将交易进行提交.

分片Peer的跨片子交易验证也设置有超时机制, 这是为了防止网络分区(通信断连导致原有网络分割成多个子网络)使得部分子交易结果未知, 导致交易验证阻塞. 有两种情况, 一是Leader搜集子交易结果超时, 二是分片Peer节点等待总结果超时. Leader对于超时的子交易验证结果, 会标记为无效. 分片Peer节点等待交易验证超时, 则将子交易标记为超时状态加入队列并跳过, 后续涉及相同状态数据的交易的验证都会进入待队列等待. 当网络分区恢复后, 会查询实际结果, 重新标记交易状态并对相关数据进行重放. 实际中网络发生断连较短, 重放代价是可以接受的. 若断连时间较长, 意味着后续的区块都无法从排序组织接收到, 节点工作状态等同于崩溃. Fabric有崩溃重启的追赶机制.

3.5 交易提案路由

交易提案路由问题即请求路由问题, 具体指当客户端想要发出请求时, 如何知道连接到哪个节点. 在传统数据库的分区(分片)技术中, 请求路由的客户端或者转发服务器都可以根据分区规则直接计算出要访问的数据所在. 但是在Fabric中, 因为一笔交易的模拟执行可能存在判断分支逻辑, 在执行过程中才能判断需要读哪些键, 所以此时交易请求无法得知应该发往哪个分片.

如果一笔交易提案被发送到一个错误的分片Peer上进行模拟执行, 那么可能进行多次跨片读请求, 执行Peer就需要阻塞计算, 造成性能损失.

在Fabric中, 客户端发送交易提案给Peer时, 会带上客户身份证书用来证明用户身份. 观察发现, 在Fabric中同一个用户在短时间内多次调用的交易涉及的键值数据往往是相同的. 基于该启发, 设计了如表1所示的路由表. 每个分片Peer都会维护这样一张路由表, 路由表是一张哈希映射表, 键为交易提案的身份证书哈希值, 值内容为<是否转发, 转发目标>.

当一个交易提案被客户端随机发送到Peer之后, Peer根据提案中的身份证书计算出键, 在交易提案路由表中检索对应的条目, 若存在且标记转发, 则会进行转发并告知客户端, 转发后根据转发目标反馈, 会再次更新路由表; 若不存在或者标记不转发, 则在本地进行模拟执行. 在这次模拟执行的过程中若发现对某一分片X的跨片读次数大于本地读次数, 那么在执行结束后, 对交易提案路由表进行更新, 标记为<是, 目标分片X>.

表的容量根据启动配置设定上限. 若表满, 通过LRU算法进行替换.

3.6 总体流程

基于键值数据状态分片后的Fabric, 交易处理流程与原Fabric对比如图6所示. 分片后Fabric的Orderer和Peer节点根据启动配置会分配到不同的分片中, 每个分片并行地处理不同交易. 分片前后每个阶段的对比如下.

背书阶段: 与原Fabric相比, 基于键值状态分片的Fabric在交易执行背书阶段通过跨片读请求和交易路由转发两种方式, 分别解决跨片交易读数据不在本地的问题和多次跨片读代价过大的问题, 因此不同分片的背书Peer之间存在交互.

排序阶段: 通过增加跨片Orderer进行交易分割与冲突跨片交易的排序, 保证跨片交易的最终一致性. 分片后的排序阶段, 交易首先被发送给跨片Orderer. 在跨片Orderer, 跨片交易被分割排序后发送给各个分片Orderer; 非跨片交易直接被转发给各个分片Orderer. 分片Orderer为各个分片排序交易并打包出块, 各分片区块被发送给分片验证Peer.

验证阶段: 分片后的验证Peer在验证跨片交易时, 采用类似两阶段提交的工作机制, 让跨片Orderer作为协调者收集并分发跨片交易的验证结果, 保证跨片交易的原子性.

4 实验与分析 4.1 实验设计与配置

本节实现了Fabric的键值状态分片, 称为KVFabric. 首先为了证明该方法能够有效提升Fabric的性能和解决热点访问问题, 设计实验对比Fabirc、SmartFabric^[9](基于智能合约分片)、KVFabric在均衡负载和热点负载下的性能. 然后针对细粒度分片会导致跨片交易占比上升的场景, 设计实验测试KVFabric性能在是否增加提案路由表时受跨分片交易占比的影响, 从而证明交易提案路由方案的有效性. 最后, 将公链的分片重分配和状态迁移方法^[22]移植到SmartFabric上, 称为LB-Fabric, 设计实验对比LB-Fabric和KVFabric在改善智能合约热点访问问题上的表现, 证明KVFabric在解决这个问题上的优越性.

实验的配置如表2所示, 工作负载采用迷你银行智能合约SmallBank, 可以进行创建账户和转账等操作. 使用Docker创建多个容器模拟多节点工作并防止节点间发生资源竞争.

4.2 评价指标

本文采用系统吞吐量和交易确认时延作为性能评价指标. 两个指标的定义如下.

定义5. 吞吐量: 在某段时间内T内, 所有交易完成的数量S_Tx与该时间T的比值, 计算公式为:

$ {N_{{\textit{TPS}}}} = \frac{{{S_{\textit{Tx}}}}}{T} $

(1)

定义6. 时延: 从客户端发送交易提案到最终确认交易上链所需要的时间, 计算公式为:

$ {T_{{\rm{latency}}}} = {T_{{\rm{commit}}}} - {T_{{\rm{send}}}} $

(2)

吞吐量数据代表系统的处理负载能力上限, 时延数据代表用户感知的交易确认延迟. 实验过程中运行多轮, 对吞吐量数据计算平均值, 对时延数据采用中位数(第五十百分位数).

4.3 性能对比实验

本实验测试Fabric、SmartFabric、KVFabric这3个系统的吞吐量和时延随着提供节点资源数量的变化. 原Fabric系统没有进行分片, 所以增加节点意味着组织内Peer节点数增加. SmartFabric、KVFabric中则利用增加的节点建立新的分片. 实验中对SmartFabric、KVFabric设置了10%的跨片交易.

假设分片数量为N, 在链上部署N个功能相同的智能合约, SmartFabric中每个分片分配一个智能合约. 等概率调用N个智能合约的测试结果如图7、图8所示. 模仿热点问题, 设某智能合约调用概率为X, 其余智能合约调用概率合计为Y, 以X:Y=8:2概率进行调用, 测试结果如图9、图10所示.

Fabric因为在模拟执行节点实现了交易并行执行, 所以增加节点数可以增加交易吞吐量. 但因为在排序阶段和验证阶段交易都是顺序处理的, 吞吐量很快达到瓶颈. 因为节点各流程执行效率不受节点数影响, 故时延变化较小. 因为Fabric没有实现分片, 所以其在均衡负载测试和热点负载测试中表现一致. 无论在均衡负载或热点负载测试中, KVFabric的吞吐量随着分片数量的增加大幅领先Fabric, 时延因为跨片交易存在额外的处理流程而轻微增加. 在分片数为8时, 吞吐量提升226.9%, 时延增加18.4%.

在均衡负载测试中, SmartFabric的吞吐量和时延效果都略差于KVFabric. 因为在验证阶段随着分片数量的上升, SmartFabric每个节点广播子验证信息的代价增长速度大于KVFabric的两阶段提交代价.

在热点负载测试中, KVFabric的细粒度分片使得各个分片负载均衡, SmartFabric大量的请求都发送到一个分片上, 造成单分片过载, 其余分片过闲, 故前者性能表现优于后者. SmartFabric时延维持在3500 ms左右波动并轻微上升的原因是测试时延时的交易发送速度不变, 且热点分片每秒处理的交易数量能力不变, 所以在不同分片数下, 热点分片的阻塞任务数差不多, 交易时延接近. KVFabric因为有跨片交易的排序和两阶段提交, 时延略大于Fabric.

综上所述, 随着节点资源增多, KVFabric的吞吐量增长远大于Fabric, 时延略高于Fabric. KVFabric在均衡负载下性能略优于SmartFabric, 在热点负载下性能大幅优于SmartFabric.

4.4 交易提案路由表实验

本实验测试交易提案路由表方案是否能有效改善跨片交易占比上升对KVFabric带来的影响.

实验设置了100份客户身份证书, 发送交易会按顺序取用不同的身份证书. 交易将被等概率地发送到不同分片中. 为了模拟跨片交易在执行阶段多次跨片读的行为, 部署的转账智能合约修改为读取多个账户的金额为某一个账户转账. 跨片交易占比表示客户端发送的交易是跨片交易的概率. 实验测试了在是否增加交易提案路由表的情况下, 吞吐量和时延随跨片交易占比的变化. 性能测试结果如图11、图12所示.

从图12可以观察到, 在跨片交易占比低的时候, 因为路由表的更新开销和命中率较低, 损失大于收益, 所以加路由表的时延会略微高于未加路由表. 当跨片交易占比超过50%之后, 因为跨片交易的占比增多提高了路由表的命中率, 所以时延会逐渐下降, 此时加路由表方案优于未加路由表.

从图11的吞吐量变化中也可以得到相同的结论. 100%跨片占比下吞吐量无法回到原有水平的原因是因为转发交易存在损耗.

综上所述, 当跨片交易占比较高, 并且能保证命中率(启发有效)的情况下, 交易提案路由表能降低分片Fabric的时延, 提升其吞吐量.

4.5 热点访问改善效果对比实验

为了模仿现实中热点智能合约发生变化的情况. 本实验在热点负载测试的基础上, 每隔30 s切换热点智能合约, 即周期性调整对不同智能合约的访问频率. 测试KVFabric和LB-Fabric^[22]中交易吞吐量随时间的变化, 测试结果如图13所示.

LB-Fabric需要根据历史预测各个分片下一周期的交易量, 然后计算如何迁移智能合约能够尽可能保证分片间的负载均衡. 迁移智能合约会造成交易的阻塞, 并且打破了智能合约与分片的绑定关系, 导致客户端发送交易和处理跨片交易都需要向特定的角色查询目标分片. 以上计算和缺陷都可能影响系统吞吐量, 并且热点智能合约的切换会导致历史预测的失效. 实验结果证实了上述分析, LB-Fabric的吞吐量都会周期性地下降, 然后再快速提升, 但最好的情况也无法超过KVFabric.

5 总结与展望

本文针对HyperLedger Fabric现有分片方法存在热点访问的问题, 提出了细粒度的键值状态分片方案. 针对细粒度分片导致跨片交易增多的问题, 提出了交易提案路由表的解决方案. 通过实验证明, 以上方案能够有效地解决问题. 但是本文方案仍旧存在缺陷, 例如如何解决随着分片数上升性能提升效果下降的问题, 以及交易路由表失效情况下该如何优化高跨片交易占比下的交易处理等问题. 相关研究有待进一步展开.