论文阅读SBFT：A Scalable and Decentrailized Trust Infrastructure

这篇论文发在Dependable Systems and Networks(DSN) ccf B, 地址附上https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8809541

摘要

SBFT，这是一个最先进的拜占庭容错状态机复制系统，解决了可扩展性、分散性和全球地理复制的挑战。SBFT针对分散化进行了优化，并在超过200个活动副本的部署上进行了实验评估，以抵御控制当恶意节点数量为 f=64 的情况。

通过实验证明了SBFT的不同算法成分如何对其性能和可扩展性做出贡献，相对于实施PBFT协议的高度优化的系统，SBFT同时提供了近2倍的吞吐量和约1.5倍的延迟。

我们将这一性能改进的实现归因于，SBFT的四个设计关键：使用收集器和阈值签名线性地降低了通信耗费；使用乐观的快速路径，减少客户端通信并利用快速路径的冗余服务器。

SBFT是第一个实现正确的双模式视图变化协议的系统，允许有效地运行乐观的快速路径或回退的慢速路径，而不产生视图变化来切换模式。

1 引言

集中式系统能够提供良好性能，却容易遭受单点故障攻击，伴随着比特币和以太坊的出现，激发了对于去中心化的信任基础设置的创新热情。事实上比特币和以太坊没有想象中那么去中心化，排名前20的挖矿联盟控制了90%的算力，说明了一个BFT Quorum系统可以用更低的资源成本实现更好的去中心化。

可以提出一个基于拜占庭的去中心化解决方案吗？如何大规模部署这样的解决方案？

基于拜占庭容错的复制协议，不仅在许可链中至关重要，也是公链的重要技术组件。大量的研究方案[4,38,45,62,66]在探索用BFT替换或者组合现有的工作量证明机制，基本思路是从一个大的节点池中选举一个小的委员会，并让这个小委员会运行一个BFT容错复制协议。在这些方案中，若要保证较高的安全性，委员会的规模需要能容忍这个规模对应的f个恶意节点。

因此需要重新考虑基于BFT的容错算法，这也是我们工作的出发点。

A SBFT

本文提出了SBFT，在PBFT的基础上改进，能够扩展到209个备份节点，承受f=64的恶意节点。通过实验展示了SBFT在PBFT的基础上，能够提供近2倍吞吐量，降低了1.5倍的延迟。

SBFT设计的四个关键是：1.从PBFT到线性PBFT；2.添加了一条快速路径；3.使用密码学允许单个消息确认；4.添加冗余服务器以提高弹性和性能。

1 从PBFT到线性PBFT

之前的系统包括PBFT在内，都是用全对全的消息模式来提交决策块。因此，考虑使用收集器将全对全通信模式简化为线性通信模式。与**其去给每个备份节点发送，不如让每个备份节点向收集器去发送，然后由收集器向所有备份节点广播。**再使用阈值签名[19,20,68,73]，可以将收集器消息的大小从线性减少到常数级别。

Zyzzyya中使用以上的模式减少通信量，它将收集器的责任交给了客户端。考虑到轻量级客户端连通性受限，SBFT中使用轮转的方式将收集器的工作移到了备份节点，并且SBFT使用门限签名减少收集器消息规模和验证总签名的计算开销。SBFT还用了轮转收集器来减少负载以及使用 c+1 个收集器（不是1个）来提升容错，能处理 c 个延迟或者故障的收集器。

2 添加一条快速路径

在AZyzzyyya[11]中，提供了一个快速路径状态机复制协议，并允许切换到慢路径，但不允许同时允许快速路径和慢路径；并且在AZyzzyva中的模式切换需要一个冗长的view-change来更改协议。而SBFT可以在路径之间无缝切换，并调整到network/adversary的条件（无需切换视图）。

3 将客户端通信从f+1降到1

一旦使用了阈值签名，下一步就是使用它们来减少客户端需要接收和验证的消息数量。以前的方案[14,22,48,]都需要接至少 f+1=O(n) 消息，每个消息都需要不同的签名验证和请求确认（f对应n=3f+1的副本数量），这增加了大量的开销。

SBFT通过添加一个阶段，该阶段使用一个执行收集器来聚合执行阈值签名、并向每个客户端发送一个包含一个签名的消息，从而将客户端的线性成本降低到只有一个消息。像公链（eth，btc），SBFT也可以使用Merkle树来有效地验证仅从一个副本中读取的信息。SBFT使用BLS签名，签名长度只有33个字节（安全性相比较于2048位的RSA签名是相当的），通过BLS实现阈值签名要快得多。

4 添加冗余服务器以提高弹性和性能

即便存在f 拜占庭式的故障，SBFT也可以保证安全。为了使快速路径更加普遍，SBFT允许快速路径忍受 n=3f+1+2c 的副本节点（c为崩溃或偏离节点），当超过 c 个错误的复制副本发生，SBFT才会返回到慢路径。

B 评估SBFT的可扩展性

