收藏 分销(赏)

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

上传人:自信****多点 文档编号:654959 上传时间:2024-01-24 格式:PDF 页数:12 大小:2.51MB
下载 相关 举报
面向超级账本Fabric的多通道分片技术研究.pdf_第1页
第1页 / 共12页
面向超级账本Fabric的多通道分片技术研究.pdf_第2页
第2页 / 共12页
面向超级账本Fabric的多通道分片技术研究.pdf_第3页
第3页 / 共12页
亲,该文档总共12页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、第41卷 第4期2023年7月应用科学学报JOURNAL OF APPLIED SCIENCESElectronics and Information EngineeringVol.41 No.4Jul.2023DOI:10.3969/j.issn.0255-8297.2023.04.006面向超级账本 Fabric 的多通道分片技术研究刘洋1,2,林致远1,3,张玉玺1,3,蒋琳1,吴宇琳11.哈尔滨工业大学(深圳)计算机科学与技术学院,广东 深圳 5180552.鹏城实验室,广东 深圳 5180383.广东省安全智能新技术重点实验室,广东 深圳 518055摘摘摘要要要:区块链技术被广泛运

2、用在物联网、金融、供应链等领域。Hyperledger Fabric 是目前主流的企业级许可区块链系统,该系统允许事务并发的执行与验证。然而,在高并发场景下其吞吐量的限制却制约了该系统更大范围的应用。分片技术是现有解决区块链性能问题的方案之一,可同时满足低延迟和高吞吐量的目标,大多数现有分片方案只是针对非许可区块链加密货币的应用,而针对许可区块链的分片研究方案却很少。面向超级账本平台,本文提出了一种多通道交互的分片方案。首先根据客户端事务发送的速率,对当前交易通道进行动态复制,进行并行背书;然后将在排序节点对复制的通道所背书的事务进行合并,生成新的区块;最后并行地在多通道内将新区块分发给各个节

3、点,并整合在主账本内,确保节点之间账本的一致性,并更新世界状态。实验表明,提出的新方法能够在高并发的情况下显著提高事务吞吐量,相对原有的交易流程,吞吐量可提升 3 倍以上。关键词:超级账本;分片;吞吐量;多通道中图分类号:TN915.08文章编号:0255-8297(2023)04-0614-12Research on Multi-channel Sharding Technology forHyperledger FabricLIU Yang1,2,LIN Zhiyuan1,3,ZHANG Yuxi1,3,JIANG Lin1,WU Yulin11.School of Computer Sc

4、ience and Technology,Harbin Institute of Technology,Shenzhen,Shenzhen 518055,Guangdong,China2.Peng Cheng Laboratory,Shenzhen 518038,Guangdong,China3.Guangdong Provincial Key Laboratory of Novel Security Intelligence Technologies,Shenzhen 518055,Guangdong,ChinaAbstract:Blockchain is widely used in va

5、rious fields,including the Internet of thingsand finance.Hyperledger Fabric is the one of the mainstream enterprise-level licensedblockchain systems,but its throughput limitation in high concurrency scenarios hinderswider application.Sharding is a solution to this problem,which can meet the goals of

6、 lowlatency and high throughput simultaneously.However,most existing sharding schemes are收稿日期:2022-10-28基金项目:国家重点研发计划(No.2020YFB1005805);广东省安全智能新技术重点实验室(No.2022B1212010005);鹏城实验室重点攻关项目(No.PCL2021A02);深圳市高等院校稳定支持计划(No.GXWD2020123015-5427003-20200821160539001)资助通信作者:刘洋,助理教授,研究方向为数据安全与隐私计算。E-mail:第4期刘洋

7、,等:面向超级账本 Fabric 的多通道分片技术研究615designed for non-licensed blockchain confidential currency only.In this paper,we proposea multi-channel interactive sharding scheme for the Hyperledger Fabric blockchain plat-form.First,the current transaction channel is dynamically copied and endorsed in parallelaccord

8、ing to the sending rate of client transactions.Then,the transactions endorsed bythe copied channel are emerged at the sorting node to generate new blocks.Finally,thenew blocks are distributed to each node in parallel in multiple channels and integrated inthe main ledger to ensure the consistency of

