Scaling Hyperledger Fabric Using Pipelined Execution and Sparse Peers(提升fabric 6倍性能的文章翻译)

本文章是记录我对hyperledger fabric pipelined 

 

ABSTRACT

许多使用Hyperledger Fabric(允许使用的区块链平台)构建的区块链应用程序的概念证明，最近已经转化为生产。但是，由于网络使用量的稳定增长，Hyperledger Fabric提供的性能对于企业来说是至关重要的。因此，在本文中，我们研究了使用垂直扩展（即通过添加更多vCPU）和水平扩展（即通过添加更多节点）技术在Fabric网络中实现的性能。我们发现，使用这两种技术，网络扩展性都非常差。在垂直扩展中，由于事务的验证和提交阶段的串行执行，分配的vCPU使用不足。 对于水平缩放，由于节点之间的冗余工作，分配的资源虽然被利用，但却被浪费了。此外，我们发现这些技术不适合快速动态扩展网络以减轻过载情况，因此会导致性能下降30％。为了提高CPU利用率并因此提高性能，我们通过使用Trie数据结构引入脏状态管理来重新构造Fabric，以实现验证和提交阶段的流水线执行。此外，我们通过引入等待事务依赖关系图，促进了验证阶段以并行验证事务。 为了避免节点之间执行多余的工作并快速扩展网络，我们提出了一种新型的对等节点，称为稀疏对等，该节点选择性地提交事务。 总体而言，我们将吞吐量提高了3倍，并将网络扩展所需的时间减少了96％。

1. INTRODUCTION(引言)

区块链技术之所以流行，是因为它提供了一种摆脱中介和分散应用程序的方式。 区块链是一个分类账，记录交易和数据，这些交易和数据跨多个对等节点复制，其中一个节点不信任另一个节点。 每个节点都拥有与区块链相同的总账副本，每个区块都是逻辑上的交易顺序。通过在节点之间执行共识协议来创建一个块，并且每个块都将其前一个块的哈希括起来，从而保证分类帐的不变性。

对于涉及多个组织之间交互的企业用例，许可的区块链网络是合适的，因为它支持经过身份验证的参与者，并具有交易，数据和用户的隐私权。不同的组织在许可的网络中拥有节点，并且交易逻辑是使用智能合约实现的。Hyperledger Fabric [20]是由Linux Foundation [8]托管的最受欢迎的许可区块链平台。 使用Hyperledger Fabric为各种行业构建的许多概念性区块链应用证明，例如Food Trust [7]，Chain-m [2]，openIDL [10]，TradeLens [14]，WeTrade [17]，SecureKey [13]，CLSNet [3]和everledger [5]仅举几例，最近都已转化为生产。

但是，由于网络使用量的稳定增长，Hyperledger Fabric的性能已成为企业关注的重点。例如，要跟踪食品中使用的成分（如蛋白棒，巧克力和其他包装食品）的来源，我们需要大量存储大量记录。在当前形式下，Fabric无法提供大型出处用例和金融业所需的性能，例如证券交易所，Visa [16]等信用卡公司和AliPay [1]等移动支付​​平台（ 325k tps）。此外，随着令牌[22、15]和相关应用程序（例如分散市场[11、9、12、4]）的创新，吞吐量需求只会增加。因此，有必要提高Fabric的性能以主动支持持续的增长。即使使用Fabric提供的当前性能，由于不存在放大/缩小网络的机制，节点仍会超额配置以满足峰值负载。结果，运营成本不必要地增加。

尽管最近许多研究[34,35,27,25,23,30]提出了各种优化方案来提高织物性能，但没有人研究过缩放技术(如垂直和水平缩放)对织物性能的影响。因此，在本文中，我们研究各种扩展技术的效率，并确定瓶颈。然后，我们以透明的方式重新构建织物以提高性能。一般来说，共识层被认为是瓶颈。由于工作证明共识(PoW)，虽然它对不允许的区块链(如Ethereum[21]、Bitcoin[31])是有效的，但我们发现瓶颈是块的验证和提交，而不是共识层，因为它使用Raft[33]进行订单交易。我们的四大贡献如下:

1. 我们使用各种技术进行了实验，以了解Fabric的可伸缩性，这些技术包括(a)按vcpu进行伸缩、(b)按节点进行伸缩、(c)按通道进行伸缩、(d)按节点和通道进行伸缩以及(e)按背书策略进行伸缩。我们发现，这些技术(i)由于验证和提交阶段的串行执行和CPU和IO密集型任务的重复导致网络伸缩性差，或(ii)创建数据竖井，或(iii)导致信任模型较弱。此外，为了动态扩展网络以处理过载情况，我们认为这些技术不适合。

2. 我们重新架构了Fabric，使验证和提交阶段能够以流水线方式执行，而不会违反序列化隔离。除此之外，我们还通过引入等待事务依赖关系图(它跟踪事务之间的六种依赖关系)，促进了验证阶段并行地验证属于不同块的多个事务。结果，性能提高了1.36倍，CPU利用率从50%提高到70%。

3.我们引入了一种名为稀疏对等的新型节点，它有选择地提交事务，这有助于避免重复CPU和IO密集型任务。因此，性能提高2.4倍。总的来说，我们的方法至少提高了3倍的性能。

4. 我们构建了一个自动伸缩的框架，它可以将一个完全对等点分解为多个稀疏对等点，或者将多个稀疏对等点合并为一个完全对等点。这有助于快速扩展网络以处理过载情况，并减少无效事务的数量。我们的方法将扩展网络所需的时间减少了96%，同时增加了扩展时间。

本文的其余部分结构如下。§2提供了Hyperledger Fabric的背景知识，并通过进行各种实验来激励我们的工作。§3描述了我们提出的Fabric架构。§4给出了一个框架，可以帮助织物网络的动态伸缩。§5简要描述了实现细节。§6用香草织物对我们提出的架构进行评估，并展示所取得的改进。§7介绍了相关工作，§8对本文进行了总结。

2. BACKGROUND AND MOTIVATION (背景和动机) 

2.1 Hyperledger Fabric Architecture (建筑学)

Hyperledger Fabric由三个实体组成——客户端、对等方和订货方。Fabric中的事务流涉及所有三个实体，并由四个阶段组成——模拟、排序、验证和提交，如图1所示。图2显示了对等节点中的各种组件，这些组件涉及到模拟、验证和提交阶段的执行。不同实体之间的通信通过谷歌远程过程调用(gRPC)[6]进行。

  

Figure 1: Transaction flow in Hyperledger Fabric

Figure 2: Various components in peer involved in simulation, validation, and commit phase.（peer中的各种组件涉及仿真、验证和提交阶段。）

Phase 1—Simulation.（模拟阶段）客户端向对等端提交事务建议，调用实现事务逻辑的智能契约。背书人验证提案消息中的输入并将其传递给适当的智能合同。根据输入，smart-contract执行逻辑并通过向背书方发出GetState()、PutState()和GetStateByRange()调用来读写它所管理的状态。对于一个读请求，即GetState()，背书人从状态数据库中读取状态，并在将其传递给smart contract之前将其添加到背书人维护的事务的读集中。对于一个写请求，例如PutState()，背书人在不修改状态数据库的情况下将值存储在事务的写集中。对于一个范围读取查询，即GetStateByRange()带有一个开始和结束键，背书者返回一个迭代器到智能契约。通过调用迭代器上的Next()，智能契约读取状态。背书人将开始键、结束键和键列表存储在一个称为范围查询信息的单独数据结构中，而不是将这些状态存储在读集中。事务执行完成后，背书人在将事务响应(包括事务建议、读写集和范围查询信息)发送给客户端之前，对其进行加密签名/背书。