我们将SBFT实现为一个可伸缩的BFT引擎和一个执行EVM智能合约[81]的区块链（见第七节）。我们所有的实验评估都是在全球广域网部署中能够承受 f= 64拜占庭式失败的环境下完成的，为了创建一个baseline，我们花了几个月的时间来显著改进、修复和加固现有的PBFT代码库，以使其在我们的实验设置中可靠地工作，这个工作我们称为优化的PBFT，并将其与SBFT进行了实验比较。

我们首先使用合成工作负载进行标准的键值基准测试实验，从一个规模优化的PBFT开始，然后展示添加每种成分如何有助于提高性能。虽然使用合成工作负载的标准键值基准实验是比较BFT引擎内部的好方法，但我们意识到，像以太坊这样的真实世界区块链具有基于智能合约的非常不同类型的执行工作负载。

我们在真实世界的智能区块链工作负载上进行了实验，以衡量一个更现实的区块链设置的性能。我们的目标不是将被允许的BFT系统与公链的PoW进行比较，这显然不是一个公平的比较。我们提取了大约50万次由以太坊在两个月内处理的智能合约执行过程，实验表明，在一个世界规模的地理复制部署中，有209个副本能够承受=64拜占庭故障，我们获得了每秒超过170个智能合约事务的吞吐量，平均延迟为620毫秒。我们的实验表明，相对于实现PBFT协议的高度优化的系统，SBFT同时提供了几乎2倍更好的吞吐量和大约1.5倍更好的延迟。

我们得出的结论是，相对于以前的BFT解决方案，SBFT更具可扩展性和分散性。相对于像以太坊这样最先进的工作证明系统，SBFT可以以更高的吞吐量、更好的最终性和延迟运行相同的智能合约，并且能够承受200多个副本中的 f= 64的恶意成员。显然，以太坊和其他证明工作系统受益于作为一个公链系统，而SBFT是一个被许可的区块链系统，并将SBFT的集成留在一个无许可系统中，供未来的工作。

贡献

本文的主要贡献是一个BFT系统，它被优化为在数百个副本组上工作，这些副本可以支持在世界规模的地理分布式部署中执行现代EVM智能合同执行。
SBFT通过4种算法成分的组合来获得其可伸缩性：
(1)使用收集器获得线性通信，
(2)添加带有正确视图更改协议的快速路径，
(3)使用收集器和阈值签名减少客户端通信，
(4)添加冗余服务器以提高弹性和性能。
显然，上面提到的成分的某些方面在以前的工作中已经以某种形式出现过；然而，SBFT是第一个正确地将所有这些成分编织并实现到一个高效的系统中的公司；此外，SBFT是第一个使用正确的双模式视图更改协议的部署。

2 系统模型

1.我们假设一个标准的异步BFT系统模型，对手可以控制f拜占庭节点，可以造成整个网络的延迟（特别是我们假设重新传输层，允许对手放弃任何给定包有限的次数）。
为了获得活性和我们改进的结果，我们还区分了两种特殊条件：
2.系统处于同步模式，当对手可以控制多达f个拜占庭节点，但任何两个无故障节点之间的消息有一个已知的有界延迟。
3.系统处于公共模式，当对手只控制一个只能崩溃或动作缓慢的节点，并且任何两个无故障节点之间的消息有一个已知的有界延迟，该模型遵循参数化的FaB Paxos [57]。

