【论文阅读】Gosig: A Scalable and High-Performance Byzantine Consensus for Consortium Blockchains

标题

• Gosig：联盟区块链的可扩展和高性能拜占庭共识
• 偷懒式阅读法：先整体拿软件翻译，再在课上对照英文阅读。

摘要

现有的拜占庭容错 (BFT) 协议在安全性、可扩展性、吞吐量和延迟方面面临重大挑战。
我们为联盟区块链提出了一个新的 BFT 协议 Gosig。 Gosig 通过将秘密领导者选择与多轮投票相结合，即使在完全由对手控制的异步网络中也能保证安全。我们共同设计共识协议和底层八卦网络以优化性能。特别是，我们采用传输流水线来充分利用网络带宽，同时使用聚合签名八卦来减少消息数量。这些优化帮助 Gosig 实现了前所未有的单链性能。在跨越五大洲 14 个城市的 280 个节点组成的多个数据中心的公共云测试平台上，Gosig 以 15.8 秒的确认时间实现了每秒超过 15,000 笔交易。当系统扩展到 5000 个节点时，Gosig 仍然可以实现每秒 3000 笔交易，确认时间约为 23.9 秒。

1 介绍

比特币 [42] 等加密货币的兴起提高了对底层区块链技术的认识和采用。区块链提供了一个分布式账本，用于序列化和记录交易。区块链提供了有吸引力的特性，例如完全去中心化、离线可验证性，以及最重要的是在互联网规模上的强大共识。因此，区块链在加密货币之外变得流行，扩展到支付服务、医疗保健和物联网 (IoT) 等不同领域 [10, 51, 59]。

虽然 Nakamoto 共识在比特币的应用中很受欢迎，但它具有严重的性能限制，阻碍了它们的进一步采用。对于部署在传统云服务上的联盟区块链，每个节点的身份都是已知的，更适用于使用拜占庭容错（BFT）协议[13]。最近的工作表明，BFT 算法可以比 Nakamoto 共识实现大约两个数量级的吞吐量提升 [23, 40]。

然而，传统的 BFT 协议最初是为在数据中心内的一小组计算机上构建复制状态机而设计的。最近的工作 [23–25, 33, 40, 57] 试图通过改变网络假设或减少总消息大小来在区块链上采用现有的 BFT 协议，但仍然存在以下三个重大挑战：

1. 目标单点故障在只有少数数据中心的云中很常见。攻击者很容易针对诚实节点发起 DDoS 攻击并将其与其他节点分开。因此，任何依赖于特权公开暴露节点的协议都将在所谓的自适应攻击下失去活力。
2. 有限的带宽和长的延迟。与数据中心内的网络相比，跨数据中心网络具有高延迟和低带宽，因此大多数区块链系统会积极地将交易批量处理成大块以分摊共识开销（带宽和延迟）。虽然块广播通常受到网络带宽的限制，但元数据传播受延迟限制。

两者都在关键路径上，但在现有的 BFT 协议中经常忽略差异。其中一些以一对多的模式广播该块 [13, 24, 36, 57]，使源成为瓶颈。其他一些人用一种简单的类似八卦的方法来广播区块 [25, 33]，但广播延迟仍然支配着整个共识过程。

3. 受限于最慢的节点。单个节点上的通信和计算开销都限制了协议的可扩展性。各方可能会使用具有不同容量/成本的实例。如果有任何节点需要接收和处理来自所有其他节点的消息，它将成为瓶颈并减慢整个过程。PBFT 及其变体依靠领导者对请求进行排序。

由于用 ViewChange 替换领导者的成本很高，并且可以提前知道和攻击后续领导者，因此他们无法解决挑战 1 和 3。

大多数最近的提议，虽然依靠一个小委员会解决了挑战 3，但未能解决挑战 1。Algorand [23] 通过结合随机委员会选举和无状态 BFT 算法来避免自适应攻击。但是，它需要网络定期保持同步（比 PBFT 更强的假设）才能从软分叉中恢复以保证安全。

解决挑战 3 的其他尝试是使用阈值签名进行消息压缩，如 SBFT [24] 或 HotStuff [57]。它们显着减小了总消息大小。

然而，由于节点需要等待一些收集器从所有节点收到签名共享，因此性能受到其单节点容量的限制（挑战 3）。

扫描二维码关注公众号，回复： 14663273 查看本文章

我们展示了 Gosig，这是一个快速、可扩展且完全去中心化的 BFT 系统，它通过将协议与底层 gossip 网络集成来解决这三个挑战。

从概念上讲，Gosig 是循环运行的，在每一轮中，它都会将一个块（w.h.p.）附加到区块链上。每轮包含两个阶段，出块阶段和签名收集阶段。在区块提议阶段，Gosig 首先随机选择几个提议者。然后每个提议者将交易打包到一个新块中，并将该块广播给所有其他节点。在签名收集阶段，每个节点选择在第一阶段收到的一个块进行投票，签署自己的决定，并不断中继自己签名和从其他人那里收到的聚合签名。如果一个节点已经收集到足够的签名表明没有冲突的块可以被提交，它就会提交一个块。

在共识协议的基础上，Gosig 使用八卦网络来传播所有消息。共识协议保证了同一阶段的消息在八卦过程中可以有效聚合。除了采用的常用技术外，Gosig 还采用以下密钥：为每个新块，流水线化所有可能的过程，并使用基于八卦的广播即时聚合所有签名。

安全且廉价的提议者替换。为了解决挑战 1，我们更改每个区块的提议者。由于确定性选择的提议者容易受到自适应攻击，我们选择使用可验证随机函数 (VRF) [39] 来实现提议者选举，以使选择随机且不可预测。

此外，我们还需要消除标准 PBFT 中昂贵的 ViewChange。 We exploit the fact that a proposer proposes at most one block during its elected round, and achieves zero-overhead proposer replacement by including a small proof in every proposal to prove the new proposer’s validity.该协议在同步轮次中进行，并且在一轮中最多可以提交一个块。

此外，我们还需要消除标准PBFT中昂贵的ViewChange。我们利用了一个提议者在其选举回合中最多提出一个区块的事实，并通过在每个提议中包括一个小证明来证明新提议者的有效性，实现了零开销的提议者替换。该协议在同步回合中进行，并且在一个回合中最多可以承诺一个区块。

聚合签名八卦。为了解决单节点容量挑战，Gosig 使用一种新颖的聚合签名八卦协议来优化签名收集。它将多个接收到的签名组合成一个等效的聚合签名 [8] 并中继聚合签名。

我们扩展了多重签名数据结构 [8] 以允许任意签名顺序，以便在八卦期间可以再次聚合一组聚合签名。

