BLOCKBENCH- A Framework for Analyzing Private Blockchains

译者：华南理工大学软件学院区块链实验室某摸鱼本科生

注：仅供阅读理解大体意思使用，部分词汇（如transaction）有前后翻译不一致的情况（之前翻成事务，后来又觉得还是交易更好）；部分词组我觉得不翻意思更加准确；译者仍将继续编辑，在学习过程中进行精化。

翻译过程：谷歌翻译+译者校对。

version:1.2

摘要

区块链技术正在颠覆世界。公有链，如比特币和以太坊，实现了一些P2P应用如加密货币和智能合约。它们的安全性和性能已经为很多人所研究。本论文涉及到的是最近的一些私有链系统，这些系统应更高的安全性和更强的性能指标而设计。对于一些实现在数据库系统顶层的应用（比如银行业，金融业和交易应用），这些私有链系统旨在取代他们的位置。各种搭建私有链的平台发展的很快。然而，我们缺少一个清晰的框架——一个用于分析和比较不同系统的框架。我们可以用这个框架来评估一个区块链作为分布式数据处理平台的性能瓶颈，并由此改善我们的平台。

在这篇论文中，我们首先介绍BLOCKBENCH，用于分析私链的第一个评估框架。它是比较不同平台的一种公平的方式，能够让我们对不同系统设计选择有更深入的理解。任何一个私链都可以通过简单的API整合进BLOCKBENCH中，通过让私链负载workload（跑一跑现实中的，别人编写的智能合约），BLOCKBENCH就可以对其做出评价。BLOCKBENCH从throughput, latency, scalability and fault-tolerance几个方面衡量整体和局部的性能。

接着，我们会使用BLOCKBENCH来对三个主流私链系统：以太坊，Parity和Hyperledger进行全面的分析评估。分析的结果会证明：在传统的workload工作条件下，这些系统想要取代现行的数据库系统还为时过早。此外，这三个系统在性能表现方面有比较大的差异，因为它们在设计时的重心放在了区块链软件栈的不同层次。

我们已经发布了BLOCKBENCH以供公众使用。

 

第一节 介绍

区块链技术在过去几年里取得了很大发展，这很大程度上归功于加密货币比特币的成功。一个区块链，也叫分布式账本，实质上是一种由一组互不完全信任的节点所组成的（只允许添加数据的）数据结构。区块链网络上的所有节点认可同一个有序的区块集合，每一个区块包含很多交易，所以区块链可以被视作为按时间顺序记录交易的记录。从数据库的意义上看，区块链可以被视作为一种解决分布式交易管理问题的解决方法。然而，传统的数据库系统工作在完全信任的环境中工作，并且通过并发控制技术来处理交易。区块链的关键优势在于：它并不认为节点之间互相信任，因此从这一点上来说，设计它是为了实现拜占庭容错。

在最初的设计中，比特币的区块链将coins储存为一种系统状态，这种系统状态成为所有参与者的共识。对于这个简单的应用，比特币节点实现了一个简单的复制模型，简单地将硬币从一个地址移动到另外一个地址。此后，区块链迅速的成长，能够支持用户自定义状态和完全图灵机模型。以太坊是一个知名的支持智能合约的例子。更加重要的是，业界已经开始发展新的区块链平台，这些平台是专为参与者进行身份验证的私人环境而设计的。这种（私人）环境下的区块链系统被称作私有链（或者许可链），与早期的任何人都可以加入或离开公有链系统相区分。过去，人们创造了很多用于安全交易，资产管理，银行业以及保险相关的应用并评估他们的效用，这些应用都是由企业级数据库系统诸如Oracle和MySQL所支持的，但是现在区块链有能力瓦解这种状况因为使用区块链系统不需要那么多的基础设施，也不需要那么多的人力成本。区块链所特有的不可篡改性和透明性能够减少人为的错误和用于处理数据冲突的人力成本。区块链通过省去数据处理中的重复性工作来优化商业流程。据估计，高盛资本市场因此而节省了60亿美元，摩根大通预测，截止到2020年，区块链将开始取代目前的冗余基础设施。

考虑到目前虽然数据库技术仍占主流，但区块链技术已经开始被逐渐部署的趋势，一个问题就是区块链能够在何种程度上处理数据。另一个问题是，我们该如何从今天的多种多样的区块链平台中选择一个合适的来使用。因为即使区块链是一个开源的协议，不同的平台实现细节也是不同的。为了解决这两个问题，我们开发了一种标准评价框架，即BLOCKBENCH。BLOCKBENCH是第一个用于研究和比较私有链性能的标准评价工具。尽管私有链的节点彼此之间仍然不完全信任，但他们的身份是已经被认证的了。这就意味着系统可以使用更有效的协议来实现拜占庭容错，而这在公链中是难以做到的。我们不关注公链是因为公链的性能（以及对于安全保证的权衡）相对来说已经被很深入的研究过了。应用开发者可以用我们的框架评估区块链的性能能否达到应用的要求，不仅如此，对平台开发者，我们的框架也可以帮助他们洞察，识别性能的瓶颈并设法改善之。

我们在开发BLOCKBENCH时主要面临三个挑战。第一，一个区块链系统包含很多部分，同时我们发现不同平台对于不同细节的设计选择是多种多样的。所以我们在BLOCKBENCH中将区块链的结构模块化地分为三层，逐个研究。分别是：共识层（consensus layer），数据模型（data model）和执行层（execution layer）。第二，对于平台的选择有很多，但并不是所有的平台都有成熟的设计，实现和现成的用户群。所以，我们在开始设计BLOCKBENCH的时候，是基于三个最为成熟的平台：以太坊，Parity和Hyperledger。之后我们会着手支持更多的平台。这三个平台都支持智能合约，而且都可以被部署在私有环境中。第三，我们缺少面向数据库的workload以用于区块链。虽然我们在以太坊的公链上能够找到真实的交易和合约，但是这样的workload能否作为代表来评估区块链的一般数据处理能力，这一点是不清楚的。为了解决这个挑战，我们将区块链视为一个数据仓库和一个引擎的结合体。数据仓库存储key-value，引擎通过智能合约实现交易和分析的功能。之后我们可以基于真实或合成的数据，设计交易的workload和分析的workload，然后放在区块链上跑跑看。

