设计Espresso网络：将HotShot共识与Espresso的数据可用性层结合起来

介绍

我们在之前的 笔记 中介绍了 Espresso 网络的动机、设计原则和高层次要求。在这篇文章中，我们将深入理解 Espresso 网络的两个关键组件：HotShot 共识协议和我们的自定义数据可用性（DA）层 EspressoDA。

我们将分为三个部分进行讨论：

• 第一部分：理解排序器网络的限制，以及它与状态机复制（SMR）系统的不同
• 第二部分：HotShot 共识
• 第三部分：EspressoDA 数据可用性

（关于该设计的更技术性解释，请阅读我们的学术论文，请注意它将 EspressoDA 称为 Tiramisu DA。）

第一部分：排序器与状态机复制系统

一种拜占庭容错状态机复制（BFT SMR）系统要求一组节点就一系列交易达成一致，然后执行这些交易，以使系统在某些节点为拜占庭故障的情况下仍然能够正常工作。这通常满足三个独立的要求：

• 共识：确保所有非故障节点就这些交易的顺序达成一致
• 数据广播：确保交易数据被广播到每个非故障节点
• 执行：确保每个非故障节点执行交易并更新状态机

这些都是独立的要求，从性能角度来看，它们不一定是相互对立的。因此，SMR 系统的整体性能由其中最慢的一个决定。

传统的 SMR 系统（区块链）。所有节点接收、排序和执行所有交易。

另一方面，共享的去中心化排序器不需要满足所有这些要求。在典型工作流程中，用户将交易提交到 rollup，交易最终排队在内存池中。排序器网络检索这些交易并输出一个最终排序的交易列表。在此排序之后，rollups 自身负责执行交易（并且它们也提交状态更新以记录在Layer1 上）。因此，排序器网络不负责执行甚至验证交易。因此，虽然对于 rollup 来说，确保交易数据的可用性是一个要求，但交易数据不必广播到排序器网络的节点。总而言之，我们对排序器网络有以下要求：

• 共识：确保所有非故障节点就这些交易的顺序达成一致
• 数据可用性：确保数据对需要它的人（例如，rollups）可用
• 执行：不需要执行

因此，虽然去中心化排序器网络可以使用 SMR 协议实现，但我们有机会开发出一个更简单、更高效的系统。对于 SMR 系统的理想设计，可能并不一定是排序器网络的理想选择。尤其是，虽然这三个需求在 SMR 系统中可能会成为瓶颈，但放宽的数据可用性要求和不要求执行使得共识成为一个重要的瓶颈。

Espresso 网络模块性地将数据可用性（DA）和共识分开，以提高吞吐量和延迟。共识层仅负责就数据块的短承诺达成一致，而完整数据的可用性则委托给并行运行的 DA 层。在接下来的两个部分中，我们将介绍 HotShot 的设计，我们的共识问题解决方案，以及 EspressoDA，我们的数据可用性问题解决方案。

在 Espresso 网络中，节点只接收数据的小份额，并保证其余数据是可用的。

第二部分：HotShot 共识

HotShot 共识是 Espresso 网络的核心部分。从高层次来看，网络接受来自不同 rollup 的交易（无论是否已排序），使用共识节点对其进行公证（如果 rollup 将网络用作去中心化排序器，可能还会对其进行排序），并为执行提供确认。

使用 Espresso 网络作为去中心化排序器的说明： 今天，大多数 rollup 使用他们自己的（中心化）排序器来对交易进行排序，这引入了一个受信实体和单点故障（即，如果排序器出现故障，活跃度受到影响）。

去中心化的共识网络相比于这种中心化世界提供了两个关键优势：

1. 去中心化可以提供审查抵抗能力，防止垄断（例如，通过区块生产的竞争）。
2. 去中心化共识提供交易顺序的最终性（或公证）。这种不可相互矛盾的承诺在中心化实体中是无法实现的，除非它完全可信。