签名聚合使签名消息的大小最多可缩小两个数量级，并显着减少签名收集阶段的总数据传输。更重要的是，减少是在所有参与方之间平均实现的，防止任何单节点容量成为瓶颈。

各级传输流水线。我们意识到，在应用聚合签名八卦后，投票交换受到延迟限制，因此当每个人都在等待足够的投票进行时，很大一部分网络带宽没有得到充分利用。当每个人都在等待在一轮开始时听到区块提议时，时间也被浪费了。在 gossip 层和 BFT 投票层都使用 Gosig 管道，以最大限度地提高网络利用率。我们精心设计它们以不影响协议的正确性。

我们在跨越五大洲 14 个城市的基于 Amazon EC2 的 280 个实例测试平台上评估 Gosig。我们可以实现每秒 15,000 个 250 字节事务 (tps) 的吞吐量，平均事务确认延迟为 15.8 秒，与 HoneyBadgerBFT [40] 相比，这是吞吐量的 8 倍和延迟的 1/10，一种状态-theart 协议，提供相同级别的安全保证。

此外，使用 1,000 个 A WS EC2 虚拟机在典型的 WAN 带宽和延迟上模拟 5,000 个完整节点，我们表明 Gosig 可以以 23.9 秒的延迟确认每秒 3,000 个 250 字节的事务，实现 3.6 倍的吞吐量和 70% 的延迟减少与 Algorand 相比。而且Gosig即使在全异步网络下也能保证安全（如传统的 BFT）。我们的结果表明，BFT 共识算法和点对点（P2P）网络传输层的协同设计可以显着提高基于 BFT 的大规模区块链系统的性能。

本文做出以下贡献：

• Gosig：我们介绍了基于 BFT 的区块链协议 Gosig 的设计和实现。我们表明，通过共同优化共识和八卦协议，我们可以实现以下所有目标：1）对互联网自适应攻击的容忍度，2）网络资源的充分利用，3）现有区块链的可扩展性（即数千个完整节点） ）。

• 聚合签名八卦：我们提出聚合签名八卦，这是一种新技术，可将签名交换流量减少到 1/100，并显着缓解 Gosig 在数千个完整节点上运行时的消息爆炸问题。

• 传输流水线化：我们提出了传输流水线化技术，一种结合了 BFT 协议和 gossip 网络的通信模式的新技术，可实现 7.5 倍的吞吐量

2 相关工作

比特币及其变体。标准的无许可区块链，如比特币 [42]、以太坊 [56] 使用工作证明 (PoW) 或权益证明 (PoS) 来就一致的交易历史达成一致，以阻止双花攻击。结合激励机制，可以防止女巫攻击，鼓励人们加入公共网络，保证系统安全。其他设计 [17, 20] 试图避免链分叉，但保留 PoW 或 PoS 的设计。我们假设联盟区块链 [11, 48, 54] 并使用 BFT 算法在交易历史上达成共识。我们的重点是构建基于 BFT 的区块链系统的性能和安全性，而不是其他经济方面。

拜占庭容错。 BFT 协议最重要的特点是安全性。不幸的是，许多开源 BFT 协议并不安全 [12]。设计可证明的 BFT 协议协议有两种主要方法。 1) 使用多轮投票：示例系统包括 PBFT [13] 及其后继者 [14, 31, 36, 47]； 2) 使用无领导者原子广播：HoneyBadgerBFT [40] 和 [16, 32]。为了防止恶意领导者影响系统，Aardvark [15] 使用性能指标来触发视图更改，并且 Spinning [53]、Tendermint [33] 或其他 [5, 41] 以循环方式轮换领导者角色。然而，这些方法很容易受到自适应攻击，因为领导者角色是所有人都预先知道的，因此可以在它成为领导者之前被 DDoS 等攻击静音。 Gosig 采用类似 PBFT 的投票机制，无需失败并采用随机提议者选择算法来保持自适应攻击下的安全性和活性。

SBFT [24] 和 Hot-Stuff [57] 使用阈值签名加速签名广播，但收集者或提议者仍然需要在发送压缩签名之前从所有节点接收全尺寸签名，从而使自己成为瓶颈。 Hot-Stuff 还通过添加额外的签名交换阶段来避免视图更改，而 Gosig 在最坏的情况下选择更好的正常情况性能而不是“响应性”[57]。 ByzCoin [29] 采用 CoSi [49] 来减轻领导者的压力，但树形结构和两阶段签名使其容易受到自适应攻击。然而，在 Gosig 中，通过在 gossip 期间聚合签名，每个节点收到的签名大小都会减少。

为了扩展系统，许多系统采用“混合共识”设计[28、29、43、44]，使用类似比特币的协议来选择一个小的法定人数，并使用另一个（希望更快）BFT 协议来提交交易.如果对手可以立即对领导者发起自适应攻击，那么这些协议就很难保持其活性或“最佳路径”。 Algorand [23] 利用秘密领导人选举和仲裁成员替换方法来保持活跃性，但通过允许异步网络下的临时分叉而牺牲了安全性。 DFINITY [25] 采用类似于 Algorand 的可验证随机函数（VRF），但仅在完全同步网络下确保安全。 Stellar [37] 允许参与者单独指定他们的受信任机构，因此具有不同的信任模型。相比之下，Gosig 让每个节点都参与共识，因此确保了异步网络下的可证明安全性。

OmniLedger [30] 和 RapidChain [58] 为每个分片选择一个小型委员会以提高可扩展性，由于重新配置开销，只能缓慢（几天）更改，因此仍然容易受到自适应攻击。

覆盖网络和八卦。大多数共识协议使用广播作为通信原语。为了提高互联网的可靠性，人们经常使用应用层覆盖网络。我们采用可靠多播 [7]、概率广播 [22, 27] 和其他点对点 (P2P) 网络 [26, 52] 等技术。现有的 P2P 网络可能会容忍一些拜占庭式故障，但不能保证收敛 [35]。通过将诸如 gossip 之类的网络优化与健壮的协议设计相结合，我们可以提高系统弹性和性能。

3 综述

Gosig 维护一个区块链。每个节点将交易中继给其他节点，并稍后按特定顺序将它们打包成块。所有提交的块都被序列化为区块链，复制到所有节点。在区块链上，一个区块通过包含前一个区块的哈希来扩展另一个区块。

当且仅当包含该交易的块被提交时，交易才被确认。 Gosig 作为一种共识协议，确保所有区块链副本都是相同的。

3.1 系统模型和假设

Gosig 具有 BFT 协议中常用的标准系统模型和安全假设。这些假设包括： 1）在系统的 N = 3f + 1 个节点中，最多 f 个节点出现拜占庭故障，其余 2f + 1 个正常工作； 2）节点可以通过可信公钥基础设施（PKI）认证其他节点的身份。