对于n个= 3 f + 2c + 1副本，SBFT获得以下属性：
(1)在标准异步模型中的安全性（对手最多控制 f 拜占庭节点和所有网络延迟）。这意味着为给定序列号执行决策块的任何两个副本，执行相同的决策块。
(2)同步模式下的活动（对手最多控制f个拜占庭节点）。粗略地说，活动意味着客户端请求返回一个响应。
(3)公共模式下的线性(对手最多控制一个恒常的c慢/崩溃节点）。
线性是指在一个抽象模型中，我们假设一个块中的操作数量是O (n)，客户端数量也是O (n)，c = O (1)，那么提交一个操作的已摊成本是恒定大小的消息。在更实际的术语中，线性意味着提交每个块需要一个线性数量的固定大小的消息，并且每个客户端发送和接收的每个操作只接收一条消息。

3 现代密码学

我们使用阈值签名，其中对于阈值参数k，来自n个签名者的任何子集都可以协作在任何给定消息上生成有效签名，但没有小于k的子集可以做到这一点。每个签名者都持有一个不同的私人签名密钥，它可以使用它来生成一个签名共享。我们用xi (d)表示签名者i在摘要d上的签名共享。同一摘要d上的任何一个有效签名共享{xj(d)|j(d)|j∈J，|j|=(d)}都可以使用一个公共函数组合成一个单一的签名x (d)，生成一个数字签名x (d).验证者可以使用单个公钥来验证此签名。我们使用了鲁棒的阈值签名方案，这意味着签名者可以有效地从恶意参与者中过滤出无效的签名共享。

我们使用了一个基于BLS签名的鲁棒阈值签名方案。在已知阶的椭圆曲线组上使用配对建立了BLS签名。与具有相同安全级别的RSA签名相比，BLS签名要短得多为33字节，而2048位RSA需要256字节。对比于“在指数中”的插值来创建和组合RSA签名共享需要几个昂贵的操作，BLS阈值签名允许直接插值，而没有额外的开销。与RSA不同，BLS签名共享支持批验证，允许以验证几乎相同的成本只验证一个签名。

我们假设一个有计算边界的对手，到2019年还不能对加密哈希函数SHA256和基于BLS BN-P254 [15]的签名上比已知的攻击做得更好。我们在客户机和复制副本之间使用PKI设置来进行身份验证。

4 服务属性

SBFT提供了通用复制服务（即状态机复制服务）的可扩展的容错实现。除此之外，我们实现了一个经过身份验证的密钥值存储区，它使用Merkle树接口来进行数据身份验证。在此基础上，我们实现了一个能够运行EVM字节码的智能合约层。这种分层的体系结构允许我们在未来集成其他智能合约语言，只需将它们连接到通用的经过身份验证的密钥值存储，并允许更好的软件重用。

通用服务

作为一个通用复制库，SBFT需要以下服务接口的实现作为初始化参数。该接口通过状态、确定性操作和只读查询实现任何确定性复制服务，执行val = execute（D，o）根据操作o修改状态D并返回输出val。通过查询变量val=（D，q）返回给定状态D的查询序列值q（但不更改状态D）。这些操作和查询可以对状态执行任意的确定性计算。

服务的状态以离散块的形式移动，每个块都包含一系列的请求。我们用Dj表示序列号j末尾的服务状态，用reqj表示块j的操作级数，它将状态从状态Dj−1变为状态Dj。

一个经过身份验证的密钥值存储区

我们实现的基本服务是一个键值存储。为了支持来自一个复制副本的高效客户机确认，我们使用数据身份验证接口增强了密钥值存储。与在公链一样，我们使用Merkle树接口来验证数据，为了提供数据身份验证，我们需要实现以下接口： **(1) d =digest(D)**返回D的Merkle哈希根作为摘要。(2) **P = proof（o、l、s、D、val）**返回一个证明，证明操作o在决策块中系列请求的序列号为s，其状态为D，该操作的输出为val。对于密钥值存储，输入操作的证明是Merkle树证明，证明输入操作作为序列号请求中的第l个操作进行。对于只读查询q，我们编写P=proof（q，s，D，val），并假设所有这些查询都是针对D（完成序列号s后的状态D）执行的。对于键值存储，一个get操作的证明是一个Merkle树证明，证明在序列号为s的状态下，所需的变量具有所需的值。(3) 验证（d、o、val、s、l、P）返回真iff P是一个有效证明，操作序列编号s和执行后的结果状态这个决策块执行的digesst of d 和val操作的返回值o（同样验证（d，q、val、s、P）当q是一个查询）。对于上面的一个密钥值存储区和一个put操作，验证是植根于digest d（Merkle哈希根）的Merkle证明验证。

智能合约引擎

我们在复制的键值存储的基础上构建了一个能够执行以太坊智能合约的层。这种分层的体系结构允许我们在未来集成其他智能合约语言，只需将它们连接到通用的经过身份验证的密钥值存储，并允许更好的软件重用。EVM层由两个主要组件组成： (1)以太坊虚拟机（EVM）的实现，它是合约的运行时引擎；(2)一个接口，用于将两种主要的以太坊事务类型（合约创建和合约执行）建模为我们的复制服务中的操作。

只能合约是用一种名为EVM字节码的语言编写的，这是一种基于图灵完整的堆栈的低级语言，具有为以太坊平台设计的特殊命令。键值存储区保持分类帐服务的状态。特别是，它保存了合约的代码和合约的状态，EVM字节码是确定性的事实确保了新状态摘要在所有非错误副本中是相等的。

5 SBFT复制协议

我们维护了一个n = 3 f + 2c + 1的副本，其中每个副本在{1，…，3 f + 2c + 1}中都有一个唯一的标识符。一个标识符 i 的副本存储三个秘密σi、τi、πi对应三个阈值签名方案：σ（3f+c+1），τ（2f+c+1）和π（f+1）。

我们采用了[22]，[65]的方法，其中副本使用视图更改协议从一个视图移动到另一个视图，在视图中，一个副本是主副本，其他副本是备份，主副本负责对一系列提议进行发起决策。与PBFT不同，一些备份副本可以具有作为提交收集器和或执行收集器的其他角色。在给定的视图和序列号中，c+1个非主副本被指定为c收集器（提交收集器），c+1非主副本则被指定为E收集器（执行收集器）。这些副本负责收集阈值签名，组合它们并传播生成的组合签名。为了保持活力，需要一个正确的收集器。我们使用c+1收集器在快速路径中实现冗余（受RBFT启发），假设c是一个小常数（对于n≈200，我们将c设置为0，1，2，8，f=64）时，这将最坏情况下的消息复杂度增加到O（cn）=O（n）。实际上，我们错开了收集器，所以在大多数执行中，只有一个收集器处于活动状态，而其他收集器则处于空闲状态。

该算法在快速路径中的工作如图1（n=1，f=1，c=0）
1.客户端跟主节点发送请求
2.主决策块收集客户端请求，创建一个决策块，并将这些块作为预准备消息转发给副本
3.副本使用其签名（3f+c+1）对决策块进行签名，并向服务器收集器发送签名共享消息
4.每个c收集器收集签名共享，并将它们组合起来，为决策块创建一个简明的提交证明（full-commit-proof），并将其发送回副本。单个消息提交证明具有固定大小的开销，包含单个组合签名，足以让副本去提交。

234步要求线性消息复杂度（c为常数时），并替换以前的解决方案的二次消息交换，通过为每个决策块选一个不同的c收集器组，我们平衡了所有副本的负载。

一旦副本收到提交证明，它就提交决策块。然后，该副本将启动执行协议：
1.当副本完成执行提交的决策块之前的块序列时，它执行决策块中的请求，并使用其π（f + 1）阈值签名签名新状态的摘要，并向E-收集器发送签名状态消息。
2.每个E-收集器收集签名共享，并为决策块创建一个简洁的完全执行验证。然后，它将证书发送回副本，表明该状态是持久的，并将证书发送回客户端，表明其操作已执行。

此单个消息具有固定大小的开销，它包含单个签名，并且足以确认单个客户机的请求。
12两步为每个客户端提供每个请求的单条消息和请求证明。所有以前的解决方案都要求每个客户端的每个请求确认都有线性数量的消息。当客户机的数量很大时，这是一个显著的优势。通过为每个决策块选择一个不同的E-收集器组，我们将主要领导层、C-收集器和E-收集器的总体负载分散到所有副本中。

A 客户端

每个客户端k维护一个严格单调的时间戳t，并通过向它认为主要的<“request”，o，t，ki>来请求操作。然后，主节点将消息发送到所有副本和副本，然后使用协议算法。以前的系统要求客户端等待+1回复以接受执行确认。在我们的算法中客户端等待一个回复<“Execute-ack”，s，val，o，π(d)，proof（o、l、s、D、val）>我从一个副本，并接受val响应执行o通过验证证明（o，l，s，val）是证明o执行的决定块操作，导致状态的序列号是年代，o的返回值是val，d的摘要是d。这是通过检查Merkle证明验证（d、o、val、s、l、proof（o、l、s、D、val））=为真来完成的，并且π(d)是D的有效签名（当o长时，我们只发送o的摘要）。

在接受执行攻击消息时，客户端将o标记为已执行的，并将val设置为其返回值。与以前的协议一样，如果客户端计时器在接收执行程序之前过期，客户端将请求重新发送给所有副本（并请求f+1确认路径的PBFT样式）。

B 副本节点

每个副本的状态包括一个按序列号、视图号和消息类型排序的可接受消息的日志。该状态还包括当前视图号、最后一个稳定序列号ls（参见第V-F节）、应用所有已提交请求后的服务D的状态。我们还使用了一个已知的常数，以限制未完成的方块的数量。回想一下，每个副本都有一个标识i∈{1，…，n}，用于确定三个签名共享： σi为3f++1阈值方案，τi为2f++1阈值方案，πi为f +1阈值方案。复制副本之间的所有消息都是通过经过身份验证的点对点通道发送的（实际上使用TLS 1.2）。

**如下所述，副本可以作为主（领导）、C-收集器（提交收集器）或E-收集器（执行收集器），给定视图的主视图以循环的方式选择，作为视图的函数；它还存储当前序列号给定视图的c收集器和e收集器，序列号从所有非主副本中选择为伪随机组（大小为c + 1），作为序列号和视图1的函数。**对于回退的Linear-PBFT协议，我们总是选择主协议作为最后一个收集器。
C收集器的作用是收集提交消息，并将（组合的）签名发送回副本，以便它们拥有已提交块的证书。
执行收集器的作用是收集执行消息，并将一个（组合的）签名发送回复制副本和客户端，以便它们都有一个执行其请求的证书。

快速路径

快速路径协议是默认的执行模式，当系统同步且最多有c崩溃/慢的复制副本时，保证取得进展。

要提交一个新的决策块，主协议将启动一个三阶段的协议：预准备、签名共享、提交证明。在预准备阶段，主服务器将其决策块转发给所有副本。在签名共享阶段，每个副本i使用σi为请求签名并将其发送给c收集器。在提交验证阶段，每个c收集器生成一个决策的（组合）签名，并将其发送给所有副本。

预准备阶段：如果操作o通过了静态服务身份验证和访问控制规则，则主节点接受来自客户端k的h“request”、o、t、ki。注意，这是一个状态独立的测试，可以通过重新配置视图来更改。

在接受至少b≥batch 客户端消息（或达到超时）设置r=（r1…，rb）客户端请求块和广播<“pre-prepare”，s，v，r>所有3 f + 2c + 1副本的s是当前序列号，v是视图号码。参数批处理通过第七节中描述的自适应算法进行设置。

签名共享阶段：如果(1)副本的视图等于v，则副本接受<“pre
-prepare”、s、v、ri；(2)没有接受序列s的“pre-prepare”；(3)序列号s在ls和ls+win之间；(4)r是通过身份验证和访问控制要求的一系列有效操作。

在接受一个预先准备的消息后，副本i计算h = H（s||v||r），其中H是一个加密哈希函数（SHA256）。然后符号h通过计算一个可验证的阈值1随机选择主要和收集器提供弹性对一个更自适应的对手是可行的，但不是当前实现的一部分签名σi (h)和发送<“sigh
-share，s，v，σi(h)>c收集器c收集器(s、v)。

提交证明阶段：（s，v）的C收集器接受副本i的h“sign-share”，s，v，如果(1)它的视图等于视图；(2)副本i没有接受以前具有相同序列的“sign-share”；(3)可验证的阈值签名σi (h)通过验证。

当C收集器接受3f+1不同的签名共享消息时，它形成一个组合签名σ(h)，然后向所有副本发送h“full-commit-proof”、s、v，σ(h)i。

提交触发器：一个副本接受h“full-commit-proof”，s，v，σ(h)i，如果它接受h“pre-prepare”，s，v，r，hi，其中h = H（s||v||r）和σ(h)是h的有效签名,在接受完全提交证明消息时，副本提交r作为序列s的请求。

D. 执行和确认

我们的执行算法与以前的工作的主要区别是使用了阈值签名和单个客户端响应。一旦一个副本有一个连续的提交决策块序列，它就参与一个两阶段协议：签名状态、执行验证。粗略地说，在符号状态阶段，每个副本i使用πi，f+1阈值签名，并将其发送给C收集器。在执行验证阶段，每个C收集器都会生成一个简洁的执行证书。然后，它将此证书发送回副本，并向每个客户端发送一个证书，表明其操作已执行。

E 线性PBFT

这是一种后退协议，可以在快速路径无法前进时提供进度。该协议是对PBFT的一种适应，优化后使用阈值签名和线性通信，通过在中间阶段使用主协议作为收集器和作为承诺收集和执行收集的回退收集器，避免了所有对所有的通信。为了保证主服务器无故障时的进展，我们使用c + 1收集器并交错使用收集器，以便要激活的c + 1收集器始终是主服务器。最坏的情况通信是O（cn），当c是常数（如c = 2)时，为O (n)。特别是，选择c = 0可以保证O (n)消息（仍然可以在快速路径中有更多的收集器）。