9、the ledger between peer nodes and update theworld state.Keywords:Hyperledger,sharding,throughput,multi-channel随着比特币和以太坊等加密货币的兴起,全球市场上出现了大量的区块链系统。区块链的分布式账本技术提供了一种以安全和可验证的方式进行交易的方法,而无需可信任的第三方。通俗来讲,区块链系统根据时间序列生成数据区块,并以顺序结构的形式组成一个链形式结构,同时采用密码学的方式实现不可篡改的分布式账本。区块链系统按开放程度可以划分为公有链、私有链、联盟链三种类型。公有链,如比特币1和以太坊2

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

11、授权进入联盟链组织中,联盟链中各个对等节点之间权限相同。同时,联盟链更改了原有无许可区块链的交易流程,数据区块写入区块链账本后,该数据块便会被认为是最终确定的。这种交易流程大大提高了区块链的吞吐量性能,大多数商业应用也更青睐于许可区块链的解决方案。其中,Hyperledger Fabric3是一个具有代表性的联盟链平台,由于其广泛的商业应用而倍受关注,本文选择 Fabric 区块链系统作为研究对象。Hyperledger Fabric 作为目前最受欢迎的企业级许可区块链系统之一,目前正被用于许多不同的应用中,例如 Everledger4和 SecureKey5。通过限制参与共识过程的节点数量,

12、达到在相对较短的时间内达成共识的效果。Fabric 系统针对传统公有链“排序-验证”架构下只能顺序执行交易的问题,提出了“执行-排序-验证”的新型事务处理架构(EOV 架构),提高了系统整体的吞吐量。在执行阶段,客户端将事务发送给背书节点进行模拟执行,背书节点在事务执行完毕后将执行结果返回给客户端。在排序阶段,客户端将事务发送给排序节点集群,排序节点按照事务的到达顺序达成共识,打包成区块,并将该区块广播给通道内的所有对等节点。在验证阶段,通道内所有对等节点将会对该区块内的事务进行验证,以确保满足背书策略,并在确保交易执行生成数据的读写集后,读集中变量的账本状态没有变化,同时块中交易会备注是否有

13、效。最后,Peer 节点将最终区块提交到本地区块链结构中,有效的交易将会被追加到状态数据库中,并把事务的交易结果通知给客户端。分片是提高区块链系统扩展性及吞吐量的方法之一。区块链内主要的分片可分为两类:一类是在各个分片中对交易进行处理后,整合在唯一账本内,形成最终一致性账本;另一类是不同的分片来记录不同的事务,相当于多条链并行处理。文献 15 提出了基于 HyperledgerFabric 的通道扩展方案。但是这项工作并没有定量地分析以及对其他许可区块链系统的适用616应用科学学报第41卷性并不清晰。文献 16 提出在每个分片上运行一个基于实用拜占庭容错(practical Byzantine

14、fault tolerance,PBFT)算法17的共识协议,并要求共识节点运行可信硬件,该方案的使用条件相对苛刻难以大规模使用。在现有的区块链的分片方案中,大部分方案需要额外消耗资源来组建分片委员会,此外,在跨分片的数据交易中现有的方案会产生较大的时延,从而影响整体的性能。基于以上问题,本文首先提出了一种基于 Fabric 管道的动态分片方案,针对区块链系统的事务吞吐量进行了改进尝试。针对当前 Fabric 系统的事务吞吐量进行了系统性分析,并根据各部分的延迟大小确定了当前事务交易的瓶颈。其次,根据客户端事务发送的速率,对当前交易通道进行动态复制,并针对交易数据以及分片的通道进行一致性哈希来

15、选择分片后的通道,进行并行背书以及验证。最后,将新区块提交到主账本内,确保 Peer 节点之间账本的一致性,并更新世界状态。本文的贡献如下。1)从实验和理论的角度分析了当前 Fabric 的交易流程,并对 Fabric 中各阶段的处理能力进行了实验分析,针对不同的生成区块参数数据进行了调整,主要针对原始 Fabric 的吞吐量、延迟、事务成功率进行了一定的分析。2)基于上述实验,提出了一个基于多通道的动态数据分片的实验方案,并以 HyperledgerFabric v2.4 版本为基础,使用该方案对当前交易流程进行改造,形成新的多通道扩展的 Fabric结构。3)将多通道扩展的 Fabric

