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节点执行此阶段。块中的事务根据相应的背书策略和事务的可串行性进行顺序验证。事务的可串行性通过检查其读集的