根据为智能合同定义的背书策略[29]，客户端可以同时向多个对等端提交交易建议。每个智能合同都维护着自己的状态。一个智能契约可以通过调用它来访问/修改由另一个契约维护的状态。一个智能契约调用另一个契约使应用程序设计者能够将一个单块契约分割成多个微契约，每个微契约执行一个特定的任务。

Phase 2—Ordering. （排序阶段）客户端向订购服务提交已批准的事务响应。由来自不同组织的订购者节点组成的订购服务使用一致协议[33]对接收到的事务进行排序并创建一个块。每个块都有一个称为块号的序列号、前一个块的散列、当前块的散列、有序事务列表(即提交顺序)和顺序者的签名。orderer节点将创建的块广播给对等节点。

Phase 3—Validation.（验证阶段）对等方的八卦组件接收块并将它们存储在一个块队列中。(1)收集到的背书满足smart contract指定的背书策略;(2)事务可序列化。背书策略验证器通过检查事务响应上的签名集是否由背书策略中指定的组织集签名来根据背书策略验证背书。如果一个交易调用了多个智能契约(通过允许一个智能契约调用另一个智能契约的特性)，那么每个智能契约的策略必须得到满足。当交易没有足够的背书时，交易被标记为无效。

策略验证器验证所有事务之后，可串行性验证器使用有效事务的事务响应中的读写集应用乐观并发控制(OCC)[28]。为了方便OCC, Fabric为区块链中存储的每个状态添加了一个版本标识符。状态的版本只是块号和最后更新/创建状态的块中的事务号的组合。所有验证器检查的是是否事务已读的状态，以决定它的写集，并没有被区块中有效的事务和已经提交的事务修改。此外，验证器会重新执行范围查询信息中出现的范围查询，以检测任何违反serializability属性的幻影读取。注意，策略验证器并行验证块中的事务，而串行性验证器串行验证每个事务，这样它就可以考虑块中以前有效事务的写集。

Phase 4—Commit. （提交阶段）

在验证阶段之后，首先，提交者将块存储在块存储中，它是存储在文件系统中的一串块，以及事务有效性信息。其次，提交者将所有有效事务的写集应用到状态数据库，该数据库维护所有活动状态。第三，它将所有有效和无效事务的写集存储到历史数据库中，该数据库同时维护活动和非活动状态。磁盘写入块存储、状态数据库和历史数据库是串行和同步的，以处理故障后的恢复。注意，历史数据库只维护一个状态形式的索引，该索引为{块号，块内的事务号}的列表，这样可以检索每个状态的实际历史使用事务的写集从块存储中获取。

Fabric blockchain network & channel.（区块链网络及通道）

使用Fabric创建的区块链网络由多个组织组成，每个组织都拥有一组客户机、对等节点和订购者节点。Fabric引入了一个称为channel的概念，以提供组织对等方之间通信的专用子网。通道上的事务只被通道的成员看到。各州和智能合同都是基于个人利益。此外，这个共识是适用于所有渠道的，也就是说，对于跨渠道的交易没有定义的顺序。每个通道维护自己的区块链，即文件系统上单独的块链和用于保存活动状态的单独数据库。根据隐私要求，fabric网络可以运行多个通道。

2.2 Scalability of Fabric and Bottlenecks( Fabric的可伸缩性和瓶颈)

在本节中，我们将介绍扩展fabric网络以获得更高事务吞吐量的不同方法。此外，我们通过进行各种实验来量化可伸缩性，并找出限制可伸缩性的瓶颈。传统上，分布式系统可以纵向扩展，即通过向现有节点添加更多的功率(vcpu)，也可以横向扩展，即通过添加更多的节点。除此之外，渠道的概念和简化的背书政策也有助于扩大网络。

Step :图3展示了用于所有实验的区块链网络拓扑。它由4个组织组成，每个组织托管N个对等节点，基于raft共识协议[33]的5个节点订购服务，M个客户端在网络上生成负载。根据实验的不同，M和N的值会发生变化。每个节点都托管在数据中心的虚拟机上(有关资源配置，请参阅图3)。我们将吞吐量作为主要的性能度量。吞吐量是指在保持小于或等于500毫秒的延迟的情况下，在网络中提交事务的峰值速率。延迟是客户端从发送事务建议到提交事务所花费的时间。请注意，我们在区块链网络中只使用了四个组织，因为它代表了大部分的用例。例如，在供应链解决方案中，参与者将是买方、制造商、供应商和承运商。在汽车保险解决方案中，参与者将是保险公司、警察局、修理店和汽车零部件店。此外，我们的结果也适用于拥有大量组织的网络。这是因为本节中确定的瓶颈与网络大小无关。当组织数量增加时，订购者节点需要将块发送给多个对等点，这会极大地增加订购者和对等点之间的网络利用率。这可以通过增加订货节点的数量来解决[20,35]。

                                          Figure 3: Experimental setup.(实验设置)

Workload and Configuration.(工作负载和配置)除非另有说明，在默认配置中，每个组织托管一个对等体，并且所有组织都是一个单一通道的成员，该通道托管8个智能合同，每个实现小银行基准[18]。我们使用small bank(由BlockBench[24]定义)作为本文的主要基准，因为它是被允许的区块链系统的一个流行基准。工作负载由对一组100,000个帐户的6个操作组成。在这6个中，有5个既涉及读也涉及写，有一个只涉及读。为了产生负载，我们均匀地选择一个特定速率的操作。我们采用了以下两种背书策略:(1)简单——通道中的任何一个组织都可以执行和背书交易;(2)复杂——通道中的所有组织都必须执行并认可该事务。所有实验的块大小为100个事务。表1展示了用于研究fabric网络性能的参数配置，同时使用了六种不同的缩放方法(包括我们在§3中提出的方法)。表1还总结了实现的最大吞吐量以及每种方法的缺点。

Table 1: Parameters used to study the performance of a Fabric network using various scaling approaches(使用各种缩放方法研究fabric网络性能的参数)

Base Case Performance.(基本情况的性能)我们没有使用普通的Hyperledger Fabric v1.4作为基础案例，而是使用了一个优化的版本，它使用了[26]中提议的块序列化缓存，避免了对等点中各个阶段的冗余块序列化和反序列化。这是因为Hyperledger Fabric社区意识到了这一点，并计划在即将发布的版本中修复它。使用块反序列化缓存，吞吐量提高了1.67倍，即使用默认配置从1040 tps提高到1790 tps。

(1) Scaling By vCPUs.O(通过vcpu进行缩放)图4(a)在不同数量的已分配vcpu上绘制吞吐量和CPU利用率。随着分配的vcpu从1个增加到16个，吞吐量不成比例地从280 tps增加到1790 tps(增量6.4倍)，而CPU利用率从87%下降到50%。当vcpu数量较低时，endorser和validator都会争用CPU资源，从而增加了CPU利用率。随着vcpu数量的增加，CPU争用减少，背书策略验证器使用多个vcpu并行验证事务，从而提高吞吐量。此外，在IO较多的提交阶段的执行期间，不执行CPU较多的验证阶段，反之，这将导致CPU利用率不足。这是因为验证器不能同时验证块(i + 1)和块(i)的提交，因为在提交期间执行的状态更新会使验证器利用陈旧状态。正如在§2.1中提到的，serializability验证器串行地验证每个事务，这进一步降低了CPU的利用率。

图5(a)绘制了验证和提交阶段处理大小为100个事务块所花费的时间。正如预期的那样，随着vcpu数量的增加，验证阶段所花费的时间从144毫秒显著减少到23毫秒。在提交阶段所花费的时间(≈20 ms)中没有观察到这种减少，因为它主要取决于IO性能，而不是CPU。(这里所说的验证和mvcc 读集验证没有关系)

Figure 4: Performance of various scaling approaches.（各种可伸缩方法的性能。）

Figure 5: Time taken by the validation & commit phases.（验证和提交阶段所花费的时间）

Takeaway 1.(结论)对等点的垂直扩展可以起到一定的帮助，但是为了充分利用已分配vcpu的潜力，验证和提交阶段的流水线执行是必要的。