BLOCKBENCH是一个灵活的，可扩展的框架。它提供了很多workload，并且可以将以太坊，Parity和Hyperledger当作后端。workload目前是面向交易的，旨在帮助macro-benchmark and micro-benchmark blockchain（宏观基准和微观基准区块链）支持类数据库的应用。具体来说，现行的宏观基准包括一个键值，一个OLTP workload 和一些真实的以太坊智能合约workload。对于三层模型中的每一层，其各自拥有至少一个微观基准workload来衡量其性能。举个例子，对于执行层，BLOCKBENCH提供了两个workload用以对智能合约I/O和计算速度进行压力测试。新的workload和区块链可以很容易的通过一些简单的API整合进框架中。BLOCKBENCH通过几个主要的指标将后端系统的性能数量化:吞吐量（throughput）,延迟（ latency）,可扩展性 （scalability） 和 容错度（fault tolerance）。通过模拟网络级的攻击，它支持安全性的评估。我们可以使用BLOCKBENCH对三个区块链系统，结合两个宏观基准的workload和四个微观基准workload进行深入的比较。结果表明区块链系统的性能被限制住了，远低于最先进的数据库系统。Hyperledger在七项标准中表现的都比其他两个系统要好，但是当节点数超过16个时，Hyperledger就难以扩展了。我们的评估表明，共识层的协议是造成以太坊和Hyperledger在应用层性能差异的主要原因。我们也识别出了Parity的信息处理的瓶颈。最后，我们也揭露了以太坊和parity的执行层和数据层的瓶颈。

综上所述，我们的贡献是：

我们展示了第一个用于理解和比较私有链系统性能的标准评价框架，并将其发布以供公众使用；

我们对以太坊，Parity和Hyperledger做了比较全面的评估。我们的经验结果给出了一些具体证据，证明区块链系统处理数据的能力是有限的，同时揭露了三个系统的瓶颈。这些结果将作为区块链技术日后发展的一些参考标准（baseline）。、

在下一节中，我们将深入讨论区块链系统。第三节中，我们将介绍BLOCKBENCH的设计和实现。第四节中我们将展示我们对三个系统的比较研究。第五节中我们将讨论从这些结果中学习到的教训。第六节中我们会谈到相关工作。之后我们在第七节做一下总结。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

第二节 私有链

一个典型的区块链系统是由很多互不完全信任的节点所组成的。一些节点会表现出拜占庭行为，但大多数是诚实的。这些节点共同维护一组共享的，全局的状态，同时执行修改这些状态的事务。区块链维护这些状态和历史事务，是一种特殊的数据结构。系统内的所有节点认可储存在区块链内的事务以及他们发生的顺序。因此，区块链也常被称作是分布式账本。

区块链事务

区块链中的一个事务和传统数据库中的事务是一样的：对一些状态所进行的一系列操作。因此，区块链事务也需要有相同的ACID语义。关键的区别在于故障模型的设想。现有的事务型，分布式数据库通过部署并行控制技术（比如two-phase）来确保ACID语义。这样的做法可以实现高性能，因为这种故障模型很简单，也就是说，一旦失败就崩溃。相反，最初的区块链的设计所设想的是一个更加充满敌意的环境——在这个环境中节点可以随意进出而且都可能表现出拜占庭行为。在这种模型下，并发控制的成本要高得多。

比特币

在比特币中，状态是网络中可用的数字硬币（加密货币）。一个比特币事务将硬币从一组地址移至另一组地址。当每个节点想要执行一组事务的时候，它就广播这一组事务。一些称作矿工的特殊节点将这些事务收集并放入区块中，检查它们的有效性，之后开始执行共识层协议来将区块接入区块链。下图展示了区块链的数据结构，每个块通过加密指针链接到它的前一块，由此一直追溯到创世区块。比特币使用POW作为共识层的协议：只有成功解决一道数学难题（猜对区块头相对应的随机数）的矿工节点才能为区块链添加区块。POW可以容忍拜占庭故障，但它本质上是概率性的：可能会有两个区块同时被加在了区块链上，使区块链分叉。比特币采用了这样的解决方法：当一个区块后面跟了6个区块的时候，这个区块才被真正承认。这种概率性的保证带来了安全和性能两方面的问题：当敌手控制了25%的节点的时候就可以发动攻击，同时比特币的事务处理吞吐量很低（每秒7个事务）。

以太坊

由于简单的事务语义，比特币节点所执行的是非常简单的，提前写入协议的状态机。以太坊在比特币的基础之上开始支持用户自定义功能和图灵完全状态机。特别是以太坊允许用户以智能合约的形式定义任意复杂程度的计算。一旦这个智能合约被部署，它就会以复制状态机的形式运行在所有的以太坊节点上。除了一些区块链上共享的状态（如加密货币），每个智能合约都有它自己的状态。图1展示了一个典型以太坊节点的软件栈：一个完全的认证节点包含了区块链的全部历史，而一个非认证节点只储存区块头。和比特币的一个关键区别在于智能合约的状态是和普通事务一样被维护的。事实上，一个智能合约是由一个unique的地址所标识的，这个地址在以太坊的网络中有自己的货币余额，当有交易在这个地址上发生时，合约的逻辑就被执行。以太坊自带一个执行引擎，叫做以太坊虚拟机，用以执行智能合约。

 

图2展示了一些目前流行的实现了pyramid scheme（金字塔骗局：传销）的智能合约：用户们打钱到这个合约，这个合约会向更早的加入者支付利息。这个合约有自己的states，比如参加者的列表和它所提供的函数enter。用户通过执行一个事务来把他的钱打过去，而这个事务将由智能合约来处理。（by msg.sender and msg.amount）

 

私有链