可能仍然存在的问题是：如果我们无法完全信任一个中心化实体，我们如何确保 HotShot 的大量共识节点不会腐败到相互矛盾或被贿赂以审查交易？此外，从效率的角度来看，中心化实体可以快速提供即时最终性（如果可信）——去中心化排序器网络能否实现相同的性能？

我们在以下关于 HotShot 共识的安全性和效率期望中扩展这些话题。

HotShot 安全性期望

• 以太坊级别的安全性。 作为基准，HotShot 应至少与以太坊网络本身一样安全。如果没有这样的要求，最终用户将会得到两个不同级别的保证——首先，HotShot 会有最终性，而随后以太坊会在几分钟后提供一个独立的最终性保证。如果用户需要等待这几分钟才能获得最终保证，那么使用共识网络的机会就会被错过。我们计划通过依赖于以太坊的节点集（例如，通过 EigenLayer）来实现这个目标。实际上，以太坊验证者将订阅与 HotShot 相关的额外惩罚规则。因此，如果任何恶意行为（例如，双签 HotShot 块）导致 HotShot 中的安全性违规，验证者将失去他们的股份。因此，HotShot 提供了类似于以太坊的最终性的经济保证。我们还注意到，我们的惩罚能力意味着 HotShot 共识协议是可追责的。
• 抵制贿赂。 以太坊节点的最终性为可追责行为提供了安全性。那么，其他形式的行为如何呢？例如，审查或活跃性违反。在去中心化共识网络中，攻击者可以轻易贿赂处于权力位置的参与者，例如，领导者，以进行不当行为。例如，攻击者可以创建一个智能合约，贿赂节点以审查交易。一方面，我们希望攻击者不能使用少量贿赂预算造成永久性的性能问题。因此，这排除了基于小委员会的解决方案，如 Algorand。原因是攻击者可以贿赂一个委员会，永久性地偏向于一个信标，或阻止数据可用性。另一方面，观察到一个拥有无限贿赂预算的攻击者可能过于强大并无法应对。因此，我们专注于向具有足够贿赂预算（例如，三分之一节点数量）的攻击者提供防贿赂解决方案。我们的解决方案确保这样的贿赂攻击者只能造成暂时的进度损失。这意味着，一旦攻击者用完资金，网络将继续进展。更重要的是，这在第一时间就强烈抑制了贿赂行为，因为其潜在影响是有限的。

HotShot 效率期望

我们的目标是接近中心化排序器的效率。

• 低延迟高吞吐量协议。从性能角度来看，我们的目标是补充以太坊。因此，虽然以太坊在间歇性参与下实现动态可用性以支持活跃性，HotShot 旨在获得低延迟和高吞吐量的快速最终性。
• 可扩展到大规模节点。由于安全性要求使用与以太坊相同的节点集，我们的目标是能够扩展到数万台节点。

请注意，虽然我们的安全性要求非常严格，并旨在防止最坏情况，例如系统的永久崩溃，但如果效率要求仅在正常即乐观情况下得到满足，也即在网络正常运行且没有主动攻击时，这也是足够的。这受到理论和实践的支持，因为攻击和网络故障通常是暂时事件，我们可以设定激励（例如惩罚标准和抵制贿赂）以确保对抗性利润不足以维持长期的积极攻击。

我们的解决方案：对 PoS 环境进行响应式、通信高效的共识，使用网络层 CDN

我们的解决方案旨在实现上述所有目标。HotShot 是 HotStuff 的一种变体，在视图中以逐视图的方式在节点之间运行简单的共识协议，其中指定的领导者在每个视图中提出下一个交易块。各节点验证提案是否基于共识不变量有效，然后只向下一个领导者发送投票。块中的交易在任何两个连续视图及扩展它们的块获得投票法定人数时被承诺。该协议具有以下令人振奋的特性：

