这是来自于 Hyperledger 性能和扩展性工作组 的第一篇白皮书。这个文档的目的是定义用来衡量一个区块链性能并且能够表述结果的基本的术语以及核心的指标。这个白皮书也是面向这些感兴趣使用业界标准法则的区块链开发者和管理者的一个平台无关的资源。
这里可能会有针对于术语 "区块链" 以及 "分布式账本技术 (DLT)" 有不同的定义，但针对于这个白皮书的目的来说，我们会将这两个词语等同对待，并且会在全文中使用 "区块链" 这个术语。
这个文档提供了一些关于如何选择和评估负载的指南。我们期望这里谈到的这些定义以及新的针对于区块链特定的一些指标的改进在将来会被用来校订该文档。
将来对于这个文档，工作组计划将会更详细地讨论负载的问题并且会提供关于衡量区块链性能的标准流程以及最佳实践的额外的指南。为了给您提供该白皮书的后续版本反馈并且保持更新，请加入 性能和扩展性工作组 。
Hyperledger 是一个开源项目，旨在推动跨行业的区块链技术。这是一项全球合作，包括银行、金融、物联网、制造业、供应链和技术领域的领导者。Linux 基金会是一个通过开源实现大规模创新的非营利组织，来管理 Hyperledger。Linux 基金会还使来自全球的开发者社区能够一起工作，共享想法、基础设施和代码。
本文发布于October 2018. 版本 V1.01
本作品根据 Creative Commons Attribution 4.0 International License 进行授权。
Hyperledger 性能和扩展性工作组感谢以下人员对本文的贡献: Mahesh Adulla (Reddy), Salman Baset, Vipin Bharathan, Gordon Graham, Guy Hochstetler, Imre Kocsis, Todd Little, Dan Middleton, Mark Simpson, Harish Sukhwani, and Mark Wagner.
工作组的目标是确保所有区块链项目的性能和可扩展性都以一种平等、公平的方式度量，采用一致的方式来定义、收集和报告。请注意，PSWG 是向所有人开放的，我们鼓励你贡献你的力量。
虽然区块链可能看起来类似于分布式数据库，但它们通常在没有中央权威机构和中央存储库的情况下实现。因此，相较于中心化系统，区块链有很多新的特性。区块链通过在多个节点上使用冗余检查来避免故障和攻击。它在没有任何中央协调者或中介的情况下横跨整个网络实现/运行的，因此这种弹性远远超出了复制的能力。
在其他一些网络系统(如网络层)中，添加节点可以在更多的资源之间分配工作并提高性能。这在区块链中通常是相反的，在完整性和可用性方面，更多的节点增加了系统的弹性，通常会损耗性能。
例如，在比特币中，最好的情况是，随着节点的增加，整体性能不至于降低。 当我们纵观区块链的时候，即使是这个简单的概念也可能变得复杂。一些区块链特定了节点的角色。在这些系统中，“节点”可能不再意味着具有共享的弹性职责的唯一参与者(比如，一家公司)。
这使得衡量和比较不同区块链之间的性能变得非常困难。为了帮助准确、一致地评估区块链的独特性能属性，本文定义了许多相关术语和指标，并讨论了一些复杂的场景。
当发布任何区块链评估的结果时，我们强烈建议所有报告都包括本文中描述的所有术语、指标和问题的全部细节和限定符。
性能评估 是测量被测系统性能的过程。这种评估可以涵盖系统范围的度量，如响应时间或延迟，或者度量特定的活动，比如将区块写入持久存储的时间。
任何性能评估的目标都是理解并记录被测试的系统或子系统的性能。这通常涉及到测量因变量改变时会发生什么;例如，根据不同的并发请求的数量来度量系统的吞吐量。
基准 是将一个系统与另一个系统或同一系统在以前的测量值进行比较的过程。
基准 一词最初是指用来测量材料标准长度的工作台上的标记，或者测量师用来测量高度的留在建筑物上的切口。 性能基准是一种特定类型的性能评估，通常由标准性能评估公司(SPEC)、安全技术分析中心(STAC)和交易处理性能委员会(TPC)等标准机构制定。这些组织仔细地定义了在测试以及特定的性能度量下，在测试过程中所需要的用于驱动系统的工作负载。
非正式的基准可以用来寻找当系统代码或设计发生变化时对性能的影响。例如，您可以度量系统 3.4 版的性能，然后使用该度量作为基准，来查看 3.5 版的性能是更好还是更差。
一般来说，基准比性能评估更容易控制，因为基准往往运行在一个更标准化的环境中，并且有良好记录的工作负载。如果没有基准，在迥然不同的环境之间进行比较就没有什么意义。
本文将关注区块链性能评估和相关的度量标准，而不是基准。这是行业开发任何正式基准之前必要的第一步。我们期望这个工作组在未来的某个时候开始定义衡量区块链性能的基准。
图1显示了区块链性能评估的典型配置。左侧的测试工具部分显示了用于对右侧的被测系统(SUT)产生负载的程序和系统。图1中的每个术语都在本节中定义。
测试工具 是用于运行性能评估的硬件和软件。这个测试工具通常代表许多客户端，这些客户端可以注入负载并在任意数量的节点上进行观察。
客户端 是可以将工作引入系统或调用系统行为的实体。在区块链系统中，通常在多个层级上有多种类型的客户端。
例如，在使用部署到区块链的智能合约的供应链应用程序中，供应链应用程序是区块链平台的客户端。然而，供应链应用程序的进一步的客户端通常会通过浏览器与应用程序交互。另一个客户端可能是供应链应用程序的审计组件的用户，他会通过电子邮件或SMS消息收到策略违规的通知。
出于本文的目的，我们将关注直接与区块链平台交互的实体，而不是构建在这些平台之上的任何应用程序。
负载生成器客户端 是代表用户向区块链网络(SUT)提交交易的节点，通常遵循自动化测试脚本。客户端和SUT之间的接口可以从简单的 Representational State Transfer (REST) 接口到全面的软件开发工具包 (SDK)。根据接口的不同，客户机可以是无状态的，也可以是有状态的。
观察者客户端 是一个节点，它接收来自SUT的通知，或者可以在SUT查询关于已提交的交易的状态，通常遵循自动化的测试脚本。可以有多个观察者客户端。观察者客户端不能提交任何新的交易。
定义被测试系统(SUT)是一个复杂的问题。在本文档中，SUT被定义为运行和维护区块链所需的硬件、软件、网络和每种网络的特定配置。
SUT不包括客户端api、任何相关的库或任何用于加速读取时间的外部缓存或数据库。
在区块链网络的上下文中，节点是一个独立的计算实体，它与网络中的其他节点通信，共同工作以完成交易。
节点是一个虚拟实体，它可以运行在物理硬件上，也可以作为VM或容器化环境运行。在后一种情况下，一个节点可以与同一网络中的其他节点共享物理硬件。
一组节点可以由同一个组织管理。例如，一个由一家公司运营的挖矿池，其中一组机器作为单独的节点在网络上执行工作证明(PoW)。
在大多数区块链网络(比特币、以太坊、Hyperledger Burrow、Hyperledger Indy、Hyperledger Iroha、Hyperledger Sawtooth)中，每个节点在网络中扮演统一的角色类别，例如生成区块、传播区块等等。在这些网络中，节点通常被称为 peer。这样的网络可能需要一个或多个节点来临时扮演领导者的角色。在某些确定的条件下，这个领导角色可以转交给其他节点。
然而，在一些区块链网络(如Hyperledger Fabric)中，节点被分配一个或多个可能的角色，如背书节点、排序服务或验证节点。
区块链是一项新技术，其命名方法每天都在形成和发展。虽然区块链是分布式数据库的一种新形式，但一些数据库术语在区块链上下文中有略微不同的含义。很多常用的软件术语在描述区块链时有了新的细微差别。本节描述一些用于讨论区块链技术的最常见术语。
在区块链的上下文中，共识是分布式的过程，通过它，一个由节点组成的网络能够提供一个有保证的唯一的交易顺序，并验证交易的区块。
关于Hyperledger的更多细节，请参考 Hyperledger架构工作组的共识白皮书第1卷，这里 。
在传统的数据库中，提交指的是交易写入数据库的时间点。区块链有一个额外的复杂性，即定义何时跨多个节点发生这种情况。通常，一个区块被认为是已经提交的交易的记录，并且当区块在网络中传递并被所有节点接受时，这些交易就被提交了。关于该区块的协议规则是由共识决定的，共识可能有独特的最终规则。
终结性 意味着一旦交易被提交，它就不能被逆转，也就是说数据不能回滚到之前的状态。不同的区块链系统可能提供不同类型的终结性。通常，这是在共识协议中定义的。不同类型的共识是存在的，例如基于投票的即时最终共识和基于彩票的概率最终共识。
为了测试目的，应该设置最终概率的正式阈值。参见附录A了解更多细节。
网络大小 是SUT中参与共识的验证节点的数量。网络大小是指积极参与区块链网络的支持区块链的独特功能的节点总数。
这个计数不应该包括观察者节点，或者不积极参与共识和验证交易的其他节点。
在将共识和验证逻辑分离到不同节点的系统中，网络大小应该用两者中较小的节点数来表示。这是因为系统的弹性(区块链的关键方面)受到较少数量的限制。
例如，部署了单个共识节点但有许多其他类型节点的系统会有单点故障。根据我们的定义，这样的网络的大小为1。
查询是对区块链中包含的数据集运行特别操作或搜索的能力。SUT可能不是以一种高性能的方式来执行这些查询的方式来构建的。
任何链下数据库或支持高效查询的缓存仍然可以测量。但我们假设这些不是区块链的标准部分。因此，查询性能超出了本文档该版本的讨论范围。
读取 操作与交易的不同之处在于没有对状态的更改。读取可以是区块链节点的内部机制，比如在验证交易的过程中获取数据。出于本文档的目的，我们只对定义系统上外部读取的度量感兴趣，例如检索交易或查询余额。在任何特定工作负载中，任何内部读取都是交易度量的隐式部分。
许多部署除了使用一个区块链节点外，还使用其他的系统或层来支持更复杂的查询或提供缓存以提高读取吞吐量。在本文档中，我们只对区块链节点本身提供的原始数据获取感兴趣。
工作负载的定义应该考虑“纯”读操作是否和交易混在一起，以及多大程度的“纯”读取操作跟交易混杂在一起。所有的性能评估报告都应该披露任何外部数据库以及这些数据库是如何配置的。
您可以将大多数区块链系统视为 状态 机，其中每个交易或交易区块都是一个状态转换。状态本身就是数据库在某个时间点上的内容。交易的日志(区块链数据结构)通常不被认为是状态的一部分，而只是状态之间转换的定义。
全局状态 是所有节点共享的状态。注意，并不是所有的区块链系统都实现了全局状态。一些系统出于隐私或其他原因限制信息协议。
一个 交易 是一种状态转换，它将区块链中的数据从一个值更改为另一个值。这些数据可以代表一个资产数量、几个物联网传感器读数，或使用区块链跟踪的任何其他类型的数据。
交易通常由 客户端 提出，然后由区块链系统根据一系列规则(有时称为 智能合约)进行评估。如果有效，系统将 提交 交易，这将使状态更改。
由于附录b中列出的原因之一，一个交易可能无法通过验证。一些区块链系统也将那些无效的交易记录在区块中，但大多数系统不会这样做。在评估区块链的性能时，有效交易的度量更有意义。因此，在计算 吞吐量 时应该减去无效交易的总数。
本节定义了应用于区块链的几个常见指标，以及适当的数学公式。有关区块链上下文中的延迟的进一步讨论，请参阅附录A。请参阅附录C，了解一些有趣但尚未成熟到可以包含在本文档主体中的实验性度量标准。
读取延迟 = 收到响应时的时间 - 提交时间
读延迟是指从提交读请求到收到应答之间的时间。
读取吞吐量 = 读操作总数 / 总时间(秒)
读取吞吐量是对在给定的时间内完成多少读操作的度量，表示为每秒读数(RPS)。这个度量可能是有用的，但它不是区块链性能的主要度量。实际上，系统通常部署在区块链附近，以方便有效的读取和查询。
交易延迟 = (确认时间@网络阈值) - 提交时间
交易延迟是指在整个网络中完成一个交易所花费的时间的一个网络范围的视图。测量包括从它被提交到结果在网络中广泛可用的点的时间。这包括传播时间和由于既有的共识机制而产生的任何确认时间。
考虑到这两个因素并给出网络范围的视图，应该考虑使用SUT中的所有节点来测量这个延迟。Eyal et al 提供了一个很有帮助的定义，定义了网络提交交易的时间百分比1，我们在这里做了一些简化。这个定义的后一部分，即网络的百分比，对于PoW这样的共识协议来说是最重要的。在这样的系统中，可能需要90%这样的阈值，而在PBFT这样的非概率协议中，100%是唯一有意义的阈值。
这个指标是针对每个交易计算的，但在大多数情况下，报告应该提供所有交易的各种统计数据，如平均、高、低和标准偏差。
交易吞吐量 = 已提交的交易总数 / 总时间(秒) @ #已提交节点
交易吞吐量是区块链SUT在指定的时间范围内提交有效交易的速率。注意，这不是单个节点的速率，而是整个SUT的速率，即在网络的所有节点上提交的速率。这个速率表示为以网络大小计算的每秒交易数(TPS)。
请记住，无效交易的总数应该从总交易中减去，以产生总提交的交易。有关如何计算不同延迟示例的进一步讨论，请参阅附录A。
本节讨论在设计任何区块链性能评估时的几个关键考虑事项，包括测试环境、观察点、交易特征、工作负载和故障负载。为了创建一个有效且可以复用的设计，开发人员必须仔细权衡这些考虑因素，清楚地记录他们的决定，并充分报告他们的结果。
这些特征应该作为测试结果的一部分加以注意，因为揭示这些细节可以更容易地比较在不同的平台的性能测试。
试验结果应是独立并且可重现的。为了支持这一目标，所有的环境参数和测试软件，包括任何工作负载，都应该被记录下来并保证可用性。
在评估将要进行性能测试的环境时，以下是一些额外的考虑事项:
- 共识协议。 描述测试过程中使用的共识协议，如RAFT、实用拜占庭容错(PBFT)等。
- 节点的地理分布。 描述网络的物理设置。所有节点是在同一地点还是在地理上分散?如果分散了，那么描述一下如何分散，在分散在哪里。
- 所有节点的硬件环境。 表示处理器速度、内核数、内存等。
- 网络模型。 关于节点之间所使用的网络复杂性的任何信息都可能揭示可能突出的潜在瓶颈。例如，了解要穿越的防火墙的数量和类型。任何一种复杂的网络组件都应该被指出。
- 测试交易中涉及的节点数。 一些区块链平台将交易广播到所有节点，而另一些则将交互限制到节点的一部分(例如Hyperledger Fabric背书节点)。
- 软件组件依赖。 测试或平台是否需要平台或测试本身的任何额外组件才能发挥作用?应该描述所有的组件。
- 测试工具和框架。 描述使用了哪些工具，以及设计了哪些测试框架来生成负载和捕获结果。描述如何驱动测试负载，以及客户端负载驱动程序相对于平台节点的位置。
- 使用的数据存储类型。 数据存储会影响性能，特别是在同时包含读和写的情况下。不同的平台为底层账本数据存储提供可插拔的选择，比如CouchDB、H2、Postgres和主要的供应商数据库。
- 工作负载， 用于生成和验证交易的代码。有关工作负载的进一步讨论，请参阅下面的小节。
这些特征应该作为测试结果的一部分加以注意，因为揭示这些细节可以更容易地比较不同平台的性能测试。
在可能的情况下，应该从位于SUT外部的测试工具的角度进行测量。这将更接近最终用户的观点。当不能做到这一点时，测量点应该被清楚地识别出来。
考虑扩展工作负载入口点。实际上，交易代表了不同节点集之间的异构交互。因此，评估可伸缩性的一个方面是观察当工作负载注入被分散到不同节点(而不是从单个节点入口点)时，平台是如何改进或降级的。
- 复杂性: 智能合约的逻辑计算强度有多大?
- 数据访问模式: 读写模式是否为产品使用的模型?
- 依赖关系: 交易对于您的产品使用有交易和数据的依赖吗?
- 大小: 交易有多大?这对网络中的传播时间有影响。
工作负载定义如何执行SUT。在任何性能测试中，代表实际的生产使用情况的工作负载是至关重要的。例如，如果工作负载只是在数据库中创建新条目，而产品的使用主要是对现有条目的修改，那么工作负载将不会告诉我们有关系统在生产环境中是如何运行的任何信息。
设计工作负载有多种方法。有两个例子是重新执行生产交易和使用预先存在的数据库基准并将它们应用到区块链环境。
我们希望存在多种工作负载，以帮助评估不同类型的使用方式。每个工作负载都应该被通知并且代表了某些生产环境的使用。定义任何特定的工作负载不在本文档的讨论范围之内。
所有的区块链都应该设计成提供账本不可修改性、加密真实性和对错误和攻击的容错性作为核心属性。通过分配额外的资源，可以在系统中启用这些特性。当启用这些特性或出现故障时，系统的峰值性能会降低。
由于许多区块链网络预计都将运行在错误和攻击是常见事件的环境中，因此性能基准应该包括错误甚至恶意的交易。错误加载代表了一组故障和压力条件，模拟了现场实际经历的故障2。
性能基准测试活动应该在与网络运行环境类似的环境中进行。 即使在许可的区块链网络中，环境也会发生变化，从封闭的小规模网络到高度分布式的在公网部署的网络。
本附录描述了三种不同的情况，对于测量区块链中的延迟，它们会产生不同的问题。一种情况具有直接终结，两种情况具有已知和未知拓扑的概率终结。数字仅用于说明目的，并不反映任何特定平台的性能。
采用基于投票的共识的系统具有立即的终结性。一旦交易被提交，该状态就保证是不可撤销的。与其余的用例一样，测试过程应该度量每个节点上的提交，以确保在这个跨分布式系统里已经全部提交了。
图 2:使用PBFT共识的区块链平台的交易流。来源
示例:在运行Min-BFT的10节点网络中，9个节点在11秒后提交一个交易。第10个节点与leader的连接有更高的延迟，需要额外的一秒。该交易在100%的节点上有12秒的延迟。
使用基于彩票的共识的系统具有概率最终性。在受控的性能测试中，拓扑结构是已知的。在大多数许可的部署中可能都是这种情况。在这种情况下，只有当多个节点达到相同的状态时，交易才会被确认。
图 3 描述了使用PoW或消耗时间证明(PoET)等随机领导人选举共识的对于平台的交易流程。这种形式的共识不像PBFT那样有离散回合。然而，图中描述的阶段能够代表概念上的操作:
- 请求 - 客户端向网络提交一个交易。
- 提交 - 一个验证节点将交易以区块的形式发布到网络。
- 分叉 - 零个或更多验证节点无意中发布了相互竞争的区块。
- 处理 - 在收到获胜区块后，其他验证节点处理分叉。
- 一致性 - 后续对任何验证节点的读取都会产生一致的结果。
由于网络的最终一致性是概率性的，因此需要使用网络的百分比作为度量延迟的阈值。
例如:在一个20个节点的网络中，运行PoET, 19个节点在客户端提交交易后的25秒内提交交易。最后一个节点发布一个竞争区块，并在分叉解析期间回滚，造成额外的10秒延迟。表1列出了所有20个节点的提交时间。
如表 2 所示，该交易在95%的节点阈值下有25秒的延迟，在100%的节点上有35秒的延迟。
一家公司可能需要100%的阈值，在这种情况下，所有节点的延迟应该报告为35秒。
这样的系统通常被设计成在一个运行着匿名的“矿工”的不受信任的环境中。只有有限的访问点显示给客户端。在这种情况下，确认应该被延迟，直到足够多的区块被链接到区块/交易后面。
例如，在比特币中，六个区块的延迟通常被认为足以确认交易。性能测试工具可以通过记录每个交易出现的区块来估计这一点。该数据可用于进行百分位分析，因此我们可以估计在某个区块之前提交的交易的百分位，如下面的图4所示。组织可以使用这个度量来评估其交易的风险。
例如:当一笔交易在区块x是最高的时候交易的话，那么在区块(x+ 2)中被找到有50个百分位的概率，在区块(x+5)中被找到有90个百分位的概率，在区块(x+7)中被找到有99个百分位的概率。因此，交易延迟分别为2个块(第50百分位)、5个块(第90百分位)和7个块(第99百分位)。如果块的生成频率可变，这也可以通过时间来显示。
注意，这种度量会随着平均区块大小(kB或每个区块的平均交易数)、出块频率和网络大小而变化。
区块链交易可能被拒绝的原因有很多，包括共识错误、语法错误和版本错误3。
共识错误
- 验证逻辑(Hyperledger Fabric中的VSCC)
- 策略失败(在Hyperledger Fabric的情况下，背书策略不满足)
语法错误
- 无效输入(智能合约id、解组错误等)
- 无法核实的客户端或背书签名
- 重复交易(由于错误或重放攻击)
版本错误
- 通过版本控制(readset版本不匹配，writeset不可写)
对于这份文件的当前版本，我们认为 吞吐量 和 货物吞吐量 是一样的。
由于不同的区块链平台处理共识和交易验证的方式不同，因此很难在不同的平台上对齐错误类型。评估任何交易被拒绝的原因需要对子系统指标进行更深入的分析。虽然这个平台的开发人员可能会感兴趣，但这超出了本文档的范围。
本附录定义了任何可能对区块链性能提供有趣见解的指标，但还没有达到足够成熟的定义，不能包含在本文档的主体中。
性能和扩展性工作组希望得到关于这些实验性指标是否以及如何在企业区块链中使用的反馈。我们也希望这有助于在开发区块链特定指标方面产生一些研究兴趣。
区块链工作 = f(交易吞吐量，网络大小)
区块链工作 是交易吞吐量和验证共识节点数量的函数。该指标旨在以单个数字的方式最完整地表示一个区块链网络完成的工作量。
考虑具有单个节点的区块链:这可以实现高吞吐量，但不能保证可用性或完整性。区块链工作指标提供了区块链性能的有意义的描述，而不仅仅是数据库性能。
在出版时，工作组尚未确定一项理想的功能。一项建议的功能如下:
产品:交易吞吐量 * 日志(网络大小)
- Ittay Eyal, Adam Efe Gencer, Emin Gün Sirer, and R. Van Renesse. Bitcoin-NG: A Scalable Blockchain Protocol. Usenix Conference on Networked Systems Design and Implementation, ser. NSDI’16. Berkeley, CA, USA. USENIX Association. 2016. pp. 45–59.
- Karama Kanoun and Lisa Spainhower. Dependability Benchmarking for Computer Systems. Wiley-IEEE Computer Society Press. 2008.
- Hyperledger Architecture, Volume 1: Consensus
在编写本文时引用了以下资料来源。
Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation. New Orleans, USA. February, 1999.
Kyle Croman, Christian Decker, Ittay Eyal, Adam Efe Gencer, Ari Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin Gün Sirer, Dawn Song, and Roger Wattenhofer. On Scaling Decentralized Blockchains. Financial Cryptography and Data Security. FC 2016. Lecture Notes in Computer Science, vol 9604. Springer, Berlin, Heidelberg. pp. 106–125.
Ingo Weber, Vincent Gramoli, Alex Ponomarev, Mark Staples, Ralph Holz, An Binh Tran, and Paul Rimba. On Availability for Blockchain-Based Systems. IEEE Symposium on Reliable Distributed Systems (SRDS). 2017. pp. 64–73.