16、与传统 Fabric 在 Smallbank 基准测试和自定义工作负载下进行对比测试实验,以检验改进成果的正确性。实验结果显示,基于多通道的分片方案实现了更高的吞吐量以及较低的交易延迟。1相关工作介绍目前有一些针对 Hyperledger Fabric 的性能优化研究方案,如文献 6 通过减少交易流程中的计算和 I/O 开销,并针对缓存、并行运算等提出优化方案,将 Fabric 事务的吞吐量提高到 20 000 个事务/s。另有一些学者7-8研究了 Fabric 系统的配置参数对吞吐量等性能的影响,并提出了改进意见。文献 9 研究块大小、背书策略、通道、资源分配、状态数据库选择等配置参数对 F

17、abric 性能的影响,并针对这些影响提供了 MSP 缓存、并行 VSCC 验证等优化方案。尽管上述方案对 Fabric 的性能提升有所增益,但这些解决方案的核心仍然依赖于经典的共识算法,可扩展性增益却并不会很高。区块链分片技术是现有解决区块链性能问题的方案之一。分片技术是一种针对分布存储、计算和通信以节省资源和提高系统可伸缩性的技术,可以同时满足低延迟和高吞吐量的目标。Elastico 第一个将分片应用到区块链的工作,该方案对区块链网络以及交易事务进行分片10,然而其无法处理跨分片事务,同时只能使用较小的分片大小。还有很多针对公有链的分片方案,如 Monoxide11、RapidChain1

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

19、压力。而针对许可区块链系统,文献 15 提出了基于 Hyperledger Fabric 的通道扩展方案。然第4期刘洋,等:面向超级账本 Fabric 的多通道分片技术研究617而,这项工作并没有定量地分析以及确定其方法的效益。由于该方案依赖于UTXO 模型,对其他许可区块链系统的适用性并不清晰。已证明的超级账本(Attested HyperLedger,AHL)16同样是针对 Fabric 的分片方案,该方案在每个分片上均运行一个基于 PBFT17的共识协议,并要求共识节点运行可信硬件,以防止拜占庭节点产生混淆。2准备知识2.1Hyperledger Fabric系统架构Hyperledge

20、r Fabric 是一个许可的区块链架构,其由 IBM 和 Digital Asset 提交给 Linux基金会,是目前最受欢迎的企业级区块链框架之一18。Fabric 采用了松耦合的设计,将共识机制、节点运行、身份验证等组件模块化,使之在应用过程中可以方便地根据应用场景来选择相应的模块。Hyperledger Fabric 系统中的节点类型主要分为三类。1)Peer。该类型节点主要针对智能合约的执行、交易提案的背书批准以及数据块的最终验证。Peer 节点会存储账本以及智能合约,负责链代码及其生命周期的执行,是区块链网络的基本元素。2)Orderer。该类型节点会对 Peer 节点背书后的事务

21、进行排序并生成数据块。因为 Fabric用确定性共识算法,所以 Peer 节点所验证的区块都是最终的和正确的。账本不会像其他分布式以及无需许可的区块链中那样产生分叉3。3)Client。客户端属于轻量型的网络节点,通常使用 Hyperledger Fabric SDK 来绑定某个 Peer 节点并与区块链网络进行通信。Hyperledger Fabric 采用“执行-排序-验证”三步架构达到共识,与原有无许可区块链“排序-执行”的交易模式不同,数据区块写入区块链账本后,该数据块便会被认为是最终确定的。同时,执行和验证阶段可以并行化处理事务,这种交易流程大大提高了区块链的吞吐量性能,大多数商业应

22、用也更青睐于 Hyperledger Fabric 区块链系统的解决方案。其具体的执行流程主要包括以下三个方面,如图 1 所示。?图 1 Fabric 交易流程图Figure 1 Fabric transaction flow chart1)执行阶段。在此阶段,客户通过封装了 gRPC 服务和签名服务的 Fabric SDK,将事务提案发送给背书策略指定的一个或多个背书节点。背书节点会根据客户端所指定命令,参数运行对用的链码,并生成对应的读集与写集。在背书执行阶段并不会更新账本数据。背书节点执行完链码后,对事物提案进行签名,并返回给客户端节点。客户端会根据背书策略检查接收到的提案,当结果相同回