以太坊使用和比特币一样的共识层，尽管参数有些不同。事实上，90%的公有链系统部署了各种各样的POW协议。而POW是non-deterministic而且十分耗费算力，这两者使得POW不适于应用在银行业和金融业。最近的区块链系统比如Hyperledger，考虑提前设定一些限制条件比如认证节点来方便工作。尽管POW在类似以太坊这样的区块链环境中依然是有用的，但在节点已知的前提下，有一些方法会更加确定而又有效。在这种受限前提下，分布式容错共识是分布式系统领域中一个很好的研究课题。Zab,Raft,PaxosPBFT都是时下流行的协议。最近的私链系统如Hyperledger使用PBFT，再如Parity，Ripple等开发他们自己的变种。大多数此类系统支持智能合约，即使这些系统使用不同的语言，不同的API，不同的执行引擎。结果就是，此类私链，相对于基于POW的区块链，可以执行复杂的应用，同时还可以实现拜占庭容错。巨大的商业利益为私链系统成为数据管理主流提供了庞大的潜力。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

第三节 BLOCKBENCH 设计

3.1 区块链分层

 

本节讨论blockbench抽象出来的各层和benchmarking workloads

 

对于区块链，我们有很多选择：超过200种比特币的变种，以太坊和其他的私链。为了有意义的比较它们，我们定义了在所有的系统中都出现的四种抽象层（如上图）并且针对这些层设计了我们的workload。

共识层包含了如何将区块接上区块链的协议；数据层包含了链上数据的结果，内容和相应操作；执行层包括了区块链环境下执行操作时的细节；最后，应用层包括了区块链应用的类。

在最近的一份工作中，Croman建议奖区块链划分至如下几个层次：网络层，共识层，存储层，view层和side层。这与我们的四层划分很相似，这种划分更多考虑的是加密货币的应用，并没有过多考虑智能合约的执行。我们的模型精确考虑了私链的实际实现。现在我们将以此讨论这些层。

 

1，共识层

共识层的目标是使得系统中的所有节点都同意区块链内容的合法性。也就是说，如果一个节点要添加一个区块，其他的节点也就要将同样的区块添加至他们区块链拷贝的末尾。用于达成共识的协议对于分布式数据库中的crash-failure model来说至关重要，这种模型下的节点们只同意一条全局的transaction order存在。另一方面，区块链系统采用一系列协议来实现拜占庭容错。

在一种极端情况下，以太坊使用POW，可达到每个块14s的速率，比特币则达到每个块10min的速率。事实上，POW算法在每一轮随机选择一个节点来为链添加块，每个节点被选中的可能性由节点们的总算力决定。这个简单的方案可以对抗Sybil攻击[20,49] - 这是一种在开放的，分散的环境中的常见攻击，其中攻击者可以获得多个身份。然而，POW会耗费大量能量和算力，节点在做着低效无用的工作。更糟糕的是，POW并不能保证安全性，两个节点可能会同时被选中，区块链可能同时接收两个块。这将导致区块链分叉，所以大多数基于POW的系统添加了额外的规则。比如，只有添加在最长分叉上的区块才被承认。而以太坊则特别地使用了一个POW的变体——GHOST，这种变体使得区块链在heavt branches上接收区块。无论如何，大部分情况下只会有一个区块被接纳进链中。

在另一种极端情况下，Hyperledger使用经典的PBFT协议。其通信约束为：O(N^2) where N is the number of nodes。PBFT可以容忍少于三分之一节点数的故障，并且工作分三阶段进行，节点之间彼此广播消息。第一阶段，pick一个leader选择一个值；第二阶段，广播这个待验证的值；第三阶段，等待超过三分之二的节点...（此处涉及PBFT算法的原理 不太懂）。PBFT已经显示出它在部分异步模型中的活跃性和安全性，与POW不同，PBFT一旦附加了块，就立即确认。故可比POW容忍更多的故障（POW更容易遭受25%攻击）。但是，PBFT假定节点身份已知，因此它只能在允许的设置中工作。 此外，由于其通信开销，协议不太可能扩展到以太坊的网络规模。在这两者之间，有各种混合设计结合了PoW的可扩展性和PBFT的安全性[43]。例如，Bitcoin-NG [25]通过使用PoW进行领导者选举，将一致性与交易验证分离，然后可以一次追加多个块。同样，Byzcoin [34]和Elastico [37]利用PoW来确定运行PBFT的随机，较小的共识组。另一个例子是ErisDB采用的Tendermint协议[5]，该协议结合了股权证明（PoS）和PBFT。与PoW不同，PoS选择一个节点，该节点可以通过其在系统中的投资（或赌注）来附加块，从而避免消耗CPU资源。Parity [22]实现了PoS的简化版本，称为授权证明（或PoA）。在该协议中，预先确定一组权限，并且为每个权限分配一个固定的时隙，在该时隙内可以生成块。 PoA强烈假设当局是受信任的，因此仅适用于私有部署。

 

2,数据模型

在比特币中，transaction是一等公民：它们是代表网络中数字硬币的系统状态。私链通过关注账户而脱离了这种模式。一个直接的好处是简单性，特别是涉及加密货币的应用程序。例如，在比特币中将钱从一个用户转移到另一个用户涉及搜索属于发件人的transaction，然后将其中一些标记为已花费，而在以太坊中通过在一个transaction中更新两个帐户可以轻松完成。以太坊中的帐户将余额作为其状态，并在收到transaction时更新。一种特殊类型的帐户，称为智能合约，包含可执行代码和私有状态（图1）。在接收transaction时，除了更新其余额外，还会使用transaction中指定的参数调用合同的代码。代码可以读取其他非合约帐户的状态，并且可以在执行期间发送新的事务。Parity采用与以太坊相同的数据模型。在Hyperledger中，只有一种称为chaincode的帐户与以太坊的合约相同。 Chaincode只能访问其私有存储，它们彼此隔离。

一个块包含一个transaction列表，一个执行的智能合约列表以及它们的最新状态。每个块由其内容的加密哈希标识，并链接到前一个块的标识。在Parity中，整个块内容保存在内存中。在以太坊和Hyperledger中，内容以两层数据结构组织。这些状态存储在基于磁盘的键值存储（以太坊中的LevelDB [4]和Hyperledger中的RocksDB [6]）中，并组织在一个哈希树中(根包含在块头中)。以太坊将状态缓存在内存中，而Hyperledger将其数据管理完全外包给存储引擎。只有受块阻塞事务影响的状态才会记录在根哈希中。transaction列表的哈希树是经典的Merkle树，因为列表不大。另一方面，不同的Merkle树变体用于状态树。以太坊和Parity采用Patricia-Merkle树，支持高效的更新和搜索操作。 Hyperledger实现了Bucket-Merkle树，它使用哈希函数将状态分组为一个桶列表，从中构建Merkle树。