(2) Scaling By Peers（扩展peers）. 图4(b)绘制每个组织不同数量的对等点上的吞吐量和CPU利用率。与每个组织1个对等点相比，4个对等点仅增加了1.1倍的吞吐量。这是因为每个组织中的所有4个对等点验证并提交了每个块，即组织中的冗余工作。随着对等点数量的增加，客户机只对事务的背书在对等点之间进行负载平衡，这也降低了CPU利用率。由于需要进行多个签名验证和同步磁盘IO，因此验证和提交阶段的成本要高于模拟阶段，因此吞吐量的增量并不显著。当背书请求的负载平衡增加吞吐量时，我们希望找到零背书请求的对等点的峰值吞吐量。因此，对于一个对等点，我们不提交任何背书请求，而使用其他对等点来负载平衡背书请求。我们观察到，未认可的对等端达到了3000 tps的峰值吞吐量，这是通过验证和提交阶段可实现的最大吞吐量。图5(b)绘制了验证和提交阶段所花费的时间。随着对等点数量的增加，验证和提交时间分别从23毫秒减少到19毫秒和21毫秒减少到15毫秒。这是因为减少了每个对等点的背书负载，从而略微减少了CPU和IO上的争用.

Takeaway 2.(结论)通过添加更多的对等节点来横向扩展Fabric网络可以帮助减少背书人的负载，即模拟阶段，但是由于冗余工作，这对验证和提交阶段没有帮助。由于一个组织不信任另一个组织，因此需要跨组织进行冗余工作，但同样的工作不适用于组织内的同行。为了提高组织的性能，有必要避免组织内部同事之间的冗余工作。

(3) Scaling By Channels. （对渠道进行扩展）图4(c)绘制了不同数量通道上的吞吐量和CPU利用率。随着信道数量从1个增加到8个，吞吐量从1790 tps增加到3034 tps(增量1.69倍)。这是因为每个通道独立于其他通道，并维护其块链。因此，多个块(每个通道一个)的验证和提交阶段并行执行，从而提高了CPU利用率，从而提高了吞吐量。图5(c)绘制了在不同数量的通道上验证和提交阶段所花费的时间。随着每个对等点通道数量的增加，验证和提交阶段所花费的时间分别从23 ms增加到85 ms和21 ms增加到106 ms，这是由于并行处理块增加了对CPU和IO的争用。

Takeaway 3.（结论）尽管增加通道增加了吞吐量，但它导致了有限的数据访问。托管在一个信道上的智能契约只能为读取操作调用同一对等点内另一个信道上托管的智能契约。此外，不能跨通道进行序列化验证，这可能无法满足跨通道涉及多个smart contract的事务的序列化属性。因此，信道可能不是扩展网络的合适技术。

(4) Scaling By Channels and Peers. 图4(d)绘制了当每个组织的对等点数量为4时，通过不同数量的通道实现的吞吐量和CPU利用率(对于每个组织有1个对等点的情况，请参见图4(c))。与仅通过通道扩展相比，这种方法将吞吐量显著地从1790 tps增加到9668 tps(增量5.4倍)。这是因为当每个组织的单个对等点承载所有通道时，由于并行处理多个块(每个通道一个)，该对等点上的CPU和IO争用都很高。随着每个组织的对等点数量的增加，每个对等点通道计数减少了，从而减少了对等点上的CPU和IO争用，从而提高了吞吐量。

图5(c)绘制了验证和提交时间。随着通道数量从1增加到4，验证和提交时间分别从19毫秒增加到27毫秒和15毫秒增加到19毫秒。这是因为每个对等点的背书负载增加了。由于信道在节点间的均匀分布，随着信道数量的增加，处理信道的节点数量减少，增加了每个节点的背书负载。当通道数为8时，验证和提交时间分别增加到33毫秒和36毫秒。这是因为每个对等点处理两个通道，这导致并行验证和提交两个块。

Takeaway 4.（结论） 通过添加更多的对等点和通道来扩展Fabric网络，可以显著提高吞吐量。然而，托管在一个通道上的智能契约不能调用托管在另一个对等点上的另一个通道上的智能契约(即使是在同一组织内)进行读写操作，这会导致绝对数据竖井。只有在需要完整的用户、事务和数据隐私时，才首选通道。因此，通过对等点和通道进行扩展可能不是在光纤网络中实现更高吞吐量的合适技术。

(5) Scaling by Endorsement Policy.（根据背书策略进行伸缩）图7(a)和7(b)分别绘制了在支持策略简单和复杂时，通道中不同数量的组织所实现的吞吐量和CPU利用率。请注意，每个组织运行一个对等点。与简单的背书策略相比，随着签名验证数量的增加，复杂策略导致吞吐量降低。随着使用简单策略的组织数量的增加，背书请求在更多的对等节点之间进行负载平衡，从而提高吞吐量并降低CPU利用率。但是，随着使用复杂策略的组织数量的增加，吞吐量下降，而CPU利用率增加。这是因为验证器必须对越来越多的组织验证额外数量的签名。

Figure 7: Impact of policies（背书策略的影响）.

Takeaway 5. 使用一个简单的背书策略可以显著提高性能。然而，这将导致一个较弱的信任模型。此外，背书策略更依赖于应用程序场景和所需的信任模型。在本文的其余部分中，我们只考虑复杂的背书策略，因为它封装了所有的信任模型。

2.3 Dynamic Scaling（动态扩展）

扩展方法主要用于动态地向上或向下扩展网络，以管理负载到达率，并通过避免过载来降低运行成本。因此，我们通过向现有组织中添加更多的vcpu和对等节点来度量扩展网络所花费的时间。

Dynamic scaling by adding more vCPUs.（动态拓展添加更多的CPU）为了研究动态vCPU扩展对性能的影响，我们通过生成超过4个vCPU处理能力的负载来超载网络中的对等节点。然后我们将vcpu的数量增加到16个，每次一个peer，当块队列的长度达到200个之后。图6(a)绘制了组织中每个对等点将阻塞队列长度从200减少到0所花费的时间。尽管对等节点立即扩展，但将队列长度减少到0大约需要50秒到70秒。图6(b)绘制了分类帐块高度随时间的变化，而vcpu的数量从4个增加到8个。块高度只是最近提交的块号。正如预期的那样，分类帐交接率增加了。尽管队列大小在70秒内变为0，并且分类账提交率增加了，但由于违反了序列化性，失败事务的数量受到了重大影响(如图8所示)。当更多的块在队列中等待更新分类帐状态时，使用非常陈旧的数据支持新的事务。结果，每个块中的许多事务后来被序列化验证器失效，原因是读集中出现的状态版本与提交的分类账状态不匹配。在扩展了对等点之后，花费了180秒将失败的事务数量减少到2个以下。

图6: Impact of dynamic scaling by vCPUs & peers (vcpu和对等点动态伸缩的影响) 

Figure 8: Failed transactions due to an overloaded situation.（由于超载而导致的失败事务）

Dynamic scaling by adding more peers.（通过添加更多的对等节点来动态扩展）为了研究在现有组织中添加一个新peer所花费的时间，我们在每个组织中运行一个peer，然后在第2分钟、第5分钟和第10分钟添加一个新的同伴。图6(c)绘制了新对等点与现有对等点同步所需的时间，以便它们能够处理背书请求和新块。我们观察到，所花费的时间与现有对等点的块高度成正比，因为新的对等点必须获取所有旧块、验证并逐个提交它们。由于在同步过程中，新对等点上没有背书请求，因此通过提交3000 tps的事务(而使用背书时，只有1790 tps)，可以赶上现有的对等点。然而，当现有对等块的高度过高时，可能会花费数小时。