线性PBFT中，我们不是使用主消息向所有副本广播消息，而是使用主消息作为单个收集器（或使用c +1收集器作为一个小常数c≤2）来将阈值签名合并为单个签名消息。这将消息的数量和公钥操作减少为线性操作，并使每个消息只包含一个公钥签名。我们称此操作为广播通过收集器：每个副本只将其消息发送给c+1收集器，每个收集器等待聚合一个阈值签名，然后将其发送给所有副本。

F 垃圾收集和检查点协议

序列s处的决策块可以有三个状态：(1)已提交—至少一个无故障的副本已提交；(2)已执行—至少一个无错误的副本已将所有块提交给s；(3)稳定—至少f + 1无错误的副本已执行。

当序列s处的一个决策块是稳定的，我们可以垃圾收集所有以前的决策。和在PBFT中一样，我们定期（每个win/2个 slots）执行一个检查点协议，以更新最后一个稳定的序列号。

为了避免二次PBFT检查点协议的开销，更新ls的第二种方法是添加以下限制。当s在le和le +（win/4）之间时，副本只参与序列s的快速路径，其中le是最后执行的序列号。使用这个限制，当一个副本在快速路径上提交时，它设置ls：=max{ls，s−（win/4）}。

G 视图切换协议

视图更改协议处理了具有两种提交模式：快速路径和LinearPBFT的复杂性。具有[11]、[40]、[48]、[57]等两种模式的协议必须仔细处理这两种模式都提供的要采用的值，并且必须明确地选择正确的模式。SBFT实现了一个新的视图更改协议，该协议在处理两种并发模式的挑战的同时，同时保持了安全性和活力，SBFT的视图变化已经被仔细地执行，严格地分析和测试。