块头和键值存储一起维护区块链的所有历史事务和状态。 为了验证和执行事务，区块链节点只需要几个最近的块（或者只需要基于PBFT的系统的最新块）。 但是，该节点还需要通过一些类似RPC的机制与没有整个区块链的轻量级客户端进行交互。 这种外部接口可以在区块链之上构建第三方应用程序。 当前系统支持最少的查询集，包括基于其ID获取块和事务。 以太坊和Parity通过JSON-RPC公开更全面的API集，支持特定块和其他块统计信息的帐户状态查询。

 

3，执行层

合约（或chaincode）在运行时环境中执行。一个要求是执行必须很快，因为一个块中有多个合同和事务，并且它们必须都由节点验证。另一个是执行必须是确定性的，理想情况下在所有节点上都是相同的。确定性执行可避免事务输入和输出中不必要的不​​一致，从而导致块被中止。在PoW和PBFT中，中止事务会浪费计算资源。

 

以太坊开发了自己的机器语言（字节码）和用于执行代码的虚拟机（称为EVM），Parity也采用了该代码。 EVM针对以太坊特定操作进行了优化。例如，在以太坊中执行的每个代码指令都要花费一定量的gas，而且必须正确地追踪记录总成本并向交易的发送方收取费用。此外，代码必须跟踪中间状态并在执行耗gas体时将其反转(reverse)。相比之下，Hyperledger在设计中并未考虑这些语义，因此它只支持在Docker镜像中运行已编译的机器代码。具体来说，chaincode被部署为Docker镜像，通过预定义的接口与Hyperledger的后端交互。 Hyperledger环境的一个优点是它支持多种高级编程语言，如Go和Java，而不是以太坊自己的语言。在开发环境方面，Hyperledger只公开简单的键值操作，即putState和getState。这是受限制的，因为任何合同状态都必须映射到键值元组。相比之下，以太坊和Parity支持更丰富的数据类型集，例如地图，数组和复合结构。以太坊和Parity中的这些高级数据类型使得开发新合同变得更容易，更快捷。

 

4，应用层

许多应用程序都被提议用于区块链，因为后者的两个关键属性大有可图。首先，区块链中的数据对于参与者是不可变的和透明的，这意味着一旦附加了记录，就永远不会改变它。其次，它对不诚实和恶意的参与者具有弹性。即使在允许的环境中，参与者也可能相互不信任。然而，最受欢迎的应用程序仍然是加密货币。以太坊拥有自己的货币（以太币），并且运行的大部分智能合约都与货币相关。分散式自治组织（DAO）是以太坊中最活跃的应用程序，为众筹，交换，投资或任何其他分散活动创建社区。 DAO管理参与者提供的资金，并为其用户提供与其贡献成比例的投票权。 Parity的主要应用是管理以太币的钱包应用程序。由于主要银行正在考虑采用加密货币，一些金融科技公司正在构建应用加密货币来调解金融交易，例如货币兑换市场[44]。其他例子包括应用货币和智能合约以实现更透明和更具成本效益的资产管理[39,40]。

 

一些受到人类因素而产生瓶颈的应用程序，希望在区块链的不变性和透明度的基础上建立更好的工作流程。例如，通过在区块链上存储数据可以加快安全解决和保险流程[29]。另一个例子是共享经济应用程序，例如AirBnB，它可以使用区块链来评估分散设置中的声誉和信任，因为任何用户的历史活动都是可用且不可变的。这也扩展到物联网设置，设备需要在彼此之间建立信任[3]

 

3.2 BLOCKBENCH的实现

下图展示了BLOCKBENCH的实现。

 

 

要评估区块链系统，第一步是通过实现IBlockchainConnector接口将区块链集成到框架的后端。该接口包含用于部署应用程序，调用应用程序（通过发送transaction）以及查询区块链状态的操作。以太坊，Parity和Hyperledger是BLOCKBENCH目前支持的后端，而ErisDB集成正在开发中。用户可以使用现有工作负载之一（下面讨论）来评估区块链，或使用IWorkloadConnector接口实现新工作负载（我们假设处理工作负载逻辑的智能合约已经实施并部署在区块链上）。此接口实质上将工作负载的操作包装到要发送到区块链的事务中。具体来说，它有一个getNextTransaction方法，它返回一个新的区块链事务。 BLOCKBENCH的核心组件是驱动程序，它将工作负载，用户定义的配置（操作数，客户端数，线程数等）作为输入，在区块链上执行并输出运行的统计信息。

 

异步驱动器

实现驱动程序的一个挑战是当前的区块链系统是异步服务的，这意味着提交给系统的事务将在延迟一段时间后处理。这与数据库，特别是事务数据库形成对比，在数据库中，操作是同步的，即它们阻塞直到系统完成处理。提交交易时，Ethereum，Parity和Hyperledger会返回一个交易ID，该ID可用于稍后检查交易状态。这种异步语义可以带来更好的性能，但它会强制驱动程序定期轮询提交的请求的状态。特别是，Driver维护一个尚未确认的未完成事务队列。工作线程将新的事务ID添加到队列中。轮询线程周期性地调用IBlockchainConnector接口中的getLatestBlock（h）方法，该接口根据给定高度h返回区块链上新确认块的列表。对于以太坊和Parity，如果块处于现在区块链尖端的“确认长度”内，那么就认为它是被确认的；对于Hyperledger来说，块一旦出现在区块链上就被确认。然后，驱动程序从已确认的块的内容中提取交易列表，并删除本地队列中的匹配列表。 getLatestBlock（h）可以在所有三个系统中实现：首先请求区块链的当前端t，然后请求范围内（即从t开始的h长度）的所有块的内容。ErisDB提供的发布/订阅接口可以简化这个功能的实现。

 

 

3.3 评估指标

不同配置下跑同一个workload的输出数据可结合三个性能指标来评估区块链。

•吞吐量：以每秒成功交易的数量来衡量。可以使用多个客户端和每个客户端的线程配置工作负载，以使区块链吞吐量饱和。