Takeaway 6.(结论) vCPU的动态伸缩是有效的，因为它可以快速响应增加的负载。但是，这种方法受到服务器中可用vcpu数量的限制。通过对等点的动态扩展，新的对等点需要花费大量时间与现有的对等点同步，以便能够处理负载。这是因为新的对等点验证并提交了所有的块，即冗余工作。因此，我们需要一种更好的方法来扩展网络。

2.4 Problem Statement.（问题称述）

重新构建Hyperledger结构以(1)提高每个节点的CPU利用率，(2)减少组织内的冗余工作，从而在不使用通道和简单背书策略的情况下提高网络的总吞吐量。由于负载可能会随着时间的推移而变化，因此构建一个有助于快速扩大或缩小网络以降低运营成本的框架。

3. DESIGN OF A SCALABLE FABRIC （可伸缩fabric 的设计）

首先，在§3.1中，我们介绍了一个新的块处理架构，它允许验证和提交阶段的流水线执行，以及属于不同块的事务的并行验证，从而在不违反序列化隔离的情况下提高CPU利用率和吞吐量。接下来，在§3.2中，我们介绍了可以避免组织内冗余工作的稀疏对等点。

3.1 Pipelined Execution of Phases（阶段流水线执行）

正如在§2.2的takeaway 1中提到的，我们提出了一种新的架构(参见图9)，它允许以流水线方式执行验证和提交阶段，同时仍然确保正确性，即串行性隔离。此外，它使序列化验证器能够并行地(甚至跨块)验证事务，而不是普通结构中的串行验证。该架构的两个关键思想是:(1)利用每个事务块中的读写集和范围查询信息。利用这两个信息，我们可以构造一个依赖图，可以并行地验证事务，而不违反序列化隔离;(2)在内存中维护一个脏状态，以保持有效事务的未提交到状态数据库的写操作。这种脏状态有助于避免在管道化两个阶段的执行时读取陈旧状态。接下来，我们描述每个阶段所涉及的步骤。

Figure 9: Proposed design to enable pipelined execution of validation and commit phases.（支持验证和提交阶段的流水线执行的建议设计）

3.1.1 Validation Phase(验证步骤)

建议的验证阶段由三个组件组成:(1)事务依赖提取器，(2)验证器，和(3)结果映射管理器，如图9所示。步骤①,提取器从队列中读取一个块并更新依赖图。在步骤②,每个免费验证器工人执行以下三个操作:首先,从图中检索一个事务,没有out-edges &验证;其次，如果验证通过，它将写集应用到脏状态;第三，它更新依赖关系图。在步骤③中,它添加了验证结果结果地图之前步骤②。接下来，我们将详细描述这些步骤。

(1) Transaction dependency extractor.（事务依赖器）

依赖提取器将每个块以事务的形式添加到等待事务依赖图中。此图中每个事务包含一个节点，标识符形式为{块号，块内的事务号}。我们可以互换使用节点和事务。让我们假设Ti和Tj是两个事务，并且Ti出现在Tj之前的一个块中(其中Tj可以在同一个块中，也可以在下一个块中)。从Tj到Ti的一条边表示必须在验证Tj之前对事务Ti进行验证。以下是可以创建从Tj到Ti的边缘的六种依赖类型:

1. 读写(rw)依赖:Ti写入某个状态的一个版本，Tj读取该状态的前一个版本;

2. 读写(wr)依赖:Tj写入某个状态的一个版本，Ti读取该状态的前一个版本;

3.写(ww)依赖:Ti和Tj都写相同的状态;

4.虚读(pr)依赖:Tj执行一个范围查询，Ti写入一个新的状态，该状态将匹配Tj执行的范围查询;

5.背书-策略-读写(ep-rw)依赖关系:Ti更新智能合同的背书策略，Tj使用先前版本的背书策略调用该智能合同;

6.背书-策略-写入-读取(ep-wr)依赖关系:Tj更新智能合同的背书策略，Ti使用先前版本的背书策略调用该智能合同;

图中不可能有循环，因为一条边总是从一个新事务到一个旧事务。表2展示了我们所提议的等待交易依赖图与与许可的区块链平台相关的先前技术[19,32,34]中使用的依赖图之间的差异。很明显，由于目标的不同，我们提出的图是新颖的。

Fate dependencies.(命运依赖关系) 虽然所有6个依赖项都用于决定事务的并行验证和串行验证，但只有rw-依赖项、pr-依赖项和ep- rw-依赖项也决定依赖事务的验证结果——称为命运依赖项。当Tj与Ti之间存在命运依赖关系且Ti有效时，Tj将被标记为无效，以确保可串行性。对于任何其他依赖关系，Tj都可以被验证，而不考虑Ti的验证结果。依赖提取器记录图中每两个事务之间的所有依赖关系。

Detecting phantom dependency.（检测幻影依赖）

除了pr依赖关系外，所有其他依赖关系都很容易通过读写集来识别。为了识别pr依赖关系，我们维护了一个trie数据结构，该结构包含了图中所有等待事务的写集中的状态。在向图中添加事务之前，我们在trie数据结构上运行范围查询，该范围查询出现在事务的范围查询信息中。如果查询发现任何匹配状态，那么新事务对在其写集中保存匹配状态的事务具有pr依赖关系。

提取器公开以下两个操作，以使其他组件能够访问依赖关系图。(1) GetNextTransaction() ti -从图中找到一个没有外缘的事务列表;从列表中，返回一个以最少的{块号，事务号}作为标识符的事务Ti。换句话说，它返回图中最老的不依赖于其他事务的事务(但是其他事务可以依赖于它)。如果isValid为真，也就是说，Ti是有效的，那么它将删除所有由于命运依赖关系而比Ti有优势的事务，并将它们作为无效添加到结果映射中。

(2) Validator. 背书策略验证器和序列化验证器的逻辑保持不变，除了以下两个修改:(1)两个验证器都使用脏状态和状态DB(避免读取状态数据);（2) serializability验证器使用多个worker来并行验证事务，而不是单个worker。

每个自由工作者调用GetNextTransaction()来获得要处理的下一个事务。首先，背书策略验证器检查策略是否被满足。成功时，同一worker执行可串行性检查。如果事务通过了两个验证，则worker将写集应用到dirty状态，并调用UpdateDependencyGraphAndValidationResults()来更新依赖关系图。最后，worker将验证结果添加到结果映射中。为了确保验证器没有读取过时状态，读取请求(例如对智能契约策略或状态版本的读取)首先会进入脏状态。只有在未命中时，读请求才会到达状态数据库。为了存储脏状态，我们使用了一个trie数据结构，其中leaf为{键-值对(即状态)，version}。这种trie结构允许序列化验证器验证范围查询信息中存在的幻影读取的范围查询。每个范围查询都在trie和状态DB上执行，以检测幻像读取。

(3) Result map manager.（结果地图管理器）它管理{块号，事务号}到验证结果的映射。(1) AddValidationResult(块号、事务号、isValid)将事务的验证结果添加到map中;GetAndDeleteValidationResult(块号、事务号)在删除给定事务后返回与该事务相关联的验证结果。提取器和验证器都调用(1)，而只有提交器调用(2)。

3.1.2 Commit Phase （提交阶段）

与验证阶段相比，提交阶段的逻辑没有显著变化。如图9所示，在第一步中❶，只要提交者空闲，它就会从队列中读取一个块并检索事务列表。❷步,提交者获取验证结果通过调用GetAndDeleteValidationResult()为每笔交易。如果验证结果对事务不可用，则调用将被阻塞，直到结果可用为止。一旦所有事务的提交者收集验证结果,在❸步,它存储块的块存储和应用有效的写集合状态&历史DB香草织物。❹步,它调用验证管理器删除脏状态与刚刚承诺相关批号的验证器可以阅读这些州国家数据库本身。

3.2 Sparse Peer to Avoid Redundant Work（稀疏peer，避免冗余工作）