视图更改触发器：当计时器过期或收到主副本错误的证明时（通过公开可验证的矛盾或当f+1副本时）触发视图更改。

查看-更改阶段：每个副本i维护一个变量ls，这是最后一个稳定的序列号。它准备值xls，xls+1，…，xls+win如下。将xls = π（dls）设置为序列为ls的状态上的有符号摘要。对于每个ls < j≤ls + win集xj =（lmj，f mj）是一对如下的值：

新视图阶段：新主节点收集2 f +2c+1视图来自副本的更改消息。新主节点通过发送一组2 f +2c+1视图更改消息来启动新视图。

接受一个新视图：当一个副本接收到一组I的|I| = 2 f +2c+1视图更改消息时，它会逐个处理插槽。它从ls开始，所有视图更改消息中最高有效稳定序列号，上升到ls+win。对于每个这样的插槽，一个副本要么决定它可以提交一个值，要么根据下面的算法，它将其作为新主节点的预准备值。

安全值：如果新主节点唯一安全的事情是为新视图中的序列槽提出y，那么准备y对于序列槽是安全的。粗略地说，就像在PBFT中一样，req∗将只是与具有最高视图v∗的准备消息相关联的值（如果它存在的话）。如果有大于+∗的视图的+1预准备消息，那么req0将是与最大值关联的唯一值（如果存在的话）。如果req0存在，则y采用其值。否则，如果req∗存在，则y采用其值。否则将采用特殊的不操作。