请注意，Gosig 具有以下假设和保证：1）我们允​​许 f 故障节点被对手自适应地破坏； 2）我们保证异步网络中的安全性并保证部分同步[21]网络中的活跃性，其中所有消息都可以在未知的全局稳定时间（GST）之后在已知的边界Δ内传递； 3) liveness 属性还需要一个松散同步的时钟，理论上可以用部分同步假设[46]构建，实践中也由网络时间协议 (NTP) 提供。即使时钟任意偏差，也不影响安全。Gosig 还提供了有效性属性，即所有提交的事务都遵循一些应用程序级预定义的验证规则 [33]。

3.2 Gosig 协议概述

我们在本节中提供了对 Gosig 的直观概述。我们将 Gosig 的执行划分为具有固定时间长度的轮次。每轮由一个提议者选择步骤（无通信）和两个具有固定长度的后续阶段组成。因此，所有节点都通过参考本地时钟知道当前的轮数和阶段。

图 1 提供了一个典型回合的概览。在每一轮开始时，一些节点秘密地意识到他们是这一轮的潜在提议者，使用密码抽签算法（第 4.2.1 节）。因此，对手不能比随机猜测更好地瞄准提议者。

在第一阶段，每个被选中的潜在提议者将不冲突的未提交交易打包成一个块提议，用八卦传播它，然后就像一个普通节点一样行事。第二阶段的目标是通过投票交换就本轮的部分区块提案达成协议。节点通过将其区块的数字签名添加到准备消息（“P 消息”）并对其进行八卦来为区块“投票”。一个诚实的节点每轮只投票给一个提案。在从一个区块的 P 消息中接收到至少 2f +1 个签名后，节点通过将消息和轮次存储在其本地状态中来尝试性地提交该区块，并开始为其发送临时提交消息（“TC 消息”）。一旦收到 2f +1TC 消息，节点最终将块提交到其本地区块链副本。如果它未能在同一轮中最终提交区块，则将使用本地状态来决定是否接受新的提议或决定进一步提议哪个区块。

然后，我们通过应用流水线和聚合签名传播在每个阶段优化协议。有关详细信息，请参见第 5.1 节和第 5.2 节。

4 Gosig协议设计

在本节中，我们首先描述顺序 Gosig 协议（我们称之为“香草协议”）。然后，在第 5.1 节和第 5.2 节中，我们讨论了重要的优化、传输管道和聚合签名八卦，它们使 Gosig 能够扩展到数千个节点。

4.1 消息和状态定义

3.2 节简要介绍了协议，我们正式描述了表 1 中的符号。我们使用 a.b 来表示结构 a 的字段 b。例如，如果 c 是 (H(B), h) 形式的 P 证书，c.B 表示 c 投票支持的区块。

除了具有区块承诺证明的区块链副本外，每个节点还维护一个本地状态，并根据状态和外部事件（接收特定消息或被选为提议者）决定其下一步操作。本地状态也在表 1 中定义。请注意，如果某个块是 TCed，则 ctc .r 始终等于 rtc。

当 Gosig 开始运行时，节点的本地状态被初始化为 si = ⟨ϵ, 0, ϵ⟩，其中 ϵ 代表空值。当一个块最终被提交时，这个块将被附加到区块链中并且状态将被重置。

4.2 第一阶段：区块提案

4.2.1 提议者选择我们使用可验证随机函数（VRF）[39]来选择一组潜在提议者。这个想法来自 Algorand [23]。我们使用简化版本，因为我们假设每个节点具有相同的权重，并且节点在系统启动后无法更改其私钥。

提议者选择协议如下所述。

节点 pi 所有 N 个节点中的第 i 个 (i ∈ {
    
    1, ..., N })) 节点。

PR 消息 形式为 (H(B), h, c, pp) 的提议消息，其中 H(B) 是提议块 B 的哈希值，h 是 B 的高度，c 是提议证书，pp是提议者证明。

P/TC 消息 形式为 (H(B), h) 的准备/暂定提交消息，其中 H(B) 是投票块 B 的哈希，h 是 B 的高度。

PRri (B) 提议区块 B 的 PR 消息，在第 r 轮中由 pi 签名。

PrX (B)/TCrX (B) 为区块 B 投票的聚合 P/TC 消息，由 r 轮中的一组节点 X 签名。

pi P/TCs B pi 广播关于块 B 的 P/TC 消息。

P/TC 证书由至少 2f + 1 个签名者签名的聚合 P/TC 消息。

提案证书 a P 或 TC 证书 c.根据证书类型，提案证书round c.r定义为P证书中的轮，或TC证书中的轮加一。

节点本地状态 si = ⟨Btc, rtc, ctc ⟩ 一个三元组，其中 Btc 是块本身，rtc 是 Btc 被 TCed 的轮次，ctc 是 Btc 在 rtc 轮中被 TCed 时使用的 P 证书。我们使用 ϵ 来表示一个空值。

我们在 Gosig 中定义一个公开的随机种子 Qh 为

其中 h 是已提交区块 B1 的高度，H 是安全哈希函数，lh 定义为提出区块 B 的提议者（B 的提议证书的签名者），SIGi(M) 是 Boneh–使用 pi 的私钥签名的消息 M 的 Lynn-Shacham (BLS) 签名 [9]。

基于 Qh，我们将节点 pi 在第 r 轮的提议者分数 Lr(i) 定义为 Lr(i) = H(SIGi(r, Qh))，其中 h 是第 r 轮的区块链长度。如果一个节点的提议分数低于提议者阈值，它就会成为潜在提议者。在一轮 r 开始时，每个节点 pi 计算其 Lr (i)，并知道它是否是该轮的潜在提议者。一个潜在的提议者可以用值 SIGi(r, Qh) 向其他节点证明其提议者的状态，称为提议者证明。该过程不需要节点之间的通信。

密码抽签算法有两个性质：1）签名SIGi使用pi的私钥，因此不能伪造； 2) 如果散列函数 H(·) 是完全随机的，则潜在提议者的选择是一致随机的。因此，对手无法知道谁被选中，也无法改变任何节点成为提议者的机会。

提议者阈值的值只会影响我们协议的性能，而不会影响协议的安全性。由于如第 5.1 节所述，“失败”的块将被快速丢弃，只要在大多数轮次中至少存在一个提议者，性能对阈值不敏感。我们将阈值设置为 7/N，其中 N 是节点总数，这足以将无提议者轮次的概率降低到 0.1% 以下。

4.2.2 区块提议 每个潜在提议者 pi 决定提议哪个区块，然后生成提议消息。如果 pi 已经 TCed 一个 Btc 块，Btc 将被提议。否则，pi 在区块链之后生成一个新块。