•延迟：以每笔交易的响应时间来衡量。驱动程序实现阻塞事务，即在一个交易完成之后再启动另一个交易。

•可伸缩性：在增加节点数和并发工作负载数时，以吞吐量和延迟的变化来衡量。

 

•容错能力：测量节点故障期间吞吐量和延迟的变化情况。虽然区块链系统能够容忍拜占庭失败，但不可能模拟所有拜占庭行为。在BLOCKBENCH中，我们模拟了三种故障模式：一个节点简单停止的崩溃故障；网络延迟（我们在消息中注入随机的延迟而导致的）；以及节点之间的随机答复（即我们破坏了节点间的正常通信）。

 

安全指标

拜占庭故障的一个特例是攻击者造成的恶意行为。攻击者可以是系统内的流氓节点或者被挟持的节点。在此威胁模型下，区块链的安全性被定义为 基础共识协议的安全属性。特别是，安全性意味着非拜占庭节点具有相同的区块链数据。违反安全属性会导致区块链中分叉。经典的拜占庭容忍协议（如PBFT）被证明可以在一定数量的节点故障发生时仍确保安全性。另一方面，在像比特币或以太坊这样的PoW系统中，由于网络延迟导致两个节点挖掘相同的块，因此可能发生分叉。虽然这种意外分叉可以快速解决，但攻击者设计的分叉可用于双花（double spending）和自私采矿(selfish mining)。在前者中，攻击者将事务发送到fork中的块，等待用户接受它，然后将冲突事务发送到主分支中的另一个块。在后者中，通过扣留区块和维护私人长叉，攻击者破坏了采矿的动机并迫使其他参与者加入攻击者的联盟。通过破坏25％的节点，攻击者可以控制整个网络的块生成[26]

在这项工作中，我们将安全性量化为分叉中的块数。这些块，称为孤块或陈旧块，代表了攻击者可以执行双重支出或自私挖掘的漏洞和窗口。为了操纵分叉，关键策略是隔离一组节点，即分区网络。例如，eclipse攻击[30]利用应用程序级协议围绕攻击者控制下的目标节点。在网络层面，BGP劫持[7]需要控制少至900个前缀来隔离50％的比特币总采矿能力。 BLOCKBENCH通过在给定的持续时间内对网络进行分区来实现这些攻击的模拟。特别是，在分区期间，BLOCKBENCH运行时会丢弃两个分区中任意两个节点之间的网络流量。然后通过主分支中包括的块总数与用户确认的块总数之间的比率来测量安全性。比率越低，系统对自私采矿的双重支出抵抗性越高。

 

3.4 Workloads（工作负载）

我们将工作负载分为两大类：用于评估应用层性能的宏观基准，以及用于测试较低层的微观基准。 我们为以太坊，Parity和Hyperledger的所有工作负载实现了智能合约，其详细信息在表1中进行了总结。以太坊和Parity使用相同的执行模型，因此它们共享相同的智能合约实施。

 

3.4.1 宏观基准workloads

我们将两个流行的数据库基准测试workloads移植到BLOCKBENCH，以及在以太坊区块链中找到的三个其他实际workloads。

 

Key-value storage (键值存储)。我们实施一个简单的智能合约，用于存储键值。 WorkloadClient基于YCSB驱动程序[13]。它使用许多记录预加载每个存储，并支持具有不同读写操作比率的请求。 YCSB广泛用于评估NoSQL数据库。

 

OLTP（Smallbank）。与不考虑交易的YCSB不同，Smallbank [10]是OLTP工作负载的流行基准。它由三个表和四个模拟银行账户基本操作的基本程序组成。我们使用智能合约，简单的将钱从一个账户转移到另一个账户，从而实现它。

 

EtherId。这是一个实现域名注册器的流行合同。它支持域名的创建，修改和所有权转移。用户可以通过向当前域的所有者支付一定金额来请求现有域。此合约是为以太坊区块链编写的，无需更改即可移植到Parity。在Hyperledger中，我们在合同中创建了两个不同的键值命名空间：一个用于存储域名数据结构，另一个用于存储用户的帐户余额。在域的创建中，合同只是使用域名作为键将域值插入到第一个空间中。对于所有权转移，合同会检查请求者的第二个空间来确认他是否有足够的资金。为了模拟实际工作负载，合同包含预先分配具有一定余额的用户帐户的功能。

 

Doubler。这是一个实现金字塔模式的合同。如图2所示，参与者向该合同汇款，并在更多人加入该计划时获得奖励。除了参与者名单及其贡献之外，合同还需要保留下一次支付的索引，并在支付早期参与者后相应地更新余额。与EthereId类似，此合约已经为以太坊编写，可以直接移植到Parity。要在Hyperledger中实现它，我们需要将列表操作转换为键值语义，使chaincode比它在以太坊中的对应物更加笨重。

 

WavesPresale。此合同支持 digital token销售。它保持两种状态：到目前为止销售的代币总数，以及之前的销售交易清单。它支持添加新销售，转移先前销售的所有权以及查询特定销售记录的操作。 Ethereum和Parity支持复合结构数据类型，使得实现应用程序逻辑变得简单。相反，在Hyperledger中，我们必须通过使用单独的键值命名空间将此结构转换为键值语义。

 

3.4.2 微观基准workloads

之前的工作负载测试区块链的整体性能。如本节前面所述，区块链系统包含多个层，每个层可能对整体性能产生不同的影响。我们设计了几个工作负载来强调层，以便了解它们各自的性能。

 

DoNothing。此合约接受交易作为输入并简单地返回。换句话说，它涉及执行层和数据模型层的最少操作次数，因此整体性能将主要由共识层决定。以前关于区块链共识协议[34,43]性能的研究使用时间来达成共识以衡量其性能。在BLOCKBENCH中，此度量标准直接反映在交易延迟中。

 

Analytics（分析）。此工作负载考虑区块链系统在回应有关历史数据的分析查询时的性能。与OLAP基准测试类似，此工作负载评估系统如何实现类扫描和聚合查询，这些查询由其数据模型确定。具体来说，我们实现了两个查询，用于从区块链数据中提取统计数据：

Q1：计算块i和块j之间提交的总事务值。

Q2：计算块i和块j之间涉及给定状态（帐户）的最大事务值。