23、应提案数量满足背书策略时,便会打包并发送给 Orderer 节点集群。618应用科学学报第41卷2)排序阶段。在此阶段,Orderer 节点集群将根据共识协议生成交易事务,目前 Fabric 主要包括 Solo、Kafka 和 Raft 三种公式协议。本文所基于的 Hyperledger Fabric v2.4 使用 Raft协议。Raft 协议中的有序簇分为跟随者和引导者。身份为跟随者的订购者通过 gRPC 服务将收到的交易转发给领导者。在排序阶段并不会不检查交易的具体内容,因为数据是被封装在envelope 中。Orderer 集群在接收到一定数量的事务或者达到时间限制,会将一批事务按顺序

24、打包到一个块中。Raft 共识保证跟随者的日志与领导者的日志一致,从而实现有限状态机的复制。这样,每个对等体都可以从排序器集群中的任何节点获得生成的块。3)验证阶段。在这个阶段,各个 Peer 节点收到 Order 发送的块后,会按照块中事务的顺序依次对事务的读集与写集进行验证。当一个事务满足背书策略并且其读取集合中所有密钥的版本都是最新版本时,此时事务满足 MVCC 条件,便会将该事务标记为有效,反之则将之标记为无效事务。Peer 节点会将所有事务添加到区块链账本中,但对于无效的事务,Peer 节点不会将之更新到状态数据库中。2.2分片技术分片技术被认为是提高区块链性能及可扩展性最有前景的链

25、上方案之一,有着不牺牲中心化程度便能提高区块链性能的特性。这种技术通过将区块链分成多个部分来实现,每个部分都可以独立处理交易和存储数据。分片技术最早被应用在数据库之中,将大型数据库进行更细致的划分,使得更易于数据的管理与扩展。区块链的分片技术主要分为两种类型,分别是针对网络的分片与针对数据的分片。针对网络的分片旨在通过将网络节点划分为多个组来提高网络传输效率,而针对数据的分片则通过将数据存储在不同的节点上,每个节点可同时对多个分组的交易并发处理,提高数据处理能力。区块链的分片技术主要面临着以下挑战。首先是针对分片内,由于节点减少或者账本存储数据减少等因素,会出现针对 Pow 的 51%攻击以及

26、针对 PBFT 的女巫攻击。另外,针对跨分片的交易,可能会出现双花问题,以及跨片交易的可靠性和交易效率问题对当前网络的吞吐量影响较大。联盟链在进行分片后,通常不需要再进行配置,分片中的记账权往往在少数确定的节点中,因此,联盟链的分片安全性较高。3多通道分片的 Fabric 架构3.1多通道扩展分析与系统模型术在 Hyperledger Fabric 中,每个通道都有一个完全独立的账本。在之前的工作中3,通道被定义为完全独立的区块链和完全独立的世界状态,包括命名空间,与系统的其他状态无关。当节点拥有多个通道的使用权限时,应用程序和智能合约便可以在通道之间进行通信,以便在通道间访问账本信息。当节点

27、同时属于多个通道,并且可以满足各个通道的背书策略时,便可在多个通道之间进行通信。这就是验证策略:客户端需要验证该策略,以便相信他们有权限处理通道中发生的事务。当通道 A 希望与通道 B 进行交易时,通道 A 的对等节点可以同样有效地实现通道 B 的客户端,因此通道 A 的对等节点在接收到通道 B 的请求时,便可验证 B的验证策略是否满足。基于以上所描述特性,我们设计了一个动态的区块链生态系统,在这个生态系统中,新的通道可以根据需要动态创建,并且可以随着时间的推移而进化,以满足可伸缩性的需求。在原有的 Fabric 架构中,多个通道之间无法对同一类交易进行并发的处理,因为多个通道之间存在命名空间

28、的隔离。在这个方案中,在特定情况下消除了多通道间的命名空间隔离,可以让同一类交易并发进行背书。对现有的通道状态进行复制,但并不复制已有的账本数据,产生一个第4期刘洋,等:面向超级账本 Fabric 的多通道分片技术研究619新的通道编号为 i,每个通道 Ci包含初始通道的所有用户 U,并共享用户组 U 所给定的业务逻辑,以及可跨通道的分布式账本 L。将不相交的数据分散到不同的通道中,各通道可以并行地进行数据背书和数据的验证,保持各个通道的小规模系统吞吐量,从而提高总体的吞吐量。通道的水平扩展结构如图 2 所示。Data set yLedgerSharedsmart contractData s