• 乐观线性通信。 我们的共识协议仅需在乐观情况下进行线性通信复杂度。这在我们的环境中重要的几个原因。首先，为了与以太坊验证者集交互，我们的目标是扩展到数万节点（在一个 1 万节点的二次协议中，即使每轮只发送一个签名也需要 3.2GB 的通信，而在一个线性协议中仅需 320KB）。其次，我们需要获得低延迟的最终性，这意味着在乐观情况下我们不应该依赖 P2P 通信（因为在 P2P 网络中，延迟与网络直径成比例）。这一要求使通信复杂度成为一个重要的优化指标。最后，鉴于我们放宽的数据可用性要求，我们的 DA 解决方案（在 第三部分 中描述）在关键路径上相比典型 SMR 协议也会产生更低的通信。因此，共识协议承担了系统通信的较大份额；降低通信复杂度是提升系统整体性能的重要一步。
• 乐观响应性。 我们的协议保持乐观响应性，以网络的速度进行承诺，而无需等待任何悲观的网络延迟。因此，当网络表现良好时，它允许我们更快地提交数据块，并帮助改善吞吐量。这也促使在网络完全运行时优化平均情况，因为协议可以利用这一点。相比之下，缺乏响应性时，必须保守设定参数（如以太坊），这即使在乐观条件下也会减慢协议执行。例如，下面描述的 CDN 就是这种优化的一个例子。
• 在网络层使用 CDN。 获取低延迟需要各方之间比依赖 P2P 网络更快地进行通信。然而，如果我们有数万个共识节点，直接连接并维护这些连接对于所有共识节点而言都是不高效的。我们在网络层利用 CDN，类似于 Web2 架构中的使用。CDN 是具有高带宽连接的强大硬件，能够以低延迟高效地路由信息。这种基础设施使得我们即使在节点数量庞大的情况下也能有更好的扩展，不论是在计算能力还是通信能力上。在通信方面，数据可以更快地传播到所有共识节点。在计算方面，如签名聚合等计算密集型任务可以卸载到这些硬件上。此外，我们的协议的乐观响应性特性质与网络层的这种修改相得益彰，从而实现更好的性能。
• 适应 PoS 环境。 HotShot 将 HotStuff 从授权设置转变为权益证明（PoS）环境，其中共识节点集可以随时间变化。因此，我们为每个时间段指定了一组视图，并且每个时间段的节点集保持固定。随着时间的推移，节点集的变化，协议将被重新配置为新的共识节点集。HotShot 依赖于底层 L1 层来跟踪共识节点的股份。
• 使用 Naor-Keider 视图同步。 在 HotStuff 中，只有当共识节点在同一视图中持续足够的时间时才能保证活跃性。HotStuff 通过一个时钟模块实现这一点，但该模块存在二次通信复杂度和不理想的延迟。在 HotShot 中，我们改为使用 Naor-Keidar 视图同步器，它在乐观情况下实现线性通信复杂度和常数延迟。

你可以在我们的学术论文 这里 阅读更多关于我们网络设计和 HotShot 的详细信息。

第三部分：EspressoDA：我们的三层 DA 解决方案

数据可用性（DA）是区块链共识（即状态机复制）系统的一个至关重要的安全属性。它确保所有诚实用户都可以访问系统状态，即使存在试图阻止这一点的对手。有访问状态对于用户能够创建新交易并在系统中使用其资产是很重要的。

DA 对所有区块链系统来说都是一个重要属性，但它在 rollup 中受到了显著关注。一个 rollup 验证者证明一个有序（或按顺序排列的）交易列表导致了某种状态更新。这个证明通常是相对于系统状态短承诺的，例如 Merkle 哈希。然而，这个证明确实不够充分，因为它并未确保数据可用性，即用户知道 rollup 的状态。许多 rollups 依靠Layer1 区块链，例如以太坊，来提供数据可用性。然而，Layer1 区块链的空间尤其稀缺和昂贵。在Layer1 链上使用数据可用性会造成额外的拥堵并导致更高的费用。此外，正如我们将在本文中讨论的，以太坊的共识并没有最优设计以支持快速和便宜的数据可用性，主要是由于固定块时间造成的。

