fabricsharp 一个执行顺序验证区块链的交易处理视角

名词说明:

悲观并发控制
一个锁定系统,可以阻止用户以影响其他用户的方式修改数据。如果用户执行的操作导致应用了某个锁,只有这个锁的所有者释放该锁,其他用户才能执行与该锁冲突的操作。这种方法之所以称为悲观并发控制,是因为它主要用于数据争用激烈的环境中,以及发生并发冲突时用锁保护数据的成本低于回滚事务的成本的环境中。 
乐观并发控制 (检查是否重复更改同一个数据)
在乐观并发控制中,用户读取数据时不锁定数据。当一个用户更新数据时,系统将进行检查,查看该用户读取数据后其他用户是否又更改了该数据。如果其他用户更新了数据,将产生一个错误。一般情况下,收到错误信息的用户将回滚事务并重新开始。这种方法之所以称为乐观并发控制,是由于它主要在以下环境中使用:数据争用不大且偶尔回滚事务的成本低于读取数据时锁定数据的成本。

 

本文是Pingcheng Ruan A TRANSACTIONAL PERSPECTIVE ON EXECUTE-ORDER-VALIDATE BLOCKCHAINS 论文的翻译,由于英语能力有限难免出现翻译不到位的情况,欢迎大家指正。论文下载地址

摘要

智能合同使区块链系统从简单的加密货币平台演变到一般的交易系统,比如比特币,比如以太坊。为了迎合新兴业务Hyperledger中提出了一个叫做execute(背书)-order(共识)-validate(commiter) 的新架构Fabric,Fabri通过支持并行事务来提高区块链的吞吐量。然而,这个新的体系结构在序列化事务时可能会出现许多无效事务。这个问题是由于除数据外,区块形成率在本质上受到其他因素的限制,这一数据进一步被夸大处理,例如密码学和一致性。

在这项工作中,我们提出了一种新的方法来增强execute(背书)-order(共识)-validate(commiter)架构,通过减少无效事务来提高区块链的吞吐量。我们的方法受到在现代数据库系统中最先进的乐观并发控制技术(optimistic concurrency control techniques)的启发。具体思路是对现有的区块链采用数据库的预防方法,可能中止序列化事务,我们的方法理论上更细粒度。具体来说,unserializable(无法序列化的)事务在排序之前中止,并且保证其余事务是可序列化的。我们分别在两个区块链中实现我们的方法,FabricSharp在Hyperledger Fabric之上,FastFabricSharp在FastFabric之上。我们比较了FabricSharp和vanilla Fabric的性能,并分别实现了三个相关系统使用数据库中的一种标准和一种最先进的并发控制技术。结果表明,与其他系统相比,FabricSharp实现了25%的高吞吐量在几乎所有的实验场景中。此外,FastFabricSharp对FastFabric的改进高达66%。

1 介绍

区块链像一场风暴一样冲击着世界。区块链的概念,源自中本聪的比特币白皮书[21]提出使用散列的区块链来批量处理历史货币交易。这个链分布在网络上的互不信任的节点运行工作证明(PoW)来保证链上数据的一致性。一致共识将交易组成块,节点并按顺序连续的执行块中交易以更新它们的状态。虽然比特币只支持加密货币操作,Ethereum被设计为支持图灵完整的智能契约,该契约可编码任意数据处理逻辑[31]。有了Ethereum,区块链从加密货币平台发展到分布式交易系统。区块链系统可以分为公链(公开),如比特币和以太坊,和私有链(私人),如Hyperledger Fabric[4]。在公链中,数据和事务逻辑是透明的,因此,可能会有私人资料外泄。由于其开放性,公共区块链使用耗能严重的PoW的共识。这与串行交易执行一起限制了这些系统的容量。Hyperledger Fabric是一个私有区块链,支持并发交易[4]。解决公共区块链的限制。Fabric区块链要求其成员通过可信的成员资格服务进行注册,以便参与区块链。在这篇文章中,我们关注允许的区块链,因为它们更适合支持应用例如供应链、医疗保健和资源共享,特别是,我们使用Fabric作为底层区块链系统。

Fabric支持名为执行-订单-验证(execute-order-validate, EOV)新的交易执行架构。在这个体系结构中,a事务的生命周期由三个阶段组成。在第一个阶段,执行,一个客户端发送交易到一个集合由背书策略指定的节点或peer节点。交易由这些peer node并行执行它以读和写状态的形式记录其效果。此外,来自不同客户端的交易也可能是如此在执行过程中并行化。在第二阶段,order(共识排序),一个共识协议被用来产生一个完全按块分组的已背书交易的有序序列。此命令广播给所有peer node。在第三阶段,验证,每个peer方验证与背书策略相关的已背书事务的状态变化和可串行性。

新的EOV架构将交易的执行细节限制在endorser peer,以增强安全性并利用并发性。但是,这种并发性的代价是中止不符合可串行性的交易。我们将评估Fabric中的并发控制对第5部分中描述的设置的影响。我们测量了在无操作事务(无数据访问)和更新事务(由zipfian系数控制的变化偏度)下原始的和有效的峰值吞吐量。原始吞吐量表示分类帐内事务,而有效吞吐量通过从原始数据中排除中止的事务来表示已提交的事务吞吐量。在图1中,一个条报告了原始吞吐量,而其蓝色部分报告了有效吞吐量。 尽管工作负载类型和请求偏斜,但原始吞吐量是恒定的(677 tps)。 但是,由于偏度较高,因此为了可串行化而中止了较大比例的事务。

                                                           

Figure 1: 无操作交易和偏斜度不同的单一修改交易下Fabric的原始和有效吞吐量

有两个值得注意的方向试图解决这个问题。一是改进织物的结构提高其可达到的吞吐量[22,27,6,1]。例如,FastFabric提议分割节点的功能以缓解瓶颈,并在Fabric[16]的所有改进中实现最高的吞吐量。然而,这些方法是特定于实现的,可能不能很好地推广到其他区块链。第二个方向是抽象事务生命周期以减少中止率。例如,Fabric++[26]使用数据库中完善的并发技术来早期中止事务或重新排序事务,以协调潜在的冲突。

我们的工作对应于第二个方向,作为区块链数据库的主要尝试。在这里,我们采用一种原则性的方法来学习具有开放式并发控制(OCC)的数据库中的事务分析技术。我们正式分析了Fabric和Fabric++的当前实现的行为,发现它们都实现了[5]的强可串行性(如3.2节所述)。事实上,按照原始的Fabric协议[4]的规定,这些实现比单副本可串行性(或简单的可串行性)更严格。这两个系统都采用了一种预防方法,这种方法可能会过度中止仍然可序列化的事务。相比之下,我们的建议包含了一种新的重新排序技术,它消除了由于分类帐冲突而造成的不必要的中断,并在我们的理论见解基础上建立了可串行性保证。我们的方法不会改变fabric的结构,因此它与上述优化是正交的,如FastFabric[16]和[22,27,6,1]。

综上所述,本文的贡献如下:

