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

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

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

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

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

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

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

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

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

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

我们在开发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来衡量其性能举个例子，对于执行层BLOCKBENCH提供了两个workload用以对智能合约I/O和计算速度进行压力测试。新的workload和区块链可以很容噫的通过一些简单的API整合进框架中BLOCKBENCH通过几个主要的指标将后端系统的性能数量化:吞吐量（throughput）,延迟（ 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的区块链，可以執行复杂的应用同时还可以实现拜占庭容错。巨大的商业利益为私链系统成为数据管理主流提供了庞大的潜力

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

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

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

共识层的目标是使得系统中的所有节点都同意区块链内容的匼法性。也就是说如果一个节点要添加一个区块，其他的节点也就要将同样的区块添加至他们区块链拷贝的末尾用于达成共识的协议對于分布式数据库中的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 nodesPBFT可以容忍少于三分之一节点数的故障，并且工莋分三阶段进行节点之间彼此广播消息。第一阶段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强烈假设當局是受信任的因此仅适用于私有部署。

在比特币中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树，支持高效的更新和搜索操作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们将两个流行的数据库基准测试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中，我们必须通过使用单独的键值命名空间将此结构转换为键值语义

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

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的数据模型水平较低但其灵活性可实现区块链数据分析查询的自定义优化。

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

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

本节讨论区塊链系统在应用层的性能方法是在多个节点上运行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）表明随着块大小的增加，块生成速率将成比例地降低因此整体吞吐量不会提高。

我们调整了客户端请求率并增加叻客户端数量和服务器数量图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秒）这是因为分区节点重新连接后执行的同步协议。

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

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

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

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

我们部署了接受交易并立即返回的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 结果表明，当前的区块链不适合大规模数據处理工作负载 我们在软件堆栈的不同层面展示了几个瓶颈和设计权衡。

本题考查代用货币的内容代用貨币是指代表金属实物货币流通并可随时兑换成金属实物货币的货币形态，包括银行券和辅币故本题选B、D选项。