在ClientWorkload中，我们使用带有整数值（表示汇款）的交易和具有整数值的状态预加载blockchain。对于以太坊，两个查询都可以通过JSON-RPC API实现，这些API返回特定块的交易详细信息和帐户余额。但是，对于Hyperledger，第二个查询必须通过chaincode（VersionKVStore）实现，因为系统没有API来查询历史状态。

 

IOHeavy。当前的区块链系统依赖于键值存储来持久存储区块链交易和状态。每个存储系统在不同的工作负载下可能会有不同的表现[51]。此工作负载旨在通过调用某个合约（在此合约状态上执行大量随机写和随机读操作）来评估IO性能。可以通过观察到的事务延迟来估计I / O带宽。

 

CPUHeavy。此工作负载测量执行层的计算繁重任务的效率。 EVM可能会快速执行以太坊特定的操作，但目前还不清楚它在一般任务上执行时，哪些机器本机代码可能更有效。我们部署了一个初始化大型数组的智能合约，并在其上运行快速排序算法。然后可以通过观察到的交易延迟来测量执行层性能。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

第四节 性能标准

我们选择以太坊，Parity和Hyperledger进行研究，因为他们在区块链设计空间中占据不同的位置，并且还因为他们的代码库成熟度。我们使用上一节中描述的宏观和微观基准工作负载来评估这三个系统。

 

•Hyperledger在基准测试中的表现始终优于以太坊和Parity。但它无法扩展到超过16个节点。

 

•以太坊和Parity对节点故障更具弹性，但它们容易受到区块链分叉的安全攻击。

 

•Hyperledger和以太坊的主要瓶颈是共识协议，但对于Parity而言，瓶颈是由事务签名引起的。

 

•以太坊和Parity在内存和磁盘使用方面产生大量开销。他们的执行引擎效率也低于Hyperledger。

 

•Hyperledger的数据模型水平较低，但其灵活性可实现区块链数据分析查询的自定义优化。

 

我们使用了Ethereum的流行Go实现，geth v1.4.18，Parity版本v1.6.0和Hyperledger Fabric v0.6.0预览版。我们通过定义一个创世块并直接将peers添加到矿工网络，为以太坊和奇偶校验建立一个私有测试网。对于以太坊，我们手动调整了创世块中的难度变量，以确保矿工在大型网络中不会发散。对于Parity，我们将stepDuration变量设置为1.在以太坊和Parity中，confirmationLength设置为5秒。 Hyperledger中的默认批量大小为500。

实验在48节点集群上运行。 每个节点都有一个E5-1650 3.5GHz CPU、32GB RAM和2TB硬盘，并且运行Ubuntu 14.04 Trusty（这里的意思或许是安全节点的意思），并通过容量1GB交换机连接到其他节点。 以下结果是5次独立运行的平均值。 对于以太坊，我们在每台机器的可用12个核心中保留了8个核心，因此来自客户端驱动程序进程的定期轮询不会干扰挖矿过程（这是CPU密集型的）。

 

4.1 宏观基准

本节讨论区块链系统在应用层的性能，方法是在多个节点上运行YCSB和Smallbank基准测试。

 

 

4.1.1吞吐量和延迟

我们在5分钟内测量了具有8个服务器和8个并发客户端的三个系统的峰值性能。每个客户端将交易发送到服务器，请求速率从8 tx / s到1024 tx / s不等。图5显示了峰值时的吞吐量和延迟，以及这些指标如何随着不同的交易处理速率而变化。

我们观察到，就吞吐量而言，Hyperledger在两个基准测试中都优于其他系统。具体来说，它的吞吐量分别比以太坊和奇偶校验高5.5倍和28倍。Parity具有最低延迟，而以太坊具有最高延迟。 Hyperledger和以太坊之间的差距是由于共识协议的不同：一个基于PBFT而另一个基于PoW。我们在实验期间测量了CPU和网络利用率，并观察到Hyperledger是通信绑定的，而以太坊是CPU绑定的（见附录B）。在8个服务器上，广播消息的通信成本比块挖掘便宜得多，块挖掘的难度设置为每块大约2.5s。

 

 

 

Parity和Hyperledger之间的性能差距不是因为共识协议，因为我们期望Parity的PoA协议比PoW和PBFT更简单，更高效（事实上，我们发现Parity具有与Hyperledger相同的CPU利用率和更低的网络利用率）。图5 [b，c]显示Parity的吞吐量和延迟随着事务处理速率的提高而保持不变（超过40 tx / s）。为了进一步了解其性能，我们在客户端测量待处理事务的队列。图6比较了系统达到峰值吞吐量之前和之后的队列大小。只有8 tx / s，以太坊和Hyperledger的队列保持大致恒定的大小，但Parity的队列大小随着时间的推移而增加。更有趣的是，在高负载（每个客户端512 tx / s）下，Parity的队列总是小于以太坊和Hyperledger的队列。此行为表明Parity以恒定速率处理事务，并且它强制执行最大客户端请求速率，大约为80 tx / s。因此，与其他系统相比，Parity实现了更低的吞吐量和延迟。

 

 

另一个观察结果是，Hyperledger和Ethereum中的YCSB和Smallbank工作负载之间存在差异。 吞吐量下降10％，延迟时间增加20％。 由于执行Smallbank智能合约比执行YCSB合约更昂贵（对区块链的状态有更多的读写），结果表明区块链的执行层存在不可忽略的成本。

 

在峰值吞吐量方面，Hyperledger每秒产生3.1块，并实现1273 tx / s的总吞吐量。 我们注意到这个吞吐量远远低于内存数据库系统所能提供的吞吐量（见附录B）。 由于吞吐量是块大小和块生成率的函数，我们测量了增加三个系统中块大小的效果。 结果（见附录B）表明，随着块大小的增加，块生成速率将成比例地降低，因此整体吞吐量不会提高。

 

4.1.2 可扩展性

 

我们调整了客户端请求率并增加了客户端数量和服务器数量。图7显示了三个系统如何扩展以处理更大的YCSB工作负载（Smallbank的结果类似，并包含在附录B中）。由于服务器上的交易处理速率不变，Parity的性能随着网络规模和负载的增加而保持不变。有趣的是，虽然以太坊的吞吐量和延迟几乎线性地降低到超过8台服务器，但Hyperledger却在超过16台服务器时停止工作。

 

 

 