为了解决这个问题，我们引入了 EspressoDA，一种高效的 DA 解决方案，由三个独立的可用性层构成。它在乐观情况下提供超高效的 Web2 级数据可用性，同时在任何悲观情况下（例如，当发生网络故障或攻击时）提供强的以太坊级保证。它不仅关注提供数据可用性作为后备功能，还关注在恶意行为下高效访问数据。

EspressoDA 完全与 HotShot 共识集成，并由 HotShot 节点运行，因此通过 EspressoDA 提供的块受益于 HotShot 的乐观响应性。使用 Espresso 网络进行快速确认的 rollup 自动访问 EspressoDA，但也可以自由使用其他 DA 解决方案，以提供不同的权衡。

EspressoDA 通过三层结构确保数据可用性，平衡性能和安全性：

VID 层：一种抵御贿赂的 DA 解决方案（类似于 Danksharding）

作为 EspressoDA 的基础层，VID 层是一种类似于 以太坊的 Danksharding 提议的抵御贿赂的 DA 解决方案。核心思想是通过纠删码对有效负载数据进行编码，然后将编码数据拆分到所有 hotshot 节点。纠删码允许从任何足够大的节点子集中恢复完整的有效负载（例如 1/4 的所有节点）。

试图破坏 EspressoDA 的对手需要贿赂所有节点的超多数，即完全破坏网络，才能产生针对不可用数据的恶意 DA 证书。

该协议通信高效，因为大小为 L 的有效负载仅需所有节点之间 O(L) 的总通信——这仅是有效负载大小的常数倍，与节点数量无关！相比之下，常规 DA 解决方案将大小为 L 的有效负载的完整副本广播给所有 N 个节点，总通信需要 L*N。

与 Danksharding 或 Celestia 的 DA 解决方案不同，EspressoDA 不需要数据可用性采样（DAS）。相反，它依赖于一种名为可验证信息分散（VID）的技术。实例见 这里 和 这里。

VID 直接在 HotShot 节点之间分割数据，确保可恢复性。这比 DAS 更有效，因为它限制了不必要的冗余。此外，Danksharding 使用二维纠删码，以确保数据的子集可以更高效地恢复（即使仅恢复一笔交易仍需约256个节点）。该方法的缺点是，在最坏情况下，75% 的节点需要是诚实的并提供数据，才能恢复整个块。我们的设计，以相同的参数，仅要求四分之一的节点是诚实的。为了实现高效恢复，我们增加了额外的安全层，以确保将有诚实节点能够提供对任何数据子集的细粒度访问。

EspressoDA 的 VID 层是通信高效且提供最高（类似于以太坊）的安全级别，因此它作为我们三层系统的基础层。

然而，没有单个节点拥有所有的有效负载数据，并且从单独的共享中恢复完整的有效负载需要节点之间的通信和解码纠删码的计算。此外，每个用户获得的数据共享是不同的，块生产者负责任于将所有单独的共享广播到网络中的每个人。因此，VID 层本身并没有提供良好的用户体验。此外，攻击者可能通过 withholding 数据触发更慢和复杂的解码恢复过程。

为此，EspressoDA 具有两个额外的层。

• DA 委员会层，中间层，保证数据的高效恢复，除非整个委员会被贿赂。
• CDN 层，顶层，是一个不被信任但可以大幅加速数据分散和检索的 CDN。

此插图展示了我们 DA 解决方案最初被称为 TiramisuDA 时每层的原始名称。Savoiardi 是 VID 层，Marscapone 是 DA 委员会层，而 Cocoa 是 CDN 层。

DA 委员会层：具有快速有效性条件的小型 DA 委员会

