DispersedLedger是一种新型异步拜占庭容错(BFT)共识协议，专为广域网设计。通过解耦区块提议与下载过程，实现了在可变带宽网络条件下近乎最优的吞吐量。实验证明，与HoneyBadger相比，DispersedLedger的吞吐量提高2倍，延迟降低74%。
文章目录
- DispersedLedger：可变带宽网络上的高吞吐量拜占庭共识
摘要
区块链的成功引发了人们对在广域网上大规模部署拜占庭容错 (BFT) 共识协议的兴趣。这种网络的一个核心特征是跨节点和跨时间的可变通信带宽。我们提出了 DispersedLedger，这是一种异步 BFT 协议，可在存在这种可变网络带宽的情况下提供近乎最佳的吞吐量。 DispersedLedger 的核心思想是使节点能够提议、订购和同意交易块，而无需下载其全部内容。通过使节点能够就区块的有序日志达成一致，并保证每个区块在网络中可用且不可延展，DispersedLedger 将不同节点的带宽密集型区块下载解耦，允许每个节点以自己的速度取得进展。我们构建了一个完整的系统原型，并在真实世界和模拟网络上对其进行评估。我们在 Internet 上的地理分布式广域部署的结果表明，与最先进的异步协议 HoneyBadger 相比，DispersedLedger 的吞吐量提高了 2 倍，延迟降低了 74%。
1 简介
状态机复制（SMR）是构建容错分布式系统的基础任务[25]。 SMR 使一组节点能够就命令（或事务）的复制日志达成一致并执行。随着加密货币和区块链的成功，拜占庭容错 SMR (BFT) 协议近年来引起了极大的兴趣 [2, 5, 7, 15, 31, 39]。这些协议的部署环境与标准 SMR 用例有很大不同。区块链应用程序中的 BFT 实施必须在广域网 (WAN) 上运行，可能有数百到数千个节点 [2, 18, 31]。
与跨数据中心几个节点的传统 SMR 部署相比，大规模 WAN 环境对 BFT 协议提出了新的挑战。特别是，WAN 受网络带宽的影响，无论是跨节点还是跨时间。虽然 BFT 协议在存在网络可变性的情况下是安全的，但它们的性能可能会受到很大影响。
为了理解这个问题，让我们考虑现有 BFT 协议的高级结构。 BFT 协议在 epoch 中运行，由两个不同的阶段组成：(i) 广播阶段，其中一个或所有节点（取决于协议是基于领导者 [1, 39] 还是无领导者 [17, 31]）向其他人广播一个块（一批交易）； (ii) 协议阶段，在该阶段，节点投票决定将区块附加到日志中，从而达成可验证的协议（例如，以法定人数证书 [11] 的形式）。从通信的角度来看，广播阶段是带宽密集型的，而协议阶段通常包括多轮短消息，这些短消息不需要太多带宽，但对延迟敏感。
由于落后者，带宽可变性会损害 BFT 协议的性能。在每个 epoch 中，直到绝大多数节点下载区块并在协议阶段投票后，该协议才能继续进行。具体来说，N = 3 f + 1 个节点（容忍 f 个故障）上的 BFT 协议需要至少 2 f + 1 个节点的投票才能取得进展[11]。
因此，协议的吞吐量由每个 epoch 中第 (f +1) 个最慢的节点控制。这意味着低带宽节点（需要很长时间来下载块）会阻碍高带宽节点，从而阻止它们有效地利用其带宽。落后者甚至困扰着异步 BFT 协议 [31]，该协议旨在跟踪实际网络性能（不做时间假设），但仍然需要超级多数来下载每个 epoch 中的块并投票。我们表明，这会降低这些协议的吞吐量，远低于实际 WAN 上网络的平均容量。
在本文中，我们介绍了 DispersedLedger，这是一种构建 BFT 协议的新方法，可在存在带宽可变性的情况下显着提高性能。这种方法背后的关键思想是将共识分解为两个步骤，一个不是带宽密集型的，另一个是带宽密集型的。首先，节点就承诺的有序日志达成一致，其中每个承诺都是一个块的小摘要（例如，Merkle 根 [30]）。与下载完整块相比，此步骤所需的带宽要少得多。之后，每个节点按照约定的顺序下载块并执行交易以更新其状态机。这种方法的主要优点是每个节点都可以按照自己的节奏下载块。重要的是，慢节点不会阻碍快速节点的进度，只要它们具有参与第一步所需的最小带宽即可。
实现这个想法的关键是保证区块的数据可用性。当一个节点接受一个提交到日志中时，它必须知道这个提交所引用的块在网络中是可用的，并且可以在以后被网络中的任何节点下载。否则，攻击者可以将不可用块的承诺放入日志中，从而停止系统。为了解决这个问题，我们的建议依赖于可验证信息分散（VID）[10]。 VID 使用纠删码在 N 个节点上存储数据，以便以后尽管有拜占庭行为也可以检索数据。之前的 BFT 协议（如 HoneyBadger [31]）使用 VID 作为通信高效的广播机制 [10]，但我们使用它来保证数据可用性。具体来说，与 HoneyBadger 不同，DispersedLedger 中的节点不会等待下载块来为它们投票。一旦他们观察到一个区块已经被分散，他们就会投票，一旦同意分散已经完成，下一个 epoch 可以立即开始。这使慢速节点能够参与最新的 epoch，即使它们落后于块下载（检索）。当它们的带宽提高时，这些节点可以赶上检索。图 1 显示了 DispersedLedger 的结构，将其与传统的 BFT 协议进行了对比。
使节点能够以最小的带宽参与共识协议，其应用超出了提高时间波动带宽链路的性能。它还创造了具有两种类型节点的网络的可能性：高带宽节点和低带宽节点。
所有节点都参与对有序的承诺日志达成一致，但只有高带宽节点才能检索所有块。网络参与者可以随时选择使用哪种模式。例如，在移动设备上运行的节点可以在连接到蜂窝网络时以低带宽模式运行，并在 WiFi 上切换到高带宽模式以赶上块检索。所有节点，无论是高带宽还是低带宽，都有助于网络的安全。我们的方法也是对区块链 [27] 进行分片的一种自然方式，其中不同的节点仅在自己的分片中检索块。
我们做出了以下贡献： • 我们提出了一个新的异步 VID 协议，A VID-M (§3)。与当前最先进的技术相比，当在小块（数百 KB 到数 MB）和多个服务器的集群上运行时，A VID-M 的通信成本提高了 1-2 个数量级。
• 我们设计了 DispersedLedger (§4)，这是一种基于 HoneyBadger [31] 的异步 BFT 协议，有两个主要改进： (i) 它将共识分解为数据可用性协议和块检索，允许节点异步下载块并充分利用其带宽 ( §4.2)。 (ii) 它为自 [4] (§4.3) 以来一直存在于此类 BFT 协议中的审查问题 [31] 提供了新的解决方案。与 HoneyBadger 不同，每个 epoch 最多可以丢弃 f 个正确的块，我们的解决方案保证每个正确的块都被交付（和执行）。该技术适用于类似构造的协议，并且可以在没有高级密码学的情况下提高吞吐量并实现审查弹性[31]。
• 我们解决了几个实际问题（第 4.5 节）： (i) 如何防止块检索流量减慢分散流量，这可能会降低系统吞吐量； (ii) 如何防止持续缓慢的节点任意落后于网络的其余部分； (iii) 如何避免无效的“垃圾邮件”交易，因为节点可能并不总是拥有最新的系统状态来过滤掉它们。
• 我们在 8,000 行 Go (§5) 中实施 DispersedLedger，并在多种设置 (§6) 中对其进行评估，包括 AWS 和 Vultr 上的两个全球测试平台，以及受控网络仿真。 DispersedLedger 在全球 16 个城市运行时实现了 36 MB/s 的吞吐量，以及在广泛的负载范围内保持稳定的 800 ms 延迟。
与 HoneyBadger 相比，DispersedLedger 的吞吐量提高了 105%，延迟降低了 74%。
2 背景及相关工作
2.1 BFT 问题
DispersedLedger 解决了拜占庭容错状态机复制（BFT）问题[25]。一般来说，BFT 假设一个服务器-客户端模型，其中 N 个服务器维护一个状态机的 N 个副本。最多 f 个服务器是拜占庭的，并且可以任意行为。客户端可以将事务提交到正确的服务器以更新或读取状态机。尽管存在拜占庭服务器，但 BFT 协议必须确保在所有正确的服务器上复制状态机。通常，这是通过向所有服务器（节点）提供一致的、完全有序的事务日志来实现的 [31]。
形式上，BFT 协议提供以下属性： • 协议：如果正确的服务器执行事务 m，则所有正确的服务器最终都会执行 m。
• Total Order：如果正确的服务器 p 和 q 都执行事务 m1 和 m2，那么 p 在 m2 之前执行 m1 当且仅当 q 在 m2 之前执行 m1。
• 有效性：如果一个正确的客户端向正确的服务器提交事务m，那么所有正确的服务器最终都会执行m。1 BFT 服务器和客户端之间存在多个信任模型。在本文中，我们假设一个用于联盟区块链的模型 [2, 3,6, 40]，其中服务器和客户端属于组织。客户通过其组织托管的服务器发送交易并信任这些服务器。 BFT 的许多新兴应用，如供应链追踪 [14]、医疗数据管理 [26] 和跨境交易清关 [22] 都属于该模型。
2.2 可验证信息分散
DispersedLedger 依赖于可验证信息分散（VID）。 VID 类似于分布式存储，客户端可以将块（数据文件）分散到服务器之间，以便以后检索。我们在第 3.1 节中提供了 VID 的正式定义。信息分散问题首先在 [37] 中提出，其中应用纠删码来有效地跨 N 个服务器存储一个块，而无需复制 N 次。 [19] 在异步网络假设下将该想法扩展到 BFT 设置。但是，它没有考虑拜占庭客户；这些是恶意客户端，它们试图导致两次检索返回不同的块。可验证信息分散（VID）最早是在[10]中提出的，并解决了这个不一致的问题。然而，[10] 要求每个节点在分散过程中下载完整的块，因此它并不比广播更有效。该解决方案后来被 A VID-FP [21] 改进，它要求每个节点通过利用指纹交叉校验和 [21] 只下载分散数据的 O(1/N) 部分。但是，由于 A VID-FP 中的每条消息都伴随有交叉校验和，因此只有当分散的数据块远大于交叉校验和（约 37N 字节）时，该协议才提供较低的通信成本。这使得 A VID-FP 不适用于小数据块和多个节点的集群。在第 3 节中，我们重新审视了这个问题并提出了一个 VIDM，这是一种新的异步 VID 协议，它大大减少了每条消息的开销：从 37N 字节到单个哈希的大小（32 字节），与集群大小 N 无关，使得该协议对小块和大集群有效。
2.3 异步
BFT 协议 分布式算法必须对其运行的网络做出某些假设。 DispersedLedger 做了最弱的假设：异步 [28]，其中消息可以任意延迟但不会丢弃。一个著名的不可能性结果 [16] 表明在这种假设下不存在确定性 BFT 协议。通过随机化，协议最多可以容忍 3 个 f +1 [24] 中的 f 个拜占庭服务器。 DispersedLedger 达到了这个界限。
直到最近 [31]，异步 BFT 协议对于甚至中等大小的集群来说都是昂贵的，因为它们的通信成本至少为 O(N2) [8]。 HoneyBadger [31] 是第一个异步 BFT 协议，实现了每比特已提交事务的 O(N) 通信成本（假设事务批处理）。 HoneyBadger 的主要结构受到 [4] 的启发，进而启发了其他协议的设计，包括 BEA T [15] 和 Aleph [17]。在这些协议中，所有 N 个节点在每个 epoch 广播他们提议的块，这会触发 N 个并行的二进制拜占庭协议 (BA) 实例就要提交的块子集达成一致。 [10] 表明，通过在分散后立即调用检索，VID 可以用作可靠广播的有效构造。 HoneyBadger 和后续协议使用这种结构作为黑盒。 BEA T [15] 探索了 HoneyBadger 中的多种权衡，并提出了一系列基于相同结构的协议。一种协议，BEA T3，也包括一个 VID 子组件。但是，BEA T3 旨在实现 BFT 存储，类似于分布式键值存储。
2.4 安全模型
在继续之前，我们总结一下我们的安全模型。我们做出以下假设： • 网络是异步的（第 2.3 节）。
• 该系统由一组固定的 N 个节点（服务器）组成。最多 f 个节点的子集是拜占庭，并且 N ≥3 f +1。 N和f是协议参数，是公共知识。
• 使用公钥加密对消息进行身份验证。
公钥是公共知识。
3 A AVID-M：一种高效的 VID 协议
3.1 问题陈述
VID 提供以下两个原语：Disperse(B)，客户端调用以分散块 B，以及 Retrieve，客户端调用以检索块 B。客户端调用 Disperse针对特定的 VID 实例检索原语，其中每个 VID 实例负责分散不同的块。 VID 的多个实例可以同时独立运行。为了区分这些实例，客户端和服务器使用该实例的唯一 ID 标记每个 VID 实例的所有消息。对于每个 VID 实例，每个服务器都会触发一个 Complete 事件以指示分散已完成。
VID 协议必须为每个 VID 实例提供以下属性 [10]：
终止：如果一个正确的客户端调用 Disperse(B) 并且没有其他客户端在同一个实例上调用 Disperse，那么所有正确的服务器最终都完成了分散。
• 协议：如果某个正确的服务器已经完成了驱散，那么所有正确的服务器最终都完成了驱散。
• 可用性：如果一个正确的服务器已经完成了分散，并且一个正确的客户端调用了Retrieve，它最终会重建一些块B0。
• 正确性：如果正确的服务器已经完成了分散，那么正确的客户端总是通过调用 Retrieve 来重建相同的块 B0。此外，如果一个正确的客户端通过调用 Disperse(B) 启动了分散，并且没有其他客户端在同一实例上调用 Disperse，则 B=B0。
3.2 AVID-M 概述
在高层次上，VID 协议通过使用纠删码对分散的块进行编码并将编码的块存储在服务器之间来工作。当服务器从足够多的对等方那里听到他们已经收到他们的块时，它就知道分散已经完成。为了检索分散的块，客户端可以查询服务器以获取块并解码块。
这里，一个关键问题是验证编码的正确性。未经验证，恶意客户端可能会根据用于解码的块子集分发具有多个解码结果的不一致块，从而违反正确性属性。如第 2.2 节所述，AVID [10] 和 AVID-FP 通过要求服务器从所有正确的对等方下载块或块的指纹并在分散期间检查它们来解决此问题。虽然这消除了编码不一致的可能性，但所需的额外数据下载限制了这些协议的可扩展性。
更具体地说，虽然 AVID-FP [21] 可以实现最佳通信复杂度，但块大小 |B|趋于无穷大，它对 |B| 的实际值的开销N（服务器数量）可能非常高。这是因为 AVID-FP 中的每条消息都伴随有指纹交叉校验和 [21]，其大小为 Nλ+(N−2 f )γ。这里，λ,γ 是安全参数，我们使用 [21] 建议的 λ=32 字节，γ=16 字节。限制 AVID-FP 可扩展性的关键因素是交叉校验和的大小与 N 成正比。结合节点在分散过程中收到 O(N) 消息的事实，交叉校验和带来的开销增加随着 N 的增加呈二次方。图 2 显示了这种开销的影响。在 N > 40 时，|B| = 100 KB，每个节点需要下载超过被分散块的完整大小。
图 2：在分散块的大小上标准化的 AVID-M 和 AVID-FP 分散期间的每个节点通信成本。在 N = 128（我们评估中的最大集群大小）时，AVID-M 中的每个节点下载多达 1/32 个块，而 AVID-FP 中的一个节点下载 1.2 倍的完整块大小。
我们为异步网络模型开发了一个新的AVID协议，即Asynchronous V erifiable Information Dispersal with Merkle-tree（AVID-M）。AVID-M基于一个关键的观察：只要客户端能够在检索过程中独立验证编码，服务器就不需要在散布过程中进行验证。在AVID-M中，调用Disperse(B)的客户端使用一个短的、恒定大小的承诺H来承诺一组（可能不一致的）块，然后服务器端协议简单地同意H，并保证有足够多与H相匹配的块被正确的服务器存储。 与AVID-FP中O(N)大小的交叉校验相比，这可以通过在消息中只传输H来实现。 在检索过程中，客户端验证它所解码的块在重新编码时产生相同的承诺H。
由于 AVID-M 的每条消息开销是一个小常数（32 字节），因此它可以扩展到许多节点而不需要大块大小。事实上，AVID-M 实现了 O(|B|/N+λN) 的每个节点的通信成本，远低于 AVID-FP 的 O(|B|/N+λN2+γN2)。图 2 将 AVID-M 与 AVIDFP 进行了比较。在 |B|=1 MB 时，即使 N >100，A VID-M 也接近理论下限2，而 AVID-FP 在 N >120 后停止提供任何带宽节省（与每个服务器下载完整块相比）。最后，我们注意到 A VID-M 和 A VID-FP 都依赖于哈希的安全性。因此，对于相同的哈希大小 λ，A VID-M 的安全性不亚于 A VID-FP。
3.3 AVID-M 协议
Dispersal 算法在图 3 中正式定义。客户端通过使用 (N−2 f ,N) 纠删码对块 B 进行编码并构建 Merkle 树 [30] 来启动分散编码的块。 Merkle 树的根 r 是块数组的安全摘要。客户端向每个服务器发送一个块以及 Merkle 根 r 和证明该块属于根 r 的 Merkle 证明。然后，服务器需要确保同一 Merkle 根下的至少 N−2 f 个块存储在正确的服务器上以供检索。为此，服务器交换一轮 GotChunk® 消息以宣布在根 r 下接收到块。当 N - f 个服务器宣布 GotChunk® 时，他们知道至少有 N - 2 f 个正确的服务器已经获得了同一个根 r 下的块，因此它们交换一轮 Ready® 消息以共同完成分散。
Disperse(B) 调用程序 1. 使用 (N−2 f ,N) 纠删码对输入块 B 进行编码，生成 N 个块，C1,C2,…,CN。
-
用所有的块 C1,C2,…,CN 组成一棵 Merkle 树，并计算 Merkle 树的根，r。
-
将 Chunk(r,Ci,Pi) 发送到第 i 个服务器。这里 Pi 是 Merkle 证明，表明 Ci 是根 r 下的第 i 个块。
第 i 个服务器的 Disperse(B) 处理程序 • 从客户端接收到 Chunk(r,Ci,Pi) 时： 1. 通过验证证明 Pi 来检查 Ci 是否是根 r 下的第 i 个块。如果没有，请忽略该消息。
-
设置 MyChunk = Ci, MyProof = Pi, MyRoot = r（所有初始都未设置）。
-
如果之前没有发送过GotChunk消息，则广播GotChunk®。
• 在从第 j 个服务器接收到 GotChunk® 时： 1. 增加 ShareCount[r]（最初为 0）。
- 如果 ShareCount[r]≥N− f ，则广播 Ready®。
• 在从第 j 个服务器接收到 Ready® 时： 1. 增加 ReadyCount[r]（最初为 0）。
2.如果ReadyCount[r]≥f+1，广播Ready®。
- 如果 ReadyCount[r] ≥ 2 f + 1，设置 ChunkRoot = r。
分散完成。
图 3：分散算法（B）。服务器忽略重复的消息（相同的发送者和相同的类型）。广播时，服务器也将消息发送给自己。
检索算法在图 4 中正式定义。客户端通过从所有服务器请求块的块来开始检索。服务器通过提供块、Merkle 根 r 和证明该块属于具有根 r 的树的 Merkle 证明来响应。在收集到 N-2 f 个具有相同根的不同块后，客户端可以解码并获得块 B0。然而，客户端必须确保其他检索客户端也获得 B0，无论他们使用 N−2 f 个块的哪个子集——让客户端执行此检查是 A VID-M 的关键思想。为此，客户端重新编码 B0，从结果块中构造一个 Merkle 树，并验证根与 r 相同。如果不是，则客户端返回一个错误字符串作为检索到的内容。
本节中描述的 AVID-M 协议提供了第 3.1 节中提到的四个属性。我们为每个属性提供了一个证明草图，并指向附录 B 以获得完整的证明。
终止（定理 B.2）。正确的客户端将正确编码的块发送到具有根 r 的所有服务器。 N - f 个正确的服务器将在获得它们的块时广播 GotChunk®。所有正确的服务器都会收到 N− f GotChunk® 并发出 Ready®，所以所有正确的服务器将至少收到 N− f Ready®。因为 N− f >2 f +1，所有正确的服务器都会完成。
检索调用者 • 向所有服务器广播 RequestChunk。
• 从第 i 个服务器获得 ReturnChunk(r, Ci, Pi) 后： 1. 通过验证证明 Pi 来检查 Ci 是否是根 r 下的第 i 个块。如果没有，请忽略该消息。
- 以根 r 存储块 Ci。
• 在收集具有相同根r 的N -2 f 或更多块时： 1. 使用具有根r 的任何N -2 f 块解码以获得块B0。设置 ChunkRoot=r（最初未设置）。
-
使用相同的纠删码对块 B0 进行编码以获得块 C10,C20,…,CN 0。
-
计算 C01,C02,…,C0N 的默克尔根 r0。
-
检查 r0 是否 =ChunkRoot。如果是，则返回 B0。否则，返回字符串“BAD_UPLOADER”。
检索第 i 个服务器的处理程序 • 收到 RequestChunk 后，如果 MyRoot=ChunkRoot，则以消息 ReturnChunk(ChunkRoot, MyChunk, MyProof) 进行响应。如果分散未完成或此处的任何变量未设置，则延迟响应。
图 4：检索算法。客户端忽略重复的消息（相同的发送者和相同的类型）。
协议（定理B.4）。一个服务器在收到2 f+1 Ready®后完成，其中f+1必须来自正确的服务器。因此，所有正确的服务器将至少收到 f+1 Ready®。这将促使它们全部发送Ready®。 最终，每个正确的服务器将收到N-f Ready®，这足以完成（N-f >2 f +1）。
可用性（定理 B.6）。要检索，客户端必须收集具有相同根的 N-2 f 个块。这要求至少 N-2 f 个正确的服务器具有相同根的块。现在假设一个正确的服务器在收到 2 f + 1 Ready® 时完成。当这种情况发生时，至少有一个正确的服务器已经发送了 Ready®。我们证明这意味着至少有 N -2 f 个正确的服务器必须发送 GotChunk® (引理 B.1)，即他们已经收到了该块。假设相反。那么将有小于 N - f GotChunk®。
现在，一个正确的服务器只有在接收到 (i) 至少 N− f GotChunk® 或 (ii) 至少 f +1 Ready® 时才发送 Ready®。
两者都不可能（见引理 B.1）。
通过将 ChunkRoot 设置为相同的值（引理 B.5），所有正确的服务器在完成时同意相同的根。要了解原因，请注意每个服务器每个实例只会发送一个 GotChunk。如果正确的服务器完成了 2 个（或更多）ChunkRoots，那么至少有 N - f 个服务器必须为这些根中的每一个发送 GotChunk。但是 2(N - f ) > N + f ，因此至少有一个正确的服务器必须为两个不同的根发送 GotChunk，这是不可能的。
正确性（定理B.9）。首先，请注意，两个正确的客户端在完成Retrieve后会将ChunkRoot设置为相同，也就是说，他们会从同一Merkle根r下的块解码（Lemma B.5）。然而，我们不知道r下的两个不同的子集是否会解码到同一个区块，因为一个恶意的客户端可以将任意的数据分散为子集。为了确保Retrieve在不同的正确客户端之间的一致性，每个正确的客户端对解码后的块B0进行重新编码，计算编码结果的Merkle根r0，并将r0与根r进行比较。有两种可能性：（i）一些正确的客户端得到r0=r，那么r对应于由B0的正确编码给出的块，所以每个正确的客户端从r下的任何块子集解码也将得到B0和r0=r。(ii) 没有一个正确的客户端得到r0 = r，即所有的客户端都得到r0 6= r，在这种情况下，他们都传递固定的错误字符串。在任何一种情况下，所有正确的客户端都会返回相同的数据（Lemma B.8）。
4 DispersedLedger 设计
4.1 概述
DispersedLedger 是 HoneyBadger [31] 的修改版，它是一种最先进的异步 BFT 协议。 HoneyBadger 在 epoch 中运行，每个 epoch 在 N - f 到 N 个块之间提交（每个节点最多 1 个块）。如图 5 所示，客户端提交的事务存储在每个节点的输入队列中。在每个 epoch 开始时，每个节点从其输入队列中的事务创建一个块，并建议将其提交到当前 epoch 的日志中。一旦提交，区块中的所有交易最终都会被检索并交付给状态机执行。
DispersedLedger与HoneyBadger有两个关键区别。首先，与HoneyBadger不同，DispersedLedger中的节点不广播其提议的区块；相反，它使用A VID-M（从这里开始我们将其称为VID）在整个集群中散布提议的区块。如图5所示，每个时代都有N个VID实例，每个节点一个。然后，DispersedLedger依靠N个二进制协议（BA，详见下文）[32]的实例来达成共识，即哪些提议的区块已经成功分散，因此应该在当前纪元中提交。一旦提交，节点可以在任何时候懒散地检索区块（与未来的区块提议和分散同时进行）。区块的异步检索允许每个节点通过调整其检索区块的速度来适应时间上的网络带宽变化，而不会拖累其他节点。
在 HoneyBadger 中，每个 epoch 最多可以丢弃 f 个正确的块（第 4.3 节）。这会浪费带宽，并可能导致审查制度，来自某些节点的块总是被丢弃 [31]。 DispersedLedger 的第二个创新是一种称为节点间链接的新方法，它保证每个正确的块都被提交。
DispersedLedger 使用现有的 BA 协议 [32]，该协议在 O(1) 时间（并行轮次）内完成，每个节点的通信成本为 O(Nλ)，其中 λ 是安全参数。在 BA 中，每个节点都提供一个二进制 Input({0,1}) 作为协议的输入，并且可能会得到一个指示 BA 实例结果的 Output({0, 1}) 事件。形式上，BA 协议具有以下属性： • 终止：如果所有正确的节点都调用输入，那么每个正确的节点最终都会得到一个输出。
• 协议：如果任何正确的节点得到Output(b) (b ∈ {0,1})，那么每个正确的节点最终都会得到Output(b)。
• 有效性：如果任何正确的节点获得了Output(b) (b ∈ {0,1})，那么至少有一个正确的节点调用了Input(b)。
阶段 1. 在第 i 个服务器上分散 1. 让 Bei 成为 epoch e 分散（提议）的块。
- 在 VIDei 上调用 Disperse(Bei )（作为客户端）。
• 在VIDej (1 ≤ j ≤ N) 完成时，如果我们没有在BAej 上调用Input，在BAej 上调用Input(1)。
• 在至少 N - f 个 BA 实例的 Output(1) 上，在我们尚未调用 Input 的所有剩余 BA 实例上调用 Input(0)。
• 在输出所有BA 实例时， 1. 令（局部变量）Sei ⊂ {1…N} 为Output(1) 的所有BA 实例的索引。也就是说，j ∈ Sei 当且仅当 BAej 在第 i 个服务器上有 Output(1)。
- 进入检索阶段。
阶段 2. 检索 1. 对于所有 j ∈Sei ，在 VIDej 上调用 Retrieve 以下载完整块 Bej0。
- 交付 {Bej0| j ∈Sei }（按递增索引排序）。
图 6：单纪元 DispersedLedger 的算法。
4.2 单纪元协议
在每个纪元中，目标是就一组（索引）至少 N - f 个可用于以后检索的分散块达成一致。一个 epoch 包含 N 个 VID 和 BA 实例。令 VIDei 为时期 e 的第 i 个 (1 ≤ i ≤ N) VID 实例。 VIDei 保留给第 i 个节点以分散（提议）其块。3令 BAei 为 epoch e 的第 i 个 (1≤i≤N) BA 实例。 BAei 用于同意是否提交第 i 个节点分散的块。
图 6 描述了第 i 个节点在 epoch e 的单 epoch 协议。它首先将要为这个时期提出的块 Bei 取出，并通过 VIDei 将其分散到时期 e 中。请注意，系统中的每个块都使用唯一的 VID 实例进行分散，该实例由其时代编号和提议节点标识。
节点现在需要决定在这个 epoch 中提交哪些区块，并且它们应该只提交已成功分散的区块。因为可能有 f 个拜占庭节点，我们不能等待所有 N 个 VID 实例完成，因为拜占庭节点可能永远不会启动它们的 VID 分散。另一方面，节点不能简单地等待并提交前 N - f 个 VID 以完成，因为 VID 实例可能在不同节点以不同的顺序完成（因此不能保证正确的节点提交相同的块集）。 DispersedLedger 使用 [4] 中首次提出的策略。节点使用 BAei 来明确同意是否提交 Bei（应该分散在 VIDei 中）。只有当 VIDei 完成时，正确的节点才将 1 输入到 BAei，因此只有当 Bei 可用于以后的检索时，BAei 才会输出 1。当 N− f 个 BA 实例的输出为 1 时，节点放弃等待任何更多的 VID 完成，并将 0 输入到剩余的 BA 中以明确表示该时期的结束。这保证会发生，因为 N - f 个正确节点的 VID 实例将始终由 Termination 属性完成（第 3.1 节）。一旦确定了一组已提交的块，节点就可以开始检索完整的块。下载完所有块后，节点按索引号对它们进行排序并按顺序交付（执行）它们。
如图 5 所示，单周期 DispersedLedger 协议很容易逐个周期地链接在一起以实现完整的 SMR。在每个周期的开始，一个节点从输入缓冲区的头部获取事务以形成一个块。在每个 epoch 之后，节点都会检查其块是否已提交。如果不是，它将块中的事务放回输入缓冲区，并在下一个 epoch 提出它们。此外，一个节点只有在它传递了所有先前的 epoch 之后才会传递 epoch e。
图 7：通过节点间链接提交的示例，其中 N = 4，f = 1。每个框表示一个节点在一个时期提出的块。橙色块由 BA 提交。 “VID”表示该块已分散但未提交。 “C-IL”表示通过节点间链接提交的块。蓝色虚线框表示正在进行的 VID。在当前 epoch 中，节点 1、2 和 4 的区块在交付后，节点 2 在 epoch 3 中提出的区块将通过节点间链接交付。
4.3 节点间链接
动机。上述单周期协议（以及所有具有类似结构的协议[15, 31]）的一个重要限制是，在一个周期内，并非所有来自正确节点的提议块都被提交。一个纪元只保证提交N-f个提议的区块，其中N-2 f个保证来自正确的节点。换句话说，每个纪元中最多有f个由正确节点提议的区块被放弃。无论是否有对抗性行为，丢弃的区块都可能发生。传输这样的区块会浪费带宽，例如，在我们的实验中，HoneyBadger的吞吐量减少了25%（§6.2）。更糟糕的是，对抗者（如果存在的话）可以决定放弃哪些区块[31]，即最多可以审查f个正确的服务器，从而使这些服务器的区块不会被提交。HoneyBadger提供了一个部分缓解措施，即在提交之前保持所建议的区块是加密的，这样对手就不能根据区块的内容进行审查。然而，对手可以根据提议的节点对区块进行审查。4 这对联盟区块链来说是不可接受的（第2.4节），因为对手可以审查来自某些（最多f）组织的所有交易。此外，HoneyBadger的缓解措施依赖于阈值密码学，这产生了高计算成本[15]。
我们的解决方案。我们为这个问题提出了一种新的解决方案，称为节点间链接，它保证来自正确节点的所有块都被提交。节点间链接消除了任何审查或带宽浪费，并且很容易适用于类似构建的协议，如 HoneyBadger 和 BEA T。请注意，在给定 epoch 中未由 BA 提交的块仍可能完成其 VID。例如，在图 7 中，节点 2 在 epoch 3 中提出的块被分散，但在该 epoch 中没有被 BA 选中。核心思想是让节点识别这些块并在以后的时期以一致的方式交付它们。
每个节点 i 以大小为 N 的数组 V ei 的形式跟踪哪些 VID 实例已完成，该数组存储该节点处的本地视图。当节点 i 开始 epoch e 时，它使用最大的 epoch 数填充 V ei [ j]（对于所有 1≤ j ≤N），这样直到 epoch V ei [ j] 的所有节点 j 的 VID 实例都已完成。例如，在图 7 中，(4, 4, 4, 3) 将是当前 epoch 的有效数组 V，并表示节点 2 在 epoch 3 的 VID 已完成，但节点 4 在 epoch 4 的 VID 尚未完成。
每个节点i在它在每个纪元提出的块Bei中报告其本地阵列V ei（除了正常的块内容）。 如图7所示，然后BA机制在每个纪元至少提交N-f个块。在检索纪元e的过程中，一个节点首先检索BA在纪元e中提交的区块，并像单纪元协议（§4.2）中那样交付（执行）它们。 然后，它提取已提交块中的V数组的集合，即 {V ej | j∈Sei }，并结合这些数组的信息来确定它应该在这个时代检索（和交付）的额外块。请注意，由于BA的协议属性，对于任何两个正确的节点i，j来说，Sei =Sej，所以所有正确的节点将使用相同的观察集，得到相同的结果。
使用提交的 V 数组，节点间链接协议为每个节点 j 计算一个纪元数 Ee[j]。这是由每个节点 i 本地计算的，但我们省略了索引 i，因为所有（正确的）节点都计算相同的值。然后每个节点从节点 j 检索并交付（执行）所有块，直到 epoch Ee[j]。为了确保总顺序，节点对块进行排序，首先按纪元数，然后按节点索引。他们还跟踪已交付的块，以便没有块被交付两次。
在计算 Ee[j] 时，我们必须小心不要被拜占庭节点误导，这些节点可能会报告其 V 数组中的任意数据。例如，天真地取所有 V 数组中节点 j 报告的最大值，即 maxk∈Sei V ek [ j]，将允许拜占庭节点欺骗其他节点尝试检索不存在的块。相反，我们取第 (f +1) 个最大值；这保证了至少一个正确的节点 i 在其数组 V ei 中报告了节点 j 已完成其所有 VID，直到 epoch Ee[j]。回想一下，通过 VID 的可用性属性（第 3.1 节），这确保了这些块可用于检索。此外，由于所有正确的块最终都会完成 VID（终止属性），因此它们最终都将包含在 Ee 中并被交付。我们在附录 C 中提供了完整 DispersedLedger 协议的伪代码。
4.4 DispersedLedger 的正确性
我们现在分析 DispersedLedger 协议的正确性，证明它保证了 BFT 所需的三个属性（第 2.1 节）。完整的证明在附录 D 中。
协议和总顺序（定理 D.7）。 交易嵌入在区块中，因此我们只需要显示每个正确节点的区块交付协议和总顺序即可。块可以通过两种机制提交和交付：BA 和节点间链接。首先考虑 BA 提交的块。 BA 的协议和 VID 的正确性属性保证（i）所有正确的节点将在每个 epoch 检索相同的块集，并且（ii）它们将为每个块下载相同的内容。现在考虑由节点间链接提交的附加块。如第 4.3 节所述，正确的节点根据 BA 提供的块中包含的相同信息（V 数组）确定这些块。因此，它们都检索和交付相同的块集（引理 D.2）。此外，所有正确的节点都使用相同的排序标准（BA 交付的块按节点索引排序，然后是节点间链接块按纪元数和节点索引排序），因此它们以相同的顺序交付块。
有效性（定理D.5D.6）。 将 "正确的交易 "定义为由正确的客户提交给正确的节点（服务器）的交易。我们想证明每个正确的交易最终都会被交付（执行）。这涉及到两个部分：(i) 正确的节点不会挂起，因此每个正确的交易最终会在某个正确的区块中被提出（定理D.5）；(ii) 所有正确的区块最终会被交付（定理D.6）。
对于第 (i) 部分，请注意所有 BA 最终输出，因为在每个 epoch 中，至少 N− f 个 BA 将输出（1）（引理 D.3），然后所有正确的节点将输入（0）到剩余的 BA 和驱使他们终止。此外，通过 BA 或节点间链接选择的所有块都保证成功分散，因此 Retrieve 最终将完成。根据 BA 的有效性属性，只有当某个正确节点具有 Input(1) 时，BA 才会产生 Output(1)，这只有在该节点看到相应的 VID Complete 时才会发生。此外，如第 4.3 节所述，节点间链接仅选择至少一个正确节点观察到已完成分散的块（引理 D.4）。通过 VID 的可用性属性（第 3.1 节），所有这些块都可用于检索。对于第 (ii) 部分，请注意所有正确的块最终都会完成 VID（终止属性）。因此，节点间链接协议最终将识别所有此类块已完成分散（引理 D.4）并交付它们（如果尚未由 BA 交付）。
4.5 实际考虑
并行运行多个时期。在 DispersedLedger 中，节点按顺序执行分散，一旦当前 epoch 的分散完成（所有 BA 实例都有输出），就会进入下一个 epoch 的分散阶段。另一方面，每个 epoch 的检索阶段在所有节点上异步运行。为了防止慢节点阻碍快节点的进程，重要的是它们以尽可能高的速率参与分散，仅使用剩余带宽进行检索。当存在网络瓶颈时，这实际上需要将分散流量优先于检索流量。此外，节点可以从多个 epoch 并行检索块（例如，以提高网络利用率），但它必须始终以串行顺序交付（执行）块。理想情况下，我们希望充分利用网络，但将早期 epoch 的流量优先于后期 epoch，以最大限度地减少交付延迟。在不同类型的消息中强制执行优先级的机制是特定于实现的（§5）。
不断变慢的节点。既然 DispersedLedger 解耦了快节点和慢节点的进度，一个很自然的问题是：如果有些节点一直慢，没有机会赶上怎么办？一些节点不断落后的可能性是 BFT 协议普遍关注的问题。 BFT 协议不能等待最慢的服务器，因为它们可能是试图停止系统的拜占庭服务器 [20]。因此，速度较慢的服务器（特别是最慢的 f 个服务器）可能会被抛在后面，无法赶上。从本质上讲，容纳正确但缓慢的服务器与防止拜占庭节点影响系统之间存在紧张关系。
DispersedLedger将这个问题扩大到最慢的服务器之外。我们讨论两个简单的缓解措施。首先，系统设计者可以规定每个节点的最低平均带宽，这样所有正确的节点都可以在一定的时间尺度T内支持目标系统的吞吐量，每个节点都必须在时间T内支持所需的带宽，但可以在不妨碍其他节点的情况下暂时经历较低的带宽。其次，正确的节点可以简单地在落后太多时停止提出区块，例如，如果他们的检索比当前纪元落后P个纪元以上（P=1与HoneyBadger相同）。如果有足够多的节点落后并停止提议，它会自动减慢系统的速度。 设计者可以选择参数T或P来驾驭影响系统吞吐量的带宽变化和节点能落后多远之间的权衡。
垃圾邮件交易。在 DispersedLedger 中，节点不检查它们提出的块的有效性，将此检查推迟到检索阶段。这会产生恶意服务器或客户端向系统发送无效块垃圾邮件的可能性。即使在传统的 BFT 协议中也无法过滤服务器发送的垃圾邮件，因为当其他服务器下载垃圾邮件块时，它们已经浪费了带宽。
同样，无论块的有效性如何，HoneyBadger 都必须执行 BA（并产生其计算和带宽成本），因为根据设计，所有 BA 必须最终完成，协议才能取得进展 [31]。因此，服务器发送的垃圾邮件同样会损害 DispersedLedger 和 HoneyBadger。幸运的是，服务器发送的垃圾邮件受限于拜占庭服务器的比例 (f /N)。
另一方面，客户端发送的垃圾邮件不是联盟区块链中的主要问题（第 2.1 节）。在联盟区块链中，组织对其客户负责，非拜占庭组织不会向系统发送垃圾邮件。 6出于这些原因，一些针对联盟区块链的 BFT 协议（例如 HyperLedger Fabric [2]）在广播之前放弃了交易过滤以提高效率和隐私收益。
在更开放的环境中，客户端可以自由联系任何服务器，垃圾邮件是一个问题。对 DispersedLedger 协议的简单修改可以实现与 HoneyBadger 相同级别的垃圾邮件过滤。正确的节点在检索滞后时简单地停止提出新事务。相反，他们提出了一个空块（没有交易）来参与当前的 epoch。这样，正确的节点只有在可以验证交易时才提出交易。空块仍然会产生一些开销，所以一个自然的问题是：这些空块对性能有什么影响？我们的结果表明它是次要的，并且这种我们称之为“DL-Coupled”的 DispersedLedger 变体保留了大部分性能优势（第 6.2 节）。
5 实施
我们用8,000行Go实现了DispersedLedger。DispersedLedger的核心协议被建模为四个嵌套的IO自动机：BA、VID、DLEpoch和DL。BA实现了[32]中提出的二进制协议。VID实现了我们在第3.3节描述的可验证的信息分散协议AVID-M。我们使用Reed-Solomon码[36]的纯Go实现来编码和解码块，并使用嵌入式键值存储库[23]来存储块和块。DLEpoch嵌套了N个VID和BA的实例来实现DispersedLedger的一个纪元（§4.2）。最后，DL嵌套了DLEpoch的多个实例和节点间的链接逻辑（§4.3）来实现完整的协议。
流量优先级。将分散流量优先于检索变得复杂，因为节点无法确定不同消息的瓶颈容量以及它们是否共享共同的瓶颈。例如，对低优先级流量进行速率限制可能会导致网络利用率不足。类似地，如果两对节点共享相同的瓶颈，简单地在每对节点之间强制执行优先级可能会导致明显的优先级倒置。在我们的实现中，我们使用一种简单而有效的方法，以受 MulTcp [13] 启发的工作节约方式（无静态速率限制）实现优先级。对于每一对节点，我们建立两个连接，我们修改一个连接的拥塞控制算法的参数，使其表现得像 T (T > 1) 个连接。然后我们在这个连接上发送高优先级的流量，在另一个（未修改的）连接上发送低优先级的流量。在所有瓶颈处，较不激进的低优先级连接将更频繁地回退并让步于更激进的高优先级连接。平均而言，在同一瓶颈处，高优先级连接接收的带宽是竞争低优先级连接的 T 倍。7请注意，在 DispersedLedger 中，高优先级流量仅占节点处理的总流量的一小部分（1 /20 到 1/10 在大多数情况下，如 §6.4 所示），并且其绝对带宽较低。因此，我们的方法不会对在同一瓶颈处竞争的其他应用程序造成拥塞。在我们的系统中，我们设置 T = 30。我们使用 QUIC 作为底层传输协议并修改 quic-go [12] 库以添加旋钮 T 用于调整拥塞控制。
为了按 epoch 对检索流量进行优先级排序，我们通过对不同 epoch 使用单独的 QUIC 流对每个连接的检索流量进行排序。我们修改调度程序 quic-go [12] 以始终发送具有最低纪元数的流。
块状提案的费率控制。DispersedLedger需要一定程度的批处理以摊销BA和VID的固定成本。然而，如果不进行速率控制，节点可能会过于频繁地提出区块，而产生的区块可能非常小，导致带宽效率低。更重要的是，由于分散流量被赋予了高优先级，系统可能会使用所有的带宽来提出低效的小块，而没有留下带宽用于块的检索。为了解决这个问题，我们的实现采用了一种简单的自适应批处理的形式[29]。具体来说，我们使用Nagle算法[33]限制区块提议率。一个节点只有在以下情况下才会提出一个新的区块：(i)自上一个区块被提出后已经过了一定的时间，或者(ii)在下一个区块中已经积累了一定量的数据。在我们的实施中，我们使用100毫秒作为延迟阈值，150KB作为大小阈值。 这个设置对我们所有的评估实验都很有效。
6 评估
我们的评估回答了以下问题： 1. DispersedLedger 在实际部署中的吞吐量和延迟是多少？ 2.无论网络变化如何，DispersedLedger 是否能够始终如一地实现良好的吞吐量？ 3. 系统如何扩展到更多节点？我们将 DispersedLedger (DL) 与原始 HoneyBadger (HB) 和我们的优化版本：HoneyBadgerLink 进行比较。 HoneyBadger-Link (HB-Link) 将 DispersedLedger 中的节点间链接与 HoneyBadger 相结合，因此每个时期，所有（而不是 N -2 f ）诚实块都保证进入分类帐。我们还尝试了 DL-Coupled，这是 DispersedLedger 的一种变体，其中节点仅在检索到最新时才提出新交易（第 4.5 节）。
6.1 实验设置
我们在 AWS EC2 上运行我们的评估。在我们的实验中，每个节点都由一个 EC2 c5d.4xlarge 实例托管，该实例具有 16 个 CPU 内核、16 GB RAM、400 GB NVMe SSD 和一个 10 Gbps NIC。节点形成一个全连接图，即
每对节点之间都有一个链接。我们在两种不同的场景下运行我们的实验。首先，一个地理分布的场景，我们在全球 16 个主要城市启动虚拟机，每个城市一个。我们不会限制网络。此场景类似于联盟区块链的典型部署。此外，我们在 Vultr 上的另一个测试平台上测量了系统的吞吐量（详细信息在附录 A.2 中）。其次，一个受控场景，我们在一个数据中心启动虚拟机，并使用 Mahimahi [35] 在每个节点上应用人工延迟和带宽限制。具体来说，我们在每对节点之间添加了 100 ms 的单向传播延迟，以模拟遥远的主要城市之间的典型延迟 [38]，并将每个节点的入口和出口带宽变化建模为独立的高斯-马尔可夫过程（更多§6.3 中的详细信息）。这种受控设置使我们能够精确定义网络条件的变化，并实现公平、可重复的评估。最后，为了生成系统的工作负载，我们在每个节点上启动一个线程，在泊松到达过程中生成事务。
6.2 互联网上的性能
首先，我们在我们的地理分布测试平台上测量DispersedLedger的性能，并与HoneyBadger进行比较。
吞吐量。为了测量吞吐量，我们在每个节点上产生一个高负载，以创建一个无限积压的系统，并报告每个节点的确认交易率。
由于不同地点的互联网带宽不同，我们预计测量的吞吐量也会有所不同。图8显示了结果。DispersedLedger实现的吞吐量平均比HoneyBadger高105%。为了证实我们的方案是稳健的，我们还在另一个使用低成本云供应商的测试平台上进行了实验。第A.2节中的结果显示，DispersedLedger在该环境下也明显提高了吞吐量。
图 8：在地理分布式设置上运行不同协议的每台服务器的吞吐量。
图 9：在地理分布式测试平台上运行具有节点间链接的 DispersedLedger 和 HoneyBadger 时，随着时间的推移确认的数据量，以相同的比例绘制。每行代表一个服务器。
DispersedLedger 的吞吐量提高主要有两个原因。首先，节点间链接确保所有成功完成 VID 的块都包含在账本中，因此不会浪费带宽。相比之下，在 HoneyBadger 的每个 epoch 中，最多 f 个块可能不会包含在最终分类帐中。因此，用于广播它们的带宽被浪费了。因此，节点间链接最多可以提高 N/(N - f ) 的有效吞吐量。为了测量实际设置中的增益，我们修改 HoneyBadger 以包含相同的节点间链接技术并测量其吞吐量。图 8 中的结果表明，启用节点间链接可将我们的地理分布式测试平台的吞吐量提高 45%。
其次，不同节点的确认吞吐量是解耦的，因此一个站点的暂时减速不会影响整个系统。由于系统部署在广域网中，有许多因素可能导致节点的确认吞吐量波动：网络瓶颈处的容量变化、延迟抖动，甚至拥塞控制算法的行为。在 HoneyBadger 中，除了 f 个最慢的节点之外，所有节点的确认进度都是耦合的，因此在任何时候整个系统都只与 f +1-最慢的节点一样快。 DispersedLedger 没有这个限制。图 9 显示了一个示例：DispersedLedger 允许每个节点始终以自己的容量运行。 HoneyBadger 将大多数服务器的性能结合在一起，因此所有服务器只能以相同的、有限的速率进行。
事实上，注意到与HoneyBadger（有链接）相比，在所显示的2分钟内，每个节点用DispersedLedger取得了更多进展。原因是在HoneyBadger中，不同的节点在不同的时间成为落伍者（（f+1）th-最慢的节点），使所有其他节点停滞。但在DispersedLedger中，带宽提高的慢速节点可以独立于其他节点加速并取得进展，充分利用它拥有高带宽的时间段。图8显示，由于这种改进，与HoneyBadger相比，DispersedLedger实现的吞吐量比HoneyBadger的链接好41%。
最后，DL-Coupled 平均比 DL 慢 12%，但它的吞吐量仍然比 HoneyBadger 和 HoneyBadger 平均高出 80% 和 23%。回想一下，DL-Coupled 会限制可以提出新交易以防止垃圾邮件攻击的节点。结果表明，在关注垃圾邮件的开放环境中，DL-Coupled 仍然可以提供显着的性能提升。在其余的评估中，我们专注于深度学习（没有减少垃圾邮件），以最纯粹的形式研究我们的想法。
潜伏。确认延迟定义为从事务进入系统到交付所经过的时间。与吞吐量类似，不同服务器的确认延迟因网络条件的异质性而异。此外，对于特定节点，我们只计算该节点本身生成的事务的延迟，即本地事务。这是一个有点人为的指标，但它有助于隔离 HoneyBadger 中每个服务器的延迟，并使结果更容易理解。在 HoneyBadger 中，一个慢速节点只有在确认了前一个 epoch 后才会提出一个新的 epoch，因此它提出的速率与它确认的速率是耦合的，即它在下载 O(N) 个块后提出 1 个块。由于这个原因，一个过载的节点甚至没有能力提出它生成的所有交易，并且它提出的任何交易都将是陈旧的。
当这些陈旧的交易在快速节点上得到确认时，快速节点的延迟（尤其是尾部延迟）将受到影响。请注意，DispersedLedger 没有这个问题，因为所有节点，即使是过载的节点，都会以仅受出口带宽限制的速率提出新交易。
总之，选择这个指标只对 HoneyBadger 有利，所以实验仍然是公平的。在附录 §A.1 中，我们提供了更多详细信息并报告了为仅本地和所有事务计算的所有服务器的延迟。
我们在不同的负载下运行该系统，并报告每个节点的延迟情况。在图10中，我们关注两个数据中心。孟买，它的互联网连接有限，而俄亥俄州，它有良好的互联网连接。我们首先看一下延迟的中位数。在低负载时，HoneyBadger和DispersedLedger都有类似的低中值延迟。但当我们将负载从6MB/s增加到15MB/s时，HoneyBadger的中位延迟几乎是线性增加的，从800毫秒左右增加到3000毫秒。这是因为在HoneyBadger中，提出和确认一个时间段是同步进行的。随着负载的增加，提议的区块变得更大，需要更长的时间来确认。这反过来又导致更多的交易被排到下一个区块，所以下一个提议的区块仍然很大。实际上，当我们将负载从6MB/s增加到15MB/s时，HoneyBadger的批次（一个纪元中的所有块）大小从3.4MB增加到42.5MB（每个块200KB到2.5MB）。请注意，区块大小不是由我们选择的，而是由系统本身自然发现的。相比之下，当负载增加时，DispersedLedger的延迟只增加了一点，当我们将负载从2 MB/s增加到23 MB/s时，延迟从730毫秒增加到830毫秒。批量大小在0.85MB到11.9MB之间（每块50KB到700KB）。
6.3 受控实验
在这个实验中，我们在受控环境中进行了一系列测试，以验证DispersedLedger是否实现了其设计目标：无论网络如何变化，都能实现良好的吞吐量。我们在一个数据中心启动了16台服务器，并在每对服务器之间添加了100毫秒的人工单向传播延迟，以模拟W AN延迟。然后，我们为每台服务器生成合成轨迹，独立设定服务器的入口和出口带宽。对于每一组跟踪，我们测量DispersedLedger和HoneyBadger的吞吐量。这是指不同节点的带宽不同，但在一段时间内保持不变的情况。对于第i个节点（0≤i<16），我们设定其带宽不断为10+0.5i MB/s。图11a显示，HoneyBadger（无论有无链接）的吞吐量被限制在第五个最慢的服务器的带宽上，而所有更快的服务器的可用带宽都没有被利用。相比之下，DispersedLedger在不同服务器上的吞吐量是完全解耦的。实现的带宽与每个服务器的可用带宽成正比。DispersedLedger实现了这一点，因为它在不同服务器上解耦了区块检索。
图 11：受控实验中 HoneyBadger (HB)、HoneyBadger with linking (HB-Link) 和 DispersedLedger (DL) 的吞吐量。 (b) 中的误差线显示标准偏差。
图 12：不同集群大小和块大小的吞吐量。误差线显示标准偏差。
图 13：不同规模和区块大小的分散流量与总流量的比例。
时间变化。我们现在看一下带宽随时间变化的场景，并表明 DispersedLedger 对网络波动具有鲁棒性。我们将每个节点的带宽变化建模为具有均值 b、方差 σ 和连续样本之间的相关性 α 的独立高斯马尔可夫过程，并通过每 1 秒从该过程中采样为每个节点生成合成轨迹。具体来说，我们设置 b=10 MB/s，σ=5 MB/s，α=0.98 并为每个服务器生成一个跟踪，即每个服务器的带宽独立变化但具有相同的分布，平均带宽为 10 MB/s。 （我们在 §A.3 中展示了此类跟踪的示例。）作为比较，我们还运行了一个实验，当每个服务器的带宽没有波动并保持在 10 MB/s 时。在我们的实现中（对于所有协议），一个节点在解码一个块时通知其他人停止发送更多块。当所有节点都具有完全相同的固定带宽时，这种优化效果较差，因为一个块的所有块将大致同时到达。因此，在这个特定的实验中，我们禁用了这种优化，以便对固定和可变带宽场景进行苹果对苹果的比较。图 11b 表明，当我们引入网络带宽的时间变化时，DispersedLedger 的吞吐量保持不变。这证实了 DispersedLedger 对网络波动的鲁棒性。与此同时，HoneyBadger 和 HoneyBadger with linking 的吞吐量分别下降了 20% 和 25%。
6.4 可扩展性
在这个实验中，我们评估了DispersedLedger如何扩展到大量的服务器。与许多BFT协议的评估一样[31,39]，我们使用的集群规模从16到128不等。 吞吐量。我们首先测量不同集群规模N下的系统吞吐量。在这个实验中，我们在同一个数据中心启动所有的服务器，每个链路有100毫秒的单向传播延迟，每个服务器有10MB/s的带宽上限。我们还将块大小固定为500KB和1MB。图12显示，当N从16个节点增长到128个节点的8倍时，系统的吞吐量略有下降。这是因为分散阶段的BA的每节点成本为O(N2)。在区块大小不变的情况下，随着N的增加，信息传递开销占了较大的比例。 我们注意到，增加块大小有助于摊销VID和BA的成本，并导致更好的系统吞吐量。
块分散的交通。 DispersedLedger 设计的一个度量核心是节点必须下载的数据量才能参与区块分散，即分散流量。更准确地说，我们感兴趣的是分散流量与总流量的比率（分散加检索）。这个比率越低，慢速节点就越容易跟上区块的分散速度，DispersedLedger 也能更好地实现其设计目标。图 13 显示了不同尺度和块大小的这个比率。首先，我们观察到增加块大小会降低分散流量的比例。这是因为大块大小摊销了 VID 和 BA 中的固定成本。同时，增加集群大小会降低分散流量比例的下限。这是因为在 VID 阶段，每个节点负责每个块的 1/(N -2 f ) 切片，并且增加 N 会降低这一部分。
7 结论
我们介绍了DispersedLedger，这是一种新的异步BFT 协议，可在波动的网络带宽下提供近乎最佳的吞吐量。 DispersedLedger 基于 BFT 协议的一种新颖重组，将协议与下载块的带宽密集型任务分离。我们实现了一个完整的系统原型，并在真实互联网上的两个测试平台和具有模拟网络条件的受控设置上评估了 DispersedLedger。我们在 16 个主要城市的广域部署结果表明，与 HoneyBadger 相比，DispersedLedger 的吞吐量提高了 2 倍，延迟降低了 74%。我们的方法可以适用于其他 BFT 协议，并支持对恶劣网络条件的弹性至关重要的新应用程序。
扫一扫
1061
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