6 安全性和活性

SBFT是安全的，因为视图改变协议在快速路径和线性-PBFT路径上都采取最大的视图。

由于FLP的存在，SBFT在异步模式下缺乏灵活性。在同步模式下，通过在当前视图中取得进展和移动到新的视图之间取得平衡，可以获得灵活性。

定理六 1.如果任何两个无错误的副本在给定序列号的决策块上提交，那么它们都在同一个决策块上提交。

从概念上讲，证明方法很简单：修复一个插槽，并考虑第一个视图，其中一些无错误的复制副本已经提交了一些值req，并证明在以后的任何视图中，视图更改所选择的唯一可能的值是req。粗略地说，如果一些无故障的副本通过LinearPBFT路径提交，那么就像PBFT一样，任何视图更改仲裁都是安全的，因为它将包含一个请求∗=请求的准备消息，它将有最大的视图v∗。如果一些没有错误的复制提交通过快速路径，那么任何视图更改仲裁将安全，因为它将包括f +c+1预准备消息请求0=请求足够高的视图是独特的最大（或更高的准备消息将存在，但通过感应这将是请求）。

我们的视图更改协议在两条路径上获得最大的视图（并对Linear-PBFT路径提供视图优先级），这是提供安全性的关键。

安全证明的完整版本出现在本文[39]的扩展版本中。SBFT是确定性的，因此由于FLP [36]，它在异步模式中缺乏活力。在PBFT [22]中，活力是通过在当前视图中取得进展和移动到新视图之间取得平衡来获得的。SBFT使用了PBFT [22]的技术： (1)指数后退视图更改计时器；(2)副本如果听到f +1副本发出视图更改，则会发出视图更改；(3)即使f或更少的副本发送视图更改，视图也可以继续取得进展。最后，SBFT使用c+1收集器在快速路径上取得进展。在公共路径中，我们确保其中一个收集器是主收集器。

一个没有故障的主节点只需要等待最多 n−f 的消息被接受，以便在公共路径和视图更改中都取得进展。因此，我们的协议不仅明显没有死锁，而且是反应性[33]，这意味着在GST（全球稳定时间；即，当系统移动到公共模式）时，它以最快的n−f副本的速度取得进展，并且不需要等待最大的网络延迟。

我们仍然需要表明，在一个无故障的初级GST后已经取得了进展。同样，这是一个相对标准的论点，并遵循了在公共模式中，主节点也是一个收集器的事实。

最后，我们注意到视图更改协议的活性遵循以下模式：主协议基于有签名的消息（它的证明）做出决策，然后转发决策和有签名的消息（它的证明），这样所有副本都可以重复完全相同的计算。

7 SBFT实现

SBFT是用C-++11编写，被设计为一个通用库，可用于表示各种分布式状态机，它可以用于表示和管理以太坊状态机。

密码学
密码学原语（RSA 2048，SHA256，HMAC）使用密码学++库[30]实现。为了实现阈值BLS，我们使用BN-P254 [15]椭圆曲线，它提供了与2048位RSA相同的安全性（即110位安全性），即使最近在离散日志攻击[12]，[60]上的发展。为了减少与组合基于阈值BLS的共享（在收集器中）相关联的延迟，我们并行化了独立的指数，并使用了一个后台线程。在快速路径中，只要没有检测到故障，我们就使用BLS多签名（n-out-n阈值），它比BLS阈值签名需要更少的计算，我们实现了一种基于近期历史自动切换到多签名和阈值签名的机制。

动态超时
超时是通过测量系统的实际行为来动态地学习和调整超时的。例如，用于启动Linear-PBFT路径的超时时间是基于成功完成快速路径所需的平均时间（和标准偏差）。另一个例子是客户端重新传输超时——这些超时是基于请求的平均执行时间（从客户端的角度来看）。这种方法使SBFT能够自动地适应不同的网络环境（如第八节中提到的那些环境）。

并行性和批处理
在SBFT中，可以并行地处理几个决策块。这种方法允许处理新的客户端请求，而无需等待以前的客户端请求的完成，可以并行处理的最大决策块数是win = 256。

我们使用自适应学习启发式方法，动态地修改参数批处理的大小，该参数批处理表示每个决策块中客户端操作的最小数量（批处理在V-C节中使用）。我们的启发式方法的目标是同时优化延迟和吞吐量。
它基于三个参数： (i) recPar表示系统的最大推荐并行度（recPar是SBFT配置的一部分）；（ii）最大等待表示最近历史中（不同的）等待客户端请求的最大数量；（iii）curPar是当前处理的决策块的数量。批的值确定如下：如果curPar = 0，那么批=1，否则批=最大等待÷recPar。这种启发式确保在没有处理决策块时系统永远不会等待新的请求。当curPar > 1时，系统将努力将客户端请求划分到recPar决策块之间。