为了改善 EspressoDA 的可用性和安全性，HotShot 共识选举一个小型 DA 委员会。该委员会由少于 200 个节点组成，控制 HotShot 股份不到 33% 的攻击者几乎不可能控制超过一半的委员会。该委员会直接从 CDN 或块提议者接收数据，并生成一个块数据可用性的证书。如果节点诚实的比例更高，我们可以使用 GearBox 方法生成更小、更高效的证书。这个想法是，只要我们从该委员会获得足够数量的签名，我们就可以自适应地使用来自更小委员会的签名，即如果每个人都签名，则仅由 25 个节点组成的一组委员会就足够了。

DA 委员会不仅保证数据可用性，还保证其有效恢复。委员会中的任何诚实节点都可以直接提供对数据或数据任何子集的访问。DA 委员会的主要缺点是，恶意节点可能贿赂委员会的多数成员提供数据可用性证书，而实际上数据并不可用。贿赂一个小委员会的成本明显低于贿赂整个共识的超多数，而这个共识可能由数万节点组成。但这正是基础 VID 层提供贿赂抵抗的地方，因为它涉及到所有共识节点，而不是仅限于一个小委员会。

CDN 层：通过 CDN 加速数据分散

我们可以通过使用内容分发网络显著加速 EspressoDA，以提供 web2 级别的性能。我们的 CDN 实现使用开源 NGINX 负载均衡器，旨在快速多播相同的数据，例如，块的内容，给许多不同的节点。它可以显著加速数据的分散，在我们的 Americano 测试网络中，我们展示的数据分散速率约为 2.5MB/s 到 100 个节点（DA 委员会的大小可以进一步传播数据）。CDN 还可以帮助有效恢复数据的子集，例如单个交易。

重要的是，CDN 在安全上不被信任，因此并不构成单点故障。EspressoDA 在没有 CDN 的情况下完全能够正常工作，CDN 只是加速 DA 的组成部分，且可以轻松替换或移除。

EspressoDA 大于其各个单层的总和。

为响应性增添一抹 HotShot 的 Espresso

注意，EspressoDA 的所有三层是并行运行的。尽管这意味着它们可以相互支持（例如，DA 委员会的节点可以协助 VID 分片），但这也意味着系统可能会受到最慢组件的瓶颈。

VID 层的效率仅比 Danksharding DA 高出一个常数倍，因此合理询问为何用户在 Danksharding 激活后应该优先选择 EspressoDA 而非以太坊的 DA。这就是 HotShot 共识的关键所在。与以太坊共识或 Tendermint 不同，HotShot 是响应及时的。非正式地说，这意味着没有块时间，但是新块只需要具备足够的签名法定人数即可出现。只有在最坏的情况下（例如，在 DoS 攻击下），HotShot 块的生成时间才和以太坊块一样长（每个块 12 秒）。

然而，在乐观条件下，HotShot 将更快。此外，HotShot 的最终性仅需三个网络轮次（或用 HotStuff2 如需两个轮次），相比 以太坊的两个完整时间段（约 12 分钟）。

其逻辑在于，以太坊的参数设置较为保守，以应对攻击和不良网络状态，而 HotShot 则完全适应不同的条件。因此，在良好的网络状况下以及 CDN 完全运行时，EspressoDA 的延迟和吞吐量相较于如以太坊或 Tendermint 这样的非响应设计可以显著提高，即使在全面实现 Danksharding 之后。

与其他 DA 的兼容性

EspressoDA 是 Hotshot 的默认数据可用性系统，HotShot 节点必须运行。还有许多其他数据可用性解决方案，例如 Celestia、Eigen DA 或以太坊本身。EspressoDA 与这些解决方案完全兼容，因为数据可用性本身是可加的。Rollup 可以将块数据发布到 EspressoDA 和其他 DA，数据可用性保证是两者中更强的。实际上，这种其他 DA 可以被视为在 EspressoDA 之上的一个附加层。

你可以在我们的学术论文 这里 阅读更多关于 EspressoDA、我们的网络设计和 HotShot 的详细信息。

• 原文链接： hackmd.io/@EspressoSyste...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～