29、et xData set 1DynamiccopyChannel CyChannel CxInitial channel C1User group Uu1uiuk图 2 Fabric 多通道事务交易流程图Figure 2 Fabric multi-channel transaction flow chart本系统基于许可的区块链通信模型,用户需要显式注册才能成为系统的成员,并通过异步网络进行通信。用户的角色与现有大多数许可的区块链一致,主要包括客户端、对等节点。利用区块链提供的软件开发工具包(software development kit,SDK)服务,以交易的形式提交请求。验证器可以验证客

30、户端的事务并将其提交到区块链上,以便处理相应的请求。同时,假设有一个成员管理服务用于维护成员的信息,这样成员就可以按需检索信息。注册表提供了相互识别成员的方法,并作为新成员的发现机制。用户 u 注册后,将获得一个用于链接用户身份的证书、相应的公钥与私钥,以及一些关于用户的附加信息。基于多通道分片的 Fabric,交易流程主要分为以下几部分:首先在初始阶段,联盟中的各组织会创建一个初始的通道;之后在客户端将交易数据发送到主通道进行背书之前,节点会查询当前通道的数据处理能力,倘若当前通道数据负载较高,则会向管理员节点申请创建新的通道,并将事务发送到新的通道上进行背书;背书时事务的签名等信息会消除复

31、制通道的命名信息,只保留主通道的名称,并将背书结果发送到排序节点集合;最后将会对交易进行验证并保存到主通道的账本内,分片的通道并不会保存主通道的账本以保持事务的高并发状态。针对各个节点发送的交易数据,采用一致性哈希方法。首先,按照分片出的通道进行哈希映射,存储在哈希环结构上;接下来,对节点发送数据再次进行哈希来进行通道的选择;一定时间后,再修改通道的哈希环结构,从而保护数据的安全性。3.2多通道管理流程设计通道是一个联盟中的成员彼此进行通信的主要机制,同时提供了一个联盟成员之间进行私有通信和私有数据的机制。通道提供了与其他通道以及整个网络的隐私性。在 Fabric 网络建立完成后,使用网络中的

32、联盟 X1 为内部的组织创建的一个初始化应用通道 Channel1,假设当前组织包括 Org1 和 Org2。这个通道通过通道配置来进行管理,完全独立于网络配置。该通道的通道配置由 Org1 和 Org2 进行管理,它们在 Channel1 上具有同等的权利。当两个组织的节点加入通道后,便可在该通道内共享私有数据,同时两个组织的管620应用科学学报第41卷理员会对当前通道的配置信息进行备份,以便进行多通道的水平扩展操作。在对通道的动态扩展的研究中,需要对节点参与的各个通道负载进行监控,从而实现在现有通道资源紧张的时刻,进行新通道的动态创建,以及对多分片通道的动态选择。因此在原有节点内部,增加了

33、通道负载分析插件,并采用一致性哈希的方式,将通道分散在哈希环结构中,并对数据进行哈希后,一次访问环中的通道,直到遇到空闲的通道。若所有通道此时的吞吐量均超过设定的阈值,则客户端会向对等节点进行通道创建的申请,管理员节点会检测当前通道的数量,若符合条件,则会对主通道进行复制,得到一个新的通道并为新的通道进行编号命名,以便区分。数据传输流程如图 3 所示。ManagementManagementManagementManagement1SimulateChannelsSimulatevalidatevalidateLedger432SimulationphaseOrderingphaseValid

34、ationphaseappendto ledgerappendto ledgerOrderingserviceaPeersPeersClient1Client2ProposalEndorsementEndorsementEndorsementEndorsementProposalTx1Tx2Tx3Tx2Tx2Tx4Tx1Tx3Tx3Tx1CaCbTx4Tx4图 3 多通道分片数据交易流程Figure 3 Multi-channel fragmented data transaction process1)当客户端节点发送数据时,客户端节点首先会询问 Peer 节点当前通道状态,并返回第一个空闲

35、的通道名称。若客户端未指定分片通道,则节点会对发送事务进行哈希随机选择一个分片的通道进行通信。2)客户端将向该条通道进行数据发送,并指定背书节点。当事务到达背书节点后,会在当前通道内对客户端指令进行模拟执行。由于是在不同的通道内,所以该通道的链码空间与其他节点的空间相隔离。3)当背书结束后,各个通道将背书结果发送给排序节点,此时对多通道数据进行融合。在排序节点内,将识别原通道的命名空间,并去除通道分片的标识记录,在主通道内将所有数据进行打包。4)最终传送给主通道内的各个节点进行验证。算法步骤如算法 1 所示。算法 1面向超级账本 Fabric 的多通道事务分发算法输入交易集 Trans=t1,