为了理解为什么Hyperledger无法扩展超过16个服务器和16个客户端，我们检查了系统的日志，发现节点反复尝试但无法就包含批量交易的新视图达成共识。实际上，服务器处于不同的视图中，因此从网络的其余部分接收到冲突的视图更改消息。进一步调查显示，冲突的视图之所以产生，是因为消息通道已满，从而其他peers拒绝了共识消息。随着消息被删除，视图开始出现分歧并导致无法达成共识。事实上，我们也观察到随着时间的推移，客户端请求需要更长的时间才能返回（参见附录B），这表明服务器在处理网络消息时过于饱和。然而，我们注意到，最初的PBFT协议保证了活跃性和安全性，因此Hyperledger无法扩展到超过16台服务器，这是由于协议的实施。实际上，在最新的代码库（在我们完成基准测试后更新）中，PBFT组件被另一个实现替换。我们计划在未来的工作中评估这个新版本。

到目前为止的结果表明，扩展客户端数量和服务器数量会降低性能，甚至导致Hyperledger失败。接下来，我们测试了在调整客户端数量的同时增加服务器数量所带来的成本。图8显示，由于存在更多服务器，性能变得更糟，这意味着系统会产生一些网络开销。因为Hyperledger是通信绑定的，所以拥有更多服务器意味着更多的消息被交换和更高的开销。对于以太坊，即使它是计算绑定的，它仍然消耗适量的网络资源，用于将交易和块传播到其他节点。此外，对于较大的网络，难度的增加导致了延迟的上升。我们观察到，为了防止网络发散，难度级别以比节点数量更高的速率增加。因此，以太坊吞吐量下降的一个原因是网络规模。另一个原因是，在我们的设置中，8个客户端仅向8个服务器发送请求，但这些服务器并不总是相互广播事务（它们继续在自己的事务池中进行挖掘）。结果，没有充分利用网络挖掘能力。

 

 

 

4.1.3 容错力和安全性

为了评估系统在崩溃时对故障的恢复能力，我们运行了包含8个客户端的系统超过5分钟，在此期间我们在第250秒时终止了4台服务器。图9显示，以太坊几乎不受变化的影响，这表明失败的服务器对挖掘过程没有显著贡献。在Parity中，每个节点以恒定速率生成块，因此4个节点失败意味着剩余节点有更多时间生成更多块，因此总体吞吐量不受影响。相比之下，Hyperledger的吞吐量大幅下降。对于12台服务器，Hyperledger在发生故障后停止生成块，这是预期的，因为PBFT只能容忍12个服务器网络中少于4个故障。对于16台服务器，系统仍然生成块但速率较低，这是由于其余服务器必须通过同步其视图来在故障后稳定网络。

 

 

我们接下来模拟了使区块链容易受到双花的攻击。第3.3节中描述的攻击在第100秒对网络进行了划分，并持续了150秒。我们将分区大小设置为原始的一半。图10比较了运行8个客户端和8个服务器的三个系统的漏洞。回想一下，脆弱性是以总块数和主分支上的块数的差异来衡量的（第3.3节），我们将其称为Δ。以太坊和Parity区块链在第100秒分叉，Δ随着时间的推移而增加。攻击持续时间内，在分叉分支中生成多达30％的块，这意味着系统高度暴露于双花或自私挖掘的攻击。当分区恢复时，节点在主分支上达成共识并丢弃分叉块。结果，Δ在第250秒后不久就停止增加。与之形成鲜明对比的是，Hyperledger没有预期的分叉，因为它的共识协议被证明可以保证安全。但是，我们注意到，Hyperledger比其他两个系统需要更长的时间才能从攻击中恢复（大约多50秒）。这是因为分区节点重新连接后执行的同步协议。

 

 

 

 

4.2 微观标准

本节通过使用微观基准工作负载评估区块链系统在执行，数据和共识层的性能。 对于前两个层，使用一个客户端和一个服务器运行工作负载。 对于共识层，我们使用了8个客户端和8个服务器。

 

4.2.1 执行层

我们部署了CPUHeavy智能合约，该合约使用给定大小的整数数组进行初始化。数组按降序初始化。我们调用了合约来使用quicksort算法对数组进行排序，并测量了执行时间和服务器的峰值内存使用情况。图11显示了不同输入大小的结果。虽然Ethereum和Parity使用相同的执行引擎，即EVM，Parity的实现更加优化，因此它的计算和内存效率更高。一个有趣的发现是，以太坊会产生大量内存开销。在排序10M元素时，它使用22GB内存，而Hyperledger使用473MB。当对10M以上的元素进行排序时，以太坊会耗尽内存。在Hyperledger中，智能合约被编译并直接在Docker环境中的本机机器上运行，因此它没有与执行高级EVM字节代码相关的开销。因此，Hyperledger在速度和内存使用方面更加高效。最后，我们注意到所有三个系统都未能使用多核架构，即它们仅使用一个核来执行合同。

 

 

4.2.2 数据模型

IO Heavy。我们部署了IOHeavy智能合约，该合约执行了一些关键值元组的读写操作。我们使用了20字节的密钥和100字节的值。图12报告了这些操作的吞吐量和磁盘使用情况。以太坊和Parity使用相同的数据模型和内部索引结构，因此它们会产生类似的空间开销。两者都使用比Hyperledger多一个数量级的存储空间，Hyperledger采用简单的键值数据模型。Parity将所有状态信息保存在内存中，因此它具有更好的I / O性能但无法处理大数据（在我们的硬件设置下超过3M状态）。相反，以太坊只缓存内存中的部分状态（使用LRU作为换出策略），因此它可以以吞吐量为代价处理比Parity更多的数据。 Hyperledger利用RocksDB来管理其状态，从而使其在规模上更有效。

 

 

 