为了使提议有效，潜在提议者为提议的区块 B 提供提议证书 c。如果选择 B 作为暂时提交的区块 Btc，则提议证书将是 P 证书。否则，如果 B 是新建的，则提案证书将是提交区块链中最后一个块的 TC 证书。该提案证书 round c.r，如表 1 所定义，将用于说服其他已 TCed 较早区块的节点重置其状态并准备 B。该证书由至少 2f +1 个节点签名，因此不能伪造。

最后，潜在提议者 pi 组装表 1 中定义的 PR 消息。然后 pi 使用其私钥对消息进行签名。每个人都可以通过检查包含的块、签名和证书来轻松验证 PR 消息的有效性。当节点收到提案时，它将检查高度是否与其本地提交的区块链匹配。如果某个节点中缺少某些已提交的块，则该节点只会投票，直到丢失的块被异步恢复，如第 5.3 节所述。

在第一阶段，PR 消息通过八卦广播到所有节点。在第一阶段结束时（在固定的时间间隔 T1 之后），假设一切顺利，大多数节点应该已经看到了该轮的所有区块提议。然而，Stage II 能够处理所有复杂的情况。

4.3 第二阶段：签名收集

第二阶段的目标是传播节点对区块提案投票的签名消息。与第一阶段一样，我们使用八卦来传播所有消息。

第二阶段协议。算法 1 概述了第二阶段中诚实节点 pi 的预期行为。我们将每个 pi 建模为一个有限状态机，其局部状态列在算法 1 的开头。它根据当前的局部状态和传入的消息执行操作。

第 1 到第 6 行描述了初始化过程，其中 pi 检查它在第一阶段收到的所有区块提议并决定

准备哪个块（通过调用算法 2 中的函数 DecideBlock）。一般来说，pi 更喜欢证书轮次较大的区块提议，因为它表示一个更新的区块（第 2.8 到 2.14 行）。最后，pi 恰好为高度 h 选择了一个块 B，然后 Ps 它（第 1.4 行）。

初始化后，pi 的状态机开始处理传入的消息。算法 1 中的第 11 到 24 行概述了这两种不同消息类型的处理程序例程。节点 pi 只处理它拥有 Ped 的同一块的消息（第 1.12 行和第 1.19 行），它只能在从关于 B 的 P 消息中收集至少 2f + 1 个签名后才能TC 块 B，它只能提交一个块B 从关于 B 的 TC 消息中收集至少 2f + 1 个签名（第 1.14 和 1.21 行）。这 2f + 1 条 TC 消息可以聚合成一个承诺证书，作为 B 已承诺的离线证明。

请注意，当提交块或恢复所有提交的块时，本地状态将被重置。这些规则确保了 Gosig 的安全性和活力。

4.4 安全分析

我们证明 Gosig 在完全异步的网络中提供安全性。如果我们添加一个部分同步假设（如 PBFT [13]），它也实现了活性。由于篇幅有限，我们只列出了一些关键的引理和证明草图，并将完整的证明留在技术报告中[45]。

引理 1. 如果诚实节点 pi 在第 r 轮中提交高度为 h 的块 B，则在以后的轮次中，没有诚实节点将在任何高度 h’≤h 处TC 另一个块。

证明草图。当 pi 提交 B 时，至少 f + 1 个诚实节点拥有 TCed B 并设置它们的 Btc = B, rtc = r。设这组诚实节点为 HB。 HB 中的所有节点都提交了一些高度为 h-1 的块，因此在第 r 轮之后它们不会在高度 h’ < h 的任何块上 P。因此，高度 h’ < h 的块不能有 2f + 1 个 P 消息来构建 P 证书并且不能被 TCed。现在我们只需要证明 h′ = h 的情况。

假设高度为 h 的另一个块在轮 r ′ > r 处被 TCed。它被 2f + 1 个节点 Ped，因此 HB 中的某些节点必须 Ped 它。根据算法 2，如果区块的提案证书 c′ 具有 c′.r > r，则具有 Btc ，ε 的节点只会改变其 Btc 状态和 P 另一个高度为 h 的区块。让我们考虑第一轮，为块 B’, B’, B 构造了一个 c’.r > r 的提案证书 c’。在 c’.r 轮中，HB 中的所有节点都没有将其 Btc 更改为另一个块在高度 h，他们只能在两种情况下：1）已经在高度 h 提交了一个块，2）仍然暂时提交给 Btc = B 的块。在任何一种情况下，他们都不会在 c’ 轮中准备块 B’ .r.因此，如果没有来自 HB 的投票，B’ 在本轮中无法获得足够的 P-messages 来构建有效的 P-certificate，进而无法在本轮中被 TCed 或获得 TC-certificate。这与在本轮中构建 B’, B 的提议证书的假设相矛盾。

现在我们已经证明不存在任何提议证书来说服 HB 中的节点准备另一个高度块 h 在 r 后。这意味着没有其他高度为 h 的块可以拥有 P 证书，因此在第 r 轮之后，任何节点都不会在任何高度 h’ ≤ h 处对另一个块进行 TC。

引理 1 表明，在提交一个块后，不能提交相同高度的其他块。因此，我们实现了安全。以下引理证明，如果我们添加部分同步假设，则不能永远阻止活跃性。

引理 2. 在全球稳定时间 (GST) 之后，在一轮中提交区块的概率至少为 1/N 。

证明草图。在 GST 之后，如果提案分数最低的提案者是诚实的，并且其提案证书 rtc 不低于其他 2f 个诚实节点的证书，则其提议的区块将在本轮中被提交。以最大 rtc 进入新一轮的诚实节点具有最低提案分数的概率为 1/N 。选择是随机的，无法被对手预测，作为提案证书轮次的 rtc 在进入新一轮后不会受到其他节点的影响。因此，在一轮中提交区块的概率至少为 1/N 。

请注意，这个引理适用于只有一个节点具有最大轮次的证书并且只有 2f + 1 个节点处于活动状态的更坏情况。在成功的一轮之后，我们应该能够在以后的每个同步轮中取得进展。

5 项关键性能优化

5.1 传输管道：挑战 2 解决方案

Gosig 采用传输流水线优化 vanilla BFT 协议的通信模式，更高效地利用网络资源。它允许尽可能异步运行的独立块和消息交换。目标是最小化任何节点的等待时间并利用所有空闲带宽，以便我们可以解决挑战 2。

流水线友好的块结构。 Gosig 将每个区块分为以下三个部分：1) 包含协议中使用的所有元数据的标头，例如凭证和提案证书，2) 包含有序交易哈希列表的主体，以及 3) 原始交易堵塞。这种设计背后的直觉是 BFT 协议在不同阶段需要不同种类的信息。采用这种块结构使 Gosig 能够尽可能多地流水线化协议的不同阶段，从而独立优化对延迟敏感的元数据和带宽受限的数据传输。它还使 Gosig 能够通过异步传输原始交易和投票消息来充分利用计算和数据传输之间的独立性。