36、t2,tn,通道数 C=n 选择背书节点 Peer=p1,p2输出上链结果 Resultfor t=1 t do/t 表示当前的交易事务第4期刘洋,等:面向超级账本 Fabric 的多通道分片技术研究621N GetChannelCount()/获取当前通道数量H1 Hashmap(t,n)/获取当前事务哈希C MainChannel/初始化选择通道为当前主通道for i=1,2,n do/i 表示各通道编号Si GetChannelState(i)/查询当前通道状态if Si=Free thenC Ci/一致性哈希选择空闲的分片通道breakend ifend forSendTxToSimu

37、lation(t,Ci)/将当前交易发送给背书节点RemoveNameSpace(Ci)/在背书节点消除命名空间,假设在主通道SendTxToOrdered(t,Ci)/将当前交易发送给排序节点,使用主通道名end forreturn Result/输出交易结果4实验结果分析本节将对改进的方案进行全面的实验评估。将描述实验环境及设备配置,以及所采用的工作负载环境,包括使用链码及测试环境。之后将介绍改进的成果,主要是每秒成果事务的吞吐量与事务延迟两个方面,并与原 Fabric 架构以及现有 Fabric 分片方案的吞吐量及时延进行了横向的对比。表 1 实验环境及系统参数配置Table 1 Exp

38、eriment and system configuration实验参数数值Maximum time to form a block/s1Maximum number of keys accessed per block16 384Maximum size per block/MB2Maximum number of transactions per block(BS)1 024Initialize the number of channels1Number of clients per channel4Number of committed transactions10 000工作负载:为了

39、与现有工作进行横向对比,使用与 Fabric+相同的工作负载 SmallBank作为实验中的测试链码。SmallBank 是 BlockBench 中定义的非常适合测试区块链系统的标准基准。该工作负载模拟了一个典型的资产转移场景,主要包含 6 种交易类型。首先是“CreatAccount”,该方法可创建 N 个用户,并为每个用户生成 1 个支票账户和 1 个储蓄账户,并进行随机的初始化操作。“TransactSavings”“DepositChecking”“SendPayment”“WriteCheck”“Agrammerge”这几个方法为在储蓄账户和支票账户之间的修改操作。“Balance

40、”方法为会读取用户的支票和储蓄账户。在一次实验过程中,将以一定的概率622应用科学学报第41卷进行随机读写测试,及以 Pw的概率出发读取事件,以及以 1 Pw的概率来出发 4 个写方法中的其中一个。同时,在初始阶段采用 Zipfian 分布对生成的 N 个用户进行选择,并通过设置skew 值来配置访问数据的数据分布情况。测试方法:针对上述工作负载,分别采用了 Caliper 测试工具及自行构建基准架构的方法进行实验。实验发现,Caliper 在发送率提高时,将会有更大的失败率无法将交易发送出去。因此,采用基于 go v1.18.2 版本自行构建基准测试,首先将交易事务传入 Channel 中,

41、之后创建了 1 个 Worker Pool,创建了 1 000 个 Worker,并让所有 Worker 异步进行工作,从交易管道中拿取交易进行发送。通过调用 Gateway 包,对交易进行“执行-排序-验证”三个阶段进行监控,监控各阶段的延时情况与失败原因。每次实验将运行 5 次上述测试方法,并对结果取平均值。4.1背书阶段时延分析在多通道 Fabric 区块链网络中,背书阶段各个背书节点将会并行执行背书任务,并将结果发送给排序节点,而排序阶段会对每个通道的数据进行合并整合。因此,多通道分片的排序阶段与原区块链网络在相同负载下的时延将会相同。但由于通道的数量增加,各个节点中不同的通道将会抢占

42、 CPU 资源,因此背书阶段的时延将会增加。设定当前的区块链网络的链路传输时延设为 D s,数据传输带宽为 B bit/s,设定节点对数据的处理能力为 bit/s。单通道的背书阶段主要由三部分组成,分别是:1)交易提案发送给背书节点的通信传输时延 L1,当交易提案的大小为 x bit 时,其大小满足L1=x/B+D(1)2)背书节点数据流量解析时延 L2,当背书节点接受数据大小为 x 时以 bit/s 的处理能力进行处理时,该阶段延迟大小满足L2=1 x(2)3)背书结果返回时延 L3,背书节点将大小为 bit 的背书结果发送给客户端,延迟大小满足L3=/B+D(3)与单通道区块链网络相比,L