Analytic Queries。我们通过初始化三个系统（具有固定余额的120,000多个帐户）来实现analytics workload。然后我们预装了100000块，每块平均包含3笔交易。交易将值从一个随机帐户转移到另一个随机帐户。由于Parity在有很多帐户时的巨大开销，我们只考虑使用1024个帐户的交易。然后，我们执行了第3.4节中描述的两个查询并测量了它们的延迟。图13显示Q1的性能相似，而Q2则看到Hyperledger和其他产品之间存在显着差距。我们注意到Q1和Q2的主要瓶颈是客户端发送的网络（RPC）请求数。对于Q1，客户端向所有系统发送相同数量的请求，因此它们的性能类似。另一方面，对于Q2，客户端向Ethereum和Parity每个块发送一个RPC，但由于我们定制的智能合约实现，因此只有一个RPC到Hyperledger（参见附录C）。这种网络往返时间的节省转化为Q2延迟提高了10倍以上。

 

 

 

4.2.3 共识

我们部署了接受交易并立即返回的DoNothing智能合约。 我们测量了这个工作负载的吞吐量，并与YCSB和Smallbank进行了比较。 与其他工作负载相比的差异如图13 [c]所示，展示了共识协议与其他软件堆栈的成本的对比。特别是，对于以太坊，我们观察到与YCSB相比吞吐量增加10％，这意味着 执行YCSB交易账户的开销为10％。 我们发现Parity中这些工作负载之间没有差异，因为Parity中的瓶颈是由于事务签名（即使是空事务仍然需要签名），而不是由于共识或事务执行。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

第五节 讨论

了解区块链系统

我们的框架旨在更好地理解不同私有区块链系统的性能和设计。随着越来越多的区块链系统被提出，每个系统都有不同的特点，BLOCKBENCH的主要价值在于它将设计空间缩小为四个不同的抽象层。我们对现有区块链系统的调查（见附录A）表明，这四层足以捕捉这些系统的关键特征。通过对这些层进行基准测试，可以深入了解设计权衡和性能瓶颈。例如，在本文中，通过运行IOHeavy工作负载，我们确定Parity通过将状态保存在内存中来交换性能以实现可伸缩性。另一个例子是Hyperledger对数据模型的权衡。一方面，简单的键值模型意味着无法直接支持一些分析查询。另一方面，它支持优化，有助于更有效地回答查询。最后，我们确定Parity中的瓶颈不是由于共识协议，而是由于服务器的交易签名。我们认为，如果没有系统的分析框架，这些观点就不容易提取。

 

 

区块链的可用性

我们与三个区块链系统合作的经验证实，他们认为目前的区块链还没有为大规模使用做好准备。他们的设计和代码库仍在不断完善，除了加密货币之外，没有其他已建立的应用程序。在这三个系统中，以太坊在代码库，用户群和开发者社区方面都更为成熟。我们遇到的另一个可用性问题是将智能合约从一个系统移植到另一个系统，因为它们具有不同的编程模型（参见第3节）。随着越来越多的区块链平台被提出，这个需求可能会加剧[44,16]。

 

将数据库设计纳入区块链

最近的许多工作都在解决这样一个问题，那就是如何通过改进共识协议来扩大区块链[34,37]。但是，正如我们在上一节中所演示的那样，还存在其他性能瓶颈。我们提出了四种从数据库系统应用设计原则来改进区块链的方法。

将存储，执行引擎和共识层相互分离，然后独立地优化和扩展它们。例如，当前系统采用通用键值存储，这可能不是最适合区块链中的唯一数据结构和操作。 UStore [19]证明围绕区块链数据结构设计的存储能够实现比现有实现更好的性能。

拥抱新的硬件原语。许多数据处理系统正在利用新硬件来提升其性能[47,51,21]。对于区块链，使用可信硬件，可以修改底层的拜占庭容错协议，以减少网络消息的发生[12]。像Parity和Ethereum这样的系统可以利用多核CPU和大容量内存来提高合同执行和I / O性能。

拆分。区块链本质上是一个复制的状态机系统，其中每个节点都维护相同的数据。因此，区块链与诸如H-Store之类的数据库系统根本不同，在H-Store中，数据在节点之间被分区（或分片）。分片有助于降低计算成本，并可以加快交易处理速度。分片的主要挑战是确保多个分片之间的一致性。但是，数据库系统中使用的现有一致性协议在拜占庭故障下不起作用。然而，他们的设计可以为实现区块链的更具可扩展性的分片协议提供建议。最近的工作[37]证明了分享共识协议的可行性，为分割整个区块链做出了重要的步骤。

支持声明性语言。拥有一组可以以声明方式组合的高级操作，可以轻松定义复杂的智能合约。它还为低级优化提供了机会，加快了合同执行速度。

 

第六节 相关工作

迄今为止，区块链系统的性能研究仅限于公共区块链。例如，[17,15]分析了块大小和网络传播时间对总吞吐量的影响。最近提高比特币性能的建议[27,34,37,25,43]主要集中在共识层，其中分析模型或网络模拟用于验证新设计。以太坊的各个方面，例如它们的块处理时间（用于与其他节点同步）和交易处理时间，也已经进行了基准测试[24,23]。我们使用BLOCKBENCH进行的分析与这些工作的不同之处在于，它是第一个针对数据库工作负载大规模评估私有区块链系统的分析。此外，它比较了两个不同的系统，并分析了他们的设计如何影响整体性能。 BLOCKBENCH的未来扩展将能够对区块链中的关键组件进行更多的比较评估。

 

有许多标准框架可用于对数据库系统进行基准测试。 OLTP-Bench [18]包含标准工作负载，例如TPC-C，用于事务系统。 YCSB [13]包含键值工作负载。 HiBench [32]和BigBench [28]为类似MapReduce的系统提供大数据分析工作负载。 BLOCKBENCH与这些框架具有相同的高级设计，但其工作负载和主要驱动程序专为区块链系统而设计。

 

第七节 结论

在本文中，我们提出了第一个基准测试框架，称为BLOCKBENCH，用于评估私有区块链系统。 BLOCKBENCH包含用于测量数据处理性能的工作负载，以及用于理解区块链不同层的性能的工作负载。 使用BLOCKBENCH，我们用两个宏观基准和四个微观基准对三个主要区块链系统进行了综合分析，即以太坊，Parity和Hyperledger。 结果表明，当前的区块链不适合大规模数据处理工作负载。 我们在软件堆栈的不同层面展示了几个瓶颈和设计权衡。