•我们从理论上分析了采用EOV架构的区块链事务处理与采用乐观并发控制的数据库之间的相似性(第3.1节)。基于这种相似性,我们分析了最先进的EOV区块链的事务行为,例如Fabric和Fabric++(第3.2节)。

•我们提出了一个新的定理来识别因为不能满足可串行性而重新排序的事务(章节3.3)。基于这个定理,我们提出了一种有效的算法来早期过滤掉这类事务(第3.4节),并保证了重新排序后剩余事务的可串行性。我们亦会讨论我们的建议对安全的影响(第3.5节)。

• 我在现有的两个区块链上实现了我们提出的算法。首先,我们使用Hyperledger Fabric v1.3作为基础,并将我们的实现命名为FabricSharp(或简称Fabric#)。其次,我们从FastFabric[16]开始,它在所有Fabric优化中获得最高的吞吐量,并命名我们的实现FastFabricSharp(简称FastFabric#)。

•我们对FabricSharp进行了广泛的评估,将其与vanilla Fabric、Fabric++以及其他两种基于数据库并发控制技术的实现进行了比较,这些实现来自一种标准方法[10]和Ding等人[12]最近提出的一项建议。实验结果表明,与其他系统相比,FabricSharp的吞吐量提高了25%以上。此外,FastFabricSharp对FastFabric的改进高达66%。

本文的其余部分结构如下。

第2节提供EOV区块链和OCC技术的背景。我们的理论分析将在第3节进行,最后是我们的重新排序算法。第4节描述了我们的方法的实现。第5节报告了我们的实验结果。在第7节结束之前,我们在第6节回顾相关的工作。

Figure 2: Fabric中的事务工作流示例。箭头表示事务执行的生命周期(模拟),如Txn1在第1块之后立即开始执行,在第2块之后完成模拟。(b)在每个fabric orderer中复制的程序。Fabric++在形成块之前引入了一个重新排序步骤,以降低事务中止率。

 

2背景

2.1 Fabric和Fabric++中的EOV架构

Hyperledger Fabric[4]是一款最先进的联盟区块链,其特点是基于EOV架构的模块化设计。Fabric++[26]是对Fabric的一种优化,通过协商后对交易进行重新排序来降低中断率。Fabric/Fabric++区块链由一组经过身份验证的节点运行,这些节点的身份由成员资格服务(msp)提供。这个区块链中的节点具有以下三个角色之一:(i)提交事务建议执行的客户端,(ii)执行和验证事务建议的对等端peer 节点,或(iii)定购事务并批量处理它们的排序者orderer 节点。事务顺序是由区块链中的所有订货者orderer 节点基于共识协议共同决定的。

区块链形成块后的状态由版本化的键值存储维护。这个存储中的每个条目都是一个元组(key、ver、val),其中key是表示条目的惟一名称,而ver和val分别是条目的最新版本和值。而且,ver是一对,由块的序列号和事务的更新条目(交易在块中的位置)组成。例如,在图2a中,块2之后状态中的条目(C,(2,1), 201)表明键C包含最后由块2中的第一个事务更新的最新值201。

Table 1:事务摘要如图2所示。静态读取和写入的分别用红色和蓝色标记。符号√、X、N.A.分别表示已提交、中止或不允许的事务。

在Fabric/Fabric++中,事务的工作流由三个阶段组成:执行、排序和验证。下面我们使用图2a中的示例对这些阶段进行详细说明。

Execution. 在此阶段,客户端向一组背书节点(由背书策略选择)提出由智能合约调用组成的交易读写集。各背书方同时模拟执行交易提案,并将模拟结果与背书签名一起返回。结果包含两个称为readset和writeset的值集,它们分别表示由模拟产生的版本依赖关系(读所有键及其版本号)和状态更新(修改所有键及其新值)。例如,表1总结了图2a中事务的读集和写集。在整个执行过程中,事务在状态数据库上持有一个读锁,以保证读值是最新的。跨块读取的事务(如图2a中的Txn1)在Fabric中是不允许的。相反,Fabric++乐观地删除这个锁以获得更多的并行性,但会中止跨块读取的事务。客户端按照背书策略的要求收集到足够多的相同模拟结果后,将它们打包到单个事务中,并将其提交给排序方。

Ordering.在第二个阶段中,排序节点接收事务,并将它们排列成一个总订单,以形成一个块,如图2b所示。每个排序节点可能属于不同的管理域(组织),并从不同的客户端接收不同的交易提案。但是所有的排序节点都依赖于一个单一的共识协议来建立一个共同的交易秩序。Fabric/Fabric++将此共识服务外包给Kafka。由于来自consensus的一致事务流,每个orderer都使用相同的块形成协议,并将事务批处理为块,从而将它们交付给peer节点。当挂起的事务数量达到阈值或超时时,将形成一个块触发器。例如,在图2a中,Orderer1接收Txn5, Orderer2接收Txn2、Txn3和Txn4。它们将事务发送到consensus服务,并接收相同的事务订单。基于这个订单,两个订单者将事务打包到相同的块中,即。如果协议将每个块的最大事务数限制为4,则可以使用Txn2到Txn5进行block 3。

Validation.在从排序节点中检索块之后,每个peer节点执行此阶段。块中的事务根据相应的背书策略和事务的可串行性进行顺序验证。事务的可串行性通过检查其读集的有效性(读集信息是否是最新)来测试。如果事务读取的键在读取时版本与最新版本不一致(或更早),则事务被标记为无效。例如,在图2a中,区块2中的事务Txn2是不可序列化的,因为它从区块1读取版本(1,2)的键B,这与区块2中的最新版本(2,1)不一致。假设Txn3通过了可串行性测试,并在第3块中将密钥C的版本从(2,1)更新为(3,3)。然后,事务Txn4和Txn5就失效了,因为它们都读取了块2中键C的不一致版本。因此,在此验证阶段之后,只有区块3中的事务Txn3被提交,而事务Txn2、Txn4和Txn5被中止。为了满足可串行性约束,Fabric++在块形成之前但在一致意见之后引入了一个重新排序步骤。重新排序基于事务的共识顺序和在交易的访问记录。例如,Fabric++中的每个order节点都将Txn3置于Txn4和Txn5之后。然后,在终止Txn3时提交Txn4和Txn5。因此,Fabric++比Fabric多提交一个事务。

2.2数据库中的乐观并发控制

与悲观并发控制不同,OCC技术不持有锁来调节事务干扰。相反,每个事务都有一个从全局原子时钟分配给它的惟一的开始时间戳。所有查询都反映数据库在开始时间戳时的状态快照,而不观察以后的更改。每个事务还被分配一个结束时间戳。在提交之前,数据库系统根据这两个时间戳和访问记录检查事务的有效性。OCC可以轻松实现快照隔离,即不允许并发事务更新相同的键[7]。考虑到快照隔离会遇到一些异常,比如丢失更新和写倾斜,许多尝试都试图将快照隔离转换为可序列化级别[15,33,9]。

(a)Txn1是跨块读取的,它是快照一致的,并且可以通过可串行性进行调度。Txn2不是,因为它的早读键B是在执行结束之前已经更新。(b)表示交易的简洁符号

Figure 3: 跨块读取事务的示例

3 理论分析

在本节中,我们首先描述EOV区块链和OCC数据库中的事务处理技术的相似性。然后,利用OCC数据库的事务分析方法对EOV区块链(Fabric和Fabric++)的序列化行为进行推理。最后,我们提出了一种基于重排序的并行控制算法,用于对EOV区块链中的可串行事务进行排序,并讨论了其安全意义。

3.1交易处理的相似性

与数据库系统类似,数据库快照概念用于描述数据库[20]的只读静态视图,在区块链中,我们可以定义类似的区块链快照概念如下。

Definition 1 (区块链快照):区块链快照是在提交块之后区块链的状态。设M为提交块的序列号,则对应的快照记为M,称其序列号(M+ 1,0) 。

Definition 2 (快照一致性):如果存在一个可以读取交易所有记录的区块链快照M,那么事务就是快照一致的。

Fabric中的交易满足快照一致性,因为Fabric使用锁来确保针对最新状态进行模拟。Fabric++会乐观地删除锁,但会提前终止跨块读取的事务。因此,它也满足快照一致性。但是,消除基于跨块读取的事务可能会导致快照一致事务的过度中止。

例如,在图3a中,Txn1读取快照1中版本(1,1)的键A和快照2中版本(2,1)的键B。这些版本与快照2中的键A和键B的版本相同。因此,Txn1是与块快照2快照一致的。相比之下,事务Txn2(也跨块读取)没有实现快照一致性,因为之前读取的键B的值在第2块中发生了变化。

Proposition 1: 存在跨块读取快照一致的事务。对于这样的事务,它的块快照由它的最后一次读操作决定。(快照是最新的块高)

Proof. 图3a中的Txn1是一个见证例子。在前面的示例中,我们已经展示了Txn1读取块1和块2,它仍然与块快照2保持一致。

Proposition1: 表明EOV区块链中的合法事务可以跨块读取,如果块的状态是一致的。这使得EOV区块链类似于OCC数据库,因为后者还读取由事务的开始时间戳决定的一致状态。我们还观察到区块链的序列号与数据库的时间戳具有类似的属性,比如原子  性、单调性、总顺序和对快照的惟一映射。因此,我们使用它们的序列号来定义区块链事务的时间戳。

Definition 3 (开始时间戳)。事务Txn的开始时间戳由StartTs(Txn)表示,是其读取快照的序列号。

我们使用两个值的元组,第二个元素0固定。这是为了方便实现排序关系是区块链快照小于事务时间戳的序列号。

Figure 4: Txn2和Txn3在同一块并发。Txn1和Txn2在不同的区块,但它们仍然并发。Txn1和Txn3不并发。

Figure 5: 快照事务之间的六个规范依赖项。这里(a)、(b)和(c)是非并发的,(d)、(e)和(f)是并发的。(两个交易执行重叠,称为并发)

Definition 4 (结束时间戳)。事务Txn的结束时间戳,用EndTs(Txn)表示,是它在块中的序列号,由一致共识决定。

例如,在图3a中,Txn1有StartTs(Txn1) =(3,0)和EndTs(Txn1) =(3,1),因为它最后从块2读取,并且占据了块3中的第一个位置。为了简洁起见,在后面的段落中,我们使用图3b中所示的符号来表示事务。此外,事务的序列号开始或结束时间戳是按字典顺序排列的,例如,(2,1)<(2,2)=(2,2)<(3,0)。

Definition 5 (并发事务)。两个事务Txn1和Txn2如果执行重叠,就被称为并发。具体来说,如果Txn1比Txn2早结束(即。EndTs(Txn1)< EndTs(Txn2),则Txn2必须在Txn1结束之前开始(即, StartTs(Txn2) < EndTs(Txn1))。否则,如果Txn2比Txn1早结束(即。EndTs(Txn2) < EndTs(Txn1),则Txn1必须在Txn2结束前开始(即Txn2结束前Txn1开始 StartTs(Txn1) < EndTs(Txn2))。

Proposition 2. 同一块中的每一对事务都是并发的。

Proof. 假设两个事务Txn1和Txn2分别提交到同一块M中的p和q位置,其中p < q,由于Txn2可以读取的最新区块是M−1,所以有StartTs(Txn2)≤(M, 0) < EndTs(Txn1) = (M, p) < EndTs(Txn2) = (M, q),因此Txn1和Txn2是并发的。

Proposition 3. 命题2的反面则不成立:存在不属于同一块的并发事务。

Proof . 我们在图4中给出了一个见证示例,其中事务Txn1和Txn2分别属于块M和块M+1。Txn2读取的数据块比M早,因此有StartTs(Txn2)≤(M, 0) <EndTs(Txn1) = (M, 1) <EndTs(Txn2) = (M+ 1,1),因此Txn1和Txn2是并发的。

从以上两个命题可以看出,并发不仅仅发生在同一块内的事务之间。Fabric++没有考虑跨块事务之间的依赖关系。因此,其重新排序效果有限。

3.2可串行性分析

图5显示了快照事务之间规范事务依赖(或冲突)的所有六种场景,如[15]所述。其中n-ww、n-wr、n-rw三个依赖项在非并发之间事务。其他三个依赖项,即c-ww、c-rw和anti-rw,在并发事务之间。根据[30]中的冲突可串行性定理,可串行事务调度的效果等同于任何遵循依赖顺序的串行事务历史。注意,可序列化事务调度的依赖图必须是非循环的。

Figure 6: 当切换提交顺序时,c-rw和anti-rw之间的依赖顺序保持不变,但c-ww不保持

Definition 6 (可串行性强)。如果事务调度的效果等同于序列化的历史,则事务调度是强可序列化的,后者符合由事务的结束时间戳决定的事务提交顺序。

Theorem 1. 没有anti-rw的事务调度实现了很强的可串行性。

Proof. 首先证明了任何不带anti-rw的事务调度都可以实现序列化。矛盾的是,假设这样的事务调度没有实现可串行化。然后,在计划中必须有一个具有依赖周期的事务子集,其中最后提交的事务由Txn表示。然后Txn必须显示一个anti-rw依赖关系,因为anti-rw是所有六个依赖关系中唯一一个将以后的事务与以前的事务联系起来的。但这与我们的假设相矛盾。因此,事务调度是可序列化的。接下来,我们证明了它也实现了强序列化。由于其余五个依赖项的顺序与它们的提交顺序一致,因此遵循提交顺序的序列化历史也遵循依赖顺序。根据[30]中的冲突可串行性定理,该串行化事务历史具有与可串行化日程相同的效果。因此,事务调度是强可序列化的。根据[30]中的冲突可串行性定理,该串行化事务历史具有与可串行化日程相同的效果。因此,事务调度是强可序列化的。

我们注意到Fabric/Fabric++不允许在两个事务之间使用anti-rw,因为后一个事务将读取更新后的key的版本,因此,它必须中止。根据定理1,Fabric/Fabric++中的事务满足强可串行性,这比[4]的可串行性更严格。这就提供了降低事务中止率的机会。

3.3  重新排序能力分析

在可串行性而非强串行性条件下,正式分析了EOV区块链中事务的可顺序性。我们主要通过切换挂起事务的提交顺序来确定可序列化的调度。

Lemma 1. 在区块链中,重新排序只能发生在并发事务之间。(并发分为同块未提交交易的并发,以及跨块之间的提交)

Proof.  假设事务重新排序发生在两个非并发事务之间。由于命题2的否定性,这些事务在不同的块中提交。改变它们的顺序意味着改变先前提交的块,而这在区块链中是不可能的,因为它们是不变性的。

Lemma 2. 在重新排序之后,事务不会改变其相对于其他事务的并发关系。

Proof. 假设下一个块的序列号为M。对于任何未提交的交易Txn,我们有:StartTs(Txn)≤(M, 0) < EndTs(Txn)。其他交易分为三种情况。(i) 对于任何非并发事务Txn1,我们有:EndTs(Txn1) < StartTs(Txn)。由于重新排序不影响StartTs(Txn), Txn和Txn1之间的非并发性仍然存在。(ii)对于任何Txn2在block M之前提交的并发事务,我们有: StartTs(Txn) < EndTs(Txn2) < (M, 0) < EndTs(Txn).因为重新排序不能将Txn的提交时间移到(M, 0)之前,所以Txn2和Txn保持并发状态。(iii)对于任何未提交的交易Txn3,我们都有StartTs(Txn) < (M, 0) < EndTs(Txn3) < EndTs(Txn), or StartTs(Txn3) < (M, 0) < EndTs(Txn) < EndTs(Txn3).因此,Txn和Txn3在重新排序后保持并发。

上面的引理1确保了重新排序不会影响非并发事务及其依赖关系。引理2确保非并发事务不会通过重新排序引入。因此,我们将分析局限于并发依赖关系。我们使用下面的两个引理来描述并发事务的依赖顺序。

如果两个事务Txn1和Txn2显示c-rw或anti-rw依赖关系,那么切换它们的提交顺序并不影响它们的依赖关系顺序

(a)  一个没有c-ww的不可重新排序的时间表

(b) 具有c-ww的可重新排序的时间表

Figure 7:  事务调度重新排序

Proof . 当Txn1和Txn2显示出c-rw(或anti-rw)依赖关系时,如果我们切换它们的提交顺序,它们将显示出anti-rw(或c-rw)依赖关系,如图6左侧所示。因此,在这两种情况下,它们的依赖顺序保持相同,即。Txn1读取一个key,该key稍后将由Txn2写入。

Lemma 4. 如果两个事务Txn1和Txn2显示出c-ww依赖关系,那么切换它们的提交顺序将改变它们的依赖关系顺序

Proof . 当Txn1和Txn2显示c-ww依赖关系时,Txn1将写入一个键,这个键将被Txn2覆盖。如果它们的提交顺序被切换,那么Txn2和Txn1将显示c-ww依赖关系,如图6右侧所示。现在,Txn2写入一个key,这个key将被Txn1覆盖。因此,Txn1和Txn2的依赖顺序颠倒了。

最后,我们提出了一个关于重新排序包含依赖循环的事务的定理。在3.4节中,我们利用这个定理来设计新的细粒度并发控制算法。 

Theorem 2 . 如果存在一个没有涉及挂起事务的c-ww依赖关系的周期,则事务调度不能被重新排序为可序列化。

Proof. 我们将循环中的依赖分为两类。第一类包括那些涉及至少一个已提交事务依赖的事务。由于区块链的不可变性,重新排序不会影响这些依赖性,因为两个事务的相对提交顺序是固定的。第二类包括一对未提交交易之间的所有依赖关系。对于每个依赖项,其对应的事务必须是并发的,否则将提交前面的事务。由于挂起的事务是并发的,并且没有c-ww,所以订单切换只能在使用c-rw或anti-rw的冲突事务之间进行。尽管被重新排序,它们的依赖顺序保持不变(引理3)。因此,循环调度仍然是不可序列化的,如图7a所示。

但是,如果在挂起的事务之间存在一个c-ww冲突的循环,事务调度可以被重新排序为可序列化。由于引理4,它们的依赖顺序可以翻转。我们在图7b中展示了这个场景,其中Txn1、Txn2和Txn3形成的循环调度通过切换Txn2和Txn3的提交顺序变得可序列化,Txn2和Txn3显示了c-ww依赖性。

3.4 细粒度并发控制

定理2指出,未执行事务之间的循环事务调度如果没有c-ww,即使重新排序也永远不能序列化。基于此,我们制定了以下三个步骤来实现EOV区块链中的细粒度并发控制。

• 对于新事务,我们首先考虑所有挂起事务(包括新事务)中除了c-ww之外的所有依赖关系。然后,如果存在依赖周期,我们直接删除新事务。

• 在块构造上,我们检索考虑到所有计算依赖关系的未决事务顺序。

• 最后,我们根据检索的调度恢复c-ww对未决事务的依赖。

注意,c-ww依赖恢复仍然是必要的,因为未来的不可排序事务可能会遇到包含已提交事务的c-ww依赖的循环。但是它们的提交和依赖顺序已经固定了。但是,恢复后依赖图仍然是非循环的。

我们将在算法1、2和3中概述细粒度并发控制,而实现细节将在第4节中介绍。我们使用符号A∪= B来表示带有并集A:= A∪B的自分配。在这里,我们认为算法3中的拓扑排序总是有一个解决方案,因为算法2保证事务依赖图G是无环的。即使只包含待处理事务的子图P也是有向无环图,因此必须有拓扑顺序。

与Fabric++中的重新排序算法相比,我们的算法粒度更细,因为非序列化事务在排序之前就会中止,而其余事务则保证可序列化而不会中止。我们的重新排序不再局限于一个块的范围。另一个显著的区别是,我们在模拟开始时确定块快照,而Fabric和Fabric++则根据上次的读取操作确定块快照。在智能合约模拟期间,我们允许块提交以获得更多的并行性,但这可能会在模拟期间由提交的事务更新之前读取的记录时引入过时的快照。

Algorithm 1: Contract simulation (合同模拟)

Input: Contract invocation context. (合同调用上下文。)

Output: readset, writeset are simulation results, b is the number of the block simulated on.(readset、writeset都是模拟结果,b是模拟上的块数。) // Section 4.2

1 b := fetch the number of the last block;(b:=获取最后一个块的高度)

2 readset, writeset := simulate the contract invocation on Block b snapshot; (readset, writeset:=模拟对b块快照的合约调用;)

 

Algorithm 2: On the arrival of a transaction (在交易到来时,进行交易过滤)这里是相较于orderer 来说

Data: G is the transaction dependency graph with nodes U and edges V , and P is the pending transaction set. (G为节点U、边V的事务依赖图,P为待处理事务集。)

Input: t is the transaction identifier, b is the number of the block simulated on, and readkeys, writekeys are accessed keys during simulation. (t是事务标识符,b是所模拟的块的编号,readkeys和writekeys是在模拟过程中访问的键。)

Output: reorderable property of t. (t的可重组性质。)

1 dep := Compute t’s dependency except c-ww among P based on G, b, readkeys, writekeys; (dep:=根据G、b、readkeys、writekeys计算t在P之间除c-ww之外的依赖关系;)// Section 4.3

2 reorderable := true if no cycle is detected in G with respect to dep, or f alse otherwise;(reorderable:=如果G中没有检测到dep的循环为真,否则为假;) // Section 4.4

3 if reorderable then

4 P ∪= {t};

5 G.U ∪= {t};

6 G.V ∪= dep;

3.5 Security Analysis (安全分析)

我们的重新排序算法作为排序过程的一部分,需要在排序服务建立交易顺序后在每个诚实的排序者上复制以形成分类账。我们假设最初的共识服务在其安全模型下的安全性和活力,无论是崩溃-失败还是拜占庭-失败。我们现在讨论这两个属性在重新排序后是否仍然保留。

Safety. 在原来的fabric设计中,有四个安全属性:一致性、hash链完整性、不跳过和不创建[4]。这些属性需要诚实的排序者按顺序交付一个分类账中一致的、未篡改的块。我们声明,我们的方法保持了hash链的完整性,并且没有跳过,因为我们没有改变块的形成过程。接下来,因为没有引入新的事务,所以没有创建。最后,我们达成了一致,因为我们在每个订货程序上完全复制了重新排序。此外,我们没有引入可能导致执行分歧的非决定论。只要诚实的定序者从一致的事务流中单独执行重新排序,他们将产生相同的分类账。

Liveness. Fabric根据有效性属性来定义活性,它要求所有广播的交易都包含在分类账中。我们的算法可能会损害这种活性属性,因为中止的交易被排除在分类账之外。然而,我们建议以下方法来防止滥用。具体来说,在consensus协议中,事务顺序是由leader节点尝试性地提出的。当这个顺序被其他节点接受时,它就成为我们重新排序方法的输入。因此,命令是由领导者控制的,领导者可能依赖于公开的重新排序算法恶意地延迟某些事务。假设检测到一个恶意领袖不良交易TxnT读写一块记录对状态的快照n .领导者使用代理同行和代理客户端,可以立即准备另一个事务TxnT的读取和写入相同的记录对阻止n .接下来,地方领导人TxnT”TxnT之前在订购。其次,领导在订货时将TxnT '置于TxnT '之前。其他订购者,不知道这个操作,可能接受这个订单。假设TxnT '通过算法2中的可重序性测试,每个诚实的序者将中止TxnT。这是因为这两个事务形成了一个不可重新排序的循环时间表,即TxnT ' depends TxnT with c-rw和TxnT on TxnT ' with anti-rw。缓解的关键是在建立事务订单之前隐藏事务的详细信息,比如访问记录。例如,我们允许客户端仅将事务散列发送给订货人。此外,客户有动机这样做,以避免上述操纵。在确定了事务散列的顺序之后,将其详细信息披露给排序者,以便进行重新排序。我们注意到,这种方法还可以通过改变事务内容来防止恶意客户利用重新排序。这是因为客户端已经通过发布事务散列做出了安全承诺。

Algorithm 3: On the formation of a block (在一个区块的形成上)

Data: G is the transaction dependency graph, and P is the pending transaction set. (G为事务依赖图,P为待处理事务集。)

Output: s is the commit order of pending transactions. (s是挂起事务的提交顺序。)

1 s := Topologically sort P based on reachability in G; (s:=基于G可达性的拓扑排序P;)

2 ww := Compute c-ww among P with s;  (ww:=计算P与s之间的c-ww;)

3 G.V ∪= ww;  / /Section 4.5

4 P := ∅

Figure 8: 我们的方法在排序服务中的集成

4 Implementation (实现)

4.1 Overview (概述)

在图8中,我们说明了我们所提议的细粒度并发控制在EOV区块链的订购服务中的集成。特别是,我们在Hyperledger Fabric和FastFabric之上实现了我们的方法。为了简单起见,我们只在EOV管道中显示了一个orderer和一个peer,但是在每个节点上复制了算法。虽然我们的大多数实现是在orderer中完成的,但算法1是集成在peer中,以便在背书阶段实现快照一致的事务执行。在orderer阶段,我们使用算法2来测试一个传入事务在一致意见决定其提交顺序后的可重组性。算法3在将挂起的事务批处理成块之前立即执行无中止的重新排序。我们注意到算法2和算法3对系统开发人员来说远不是实现友好的,因为两者都使用了抽象的依赖图。在此基础上,详细介绍了依赖图的设计和有效操作。

4.2 Snapshot Read (快照读取)

我们首先描述算法1使用的快照机制。我们依赖存储快照机制来确保根据一致的状态模拟每个合约调用。具体来说,在提交块之后,我们创建一个存储快照,并将其与块号关联。每个事务在进行模拟之前,必须获得最近的块的高度,如算法1所示。不进行任何模拟的静态快照将定期删除。这种设计在执行阶段允许跨合约模拟有更多的并行性,在验证阶段允许块提交。相比之下,vanilla Fabric使用读写锁来协调这两个阶段。

4.3 Dependency Resolution (不知道怎么翻译)

为了计算算法2中的依赖图,我们在orderer中引入了两个多版本存储来识别提交的事务。这些存储是在LevelDB中实现的(如果使用内存应该更快),分别表示CommittedWriteTxns (CW)和CommittedReadTxns (CR)。CW的每个键由记录键和更新值的事务提交序列的连接组成。例如,如果带有提交序列(3,2)的Txn1写入键A, CW就有一个条目{A 3 2: Txn1}。类似地,CR的每个键都由记录键和读取该键最新值的事务提交序列的连接组成。例如,输入{A 4 1: Txn7}表示Txn7是第4块中读取键A最新值的第一个事务。在CW和CR中,我们都将记录键放在提交序列之前,以有效地支持点查询和范围查询。例如,查询CW。Before(key, seq)返回最后一个提交的事务更新键,提交序列比seq早。类似地,CW.Last(key)返回最近提交的事务更新键。对于范围查询,CW[key][seq:]返回从seq到更新键的所有已提交事务。

我们维护两个内存索引,PendingWriteTxns (PW)和PendingReadTxns (P R),分别用于存储挂起事务的写和读集的键。考虑一个新的事务txn,它从startTS开始U,读取键为R,写入键为w。事务txn的所有依赖项计算如下。

anti-rw(txn) = Ur∈R CW[r][startT S :] ∪ PW[r]

rw(txn) = Uw∈UW CR[w] ∪ P R[w]

n-wr(txn) = Ur∈R CW.Before(r, startT S)

ww(txn) = Uw∈W CW.Last(w)

注意,我们忽略了挂起事务之间的ww依赖关系,并且不区分ww和rw是否并发。这是因为非并发事务可能是循环的一部分。然后计算txn的前身事务为ww(txn)∪-wr(txn)∪rw(txn),后续事务为anti-rw(txn)。

4.4 Cycle Detection (周期检测)

现在我们讨论如何表示依赖图G来检测循环和实现可串行性。我们面临两种设计选择。一方面,我们可以只维护每个事务的直接链接信息,然后执行图形遍历以进行循环检测。另一方面,我们可以维护每对事务之间的全部可达性信息。但是后一种方法将开销从计算转移到了空间消耗上。我们通过维护一个交易(txn.succ)的直接后继来实现一个最佳点,并使用bloom filter(称为txn)表示所有可以到达txn的交易。反向可得通过测试p,循环检测变得非常简单。由txn的一个前驱和一个后继者组成的每对(p, s)的抗可及性。

我们使用布隆过滤器是因为它们可以提高内存效率,并且可以执行快速合并。联盟广泛用于更新每个交易的可达性信息,如算法4所示。由于布隆过滤器内部依赖于位向量,因此可以通过按位或运算快速计算集合并集。然而,已知布隆过滤器报告误报[8]。如果过滤器向txn报告了一对相邻事务的误报,我们将预防性中止txn。 如果它们对所有对报告均为负,则txn不属于G中的任何循环。

算法4要求从txn遍历所有可达事务的开销相对较高。但是,此成本是可以承受的,因为在anti-rw(txn)为空时不需要进行遍历。在不偏斜的工作负载下通常是这种情况。 此外,如第4.6节所述,我们通过修剪依赖图来降低遍历的成本。

算法4中的另一个问题是反可达过滤器的持续增长。在实践中,我们观察到单个Bloom过滤器的误报率上升到无法忍受的比率。为了解决这个问题,我们使用两个带继电器的布隆过滤器。每个事务都与一个捕获在块M之后提交的布隆过滤器事务和另一个捕获在块N之后提交的布隆过滤器事务相关联。假设块C是最早的块,在G中包含已提交的事务。我们保持M <C <N,并使用第一个Bloom过滤器测试可达性。我们维持M <C <N并使用第一个Bloom过滤器来测试可达性。 每当C增长到M <N <C时,第一个Bloom过滤器就会清空,并开始从当前块中收集事务。 然后,我们使用第二个过滤器来测试可达性。通过这种方式,我们将布隆过滤器代表的交易数量限制在一定的区块范围内,以使误报率保持可接受的水平。 为了安全起见,诚实的订购者必须使用相同的M和N进行精确复制。

Algorithm 4: Reachability update for transaction txn(事务txn的可达性更新)

Data: G is the transaction dependency graph (G是交易依存关系图)

Input: M is the number of next block to be committed, pred is txn’s immediate predecessor transactions, and succ is txn’s immediate successor transactions.(M是要提交的下一个区块的高度,pred是txn的直接前一笔交易,而succ是txn的直接后继交易。)

1 txn.anti reachable := ∅;

2 for p in pred do

3 p.succ ∪= {txn};

4 txn.anti reachable ∪= p.anti reachable;

5 for s reachabale from succ in G do

6 s.anti reachable ∪= txn.anti reachable;

7 s.age := M;

下图是步骤的介绍:

Algorithm 5: Restoration of ww within pending transactions based on the computed commit sequence(根据计算的提交顺序恢复待处理事务中的ww)

Data: G is transaction dependency graph. (G是交易相关性图。)

Input: seq is committed sequence of pending transactions, PW is the index that associates updated keys with pending transactions.(seq是未决事务的提交序列,PW是将更新的密钥与未决事务关联的索引。)

4.5 Dependency Restoration(依赖恢复)

接下来,我们提出基于派生的提交序列将ww依赖项安装到依赖关系图G中的方法,该提交顺序是根据G中的可达性而确定的待处理事务P的拓扑顺序。一个突出的问题是,交易的可及性可能会受到来自各种更新key的多个ww依赖关系的影响。 但是我们希望在一次迭代中进行可及性修改,以提高效率。 算法5概述了还原ww依赖关系的主要步骤。 我们使用图9中的示例进一步解释该算法。

对于每个待处理事务(PW)要更新的key,我们在拓扑上对其关联的事务进行排序,并在可达性筛选器中选择尚未连接的第一对。在这样的一对中,第二笔交易可以从第一笔交易的所有前身中进行。在某些情况下,可访问性过滤器中已经连接了一对交易,这使恢复变得多余。例如,图9中的Txn0和Txn3就会发生这种情况。对于尚未关联的交易,我们需要更新其后继者。为了有效地做到这一点,我们将交易保持在一个集合(head txns)中,并根据拓扑顺序更新其后继者。因此,我们避免在第2行的迭代过程中多次更新信息。例如,图9中的Txn8通过keyA和keyB的更新是可到达的。使用我们的算法,可到达性信息将被更新一次。

4.6 Dependency Graph Pruning (依赖性图修剪)

由于图G可以快速增长,因此我们可以修剪(i)针对非常旧的快照进行模拟或(ii)不会影响待处理的交易的交易。对于第一种情况,我们引入一个名为max span的参数来限制事务的块跨度(如果针对块M模拟事务并在块M + 1中提交,则其块跨度为1。)。如果下一个块的数量为M,我们将快照阈值计算为H = M-最大跨度。 针对块H或更早版本模拟的任何事务都将中止。对于第二种情况,我们将事务txn的寿命定义为包含至少一个从G中的txn可以到达的事务的最后提交的块的序号。当快照阈值大于txn的使用期限时,将来的交易将无法与任何可以达到txn的交易并发。 在这种情况下,不会出现anti-rw依赖关系,这排除了任何包含txn的不可序列化的计划。 因此,可以从G中安全地删除txn。我们通过将G中的所有事务安排到按年龄加权的优先级队列中来简化修剪。 对于要在区块M中提交的新交易,我们在算法4(第7行)的遍历过程中将可以达到的交易寿命增加到M。 为了安全起见,所有订购者必须对最大跨度使用相同的值。

Figure 9: 具有待处理事务(标有蓝色虚线边框),提交序列,新的ww相依性(标有蓝色实线)和拓扑排序的迭代顺序的依赖关系图示例。 我们不考虑Txn0和Txn3之间的ww依赖性(用蓝色虚线标记),因为它是隐式的。 由于陈旧,红色的Txn1可能会被修剪。 交易年龄以斜体显示。

5 Experiments (实验)

5.1 Systems and Setup (系统和设置)

首先,我们在Hyperledger Fabric 1.3之上实现我们的方法,并命名结果系统FabricSharp。我们将FabricSharp与香草Fabric [4],Fabric ++ [26]以及我们通过直接采用从数据库到Fabric的OCC技术开发的两个新系统进行了比较。第一个系统,我们称为Focc-s,遵循[10]中的标准可序列化OCC方法。这种方法考虑了由两个连续并发的读写冲突与至少一个anti-rw形成的危险模式。我们修改了算法2,使具有c-ww冲突或危险模式的传入事务立即中止。 Focc-s对块形成不起作用。 第二个系统是Focc-1,它使用了最新的OCC技术[12],在此基础上我们构造了读写依赖图,并在算法3中将其基于排序的贪婪算法应用于重新排序。 Focc-1不过滤算法2中的任何事务。

其次,我们在FastFabric [20](正交的Fabric改进)的基础上实现细粒度的并发控制,并将命名的系统命名为FastFabricSharp。我们旨在调查FastFabricSharp在低争用的实际生产工作负载下的性能。在这两组实验中,我们在具有Intel Xeon E5-1650 3.5GHz CPU和32GB RAM的物理计算机上部署了两个订购者,三个Kafka节点和四个对等节点。机器通过1Gb以太网连接。 我们将智能合约配置为由单个对等方认可(执行)。 四个对等方中的任何一个都可以充当背书人,以分散工作量。 实验进行至少3次,并记录平均值。

5.2 Workloads and Benchmark Driver(工作量和基准驱动程序)

我们使用与基于Smallbank基准评估Fabric ++ [26]相同的工作负载。一笔交易从1万个帐户中分别读取和写入4个银行帐户。我们将其中1%设为热门帐户。每次读取都有一定的概率来访问热门帐户,这由“读取热比率”参数控制。同样,写入热门帐户也受写入热门比率的控制。 我们引入了另外两个工作负载参数,即“客户端延迟”和“读取间隔”。 前者控制客户从对等方收到执行结果后向定单广播的延迟。 此参数模拟客户端的网络传输延迟。后者通过控制连续读取之间的间隔来模拟繁重的事务。 表2列出了所有参数,默认值带有下划线。 我们将最大跨度固定为10,将请求速率固定为700 tps。 这是因为Fabric在我们的设置中可以维持大约700 tps的最大原始吞吐量,如图1所示。除非另有说明,否则所有报告的吞吐量均表示有效吞吐量,该有效吞吐量表示通过可序列化性检查并保持其状态的事务。

5.3 The Performance of FabricSharp(FabricSharp的性能)

 Block Size.  我们首先确定导致每个系统最高吞吐量的块大小,然后在其余的实验中使用这些大小。 图10显示,当块大小设置为100个事务时,FabricSharp实现了最高吞吐量(542 tps)。相反,当一个数据块分别限制为200、200、200和400个事务时,Fabric,Fabric ++,Focc-s和Focc-1分别达到其峰值性能411、437、327和415 tps。 因此,与最新的Fabric ++相比,我们的FabricSharp的吞吐量提高了25%。

Table 2: Experiment parameters (实验参数)

Parameter Value

# of transactions per block 50, 100, 200, 300, 400, 500

Write hot ratio (%) 0, 10, 20, 30, 40, 50

Read hot ratio (%) 0, 10, 20, 30, 40, 50

Client delay(客户端延迟) (x100 ms) 0, 1 ,2 ,3, 4, 5

Read interval (x10 ms) 0, 4, 8, 12, 16, 20

Figure 10: 不同快大小下的性能

与我们的预期相反,即使有更多事务可重新排序,Fabric ++也无法通过更大的块实现更高的吞吐量。我们将其归因于更长的延迟,这加剧了争用,从而导致更多无法序列化的事务。一方面,形成一个块需要更长的时间。另一方面,在块形成之前进行重新排序需要更多的时间,因为有更多的事务。例如,我们观察到Fabric ++中的重新排序花费4.3毫秒(每块50个事务)和401毫秒(每块500事务)。相反,由于其轻量级方法,Focc-1分别花费了0.12ms和5.19ms,尽管它类似地构造了一个依赖图。 这就解释了为什么Focc-1具有较短的延迟并在较大的块上表现更好。 但是,当块大小小于200时,与Fabric,Fabric ++和Focc-1相比,FabricSharp和Focc-s的吞吐量都明显更高。 这是因为FabricSharp和Focc-s在重新订购之前在订购阶段都应用了预防性中止。 这缓解了验证阶段的瓶颈,这是瓶颈。 相反,Fabric,Fabric ++和Focc-1具有较小块的高延迟,因为分类帐中包含许多不可序列化的事务,并且它们使Validation阶段超载。

Write Hot Ratio. 为了评估写-写冲突的影响,我们将更多的写操作集中到固定数量的热帐户中。如图11(左)所示,FabricSharp的吞吐量仍然是所有系统中最高的。不出所料,由于对c-ww的阻止,Focc-s的吞吐量显着下降。我们还观察到,Fabric ++的重新排序延迟一直很长,而Focc-1中的此延迟较小,并且与偏斜度的增加成比例。这是因为Focc-1轮流遍历未决事务的依赖关系图。 在每一轮中,其基于排序的贪婪算法都会修剪事务,直到只有没有依赖性的事务为止。相反,Fabric ++计算所有周期并确定要以批处理模式中止的事务。 因此,与Focc-1相比,它的重新排序过程对工作量偏斜不那么敏感。图11显示FabricSharp(算法3)中的重新排序延迟很短。 这是因为FabricSharp会在交易到达时将大部分工作(例如,依赖图维护)转移到算法2。 我们注意到,FabricSharp中很大比例的重新排序延迟(50%)用于恢复〜ww冲突,并且该比率随着较高的写入热比率而增加。 

Read Hot Ratio. 我们增加了读取热比率,以在工作负载中产生更多的读写冲突。 如定理2中所述,带有这些冲突的依赖循环永远都不能重新排序以变得可序列化。 根据我们的解释,我们在图12中显示,除Focc-s外,所有系统的吞吐量均以相似的速率下降。当50%的读取请求位于热帐户上时,与Fabric和Focc-1相比,Focc-s的吞吐量更高。这是因为与Fabric和Focc-1相比,Focc-s对可序列化性施加了更严格的条件。如果Focc-s与至少一个反rw形成两个连续的读写冲突,则它们将中止事务,而除FabricSharp之外的其他系统会在一个反rw时立即中止。因此,Focc-s可以恢复更多可序列化的事务,尤其是在大量读写争用的情况下。图12(右)显示了传入事务的处理延迟细分。正如预期的那样,依赖关系图上的可到达性更新在FabricSharp中占了最大的延迟比例,因为必须遍历传入的所有可到达事务。随着工作负载中更多的依赖关系,此开销会增加。与FabricSharp相比,Focc-s和Fabric ++中的事务处理延迟几乎可以忽略不计。但是,Focc-s比Fabric ++需要更长的时间,因为它需要另外标识冲突的事务,而不是像Fabric ++那样仅基于访问的记录来索引事务。

Figure 11: Throughput and reordering latency under varying write hot ratio(在不同的写热比下吞吐量和重新排序延迟)

Figure 12: Throughput and transaction processing latency under varying read hot ratio(读热比不同时的吞吐量和事务处理延迟)

Client Delay.(客户端延迟)接下来,我们在客户端模拟网络传输延迟,以研究其对交易的端到端处理的影响。 使用客户端延迟参数,我们在执行和订购阶段之间引入了延迟。 如预期的那样,更长的客户端延迟会增加端到端延迟和事务的块跨度。 反过来,这会导致吞吐量降低,如图13(左)所示。 而且,更大的块跨度导致更多的并发事务和更多的依赖关系。 如图13(右)所示,当客户端延迟较高时,FabricSharp遍历依赖关系图中的更多事务以更新其可达性(算法2)。 尽管如此,FabricSharp的性能还是优于所有其他系统。

Read Interval.(阅读间隔)为了模拟事务导致大量计算的情况,我们增加了事务执行过程中连续读取之间的间隔。 当事务需要更长的时间来执行时,跨块读取的可能性更高。 Fabric ++通过中止跨块读取的事务来防止这种情况,即使某些事务可能是可序列化的。 如图14所示(右图),在执行阶段被中止交易的比例更大,这证明了这一点。 Focc-s始终从有效的块快照读取数据,因此,扩展事务执行的效果会导致更高的端到端延迟。这导致更多的并发事务,进而导致c-ww和Focc-s中的危险模式的中止率更高。 值得注意的是,随着交易执行时间的延长,香草织物的性能急剧下降。 我们将此归因于仿真和块提交期间使用的读写锁,这可防止并行性。

Figure 13: Throughput of all systems (left) and statistics of FabricSharp (right) under varying client delay(在不同的客户端延迟下,所有系统的吞吐量(左)和FabricSharp的统计信息(右))

Figure 14: Throughput (left) and abort rate (right) under varying read interval(在不同读取间隔下的吞吐量(左)和中止率(右))

5.4 The Performance of FastFabricSharp (FastFabricSharp的性能)

接下来,我们在FastFabric [16]之上分析我们的方法的性能。FastFabric将同一管理域中的对等节点分离为背书者,存储和验证者节点。背书人,存储节点和验证人分别负责事务执行,块持久性和事务验证。 这些优化使FastFabric的速度比香草织物快6倍,如[16]中所述。

我们在FastFabric之上实现我们的重新排序技术,并将命名的系统命名为FastFabricSharp。 在我们的四个对等点的实验设置中,我们将两个对等点设置为背书,一个作为存储,另一个作为验证器。 与上一组实验中使用的经过修改的Smallbank相比,当工作负载表现出更少的冲突时,我们使用基于原始Smallbank的两个工作负载来评估我们方法的有效性。 第一个工作负载由统一的仅更新事务(创建帐户)组成,由于缺少读取操作并因此具有抗rw的特性,因此它们都可以序列化。 第二个工作负载是50%的只读交易(查询帐户),30%的交易修改单个帐户(存款检查,写支票,交易保存)和20%的交易修改两个帐户(发送付款,合并)的混合体 )。 访问的帐户的偏斜度由zipfian参数θ控制。

图15报告了FastFabric和FastFabricSharp之间的比较。 通过无争用的“创建帐户”工作负载,与原始Fabric相比,FastFabric在我们的实验设置上实现了4.5的加速,即原始吞吐量为3114 tps对677 tps。 FastFabricSharp中的重新排序开销小于5%,其有效吞吐量达到2960 tps。 与FastFabric相比,在混合工作负载下,FastFabricSharp可以实现更高的吞吐量。 此外,FastFabricSharp和FastFabric之间的差距随着偏斜度的增加而增大。 当θ= 1时,FastFabricSharp可以达到2370 tps,比FastFabric的1424 tps多66%。 FastFabricSharp的收益主要来自带有anti-rw的序列化事务,如图15所示,它们都被FastFabric中止。

我们得出结论,即使在重负载下,重新排序的好处也超过了计算开销。 根据以前的实验,这种开销主要是由于可达性更新而引起的,这取决于事务的复杂性。 在实践中,如果我们的重新排序成为瓶颈,我们可以简单地采用区别对待的方法。 例如,可以使用简单的可序列化条件(例如,存在反rw冲突)来检查具有更多引用记录的复杂交易。 另一方面,简单的事务将传递给细粒度的重新排序。

Figure 15: Effective throughput of FastFabric and FastFabricSharp under the contention-free (Create Account) and mixed workload(无争用(创建帐户)和混合工作负载下的FastFabric和FastFabricSharp的有效吞吐量)

6 Related Work (相关工作)

Concurrency Control in Databases.(数据库中的并发控制)

具有大内存和多核体系结构的现代硬件为重新设计OLTP RDBMS及其并发控制提供了新的机会[19]。 各种工作都试图使数据访问更易于缓存[35、28]或提取更多的执行并行性[34、32]。 其他人则努力根据工作负载特征和应用程序需求来简化事务排序[17、12、29]。 我们的工作更接近于后一种方法,但我们专注于区块链系统。 特别是,我们从数据库中的标准化交易分析技术中学习,并提出了一种新颖的技术来有效减少EOV区块链中已中止交易的数量。

Concurrency Control in Blockchains.(区块链中的并发控制)由于易于推理,智能合约的串行执行长期以来一直是区块链采用的唯一解决方案。 Fabric拥有新颖的EOV架构,是将并发管理正式引入区块链的先驱系统。 它引发了一系列相关的优化,例如Fabric ++ [26]和增强的体系结构,例如OXII [3]。 Fabric ++是离我们最近的工作。 它还旨在减少EOV架构下中止的事务数量。 但是,我们的方法提供了更细粒度的并发控制,该控制仍可以序列化由Fabric ++中止的事务。

Bridging the Gap between Database and Blockchain Transactions.(缩小数据库和区块链交易之间的差距)长期以来,在他们的调查[24,13]和基准[14]中都观察到了区块链和数据库之间的相似性。 通过转换已建立的数据库技术,例如经典的两阶段提交[18,36,11],解决了区块链中跨链或跨分片交易的原子性的著作有很多。 内森(Nathan)等人。 提议在数据库之上实施区块链,以依靠其存储过程来实现更丰富的合同表达[23]。 智能合约作为区块链中交易工作量的关键推动因素,已得到广泛优化,以利用沿袭信息[25]或跨应用程序的机密性[2]更好地发挥效用。

7 Conclusions(结论)

我们提出了一种新颖的解决方案,通过应用来自OCC数据库的事务分析来有效降低EOV区块链中的事务中止率。 我们首先得出EOV区块链和OCC数据库之间的理论平行性。 然后,我们提出了一种细粒度的并发控制方法,并分别在基于Fabric和FastFabric的FabricSharp和FastFabricSharp中实现。 我们的实验分析表明,FabricSharp和FastFabricSharp均优于其他区块链系统,包括香草Fabric,Fabric ++和FastFabric。 与实现高吞吐量的数据库不同,由于与安全性相关的因素,区块链的有限吞吐量为精确的交易管理开辟了机会。

8 Acknowledgements(致谢)

这项研究得到了新加坡教育部学术研究基金第3层的支持,教育部的正式资助号为MOE2017-T3-1-007。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页