从§2.2中的结论2中，我们知道一个组织中的多个同行做冗余的工作，这限制了水平扩展的效率。为了避免冗余，在图10中，我们提出了一种新的对等点类型，称为稀疏对等点。与普通结构中的完整对等点相比，稀疏对等点可能无法验证和提交块中的所有事务。稀疏对等点的概念是受到分布式数据库中的分片概念的启发。首先，在§3.2.1中，我们给出了一个稀疏对等点的设计。第二，在§3.2.2中，我们提出了一种以分布式方式执行模拟阶段的方法，因为稀疏对等点并不持有区块链的所有状态。最后，在§3.2.3中，我们提出了分布式验证和事务提交，这是分布式模拟的结果。

Figure 10: Difference between a full peer and a sparse peer.(完全对等点和稀疏对等点之间的区别)

3.2.1 Sparseness in Validation and Commit (验证和提交的稀疏性)

稀疏对等点背后的关键思想是，它可以有选择地验证和提交事务。如果组织中的所有稀疏对等点都选择一组不重叠的事务，我们就可以避免冗余的工作。为了实现这一点，首先，我们定义了确定性选择逻辑，以便每个稀疏对等点选择一组不同的事务。其次，我们更改验证器和提交器，以便在接收的块上应用选择逻辑。第三，作为一个可选的特性，我们让对等点将选择逻辑传递给orderer，这样orderer本身就可以应用筛选器，并且只发送稀疏块中需要的事务。因此，网络带宽利用率和磁盘IO都会降低。图11显示了稀疏对等点的两个变体。

(1) Transaction selection filter(事务选择过滤器)

每个稀疏对等点都拥有一个过滤器，并将其应用于接收到的块，以确定需要考虑哪些事务。过滤器只是一份智能合同列表。对于每个对等进程，管理员通过gRPC向对等进程发出请求，从而分配/更新筛选器。稀疏对等点只在调用筛选器中指定的智能契约的块中验证和提交事务。当一个事务调用多个智能契约时，即使过滤器只包含其中一个智能契约，该事务也会被稀疏对等方考虑。在过滤器中选择智能合同的原因是，大多数应用程序，如TradeLens [14]， WeTrade [17]， Food Trust[7]，都是使用多个智能合同构建的，每个智能合同执行一个类似于微服务的特定任务。这样的体系结构使每个开发团队能够独立地构建和管理智能契约。此外，该应用程序使用一个智能契约调用另一个智能契约的特性，当一个交易需要接触多个智能契约时(在提交的交易总数中占较低的百分比)。

(2) Validation and commit based on a filter（基于筛选器的验证和提交）.

当事务依赖提取器从队列中读取一个块时，它只将事务(调用过滤器中存在的smartcontract)添加到等待事务依赖图中。当提交器读取块时，它将没有调用过滤器中出现的任何智能契约的事务标记为未经过验证，而是将整个块存储在块存储中。验证器和提交器逻辑的其余部分保持不变。存储整个块的好处是，当过滤器更新时，稀疏对等点可以从本地块存储本身获取与新添加的智能契约相关的所有事务。然后，它只需要从其他对等块存储中获取验证结果，以避免重新验证。然而，缺点是它不会减少网络带宽的利用和磁盘IO。接下来，作为可选特性，我们允许稀疏对等点将它们的过滤器直接传递给订货程序。

(3) Block dissemination based on filters(基于过滤器的闭塞传播).

如果订购者自己应用过滤器，并且仅通过稀疏块向每个稀疏对等点发送适当的事务，我们可以节省网络带宽的利用和磁盘IO。因此，每个稀疏对等点将它的过滤器发送到它所连接的orderer。对于每个块，orderer应用筛选器并仅将所需的事务发送给对等方。但是，这给散列链及其验证带来了一个问题。在vanilla Fabric中，在创建块时，订货程序计算块散列并将其存储在块中。块哈希是使用该块中所有事务的字节和前一个块中的哈希计算的。当一个对等点接收到一个块时，它可以通过验证哈希链来检查它的完整性。此外，这个哈希链是区块链网络的真值来源。如果我们让orderer只发送块中的一个子事务集，那么对等方将无法验证和维护散列链的完整性。

Sparse block(解析block).为了解决这个问题，我们提出了一个稀疏块，它包括(1)一个Merkle树来表示块散列(如图12所示);(2)只对应用过滤器后的事务进行子集处理;(3)应用过滤器;(4)所有事务的事务标识符(t - id)。在我们的基于筏的共识服务中，领导节点构建merkle树，而其他节点在发送块给它连接的对等节点之前应用过滤器。当一个稀疏对等点接收到一个稀疏块时，它只能通过使用一个子事务集来验证哈希链的完整性。由于Merkle树哈希的验证，与单一哈希验证相比，这种方法将提高CPU利用率，但减少网络和磁盘IO。事务标识符列表与稀疏块一起发送，以使验证器能够检查重复项并适当地将它们标记为无效。在香草结构中，订货者不会窥视事务。然而，我们打破了这个规则，因为订货者需要找到与每个智能契约关联的交易，也需要找到调用多个智能契约的交易。由于订货者已经可以访问整个交易，即使是在一个普通的结构中，有动机的一方总是可以进入交易高峰。因此，我们的方法不会削弱信任模型。此外，稀疏块是一种优化，而不是必需的。

3.2.2 Distributed Simulation(分布式仿真)

在vanilla Fabric中，当指定供应商的智能合同调用另一个指定承运人的合同时，供应商合同向对等进程发送一条消息来调用承运人合同。对等进程将请求转发给承运商合同，并将其结果返回给供应商合同。请注意，由运营商合同读取/写入的状态也被添加到交易的读写集中。两个智能合同存在于同一对等点上没有根本原因。因此，在使用稀疏对等点时，我们允许将这些智能契约放置在不同的对等点上，并启用分布式模拟来允许托管在稀疏对等点P1上的供应商契约调用托管在P2上的运营商契约。我们通过让P1向调用运营商合同的P2发送一条消息来实现这一点。响应，包括承运人合同读取/写入的状态，被转发回P1。过滤器DB，如图11所示，持有每个稀疏对等点的过滤器，用于决定为给定的智能契约联系哪个对等点。由于分布式模拟是在网络上进行的，而背书人在整个状态DB[35]上持有一个读锁，因此如果存在大量的分布式模拟，提交操作就会被延迟。因此，我们采用Meir等[30]提出的技术来消除状态DB上的读写锁。

应用过滤器后对常规块进行稀疏对等处理                       稀疏对等处理稀疏块

Figure 11: Two variants of sparse peer.(稀疏对等点的两个变体)

3.2.3 Distriubted Validation and Commit(分布式验证和提交)

由于采用分布式模拟，现在我们需要分布式验证和提交。考虑一个调用智能契约S1、S2、…的交易。Sn。考虑稀疏对等点P1、P2……，在Pn中，每个peer Pi都有一个智能合同Si的滤波Fi。当事务满足每个契约调用的策略和序列化检查时，调用所有n个智能契约的事务被认为是有效的。因此，要提交这个事务，我们需要在验证阶段从所有n个稀疏对等点获得一个协议。

Strawman protocol（稻草人的协议）.每个对等π的验证部分事务,包括智能合同如果 Fi,然后结果广播到其他同行。一旦一个同行收到有效的结果，所有智能合同S1…Sk时，它可以认为事务是有效的并提交它。如果接收到无效的结果，对等方不需要等待更多的结果，可以通过使事务无效继续进行。由于组织中的对等点是可信的，因此不存在安全问题。虽然这种方法很简单，但有一个显著的缺点。由于由于不同的块提交率，对等点可能处于不同的块高度(这是异构硬件或异构工作负载的结果)，因此需要分布式提交的事务可能会在相当长的时间内阻塞块中的其他事务。因此，提交者可能在GetAndDeleteValidationResult()调用时被阻塞。