Gosig 进一步将 body 分成几个部分，允许节点在接收之前开始发送数据整个块体，很像 BitTorrent 传输文件的方式。与 BitTorrent 不同的是，生成区块的提议者在将每个单独的段发送到不同的对等点之前对它们进行签名。请注意，提议者在每个段上的签名至关重要，否则攻击者会生成大量垃圾段来拥塞整个网络。

阶段之间的管道。 Gosig 的 gossip 网络首先传播块的头部，然后传播主体及其原始交易。这使得两个阶段，即用于块传播的阶段 I 和用于签名传播的阶段 II，可以相互重叠。回想一下，Stage I 结束时间实际上是一个超时时间，此时我们可以假设所有节点都收到了提议者分数最低的块，因此它们可以决定要 P 哪个块。实际上，一个节点只需要块头就可以做出算法 2（第 4 行）中的决定。因此，首先传播标头并在所有节点收到标头后立即进入第二阶段是安全的。由于标头通常很小（对于 10、000 名参与者大约为 41 KB，如果我们应用第 5.2 节中讨论的压缩，则为 21 KB），这种优化大大缩短了第一阶段的时间。此外，当节点更早地看到标头时，它们可以及早决定得分最低的提议者，而不会浪费带宽来进一步传播来自其他提议者的“丢失”块。

异步原始事务传播。然后，Gosig 的八卦网络仅使用交易哈希传播块的主体。对于主体，我们采用了来自 Bitcoin-core [1, 2] 的紧凑块的想法。除非发生冲突，否则我们只包含 6 字节短哈希而不是完整的 32 字节 SHA256 哈希。因此，主体也远小于所有原始交易的总和。

Gosig 异步传输原始交易。当一个节点接收到一个以前没有见过的事务时，它会将事务传递给一些随机节点（默认为 3 个）。如果一个节点在收到原始交易之前可能会看到仅散列的块体，它会在节点处理（即暂时提交）该块之前从随机其他人那里检索丢失的交易。为了请求这些交易，节点将 3 字节索引而不是 6 字节短散列发送到块中。由于我们可以对这些索引进行差分编码 [2]，因此平均请求大小可以小至每个丢失事务的 1 个字节。

我们仍然需要节点接收块体，收集所有相应的原始交易，并在它们更新其本地状态并在第二阶段发送 TC 消息之前验证它们（算法 1 中的第 1.14 到 1.17 行）。

轮次之间的管道。在 vanilla 协议中，只有在上一轮 r-1 的第二阶段结束时才开始一轮 r，潜在的提议者会等到该轮开始提议一个块。我们意识到，一旦节点在第 r-1 轮提交了一个块（即，看到一条具有足够签名的消息），该节点就可以通过提议一个新块来安全地开始第 r 轮 如果它是潜在的提议者，则为第 r 轮。仍在第 r-1 轮中的节点将暂时缓冲这些接收到的块，并在它们在第 r-1 轮提交或第 r 轮开始时间到来时处理它们。

即使节点在第 r-1 轮结束之前已经进入第 r 轮，该节点将继续执行第 r-1 轮第二阶段的任务，例如转发/签署 P 消息，直到该轮结束。通过这种方式，我们可以保持第 r-1 轮的高签名传播率。

流水线的安全性分析。我们现在表明流水线设计不会影响我们的共识协议。 TC 消息仅在验证整个块后才发送，因此所有已提交的块仍然有效。

Ped 块可能因两个原因变得无效：1) 块与主体一起重建但未通过有效性检查，2) 块从未完全重建。在任何一种情况下，vanilla 协议都将能够为该轮提交一个有效的替代块，但流水线版本不提交 - 因为节点提前停止传播其他候选块。这种行为是可以接受的，因为只有由恶意提议者生成的块才能在验证阶段失败，而恶意提议者无论如何都可以停止轮次（通过发送一个空块），即我们不会增加攻击者的力量。

考虑以下几轮。如果一个块是 Ped 但不是 TCed，如算法 2 所示，节点状态只会受到 Btc 重置的影响。不会保留有关此无效块的任何信息。因此，下一轮将开始，就好像一个有效的块是 Ped 但不是 TCed。现在我们的协议的安全性和活性仍然存在，并且流水线不会给对手任何额外的权力。

5.2 任意顺序聚合签名八卦：挑战3解决方案

Gosig 使用聚合签名八卦来优化 vanilla BFT 协议第二阶段的签名传输，减少每个节点的数据传输，避免任何单个节点过载。请注意，每个节点都需要从所有其他节点的 2/3 处收集投票或签名。如果天真地实施第二阶段，签名消息的数量将随着节点的数量超线性增长。为了解决这个可扩展性挑战，Gosig 使用 [8, 9] 中的技术在八卦期间将多个接收到的签名聚合成一个紧凑的多签名。具体来说，Gosig 通过包含节点在 P 消息中看到的所有签名来收集签名以及八卦过程。这样，在接收到 P 消息时，节点可以了解多个新签名，它可以与之前看到的签名合并。这使 Gosig 能够转发一个紧凑的多重签名而不是许多单独的签名，以节省网络资源。此外，在消息中而不是在节点上累积签名对节点故障更具弹性。由于每个节点可以发送和接收更少的数据，我们可以缓解挑战 3 中表达的单节点容量问题。

现在我们描述签名聚合是如何工作的。节点 pi 的密码签名涉及哈希函数 H、生成器 G、私钥 xi 和公钥 Vi = Gxi。持有私钥 xi 的节点可以通过计算 Si = H(M)xi 对消息 M 进行签名，其他节点可以通过检查 e(G, Si) 是否等于 e(Vi, H(M)) 来验证它给定双线性映射 e。为了跟踪我们收到了哪些签名，我们将一个大小为 N 的整数数组 n 附加到签名中，并通过对消息 M 进行签名，节点计算 Si = H(M)xi ，并递增 nSi 的第 i 个元素。组合 (Si, nSi ) 是聚合的签名。

聚合签名只是将 BLS 签名相乘并将数组 n 相加。因此，聚合签名（又名多重签名）为 S = H(M) ˝ i xi ·nS [i]。设 (S1, nS1) 和 (S2, nS2) 是两个多重签名，我们可以通过计算 (S1 ∗S2, nS1 +nS2) 来组合它们。数组 n 跟踪已签署消息的人。每个人都可以通过检查是否 e(G, S) = e(˛ i V nS [i] i , H(M)) 来验证多重签名。