状态传输
与最初的PBFT实现类似，SBFT通过使用状态传输机制来同步陈旧副本的状态。该机制旨在从其他副本中获取状态的缺失部分，并使用基于Merkle树的数据结构来识别差异。

区块链智能合约实现
所使用的EVM实现是基于cpp-以太坊[29]。我们将与存储相关的命令与键值存储界面集成，并使用RocksDB [71]作为其后端。

8 性能评估

我们通过在一个广域地理分布式网络上部署200个副本来评估SBFT，所有实验都配置为能够承受 f= 64拜占庭故障。Zyzzyva [48]的代码包含一个严重的安全违反[2]，并且不包含一个状态传输模块。ByzzCoin[45]、[77]和[77][46]都有GitHub存储库，但只报告了模拟结果。其他项目，如Algorand [38]，只有模拟，而没有开放源代码。

我们花了几个月的时间显著地改进、修复和加固了现有的PBFT代码库，以使它在我们的实验设置中可靠地工作。我们称之为实现规模优化的PBFT。我们通过扩展和改进现有的PBFT代码库来实现规模优化的PBFT。特别是，我们将加密图形原语从更改为现代原语，将通信修改为基于TCP以支持WAN，修复了几个可伸缩性瓶颈，并添加了第七节中描述的SBFT优化。我们注意到Sousa等人[74]使用了一个名为BFT-SMaRt [14]的PBFT实现，但是BFT-SMaRt似乎并不支持运行EVM合同。而我们的基线规模优化的PBFT被调整，以提供更好的可伸缩性。

在我们的实验中，我们从规模优化的PBFT实现开始，然后展示了4种成分中的每一种如何提高性能如下： (1)线性PBFT降低通信，提高吞吐量，但牺牲延迟；(2)增加快速路径减少延迟；(3)使用加密学允许单一消息确认提高性能；(4)增加冗余服务器以提高弹性，提高了延迟-吞吐量的权衡。

对于微基准测试，我们使用来自以太坊的50万笔真实交易来测试SBFT账本协议，复制副本通过运行EVM字节码并在磁盘上持久化该状态来执行每个合同。每个客户端通过将事务批处理成12KB的块来发送操作（平均每批大约有50个事务）。我们在大陆规模的广域网和世界规模的广域网上进行了这些实验。我们的性能评估是对0、8和64个副本故障进行的。我们将一个失败的复制副本建模为无响应的。我们进行了大量的测试，以验证恶意复制活动基本上被转换为无响应行为。

我们比较了以下复制协议：(1)PBFT（基线）：PBFT的规模优化实现。(2)Linear-PBFT（添加成分1）：对PBFT的一种修改，通过使用收集器避免了二次通信。(3)快速路径+线性PBFT（添加成分1和2）：线性-PBFT添加了一个快速路径。(4) SBFT与c=0（添加成分1、2和3）： LinearPBFT添加快速路径和执行收集器，允许客户端接收签名消息确认。(5)使用c=8的SBFT（添加所有4个成分）：添加冗余服务器，以更好地适应网络差异和故障。

关键价值基准评估
关键值基准测试的结果如图2和图3所示。我们首先观察到，与我们的规模优化PBFT相比，当系统负载（128到256个客户端）时，线性PBFT协议提供了更好的吞吐量（每秒2kvs每秒1.5k）。较小的影响也出现在没有批处理的情况下。我们得出的结论是，通过使用收集器将通信从二次通信减少到线性通信，可以显著提高吞吐量，但需要花费一些延迟。

为线性-PBFT添加快速路径显著将吞吐量提高到每秒2.8k，如预期的那样，快速路径在无失败执行中提高了延迟和吞吐量，但在出现故障时并没有帮助。

添加一个执行收集器允许客户端只接收一条消息（而不是f + 1）。这显著提高了所有场景（无故障和有故障）中的性能（延迟吞吐量权衡）。这表明，从服务器到客户机的通信是一个重要的性能瓶颈。最后，通过参数化c = 8的SBFT，我们展示了添加冗余服务器的效果。毫不奇怪，当c=8出现故障时，它会产生很大的影响。

此外，我们在f = 0和f = 64的病例中看到了显著的优势。这可能是因为添加冗余减少了略慢的服务器或惊人的网络链接的差异和影响。

智能合同的基准评估
在大陆规模的SBFT同时提供了2倍更好的延迟和几乎2倍更好的吞吐量。在世界规模的广域网实验中，SBFT获得了每秒172个事务，中值延迟为622毫秒。规模优化的PBFT获得了每秒98个事务，中值延迟为934毫秒。我们得出的结论是，在世界范围内，SBFT同时提供了近2倍更好的吞吐量和约1.5倍更好的延迟。

我们注意到，仅仅在单台计算机上执行这些智能契约（并将结果提交到磁盘），而不运行任何复制，就可以提供每秒基线840个事务。我们的结论是，添加一个大陆规模的WAN 200节点复制，SBFT获得了相对于基线2倍的减速。添加世界规模的WAN 200节点复制，SBFT获得相对于基线5倍的减速。