An improved protocol using priorities(使用优先级的改进协议).为了减少提交者的阻塞时间，我们通过增强§3.1中引入的waitingtransactions依赖图来对分布式事务的验证进行优先级排序，图中的每个节点都有两个标志——committerblocked和priority。当committer调用GetAndDeleteValidationResult()被阻塞时，会标记committerBlocked标志。优先级标志在事务需要分布式验证时被标记。此外，我们将增强§3.1中描述的GetNextTransaction()的逻辑，如下所述。GetNextTransaction()首先按顺序执行以下三个步骤，直到找到一个节点列表为止(一旦找到了一个列表，其余的步骤就不执行了):(1)找到一个节点列表，其中每个节点都标记为committerBlocked，并且没有外边界;如果非空，返回列表。(2)查找每个节点标有优先级且没有外边的节点列表;如果非空，返回列表。(3)查找无外边节点列表;如果非空，返回列表。从节点列表中，GetNextTransaction()返回与具有最少{块号，事务号}作为标识符的节点关联的事务Ti。

Deferred Transactions(递延交易).即使使用改进的协议，提交者也可能由于网络延迟而被阻塞。因此，我们引入了延迟事务，在这种事务中，提交者可以继续提交所有本地事务(例如，部分块提交)，而不用等待分布式事务，而是在提交期间将它们标记为延迟的事务(因为这是对等失败后恢复所需要的)。只要结果可用，就提交延迟的事务并从图中删除。注意，任何依赖于延迟事务的本地事务都必须被延迟，即使它位于不同的块中。

4. AN AUTO-SCALING FRAMEWORK（一个伸缩框架）

从§2.2中的takeaway 6中，我们知道通过添加更多的对等节点来动态扩展一个Fabric网络需要大量的时间。因此，在本节中，我们提出了一种利用稀疏对等点快速扩展网络的方法，即将一个完整对等点分解为多个稀疏对等点，或将一个稀疏对等点分解为多个稀疏对等点。此外，我们提出了一种方法，通过将多个稀疏对等点合并成一个更小的稀疏对等点集或一个完整对等点(如§4.2所述)来缩小网络规模。

4.1 Splitting a full peer into sparse peers（将一个完全对等点分解为稀疏对等点）

为了将一个完整对等点分割成多个稀疏对等点，我们让完整对等点使用过滤器。一个完全对等包含所有部署的智能合同(用集合S表示)在它的过滤器，而不是智能合同的一个子集。分离完整对等点的过程包括三个步骤:(1)添加一个新的稀疏对等点，其过滤器包含智能契约SA的子集;(2)将集合SA中的智能契约区块链状态从完整对等点复制到新的稀疏对等点;(3)将集合SA中的smartcontract从全对等点的过滤器中移除，使其成为稀疏对等点。虽然步骤1和3是琐碎的，但步骤2是复杂的。图13显示了这样的分割示例。

Figure 13: A full peer is splitting into 3 sparse peers（一个完全对等点被分成3个稀疏对等点）.

Copy of a smart-contract’s states（智能合同条款的副本）.对于新添加的稀疏对等点，我们需要从完整对等点的块存储、状态数据库和历史数据库中复制数据，这些数据与集SA中的智能契约相关联。每个智能合同的状态都以一个智能合同的名称作为前缀。因此，识别与给定的智能合同相关的状态数据是很简单的。我们可以通过两种方法复制状态:(1)将块和验证结果一起从块存储中复制到新的稀疏对等节点，以构建所有三个存储;(2)直接从状态数据库中复制所需状态。由于前者在网络和磁盘IO方面的成本更高，所以我们采用后者。一旦状态数据库与最后提交的块一起被复制，我们就可以开始在新的稀疏对等点上允许背书和常规块提交。最后提交的块是必需的，这样当接收到新的块时，新的对等点可以验证散列链。除此之外，我们还需要从块存储中维护的索引DB中复制所有事务的标识符。验证管理器使用这些事务的标识符来检测重复的标识符。

Interference from on-going block commits（正在进行的块提交的干扰）.要复制状态数据库数据，首先，新添加的稀疏对等点使用八卦组件来识别完整对等点中最后提交的块号。其次，它要求完整对等端发送给定块号的所有活动状态。第三，它接收数据并构建状态数据库。在完全对等点上，发送给定块号的所有活动状态并不简单，因为完全对等点继续提交块并更改活动状态，这会干扰状态传输。例如，在图14中，新的稀疏对等点正在请求第3块与smart-contract S1相关联的所有状态。换句话说，它要求从区块号3开始的键K1到K5的活动值。但是，现有的对等点继续提交块并更改活动状态。在第5块，键K1甚至不存在于状态DB中。

Figure 14: A sparse peer issues a copy request to a full peer.（稀疏对等点向完整对等点发出复制请求）

Interference Mitigation（干扰抑制）

为了解决上述问题，我们执行了以下三个步骤:

1.完整对等方在历史数据库中添加表单{smart-contract，块号，事务号}7→为每个块提交添加一个{key, isDelete, isDeferred}的列表。isDelete和isDeferred分别用于表示已删除键和递延事务。

2.当完整对等方收到一个区块号副本请求时，它对新添加的索引执行范围查询，开始键为{smart-contract, 0}，结束键为{smart-contract，请求的区块号}，以查找所有需要的键。然后，完整对等点可以从状态数据库中读取值和版本。然而，状态数据库的副本可能由于新块的提交而处于请求块范围之外的版本，或者可能由于删除操作而不存在。在这种情况下，完整对等点将从块存储中获取相应的值和版本。

3.一旦新添加的稀疏对等点复制了所有需要的数据，包括与延迟事务相关联的数据，完整对等点更新它的过滤器成为一个稀疏对等点。新添加的稀疏对等点开始从订货程序接收块(包括在数据复制阶段在网络中提交的块)，并继续进行常规的块验证和提交。

因此，一个完全对等点分裂成两个稀疏对等点。将一个对等点分割成两个或多个稀疏对等点的方法是相同的。

Parallel copy of a smart-contract’s states（智能合同状态数据的平行拷贝）.当一个组织中有两个完全对等点或一个稀疏对等点的两个副本以负载平衡背书请求时，我们将所需的数据并行地复制到一个新的稀疏对等点。下面的步骤描述了流程:

1.一旦新的稀疏对等点获得其他对等点最后提交的块数，它就创建多个不重叠块范围的请求，并在考虑其最后块数的同时将每个请求发送给不同的对等点。

2.当一个对等方收到一个复制请求，该请求包含{开始块号，结束块号}表示的块范围，,它执行一个范围查询新添加的指数历史数据库的启动键,{smartcontract,开始块编号}和结束键{smartcontract,最后块编号}找到所有需要的钥匙。然后对等方可以从状态数据库中读取值和版本。它可能发生的情况是，状态数据库的副本可能在一个版本，落在请求的块范围之外。在这种情况下，完整对等点用表示相同的标记值标记键。我们称这个入口为洞。

3.如果新的稀疏对等点在响应中接收到一个漏洞，它将等待发送到其他对等点的其他请求的响应，因为它们可能会自动填补这个漏洞。

4.一旦所有的回复都收到了，可能还会有一些漏洞。然后，新的对等点请求最后提交的块号的键值。另一个对等点从块存储中存在的事务的写集中检索值。

为了使新的对等点能够从其他没有完整块存储的新添加的对等点获取状态，我们总是复制完整的历史数据库。因此，每个对等点都可以用来将状态复制到新的对等点。

4.2 Merging sparse peers into a full peer（将稀疏节点合并为完整节点）

为了缩小网络规模，我们需要将多个稀疏对等点合并为几个稀疏对等点或合并为一个完整的对等点。就更改过滤器和复制数据而言，合并操作的逻辑几乎与将一个完整的对等点拆分为多个稀疏对等点相同。在拆分操作中，我们从现有节点的过滤器中删除smartcontract，而在合并操作中，我们添加smart-contract来过滤一些现有的节点，同时清空其他节点的过滤器。保留数据量最大的对等点，删除数据量最少的对等点。