请注意，原始签名聚合算法 [8] 仅允许按特定顺序收集签名。我们通过在签名中附加一个大小为 N 的整数数组来修改它，以记录一个节点的签名被聚合了多少次。这意味着我们可以以任意顺序聚合多重签名[49]，避免自适应攻击的风险。 [49] 提到了附加数组的想法，但没有实现它，因此容易受到自适应攻击。

尽管多重签名仍然具有渐近的大小 O(N )，但对于附加数组的每个元素来说，一个 4 字节的整数已经绰绰有余了。使用 2048 位签名，10,000 个节点只需要 40,256 字节，没有聚合的大小的 0.64%。此外，由于它是一个整数数组，Gosig 对其进行了有效的压缩： 1) Gosig 使用可变长度整数编码将许多元素的大小减少到 2 个字节； 2）当签名者不多时（大部分数组元素为零），Gosig利用稀疏性将其编码为map； 3）Gosig 可以进一步适应整数数组压缩[34]。

使用 LIFO 处理堆栈连续闲聊。使用签名聚合技术，八卦网络现在面临着在立即转发签名消息或等待更多传入签名以利用签名聚合机会之间进行有趣的权衡。在我们的实现中，每个节点在并发连接的限制下连续向第二阶段的随机邻居发送 P/TC 消息。该限制有助于避免过于激进地转发签名而失去聚合机会。默认限制为 5，第 6.4 节提供了对该设置的详细评估。

如果签名到达太快而无法及时处理，节点会将这些消息放入后进先出 (LIFO) 堆栈中。Gosig 选择 LIFO 堆栈而不是 FIFO 队列，因为稍后到达的消息可能包含更多签名。

5.3 处理特殊情况

参与者加入/离开。我们支持任何授权节点加入或离开的非交互式证明，无论是来自受信任机构的签名还是来自组的多重签名。要加入/离开组，节点会提交包含证明的特殊交易。现有节点将在提交事务时更新自己的参与者列表。

处理临时故障。如果节点从崩溃或数据丢失中恢复，它应该检索丢失的块和证明。它只有在恢复整个历史后才能继续参与。由于一个区块的任何投票只能在提交前一个区块后才能处理，因此所有诚实节点在计票时将看到相同的成员资格。

如果节点检测到与对等点的明显通信问题（连接失败、超时等），它将把对等点“列入黑名单”（即停止向其发送）一段 To（通常是一轮时间的一半）。在同一对等点的后续失败中，它将累加增加 To，直到它收到来自该对等点的消息或成功重试。这种退避机制有效地限制了连接到故障节点的浪费尝试。

6 评估

我们结合使用真实世界的测试平台、仿真和模拟来评估 Gosig 的性能。我们展示了整体性能以及各种参数和优化的效果。我们还使用大规模模拟评估了解决糟糕的网络条件和单节点容量挑战的有效性。

6.1 评估设置

Gosig 原型实现。我们用 Java 实现 Gosig 原型。我们使用 pbc [38] 库进行密码计算（使用 JPBC [19] 包装器并启用预处理）并使用 grpc-java [3] 进行网络通信。至于签名参数，我们选择JPBC[18]提供的默认a-type参数，并使用它来生成1024位的BLS签名。整个系统包含大约 5,500 行 Java 代码，不包括注释。

我们针对不同的应用和规模使用了三个测试平台，包括一个真正的 280 节点跨数据中心广域网、一个 5K 节点广域网模拟器和一个 10K 节点大规模广域网模拟器。

工作量。提交给 Gosig 的每笔交易都是一个简单的键值集操作。交易被填充到 250 字节，这是典型的比特币交易大小（并在 [40] 中使用）。 交易执行不涉及签名验证或磁盘 IO 操作，因此我们的评估可以集中在共识协议的性能上。这些事务被提交到在同一个 EC2 实例上运行的服务器。请注意，延迟是端到端测量的，从生成交易的那一刻到确认打包它的那一刻之间，而大多数其他作品 [29, 30, 40] 只考虑了一个块的确认延迟，而不是个人交易。理论上，预期的交易提交延迟大约是区块确认延迟的 1.5 倍，因为在一轮中生成的所有交易都可能在下一轮打包并提交。

真正的 280 节点数据中心间广域网测试平台。我们使用 280 个 t2.large 实例（2 核，8 GB 内存）构建了一个多区域云测试平台，这些实例均匀分布在 Amazon EC2 的 5 大洲 14 个区域中。我们通过实验测量网络状况。在一个区域内，我们观察到 <1ms 的延迟和大约 500 Mbps 的带宽，跨区域的延迟高达数百毫秒，带宽从 15 Mbps 到 250 Mbps 不等。我们相信这是多区域云的良好表示。

5K 节点仿真。为了评估 Gosig 的可扩展性，我们使用 1,000 个 EC2 实例模拟具有 5,000 个节点的广域网。该设置类似于 Algorand [23]。我们每个 EC2 m4.2xlarge 实例运行 5 个节点。我们将每个节点的网络带宽限制为 20 Mbps。根据全球 20 个城市的测量结果，我们在发送方插入人工延迟以模拟网络延迟 [55]。

为了评估每个 EC2 实例上的更多节点，我们使用 sleep 来代替签名验证——CPU 繁重的操作。我们将睡眠时间设置为我们在 m4.2xlarge instances2 上测量的验证时间。

10K 节点模拟。考虑到成本，我们使用模拟来分析公共互联网上的 Gosig。我们专注于协议的核心——签名收集过程。我们使用与我们的仿真相同的网络延迟配置和签名验证时间，将网络带宽限制设置为 2Mbps3，并将丢包率设置为 1%（高于许多 Internet 链接）。

6.2 真实280节点测试台性能

我们首先介绍了与Hyperledger Fabric[6]的性能比较，Hyperledger Fabric是一个著名的用于生产的联盟区块链系统，在一个小型集群上。该比较将表明，在我们的设置下，运行一个全栈区块链系统不能有效地评估共识协议。然后，我们介绍了Gosig在280个节点的测试平台上的整体性能。280个节点的测试平台上的整体性能，然后提供详细的con-figuration参数分析，以及对Gosig的影响。构成参数和优化的效果。

6.2.1 与 Hyperledger Fabric 的比较我们使用来自 5 个不同大陆的 5 个区域的多达 20 个节点来运行实验。在每个节点上，我们使用 2.2.0 版的官方 docker 镜像部署 peer 和 orderer。提交给 Hyperledger Fabric 的交易是 Hyperledger Caliper [4] 中的 EmptyContract，这只是一个空操作。交易由所有节点平均生成，并由部署在同一节点上的对等方提交和背书。工作量类似于 Gosig 中使用的工作量，因为它们试图尽可能简单。 Fabric 尚未正式支持任何拜占庭容错算法，因此我们选择 Raft（etcdraft）作为共识模块。一轮 Gosig 为 5 秒，Fabric 的批量超时为 1 秒。