43、2阶段背书节点解析数据流量时延将随着通道的数量增加而扩展。当通道数量增加到 N 时,水平扩展结构的背书过程处理时延 M2为M2=1 N(x)(4)4.2实验评估与结果分析图 4 所示为当前 Fabric 的事务处理能力,确认时间以 s 为单位。首先针对不同区块的大小对当前系统的时延和吞吐量分别进行测试,配置系统参数,并对实验结果进行分析。可以发现,Fabric 的吞吐量与区块大小成正比,但由于网络上事务负载的增加和更大的块大小会导致区块链的硬分叉。因此,为了实现更高的吞吐量而增加 Fabric 的块大小,将损害区块链的安全性和去中心化,这类方案是不实际的。所以在接下来的实验验证以及对比实验中,

44、将对区块的大小进行限定。第4期刘洋,等:面向超级账本 Fabric 的多通道分片技术研究6231.21.00.80.60.40.201 0008006004002000?(a)?(a)Average latency of transactions(b)?(b)Successful transactions per second?13.52%16.77%21.36%24.37%26.85%79.17%75.84%71.25%68.17%65.74%2784735896477037958288517.31%7.40%7.39%7.46%7.41%2050100200300?205010015020

45、0300500 1000图 4 Fabric 事务处理能力Figure 4 Fabric transaction processing capability接下来,将对通道数量进行一个动态扩展,通道数量配置为 1,2,4,6,8,10,并比较在多通道扩展情况下的延迟与吞吐量情况。图 5 展示了针对多通道扩展结构下 10 万个交易的平均时延情况,设定了当前区块大小为最多支持 200 个交易,出块时间设置为 1 s。此外,当 1 s内没有数据会进行等待。可以发现,随着通道数目的增加,Fabric 的吞吐量逐渐增大,同时由于当前处于同一服务器内 CPU 资源的竞争,延迟时间也逐渐提高。本方案与文献

46、16,19 基于区块链网络、数据、状态的分片的方案在相同配置下进行了吞吐量及时延等的一系列对比,如图 6 所示。从图中数据可以发现,本方案虽有着一定的优势,但时延相对较高,说明本方案0.7750.7910.8220.8590.8940.9201.00.80.60.40.20?1246810?6321 1331 5892 1072 3892 5513 0002 5002 0001 5001 0005000?1246810?(a)?(a)Average latency of transactions(b)?(b)Successful transactions per second图 5 Fabri

47、c 多通道分片事务处理能力Figure 5 Fabric multi-channel slice transaction processing capability0.8950.8750.8550.8350.8150.7950.775?2-shares4-shares6-shares2 2002 0001 8001 6001 4001 2001 000800600?2-shares4-shares6-shares?63281897792411350.8020.7910.7830.8260.8030.7880.8590.8220.7910.7751 5892 1071 2071 4681105(

48、a)?(a)Average latency of transactions(b)?(b)Successful transactions per second图 6 多通道分片方案与现有分片方案对比Figure 6 Comparison of multi-channel sharding scheme and existing sharding scheme624应用科学学报第41卷所占用的处理器计算资源与存储资源更高。从上面的两个结果可以明显看出,基于多通道分片的框架可以使吞吐量和延迟保持稳定,TPS 最高可达 2 500 以上。使用多通道并行化事务处理,可以对更多的事务进行背书及验证,从而提

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

50、排序以及验证阶段的分片扩展进行分片扩展设计,并进行详细的实验分析与评估工作。参参参考考考文文文献献献:1 Bhme R,Christin N,Edelman B,et al.Bitcoin:economics,technology,and governanceJ.Journal of Economic Perspectives,2015,29(1):213-238.2 Wood G.Ethereum:a secure decentralised generalised transaction ledger R.Ethereum ProjectYellow Paper,2014,151(2):1

展开阅读全文
相似文档                                   自信AI助手自信AI助手
猜你喜欢                                   自信AI导航自信AI导航
搜索标签

当前位置:首页 > 学术论文 > 论文指导/设计

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服