4.3 Validation result sharing with replicas（与副本共享验证结果）

为了负载平衡背书请求并提供高可用性，需要运行一个空闲对等点的多个副本。如果所有的副本都做同样的工作，我们将最终浪费资源。因此，我们允许稀疏对等点的副本在它们之间共享验证结果。在一个副本集中，选择一个稀疏对等点作为leader，负责验证事务并与其他副本共享结果。所有追随者都等待从领导者那里收到验证结果以提交事务。与追随者相比，领导同伴被分配更多的资源。在未来的工作中，我们的目标是设计一个协议，使副本能够协作验证块。

5. IMPLEMENTATION(实现)

总体实现向Fabric v1.4添加了15k行golang代码，不包括测试和生成的代码。依赖关系图是使用两个队列实现的:一个用于分布式事务，另一个用于普通事务。队列中的每个条目都指向阻塞它的事务。这些指针用于跟踪依赖关系。脏状态组件是使用trie实现的，以便处理范围查询的验证。稀疏对等点本身的实现很简单，因为它主要涉及让代码忽略对等点过滤器之外的事务。为了通过管理员动态地修改对等点的过滤器，我们实现了一个系统智能契约，它提供了一个接口来修改对等点的过滤器。

 

6. EVALUATION OF PROPOSED DESIGN（评估建议设计）

在本节中，我们将根据vanilla Hyperledger fabric来评估我们所提议的设计的性能。该研究使用的设置与图3中所示相同。对于所有的实验，对等点被分配16个vcpu，并且在网络中只创建了一个通道。除非另有说明，我们每个组织使用一个对等点，8个智能合同每个承载小银行的工作负载。

Pipelined Execution of Validation and Commit Phases（验证和提交阶段的流水线执行）.图15(a)根据vanilla Fabric绘制流水线执行所实现的吞吐量。正如预期的那样，吞吐量增加了1.36倍，同时CPU利用率从50%增加到70%。验证管理器非常有效，提交器不会被阻塞。结果地图的大小总是大于500。这是因为提交者所花费的时间(在每秒2500个背书请求时≈31 ms)总是高于验证者所花费的时间。此外，一个区块的端到端提交延迟(验证+提交)从50ms (1800 eps时)减少到38ms (2500 eps时)。

Figure 15: Performance comparison of (a) pipelined execution of validation and commit phases, (b) sparse peer (SP) with full blocks (FB) and sparse blocks (SB), (c) combination of (a) and (b) against vanilla full peer (FP).((a)验证和提交阶段的流水线执行，(b)带有完整块(FB)和稀疏块(SB)的稀疏对等点(SP)， (c) (a)和(b)的组合与普通的完全对等点(FP)的性能比较)

Sparse Peer with Full and Sparse Blocks（具有完整和稀疏块的稀疏对等）.我们评估了§3.2中提出的两种稀疏对等算法的性能。每个组织托管了4个稀疏对等点，其中每个稀疏对等点的过滤器只包含2个非重叠智能合同。图15(b)在每个组织承载4个普通对等点的网络上绘制了两种稀疏对等点实现的吞吐量。如预期的那样，使用稀疏对等时吞吐量显著增加了2.4倍。与此同时，由于避免了冗余的CPU密集型任务，每个节点的CPU利用率与普通的完全对等节点相比降低了。这意味着我们可以使用更小的服务器来实现更大的吞吐量。与稀疏对等处理全块相比，稀疏对等处理的稀疏块由于减少了IO操作而实现了更高的吞吐量。

Sparse Peer with Pipelined Execution(使用流水线执行的稀疏对等). 图15(c)绘制了稀疏对等执行和流水线执行结合在普通Fabric上所实现的吞吐量。吞吐量显著增加至6400 tps，即增加3.16倍。此外，由于验证和提交阶段的流水线执行，CPU利用率也增加了。

Distributed Simulation and Validation（分布式仿真与验证）.

当事务调用多个智能契约时，稀疏对等使用分布式模拟和验证。研究我们所建议的系统的性能分布式事务，我们提交调用多个smallbank契约的事务。图16绘制了普通结构、带管道的稀疏对等点和延迟事务的吞吐量，以及带管道的稀疏对等点、延迟事务和优先级的吞吐量。当60%的事务调用多个契约时，与只有20%的事务调用多个契约的运行相比，不管采用了何种优化，所实现的性能都要低。这是因为，当60%的事务调用多个契约时，每个对等点上要完成的工作量增加了。此外，与香草织物相比，我们提出的技术显著提高了织物的性能。使用基于优先级的方法，当20%的事务调用多个契约时，延迟的事务数量从105减少到78。

Scale Up（按比例放大）.我们评估一下§4中讨论的动态缩放方法。图17(a)绘制了通过复制单个其他对等点以及两个其他对等点的状态来添加新对等点所需的时间。为了与vanilla进行公平的比较，我们添加了一个带有所有智能合约的新的稀疏对等点(等于一个完全对等点)，并在现有的对等点上产生相同的负载。与添加香草peer花费的时间相比，在不同的分钟，我们的方法提供了多倍的减少。这是因为，与普通方法相比，我们的方法复制的数据要少得多。一般情况下，块存储的大小比状态DB的大小大60倍。由于我们直接从状态数据库中复制所需的状态，添加新对等点所需的时间显著减少。此外，当新的对等点并行地从两个对等点提取状态时，所花费的时间减少了一半(图17(a)中的时间以对数尺度表示)。图17(b)绘制了状态转移对现有对等点性能的影响。每当添加一个新的对等点时，现有的对等点就会由于额外的磁盘IO争用和状态DB同步而观察到吞吐量下降。当新的对等点从多个源提取数据时，性能下降显著降低。这表明我们的方法可以帮助扩展织物网络。

Scale Down（）.当对等点未被充分利用时，就有必要缩小规模以降低操作成本。在普通的Fabric网络中，缩小操作规模非常容易，因为我们只需要停止组织中的一些同行。但是，对于稀疏对等点，我们需要通过将一个稀疏对等点的状态复制到另一个稀疏对等点来合并对等点。为了测量合并多个稀疏对等点所花费的时间，我们运行了一个实验，每个组织托管四个稀疏对等点。每个稀疏对等点在其过滤器中有两个智能契约，并且它们不与组织内的其他稀疏对等点重叠。在运行了1800 tps的网络一段时间后，我们将所有稀疏对等点合并成一个完整对等点。在2分钟、5分钟和10分钟后，合并这些稀疏对等点所花费的时间分别为4.29秒、10.17秒、24.59秒。虽然稀疏对等点有助于快速扩展网络，但与普通结构相比，它增加了缩小网络所需的时间。

7. RELATED WORK（相关工作）

在本节中，我们将介绍改进Hyperledger织物性能的现有工作。他们中没有人研究过使用不同比例技术的性能。Thakkar等[35]进行了一项全面的性能研究，发现了Fabric v1.0的瓶颈，并为设计应用程序和运营网络以获得更高吞吐量提供了指导。此外，他们还对对等进程实现了一些优化。这些优化已经包含在Fabric v1.4中，因此我们的工作就是在此基础上进行的。

为了扩展区块链网络，Dang等人在共识层应用了分片。当我们优化块验证和提交阶段时，我们的工作与他们的工作是正交的。此外，我们发现对等点的性能是Fabric中的瓶颈，而不是订购服务。

Sharma等人研究了区块链系统与传统数据库的根本异同。然后他们使用了数据库文献中的思想，即在排序阶段的事务重新排序和在模拟阶段的早期事务中止。他们使用这些技术来降低由于序列化冲突而导致的事务失败率。这些技术与我们的工作是正交的，因为我们关注的是不同阶段的流水线执行，以避免冗余工作。