表 2 显示了实现的吞吐量和延迟。使用我们的 2core 主机，Fabric 的吞吐量不到 Gosig 的 1%，因为所有 CPU 资源都被验证交易的证书和签名所占用。但是，这些与交易相关的验证实际上是在应用程序级别，并不是我们想要评估的共识协议的一部分。此外，这种开销可以通过更强大的机器来减少，因为它们可以完美地并行处理，并且这种解决方案独立于共识模块。因此，在以下所有评估中，我们将仅在 Gosig 上使用虚拟交易进行实验，以展示共识协议的性能。

6.2.2 整体性能 对于测试平台上的默认实验，我们设置循环时间 T = 10 秒（每个阶段 5 秒），max_block_size = 60 MB。请注意，我们可以支持大块大小，因为我们使用段来流水线块传输和验证。平均事务大小为 250 字节，我们可以在每个块中包含多达 240,000 个事务。由于我们只在提案中包含块头，因此 PR 消息远小于 max_block_size。我们将配置选择的讨论留给第 6.2.3 节。

我们在 70、140 和 280 个实例（即每个数据中心 5、10、20 个实例）上运行实验。我们使用每秒 4,000 到 20,000 个事务 (tps) 的不同工作负载运行每个 1,200 秒。图 2(b) 和 2(a) 分别绘制了吞吐量和平均提交延迟。我们有以下观察结果：

1. 在不使系统过载的情况下，平均事务提交延迟约为 15.8 秒，与我们理论上预期的 1.5 倍循环时间 (T = 10 秒) 的延迟一致。

2. 70 个节点，我们可以维持 17,000 tps。在 280 个节点的情况下，我们仍然可以支持 15,000 tps，这清楚地证明了 Gosig 可以达到的性能。与 HoneyBadgerBFT [40] 中报告的数字相比（使用类似的 EC2 测试平台，但地理位置更少），我们达到了 8 倍的吞吐量，并通过更多节点和更多区域将延迟降低了 90%。

3）当系统过载时，吞吐量实际上会下降。这是因为 10 秒的轮次时间不足以将所有块传播给每个人，导致轮次不完整，从而降低了有效吞吐量。为了防止这种情况，我们限制 max_block_size 作为准入控制机制。事实上，图 2(b) 中的虚线表明，当将 max_block_size 限制为 40MB（即每块 160K 事务）时，即使在过载时我们也可以维持最大吞吐量。当然，过载仍然会导致延迟上升，所有排队系统都是如此。

4. Gosig 以较小的开销很好地容忍故障。如图 2(a) 和 2(b) 所示，总共 280 个节点中的 70 个故障节点（未响应）对吞吐量或延迟的影响很小，而不会出现过载。这些故障的唯一影响是将最大吞吐量降低了大约 20%，从 15,000 tps 降低到 12,000 tps。

6.2.3 配置参数选择 Gosig 提供了几个参数来适应不同的系统条件。最重要的包括循环时间 T、最大块大小 max_block_size 和每个块的段数。我们通过实验评估它们对同一个 280 节点测试平台的影响。

最大块大小。正如我们之前所讨论的，参数 max_block_size 用作准入控制机制，以避免系统过载。对于 N 个节点，max_block_size 与三个参数 [17, 50] 成正比：1) 1 log N，2) 循环时间 T，以及 3) 网络带宽。这意味着，要将节点数量从 100 个增加到 10,000 个，我们需要将 max_block_size 减少一半或在固定带宽的情况下将循环时间 T 加倍。

保持节点数 N = 280 和回合时间 T = 10s，我们将 max_block_size 从 20MB 变为 50MB，对应 8K 到 20K tps。在每一轮中，我们都会生成使 max_block_size 饱和的工作负载。图 3 绘制了结果。图 3 中的虚线显示了系统具有无限容量的理想情况。

正如我们之前介绍的，实际吞吐量约为 16,000 tps。我们可以看到，对于小于 40MB 的 max_block_size，系统的实际吞吐量随着 max_block_size 的增加而增加，并且大致遵循理想线。在大约 16,000 tps 时，系统饱和。如果 max_block_size 明显大于系统的容量，吞吐量会降低，因为一些轮次将在块可以完全传播之前结束。

回合时间T。回合时间 T 直接影响提交延迟。如果我们可以在下一轮提交所有在一轮中生成的事务，那么在没有过载的情况下，预期的事务提交延迟是 1.5T。延迟比该值显着增加，这表明系统过载。我们想要评估 T 设置的影响。请注意，max_block_size/T（即每轮提交的数据）受网络带宽的限制。因此，对于 5 到 20 秒之间的每个 T 选择，我们通过实验确定允许最大吞吐量的相应最佳 max_block_size。我们在两个阶段之间平均分配 T。我们要求 T 至少为 3 秒，以容忍时钟同步误差 Δ 和消息传播延迟。

图 4 绘制了不同 T 设置下的吞吐量和延迟。在图中，1）我们验证我们能够将延迟保持在接近 1.5T 的预期延迟； 2）我们观察到选择小的 T 会显着降低最大吞吐量。这是因为当 T 较小时，相应的 max_block_size 必须保持较小，这意味着我们在非常短的轮次中传播了许多小块。在这种情况下，网络设置开销变得不可忽略，进一步减少了我们可以用来传输有用数据的带宽； 3) 将 T 设置为 10 秒已经支持 280 节点系统中的最大吞吐量（16,000 tps），比我们所知的所有现有解决方案都要快得多。

每个块的段数。图 5 显示了通过分段传输块来提高吞吐量。在 40 MB 块中使用 13.3 MB 段，我们可以实现大约 15,000 tps 的吞吐量。这是因为通过分段，靠近轮次提议者的节点可以更早地开始八卦出块体，从而加速块体传播。此外，由于节点可以在不接收整个块体的情况下检索丢失的交易，因此原始交易的传播速度也更快。我们还观察到，在我们的测试平台中，我们只需要每个块的少量段来饱和网络带宽。

6.2.4 流水线的好处 我们评估第 5.1 节中的每个优化如何提高性能。我们保留标准优化，如短哈希，并通过有选择地禁用其他优化来衡量性能。对于所有实验，我们保持回合时间 T = 10s 并通过实验确定最佳 max_block_size。

图 6 显示，禁用所有流水线的 vanilla 实现只能达到 2,000 tps。轮次或阶段之间的流水线可以将吞吐量提高约 75% 至 3,500，因为它允许块传播与签名传播重叠，从而提高阶段 II 中所有节点的网络利用率。每个块使用 5 个段，我们将吞吐量从 2,000 tps 提高到 8,000 tps。将所有改进加在一起，吞吐量可以达到 15,000 tps，或比 vanilla 协议好 7.5 倍。