查看-更改开销
为了评估视图更改协议的开销（不受其超时的影响），我们运行智能契约基准测试，并每60秒更改一次视图。在大陆规模的实验中，SBFT获得了每秒369个事务，中值延迟为257毫秒（小于2.5%的开销）。在世界规模的实验中，结果是每秒165个事务，中值延迟为672毫秒（约4%的开销）。

9 相关工作

拜占庭容错性（BFT）最早由Lamport等人[50]提出。Rampart [69]是第一批考虑使用BFT进行状态机复制[49]的系统之一。SBFT是基于许多旨在使BFT实用的进展。PBFT [22]、[23]和BASE [72]的扩展框架提供了许多SBFT构建的基础、框架、优化和技术。SBFT使用了基于Yin等人[82]的将承诺和执行分离的概念性方法。我们的线性信息复杂度快速路径是基于Zyzzyva [47]，[48]的技术及其理论基础[57]。我们使用的混合模型为c≤f故障提供了更好的特性，该模型的灵感来自于Martin和Alvisi [57]的参数化模型。Up-Right [25]研究了一个不同的模型，该模型假设了许多遗漏的失败和一些拜占庭式的失败。西哥特的[67]进一步提倡利用数据中心的性能可预测性和相对同步性。XFT [55]专注于一个限制对手控制异步和恶意复制的能力的模型。相比之下，即使在完全异步模型中，当不到三分之一的副本是恶意的时，SBFT也能提供安全性。Prime [5]增加了额外的预轮，以保证客户高度公平。SBFT提供了与PBFT中相同类型的弱公平性保证；我们将向SBFT添加更强的公平性属性的问题留给了未来的工作。

A2M [24]，TrInc [51]，维罗内塞等人[79]，Hybster [13]使用安全硬件获得毫不含糊。它们提供了一个拜占庭式的容错复制，这在异步模型中是安全的，即使在n = 2 f + 1。CheapBFT [44]依赖于一个基于FPGA的可信子系统来提高容错能力。此外，Troxy [52]还使用了安全的硬件来减少客户端开销。SBFT不对安全硬件做出假设，因此受到n≥3 f + 1下界[35]的限制。我们对公钥密码学（与MAC向量相反）和阈值签名的使用遵循了[20]的方法（也见[6]，[7]，[26]）。我们严重依赖于阈值BLS签名[16]，[17]。最近的几个系统提到，他们计划使用BLS阈值签名[46]，[59]，[76]，[77]。

基于主备份的状态机复制方法的另一种替代方法是使用拜占庭式的仲裁系统[56]，并使每个客户端成为一个提议者。该方法由QU [1]和HQ [28]采用，在写争用较低时提供了良好的可伸缩性。SBFT遵循主备份范例，通过指定的主领导者传递多个请求。这使得SBFT可以从批处理中获益，而这对于大规模多客户端场景中的吞吐量至关重要。

最近的工作旨在提供更好的活力保障。Honebadger[63]是第一个利用随机化来规避FLP [36]不可能的BFT系统，和最近的BEAT [32]提供了活力，即使网络是完全异步的，并由一个对抗性的调度器控制。SBFT遵循DLS/Paxos/视图戳复制范式[33]，[49]，[53]扩展到拜占庭错误，只有在网络同步时才能保证活动。

Algorand [38]提供了一个无许可的系统，可以支持数千个副本，并实现一个BFT引擎，该引擎选择一个大约2000个活动副本的随机动态委员会。然而，它的可扩展性仅在一个广域网的模拟中进行了评估。即使在最佳情况下的无故障模拟条件下，Algorand似乎提供了比SBFT（600毫秒）慢近100倍的延迟（60秒）。SBFT在一个真实的世界规模的地理复制广域网部署中进行了实验评估，执行真实的智能合同，维护完整的状态和测试故障场景。

FastBFT [54]与SBFT的许多特性相同，它还关注于PBFT的一个线性版本和一个单一的消息客户端确认。FastBFT以一种可伸缩的方式分散了信任，但它依赖于安全的硬件，并通过依赖于单个硬件供应商的安全性，从本质上集中了其安全假设。FastBFT的性能仅在局域网上进行评估。SBFT不假设可信的硬件，也不依赖于任何单一的硬件供应商。

10 总结

我们实现了SBFT，一个最先进的拜占庭容错复制库，并通过实验验证了它为广域地理分布式部署上的大型部署提供了更好的性能。当存在数十个恶意副本时，SBFT表现良好，它的性能优势会随着客户机数量的增加而增加。我们的实验表明，我们的每一个算法成分都提高了测量的性能。与实现PBFT协议的高度优化的系统相比，对于大约200个副本，SBFT同时提供了几乎2倍更好的吞吐量和大约1.5倍更好的延迟。

我们已经证明了SBFT可以与数百个副本一起稳定部署，并能承受数十个拜占庭式的失败。我们相信，线性协议（如SBFT）比二次协议的优势在更高的尺度上将会更加深刻。测量能够承受数百次拜占庭式失败的数千个副本的实际部署超出了这项工作的范围。SBFT的开源版本可以在Github上找到，作为VMware的项目协和[27]。开源版本被设计用以支持广泛的分布式应用程序，它包括额外的优化和各种软件工程扩展。