Istvan等人[27]提出将块处理范式转换为流处理范式，只使用块作为分摊磁盘访问成本的手段。这有助于减少延迟。这项工作与我们的部分正交，因为稀疏和流水线执行的好处可以转移到他们的设计中。Gorenflo等人[26]提出了各种优化方案，比如用哈希表替换状态数据库，将数据块存储在单独的服务器上，将提交者和endorser分离到不同的服务器上，并行验证事务头，缓存未标记的数据块以达到20000 tps的吞吐量。然而，我们相信这些优化中的许多对于生产环境是不实际的。例如，状态DB必须支持范围查询和持久化所有活动状态(这将有助于在故障后快速恢复对等点)。在他们的测量中，没有不适合生产设置的磁盘IO。建议的方法假设事务没有读写冲突。此外，他们的工作与我们的是正交的，因为(1)他们不以流水线的方式执行验证和提交阶段;(2)在可串行性检查过程中没有并行验证事务;(3)他们没有同类中稀疏性的概念;并且(4)他们没有提供一个框架来快速扩展一个织物网络。注意，我们采用了§2.2中提到的块缓存。

Meir等[30]在仿真阶段提出删除状态DB上的读写锁，转而使用乐观并发技术。我们采用这种技术来提高§3.2.2中所述的分布式仿真所实现的性能。

Goel等人[25]认为默认的先进先出的交易顺序是不公平和低效的。他们提出了一种加权公平排队策略，可以对不同的交易提供不同的服务质量。此外，他们以一种分散的方式实现了这一点。我们的工作与此工作是正交的，因为我们关注的是Fabric网络的可伸缩性。

8. CONCLUSION（结论）

在本文中，我们利用不同的缩放技术研究了超分类器的性能，并发现了两个主要的瓶颈:(1)代码在关键路径上的串行执行;(2) CPU和IO密集任务的重复。因此，我们重新设计了Fabric以消除这两个瓶颈。为此，我们引入了重要阶段的流水线执行和称为稀疏对等点的新对等点类型。整体织物吞吐量提高3倍。Fabric在超载时显示增加的失败事务率。由于现有的方法在扩展网络上花费了大量的时间，所以我们使用了sparse peer并提供了一个自动扩展框架，可以非常快速地扩展网络。

此外，这里描述的所有技术对应用程序代码都是透明的。因此，每个现有的应用程序都可以很容易地从提出的技术中获益。更重要的是，主要的云供应商，如亚马逊AWS、微软Azure、IBM cloud、甲骨文cloud和阿里巴巴cloud都提供支持超账本结构的区块链作为服务(BaaS)。这些BaaS平台可以采用“稀疏对等点”的思想以及自动伸缩框架来提供真正的弹性和完全管理的区块链平台，就像它们的其他弹性云服务一样。

9. REFERENCES（参考文献）

[1] Alipay press release. https://www.alibabagroup.com/en/news/press_pdf/p180201.pdf.

[2] Chain-m for airline industry. https://www.niit-tech.com/news-events/news/niittechnologies-introduces-chain-m-blockchain-poweredsolution-airlines-and-its.

[3] Clsnet for bilateral payment netting. https://www.clsgroup.com/products/processing/clsnet/.

[4] Electrum decentralized marketplace. https://electrumdark.co/.

[5] Everledger for mining industry. https://www.everledger.io/.

[6] grpc. https://grpc.io/.

[7] Ibm food trust for food industry. https://www.ibm.com/inen/blockchain/solutions/food-trust.

[8] The linux foundation. https://www.linuxfoundation.org/.

[9] Open bazaar decentralized marketplace. https://openbazaar.org/.

[10] openidl for insurance industry. https://aaisonline.com/openidl.

[11] Origami network decentralized marketplace. https://ori.network/.

[12] particl decentralized marketplace. https://particl.io/.

[13] Securekey verified.me. https://securekey.com/.

[14] Tradelens for global trade. https://www.tradelens.com/.

[15] Understanding digital tokens: Market overviews and proposed guidelines for policymakers and practitioners by token alliance, chamber of digital commerce. https://morningconsult.com/wpcontent/uploads/2018/07/token-alliance-whitepaperweb-final.pdf.

[16] Visa annual report. https://s1.q4cdn.com/050606653/files/doc _financials/annual/2018/visa-2018-annual-reportfinal.pdf. [17] Wetrade for trade finance. https://we-trade.com/.

[18] M. Alomari, M. Cahill, A. Fekete, and U. Rohm. The cost of serializability on platforms that use snapshot isolation. In 2008 IEEE 24th International Conference on Data Engineering, pages 576–585, April 2008.

[19] M. J. Amiri, D. Agrawal, and A. E. Abbadi. Parblockchain: Leveraging rransaction parallelism in permissioned blockchain systems. 2019.

[20] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukolić, S. W. Cocco, and J. Yellick. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, EuroSys ’18, pages 30:1–30:15, New York, NY, USA, 2018. ACM.

[21] V. Buterin. Ethereum: A next-generation smart contract and decentralized application platform, 2014. Accessed: July 31, 2019.

[22] Y. Chen. Blockchain tokens and the potential democratization of entrepreneurship and innovation. Business Horizons, 61(4):567 – 575, 2018.

[23] H. Dang, T. T. A. Dinh, D. Loghin, E.-C. Chang, Q. Lin, and B. C. Ooi. Towards scaling blockchain systems via sharding. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD ’19, pages 123–140, New York, NY, USA, 2019. ACM.

[24] T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi,and K.-L. Tan. Blockbench: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD ’17, pages 1085–1100, New York, NY, USA, 2017. ACM.

25] S. Goel, A. Singh, R. Garg, M. Verma, and P. Jayachandran. Resource fairness and prioritization of transactions in permissioned blockchain systems (industry track). In Proceedings of the 19th International Middleware Conference Industry, Middleware ’18, pages 46–53, New York, NY, USA, 2018. ACM.

[26] C. Gorenflo, S. Lee, L. Golab, and S. Keshav. Fastfabric: Scaling hyperledger fabric to 20,000 transactions per second. In 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 455–463, May 2019.

[27] Z. István, A. Sorniotti, and M. Vukolić. Streamchain: Do blockchains need blocks? In Proceedings of the 2Nd Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers, SERIAL’18, pages 1–6, New York, NY, USA, 2018. ACM.

[28] H. T. Kung and J. T. Robinson. On optimistic methods for concurrency control. ACM Trans. Database Syst., 6(2):213–226, June 1981.

[29] Y. Manevich, A. Barger, and Y. Tock. Endorsement in hyperledger fabric via service discovery. IBM Journal of Research and Development, 63(2/3):2:1–2:9, March 2019.

[30] H. Meir, A. Barger, and Y. Manevich. Increasing concurrency in hyperledger fabric. In Proceedings of the 12th ACM International Conference on Systems and Storage, SYSTOR ’19, pages 179–179, New York, NY, USA, 2019. ACM.

[31] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, Dec 2008. Accessed: July 31, 2019.

[32] S. Nathan, C. Govindarajan, A. Saraf, M. Sethi, and P. Jayachandran. Blockchain meets database: Design and implementation of a blockchain relational database. Proc. VLDB Endow., 12(11):1539–1552, July 2019.

[33] D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference, USENIX ATC’14, pages 305–320, Berkeley, CA, USA, 2014. USENIX Association.

[34] A. Sharma, F. M. Schuhknecht, D. Agrawal, and J. Dittrich. Blurring the lines between blockchains and database systems: The case of hyperledger fabric. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD ’19, pages 105–122, New York, NY, USA, 2019. ACM.

[35] P. Thakkar, S. Nathan, and B. Viswanathan. Performance benchmarking and optimizing hyperledger fabric blockchain platform. In 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), pages 264–276, Sep. 2018.