跨节点负载均衡。性能改进主要来自减少等待时间，这是节点之间网络利用率更加平衡的结果。图 7 绘制了前 1 个和前 3 个最繁忙节点的相对网络流量与所有节点的平均流量。我们可以看到，使用段是减少热点最有效的方法。这是因为更多节点可以在接收到完整块之前开始传播，从而减少等待第一个块的时间。

6.3 5K-node Emulation 整体性能。

我们使用 5K 节点仿真评估 Gosig 的可扩展性。我们将回合时间设置为 15 秒（在两个阶段之间平均分配），将 max_block_size 设置为 12 MB。我们将工作负载设置为 3000 tps，足以提供最佳吞吐量。在这种配置下，我们每小时可以确认 2700 MB 的数据，只有 23.9 秒的事务提交延迟。

仿真结果显示，与Algorand[23]提出的结果相比，Gosig实现了更高的吞吐量（约3.6倍）和更短的确认时间（减少70%），后者每小时提交750MB数据，每轮提交时间约为50秒（如果工作负载均匀产生，则交易提交延迟为75秒）4。 此外，Gosig在所有5000个节点之间运行共识，而Algorand只使用2000个节点的委员会。

每一轮都被充分利用。良好的性能部分来自于传输流水线可以重叠不同消息的等待时间并以异步方式利用同步轮。图 8 说明了一个块如何在一轮 r 中传播的时间线。它分别绘制了收到区块头（来自获胜区块）、整个区块主体、该区块中的所有原始交易以及足够的 (2f + 1) P/TC 签名的节点的百分比。垂直实线分隔不同回合，垂直虚线分隔回合内的阶段。我们从第 r-1 轮的第二阶段开始绘制。

第 r 轮的潜在提议者在第 r-1 轮提交块时开始提议块（并发送标头），大约在第 r 轮开始前 2.5 秒，因为我们在两轮之间进行管道传输。尽早开始一轮为我们提供了在不同轮次之间调整工作负载的灵活性，以更好地处理工作负载变化和性能干扰。

由于其体积小，所有节点只需要大约2秒就能收到提议区块的头。r轮正式开始的时间是7.5秒，但这个开始时间在正常情况下并不重要，因为所有节点都已经承诺r轮-1，并在这个时间之前进入r轮。当r轮的第二阶段开始时（在15秒），一小部分节点还没有收到提议者区块的所有交易。他们现在可以发送他们的P票，因为他们已经收到了头，但他们必须在第二阶段收到这些缺失的交易，然后再发送他们的TC票。这种阶段间的流水线允许第二阶段提前开始，并使阶段分割的配置不那么敏感。

网络带宽得到充分利用。为了证明 Gosig 也可以很好地利用带宽，我们将网络带宽限制从 10Mbps 更改为 40Mbps，图 9 显示了最大吞吐量。我们看到吞吐量几乎与网络带宽成正比（10Mbps 为 1500 tps，40Mbps 为 5900 tps）。我们分析日志并注意到对于 10、20、30、40 Mbps 带宽，原始事务传输（包括 gossip 和丢失事务检索）的实际带宽利用率分别为 8.25 Mbps、16.68 Mbps、25.01 Mbps、32.70 Mbps。超过 80% 的带宽用于“有用的”有效载荷传输，这意味着我们的协议引入的开销很小并且可以很好地利用带宽。

6.4 10K 节点模拟

我们的 10K 节点模拟侧重于第二阶段的完成时间，这是 Gosig 的核心和最复杂的部分。

在与模拟器相同的配置下，我们展示了完成具有 100 到 10,000 个节点的阶段 II 所需的时间，即所有诚实节点都会收到超过 2/3 节点签名的 TC。图 10 显示了使用不同故障模式和优化组合的结果。有几个观察：
1）（模拟器校准）我们首先重现 5K 节点的仿真结果。图 10 中的星号显示了在 5K 节点仿真中完成第二阶段所需的时间。我们发现时间与模拟器非常匹配：仿真中为 3.55 秒，仿真中为 3.70 秒。它表明模拟器确实反映了实际性能。

2. Gosig 可以很好地扩展。即使有 10,000 个节点，第二阶段也只需要 6.68 秒。多重签名在大量节点中起着重要作用。如果没有多重签名5，完成第二阶段需要多 4 倍的时间。

3. 10,000 个节点，其中 1/3 没有响应，Stage II 完成时间从 6.68 秒减至 11.31 秒。鲁棒性来自八卦机制和与顺序无关的签名聚合。

聚合签名八卦解决了单节点容量挑战。图 10 还提供了阈值签名和聚合签名八卦之间的比较。阈值签名 [24, 57] 在数百个规模上表现良好。但是，当规模超过 1,000 时，延迟会迅速增加，并且对于 10k 节点，它会超过 20 秒。性能下降是因为收集器处理的消息大小随着组大小线性增长，使得这个单个节点减慢了整个系统的速度。

在合约中，聚合签名八卦压缩了每个节点发送和接收的数据，显着提升了 Stage II 的性能。当 Gosig 运行 10k 个节点时，Stage II 只需 6.68 秒即可完成。

我们的结果还表明，小的八卦连接限制，即出站连接的数量，可以适应大多数环境。较大的限制（例如，图 10 中的 20）将使网络饱和并错过签名聚合机会。尽管较小的限制可能无法充分利用具有较少节点的网络，但与已经花费在块传播上的时间相比，成本并不显着。

7 结论和未来工作

虽然 BFT 协议是构建联盟区块链的有前途的工具，但在公共互联网上的云服务中采用时面临重大挑战。我们为联盟区块链提出了一个新的 BFT 协议 Gosig。在 Gosig 中，每个新区块的提议者都是随机秘密选举的，以防止自适应攻击。我们共同优化 BFT 协议层和 gossip 层，将所有通信流水线化，以尽可能提高网络利用率。使用聚合签名八卦，我们可以将部分投票结果打包成一条短消息，允许每个节点传输更少的数据。这些优化帮助 Gosig 支持具有数千甚至更多节点的单个共识组，并在广域网中实现数倍的性能提升，同时保持与传统 BFT 相同的安全水平（例如，容忍异步网络和自适应攻击）。

作为未来的工作，我们希望设计一种激励机制来鼓励玩家遵循协议，例如，尽最大努力转发消息。此外，Gosig 既是一个完整的系统，也是高级区块链的构建块。例如，我们想提供一个分片/链下设计，使用 Gosig 作为每个分片的共识协议。