以太坊共识中 P2P Overlays 搭便车指南

以太坊中 P2P 覆盖网络漫游指南

由 Louis Thibault 和 Dan Marzec 共同撰写

摘要

信标网络的 p2p 拓扑结构并不为人熟知。在这篇文章中，我们将剖析其底层组件，并回顾一些正在发挥作用的微妙之处和优化。利用这些知识，我们将深入研究信标链的实例化。如果非要说什么的话，可以把这篇文章看作是对 GossipSub + 共识规范的简要说明。

目录

• 摘要
• 目录
• 动机
• 点对点覆盖网络结构与功能
  • Floodsub 和 Randomsub
  • GossipSub 覆盖网络
  • 混合覆盖网络
  • 自优化混合覆盖网络
  • 基于 GossipSub 的 P2P PubSub
• 以太坊共识结构与功能
  • 验证者职责
  • 显式
  • 隐式
  • 加入、退出与诚实
• 以太坊覆盖网络
  • GossipSub 主题
  • 全局主题
  • 委员会
  • 信标
  • 同步
  • 证明聚合
  • 证明聚合打包问题
  • 问题简化
  • 不同的实现
  • 殊途同归：SSF + ZK

动机

广义上讲，以太坊共识层（CL）涉及两个研究领域：密码经济学和分布式系统。在后者中，点对点（P2P）覆盖网络的研究在以太坊 CL 协议 Gasper Proof-of-Stake 的预共识阶段起着至关重要的作用。然而，我们认为，在大多数资源中，这个引人入胜的主题没有得到应有的重视。最近，对 mev-boost 中继的双重投票攻击表明，社区对通过 p2p 层发起的这类攻击部分视而不见。我们的目标是通过本文对这一盲点提供部分补救：介绍支撑以太坊 CL 的 P2P 覆盖网络。

首先，让我们将 P2P 覆盖网络置于以太坊网络中。以太坊网络实际上是两个不同的网络，每个网络都有自己的网络堆栈：执行层（EL）和共识层（CL）。devp2p 项目提供了 EL 的网络堆栈，负责传播最新的执行状态，这些状态本身来源于先前区块中确认的交易。相比之下，CL 采用了一种更高级的 P2P 网络库，称为 libp2p，它具有强化的、高性能的网络原语，更适合用于协调保护网络安全的验证者这项微妙而重要的工作。

顾名思义，共识层（CL）负责维护某种形式的分布式共识。具体来说，它在执行层中的批量计算上维护拜占庭容错共识。冒着简化 Gasper Proof-of-Stake 协议的风险，所有分布式共识最终都归结为消息传递的练习。CL 节点必须交换消息，并对这些数据应用某种逻辑，以便所有参与者最终收敛到单个、完全排序的、链表的交易：一个 区块链。

详细了解这一点需要从两个方面入手

1. 如何在节点之间高效、可靠地共享这些消息；以及，
2. 如何在存在拜占庭故障的情况下实现这种总排序。

为此，我们首先回顾一下 P2P 覆盖网络的基本结构和功能，逐步介绍以太坊 CL 中正在发挥作用的主要优化层。从那里开始，我们对以太坊共识层（CL）中的各种覆盖网络进行简要调查，重点介绍它们的功能、局限性和未解决的研究问题。

点对点覆盖网络结构与功能

在以太坊信标网络上，节点之间需要广播几种数据类型：区块、证明、等等。这是如何实现的？特别是，如何在完全点对点的方式下实现这一点？

Libp2p 提供了一个通用的广播原语，称为“pubsub”。这个名称来源于这样一个事实，即这个广播原语是通过它的 API 定义的，而 API 又定义了一个“发布”和“订阅”方法；节点可以将消息“发布”到一个命名空间（称为“主题”），以及“订阅”主题，这使它们能够接收其他人发布的消息。至关重要的是，此 API 与实现无关，并且存在许多在后台路由消息的策略。

Floodsub 和 Randomsub

最简单的策略称为“泛洪”（或 libp2p 术语中的“floodsub”）。泛洪是 2000 年代早期文件共享网络中流行的一种策略，这主要是由于其极端简单性和弹性。在泛洪网络中，路由是通过让每个节点将每个传入消息转发到其余的对等节点来实现的。在本地，每个节点维护一组先前见过的消息，并避免转发重复消息。这种结构的一个直接问题：泛洪涉及大量消息重复。我们怎样才能做得更好？

第一个也是最明显的优化俗称 "randomsub"。使用此方法，节点通过选择与其连接的对等节点中的 f 个，随机选择，并将消息仅转发给这些 f 个对等节点来路由消息。较大的 f 值（称为“扇出因子”）会导致更快的消息传播（直至泛洪）。第二个因素，称为 v（或“视图大小”），决定了要维护的最大对等连接数（称为“邻居”）。有趣的是，v 对消息传播的速度没有影响。相反，v 值越高，网络的弹性就越强，而与 f 无关（前提是 f 至少是整个网络大小的自然对数）。这使得网络可以牺牲少量延迟来显着减少带宽消耗，而不会威胁到整个覆盖网络的可靠性。Randomsub 用于以太坊的执行层（EL），但未用于其 CL。为什么？

首先，randomsub 仍然面临与泛洪相同的问题；产生出色弹性的相同冗余也会消耗大量带宽。虽然此问题的严重性已大大降低，但实际上仍然存在。但同样重要的是，randomsub 是 随机 选择对等节点。也就是说，它没有选择“最好的”对等节点，这些节点通常是低延迟的节点和改善与其他对等节点连接的节点的混合体。理想情况下，实际上，每个节点只会选择少量的对等节点，从而使网络能够自组织成最小生成树。这正是 CL 通过 libp2p 的 GossipSub 协议实现的。

GossipSub 覆盖网络

从理解 randomsub 到理解 GossipSub 是一个三步过程。我们必须理解

1. 混合覆盖网络，
2. 如何使这些覆盖网络能够自优化其对等连接；以及，
3. GossipSub 协议如何使用这些优化的的覆盖网络来提供 p2p 发布/订阅 API。

让我们依次检查每个步骤。

混合覆盖网络

术语“混合覆盖网络”是指分层两个独立的覆盖网络的系统，分别称为“被动”覆盖网络和“主动”覆盖网络。混合覆盖网络首先出现在对 randomsub 的一种优化中，称为 HyParView（混合部分视图 的组合词）。实际上，HyParView 正在利用 f 和 v 的正交性来生成具有与泛洪相当的弹性的网络。该策略是选择 f 个对等节点，连接到它们，并使用它们来接收/转发所有消息。这是“主动”覆盖网络。同时，通过维护对等地址的有限视图（大小为 v）来构建“被动”覆盖网络。重要的是要强调，被动覆盖网络不会维护与其对等节点的任何长期连接，而是采用可以用于替换主动覆盖网络中损坏连接的有限地址池的形式。

这些覆盖网络的构建和维护超出了本文的范围，但 HyParView 论文 对其进行了直接且充分的记录。简而言之，随着每个对等节点维护网络的两个不同“视图”，这两个覆盖网络便应运而生。被动覆盖网络是通过重复采样网络来构建的，通过预定长度的随机游走，其终点被添加到“被动视图”中。一旦被接纳，被动视图对等节点会定期轮询以获取活动性，如果未响应，则会被驱逐。主动覆盖网络同时通过重复从被动视图中采样来构建，直到达到大小 f。

HyParView 架构的最终结果是一个能够以与泛洪网络相同程度修复自身的网络，同时利用更少的资源（内存、网络 io等等）。但是，就我们的目的而言，重要的是主动覆盖网络和被动覆盖网络的不同行为，我们将在下表中对其进行总结。

请注意，HyParView 不会改善网络的消息传播属性。它仅与解耦 f 和 v 以恢复从泛洪过渡到 randomsub 中丢失的部分鲁棒性有关。在下一小节中，我们将展示如何扩展混合覆盖网络架构以改善网络的实际广播属性。

自优化混合覆盖网络

随机覆盖网络之所以具有鲁棒性，是因为其网络拓扑既稀疏（每个节点都连接到相对较小的对等节点集）又连接良好，即必须有大量连接失败才能使网络被分区。这种连接良好的特性反过来又源于均匀随机图的基本属性：均匀随机对等连接。不幸的是，这种均匀性与效率背道而驰。位于纽约的节点与位于东京的遥远对等节点连接的可能性与位于波士顿附近的对等节点连接的可能性相同。理想情况下，我们希望保留被动覆盖网络的均匀随机分布（因为它负责确保鲁棒的连接），同时最大限度地减少主动覆盖网络中对等节点之间的延迟。

Plumtree 算法（推送、延迟推送多播树 的组合词）通过协调主动视图和被动视图来实现此目的。Plumtree 的核心是寻求将最初的随机图（主动覆盖网络）变成最小生成树。这样做是检测和修剪对等体之间多余连接的问题，同时确保该图保持强连接。

Plumtree 背后的直觉是，重复消息指示存在多余路径，而遗漏消息则指示连接性不足。从那里开始，Plumtree 非常简单，以至于事后看来几乎微不足道。当节点收到重复消息时，它会终止与收到消息的对等节点的连接，并将该对等节点的地址添加到被动视图。同时，额外的元数据会附加到在被动视图中执行的定期活动性检查中。此元数据包含最近查看的消息的标识符（通常是单调递增的序列号或消息哈希），并且具有双重用途。首先，它允许接收对等节点请求可能错过的任何消息的完整有效负载。其次，它表明存在用于消息子集的更快路径。对遗漏消息事件的响应是与相应的对等节点建立连接，并将其提升到主动视图。

或许令人惊讶的是，这就是网络收敛到最小生成树所需的一切。在实践中，唯一额外要求是防止由虚假重复项导致的连接流失。存在几种策略，其中最流行的是在某个时间单位（通常为几秒）内设置重复/遗漏消息事件的阈值，并且仅当超过此阈值时才触发响应。存在其他策略，但所有策略基本上都与平滑连接升级和降级（也称为“嫁接”和“修剪”）有关。

基于 GossipSub 的 P2P PubSub

回到 libp2p 的 PubSub API，我们可能会问如何扩展 Plumtree 以提供面向主题的广播语义。这就是基于 Plumtree 的协议 GossipSub 的作用。

本质上，GossipSub 为每个主题维护一个单独的 plumtree 覆盖网络。这有助于拓扑保持较小规模，从而提高其性能。还值得注意的是，由于对等节点可以动态加入和离开主题，因此它们还可以创建动态主题名称流，并定期迁移到流中的下一个主题。用于生成此类流的简单机制是将主题名称 t1 定义为 hash(t0)，例如。通过将 subscribe 和 unsubscribe 消息发送到对等节点来执行主题的实际加入和离开，并在先前超链接指定的 libp2p 文档中对其进行了详细说明。

除了提供面向主题的 API 之外，GossipSub 还增加了一些子协议，这些子协议提高了它在大型公共网络中使用的适用性。特别是：

1. GossipSub v1.0 添加了控制消息搭载。
2. GossipSub v1.1 添加了各种鲁棒性改进，最值得注意的是：
   • 对等评分
   • 对等交换

我们让读者自行研究这些子协议。在下一节中，我们将列出以太坊共识层中正在发挥作用的一些 GossipSub 主题。

以太坊共识结构与功能

这部分主要依赖于以下内容：🔗共识规范、🔗带注释的规范、🔗为人类准备的第 0 阶段、🔗eth2book，

虽然以太坊 CL 的更精细细节不在本文档的范围内，但仍有必要进行简要说明。与执行层不同，以太坊共识协议的规则会对其拓扑产生直接影响。共识由一组

N 个验证者执行

V={V1,…,VN} 对于

i≤ MAX_VALIDATOR_SET_SIZE，每个验证者之前都已质押一定数量的 ETH

w(Vi) 作为抵押品，以激励“诚实行为”。

验证者协同工作，以就概念上两个不同的账本达成共识，其中一个是可以动态使用的账本，另一个是可以动态使用的账本的最终前缀账本。另一种说法是，Gasper 表现出 “潮起潮落”属性，这意味着它是：

一种灵活的协议，支持两种类型的客户端：保守型客户端，他们倾向于终结并希望在网络分区下保持安全，以及更激进的客户端，他们倾向于可用性并希望在动态可用性下保持活跃。保守型客户端只会信任最终账本，该账本是更激进客户端认为较长的账本的前缀。当网络分区时，最终账本会落后于可用账本，但在网络恢复时会赶上。这种潮起潮落的属性避免了系统范围内的可用性与终结性之间的确定，而是将此决定留给客户端。

两个图表均来自此处。

验证者职责

运行验证者软件的最终目标是赚钱，或者运营一项公共产品，或者两者兼而有之。为了最大限度地提高利润，验证者必须诚实行事，这意味着履行特定的职责。这些职责是使用受控的确定性洗牌随机分配的：

信标链洗牌旨在为validator即将到来的委员会分配（由洗牌和槽位决定），提供至少 1 个 epoch 的前瞻性。请注意，此先瞻性不适用于提案，必须在相关 epoch 期间进行检查。 - 共识规范

有关 RANDAO 的使用以及信标链上随机性的使用和构建的更多信息，请参见此处。

在阅读 共识规范 和原始论文 时，对核心验证者职责的数量有不同的引用。在这里，我们将它们分为两类：显式 和 隐式。

显式

从 第 0 阶段共识规范 中，

验证者对信标链有两个主要职责：提议区块和创建证明。提案发生频率较低，而证明应每个 epoch 创建一次。

我们有两个主要的验证者职责：

• 提议区块
• 创建证明

提议区块 是保持扩展链和包含新交易所必需的。证明 用于就什么是“最终”的一组区块达成协议。你可以将证明视为对上述最终前缀链的投票。

隐式

• 聚合证明

BLS12-381 签名 允许我们将多个证明组合成一个紧凑的证明聚合。聚合允许减少大量证明的验证时间。稍后，我们将解释协议如何随机分配聚合职责。

在 altair 共识规范 中，引入了一项新职责：

• 同步轻客户端

信标链被设计为对轻客户端友好，以便受约束的环境能够以合理的安全性和活跃性访问以太坊。此类环境包括资源受限的设备（例如，用于最小化信任钱包的手机）和计量 VM（例如，用于跨链桥梁的区块链 VM）。

在 altair 硬分叉之后，成为验证者角色的一部分是帮助确保轻客户端可以验证最近的区块以进行同步。使用同步委员会的 Rust 轻客户端示例。

加入、退出与诚实

要进入集合，验证者需要存入 32 Eth，并负责使此余额保持在 16 Eth 以上。目前，余额只能归因于单个公钥，但是有提议取消此上限。退出与进入的过程类似，并且都需要通过信标网络发送消息。可以在下面看到 此流程 的概述：

由于验证者根据当前已知的验证者集合接受和计数消息，因此退出能力会产生一类称为“长程攻击”的攻击。对此类攻击的解决方案是弱主观性检查点，可以在此处阅读更多相关信息。

履行其分配的职责并与其对等体进行协调的验证者被认为是“诚实的”。但是，鉴于即使这些验证者也可能偶尔出现停机，因此在安全性和性能分析中，“诚实”一词可能会产生误导。我们协议的一个主要优势是其动态可用性，它可以确保在网络分区期间持续运行。同时，该协议还旨在处理验证者恶意行为的实例，例如向特定链视图提议两个区块或两个证明。

为了强制执行适当的或“诚实的”行为，该协议合并了“削减条件”——诚实的验证者永远不会违反的规则，并且可以证明地检测到任何违反行为。如果目睹了这些条件，则会触发提议者和证明者的削减事件。此类事件由诚实的验证者发起，他们将冲突的签名提交到网络。

以太坊覆盖网络

你可能已经猜到，与验证者职责相关的所有协调和通信都是通过一组称为“信标网络”的 gossipsub 主题（阅读：覆盖网络集合）完成的。我们在下面详细介绍了这些主题的结构和功能。

从信标网络的这张艺术家渲染图中，我们可以看到每个节点都维护着一个聚合的对等节点集合，这些对等节点集合跨越了它参与的所有协议（包括 GossipSub）。GossipSub 与此“对等节点存储”中的对等节点执行单播消息交换，以便执行高级主题加入/离开操作。在对等节点存储上方的层中，我们看到对等节点如何分组到各种主题（彩色节点）中。每个主题都携带与特定职责相关的消息。

GossipSub 主题

全局主题

信标网络上有六个主题，所有验证者 必须 订阅这些主题才能履行其职责：

beacon_block

这是我们的验证者和节点集达成共识的核心数据类型。

class BeaconBlock(Container):
    slot: Slot
    proposer_index: ValidatorIndex
    parent_root: Root
    state_root: Root
    body: BeaconBlockBody

class BeaconBlockBody(Container):
    randao_reveal: BLSSignature
    eth1_data: Eth1Data  # Eth1 数据投票
    graffiti: Bytes32  # 任意数据
    # 操作
    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
    attestations: List[Attestation, MAX_ATTESTATIONS]
    deposits: List[Deposit, MAX_DEPOSITS]
    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
    sync_aggregate: SyncAggregate  # [Altair 中的新增功能]

BeaconBlock 的两个主要组成部分是 BeaconBlockHeader 和 BeaconBlockBody，它们都是以太坊上盲信标区块构建的关键部分（这启用了 PBS）。签名的 BeaconBlockHeader 在发起提议验证者节点的周围传递，并用作提议信标区块的承诺。承诺世界的两种状态（即 单个槽位的两个 BeaconBlock s）是一种可削减的 offense。

beacon_aggregate_and_proof

生成聚合证明是为了减少验证时间和覆盖网络流量，本文档将进一步扩展此功能的需求。

class AggregateAndProof(Container):
    aggregator_index: ValidatorIndex
    aggregate: Attestation
    selection_proof: BLSSignature

voluntary_exit

加入和退出网络都通过以太坊上的存款和取款合约进行跟踪。来自验证者的消息声明了他们退出网络的意图，这些消息通过此主题传播。

class VoluntaryExit(Container):
    epoch: Epoch  # 可以处理自愿退出的最早 epoch
    validator_index: ValidatorIndex

proposer_slashing 和 attester_slashing

当检测到可削减的 offense 或“双重投票”时，任何见证了世界两种不同状态的承诺的人，通过签名标头或证明，将两种承诺合并为一个对象，并通过这两个主题传播它们，以削减“行为不端”的验证者。可以在此处看到上次用户提交的削减。

class ProposerSlashing(Container):
    signed_header_1: SignedBeaconBlockHeader
    signed_header_2: SignedBeaconBlockHeader

class AttesterSlashing(Container):
    attestation_1: IndexedAttestation
    attestation_2: IndexedAttestation

证明子网：beacon_attestation_{subnet_id}

从 规范 中，

可以使用 compute_subnet_for_attestation 计算证明的正确子网。beacon_attestation_{subnet_id} 主题在整个 epoch 中轮换，方式与在委员会中轮换分片（未来的信标链升级）类似。子网通过 committees_per_slot = get_committee_count_per_slot(state, attestation.data.target.epoch) 每个槽位子网进行轮换。

目前有 ATTESTATION_SUBNET_COUNT = 64 个证明子网。

class Attestation(Container):
    aggregation_bits: Bitlist[MAX_VALIDATORS_PER_COMMITTEE]
    data: AttestationData
    signature: BLSSignature

class AttestationData(Container):
    slot: Slot
    index: CommitteeIndex
    # LMD GHOST 投票
    beacon_block_root: Root
    # FFG 投票
    source: Checkpoint
    target: Checkpoint

同步子网：sync_committee_{subnet_id}

SYNC_COMMITTEE_SIZE = 512

并且

EPOCHS_PER_SYNC_COMMITTEE_PERIOD = 256

class SyncAggregate(Container):
    sync_committee_bits: Bitvector[SYNC_COMMITTEE_SIZE]
    sync_committee_signature: BLSSignature

委员会

如果整个验证者集合同时证明，那么网络上的消息数量将是无法克服的，并且会以不必要的弹性的优势为代价。通过在消息可用性方面进行较小的权衡，我们可以降低节点的要求，因此引入了委员会的概念。

委员会是一个 ValidatorIndexs 数组，每隔一定数量的槽位分配给特定任务。委员会的目的是在验证者之间分配职责。当前 MAX_COMMITTEES_PER_SLOT = 64。

信标

信标委员会负责证明信标区块。

委员会的数量通过常量 MAX_COMMITTEES_PER_SLOT 定义，当前设置为 64。为什么有 64 个？正如 Ben 在此处敏锐地指出的那样：

当前的信标委员会结构受到先前路线图的强烈影响，该路线图包括协议内数据分片。该设计现已弃用，但在我们的每个槽位 64 个信标委员会中仍然保留了它的残余。这些委员会最初旨在直接映射到 64 个分片，因为“交叉链接委员会”不再具有该功能。尽管如此，信标委员会仍然在并行化证明聚合方面发挥着有用的作用。每个槽位 64 个委员会是否仍然是正确的数量尚未进行分析。权衡是，更少的信标委员会会减少聚合证明所需的区块空间量，但会增加聚合器完成其工作所需的时间。

同步

同步委员会负责证明区块的有效性和可用性，以减轻轻客户端的负担。

SYNC_COMMITTEE_SUBNET_COUNT = 4 且 TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE = 16

从 altair 注释规范 中，

同步委员会是 Altair 硬分叉的“旗舰功能”。这是一个由 512 个验证者组成的委员会，该委员会每同步委员会周期（约 1 天）随机选择一次，并且当验证者是当前活动的同步委员会的一部分时，他们应该不断签署作为链的新区块头的每个槽位的区块头。

同步委员会的目的是允许轻客户端跟踪信标区块头的链。其他两项涉及签署区块头的职责（区块提议和区块证明）不适用于此功能，因为计算给定槽位的提议者或证明者需要在整个活动验证者集合上进行计算，而轻客户端无权访问（如果他们有权访问，他们就不会是轻客户端！）。另一方面，同步委员会 (i) 不频繁更新，并且 (ii) 直接保存在信标状态中，允许轻客户端使用他们已经知道的区块头的 Merkle 分支验证同步委员会，并使用同步委员会中的公钥直接验证较新区块的签名。

证明聚合

证明代表了通过我们的覆盖网络传输的大部分流量，并且是最终确定该链所必需的。此处可以找到对聚合器角色的简明解释：

聚合器：在每个子网中，验证者都会广播他们自己的证明。由于我们不希望所有证明都必须传播到整个网络并由每个人处理，因此我们在子网中聚合它们，并且仅在全球范围内传播聚合。每个子网都有一些具有特殊角色的验证者，称为聚合器，这些聚合器以可验证的方式随机（自我）选择 1。每个子网的预期聚合器数量为 TARGET_AGGREGATORS_PER_COMMITTEE = 16，这足以确保每个子网中至少有一个诚实的聚合器具有较高的概率。聚合器的任务是从子网收集单个证明并创建聚合证明，即其数据与所有单个证明相同且其签名是所有单个签名的 BLS 聚合签名（即它们的总和，可以使用聚合公钥进行验证，即所有公钥的总和）的证明。准确地说，他们只聚合与其自身一致的证明，并且这是他们目前执行其聚合职责的唯一激励，因为这在信标链中没有得到奖励。 此外，验证者会因为他们的区块中包含的证明而获得奖励，奖励与证明成正比。聚合者也会获得类似的奖励。下面的可视化解释展示了来自 这里 的 100 万验证者。

如上图所示，证明可以包含在被证明的 slot 之后的下一个区块中。在理想情况下，所有证明都将被聚合并包含在下一个 slot 中，但现实并非如此。下面我们可以看到证明的 slot 包含延迟的分布（注意 y-axis 是对数缩放的），虽然大部分包含在 1 个 slot 之后，但也有很多不是。我们能让这些投票范围越紧密，我们就越能用协议做更有趣的事情。

在这种情况下，聚合对我们的网络起着 4 个重要的作用：

• 减少全局 beacon_attestation_{subnet_id} 主题上的网络负载
• 减少全局 beacon_aggregate_and_proof 主题上的网络负载
• 通过减少签名占用的区块空间来减少网络负载
• 减少下一个区块提议者的签名验证负载

看到这些好处，你可能会问：“如果聚合者能够完美地将一个委员会的证明打包成一个签名，那么为什么聚合主题会收到更多的流量呢？” 这一点，以及生产系统的现实情况，突出了证明聚合的潜在复杂性，并将有助于阐明它在 p2p 流量中的作用。

证明聚合打包问题

共识层中一个非常明确的决定是使用椭圆曲线 BLS12-381，因为它允许签名签名聚合。但我们选择的签名和验证者跟踪方案也对我们施加了限制。让我们来看一个例子：

给定 4 个验证者

V1,V2,V3, v_4，每个验证者都签署

m1,m2,m3,m4 以产生

sig1,sig2,sig3,sig4（每个 96 字节作为参考），我们可以：

聚合签名

(sig1,sig2) 和

(sig3,sig4):

Siga1=Aggregate([Sig1,Sig2]), 并且

Siga2=Aggregate([Sig3,Sig4])。

此外，我们可以将

Siga1,Siga2 聚合成：

Siga12=Aggregate([Siga1,Siga2]),

创建一个聚合的聚合。这种 pairing-friendly 曲线的特性允许我们扩展大量签名的验证。

但有一个细微的差别阻止了我们实现真正的理论效率：我们不能聚合具有重叠的签名集，这意味着：

Siga=Aggregate(Aggregate([Sig1,Sig2]),Aggregate([Sig2,Sig3])

不会产生有效的结果，因为 "我们用来跟踪参与情况的位域无法表示重叠的参与者"。

这产生了一个令人讨厌的问题，验证者现在必须迭代所有可能的聚合组合，以产生最有利可图的结果。

问题简化

事实证明，证明聚合打包 (AAP) 是一个 NP 难优化问题，将其映射到诸如 Maximum Clique Enumeration、Maximum Coverage 和 Set Cover 等问题。近似算法是我们处理此类问题的唯一实际选择。

不幸的是，对这个问题的任何实现中的缺点都超出了资源使用。验证者的证明奖励与其包含的证明数量成正比。鉴于这种情况的严重性，Lighthouse 发布了 AAP 问题的正式分析，结论是：

"鉴于贪婪算法在大多数情况下接近最佳性能，我们不认为证明打包代表了以太坊的重大中心化风险。拥有快速精确求解器的区块提议者产生的区块仅比贪婪算法产生的区块略好，并且仅在少数情况下（0.03%）才能看到大于 5% 的收益。"

不同的实现

这篇帖子 证明聚合策略 很好地解释了第 0 阶段期间存在的方法。一些关于实现的更多链接。

• Nimbus 实现 twitter 帖子
• Prysm eth 研究报告
• Lighthouse 的更多内容

但正如上面提到的，这种对证明的看法受到当前实现/技术的限制，我们能否通过升级协议做得更好？

条条大路通 SSF + ZK

与所有事物（状态增长、审查等）一样，单 slot 最终性 (SSF) 和零知识 (ZK) 证明在未来证明打包中发挥着重要作用。

SSF

目前，只有验证者集的一个子集对每个 slot 进行投票，我们需要一个 epoch 才能达成最终确定，但如果整个验证者集都进行投票，我们可以在两个 slot 内达成最终确定。如果在一个 slot 中进行两次投票，我们可以在 1 个 slot 中完成最终确定。

这有多个重要的结果：

更好的确认用户体验： 用户（包括交易所、桥梁）可以快速依赖经济最终性。

重组预防： 减轻 MEV 可能造成的破坏稳定的影响

可证明的活跃性： 如果每个人都能够同时投票，则更容易保证共识协议将成功地最终确定某些内容，因为我们只需要确保对需要最终确定的内容达成短期协议。例如，提议者可以用作协调点。 - 来源

如下图所示 diagram，进行第二轮证明比第一轮更容易，因为我们可以假设我们有一个不相交的集合。

最深入的多轮聚合提案可以在 here 找到。

最后，在 "Path towards single slot finality" 中，Vitalik 声称这是三个主要问题之一：

确定最佳聚合策略。 对于尽可能高的

N，我们希望将来自

N 个验证者的签名聚合并包含到一个区块中，并且节点开销在我们愿意接受的水平。

ZK

零知识证明的所有“简洁性”属性也可以用于签名聚合。来自 Horn 提案中提到的

众所周知，你可以设计 SNARKs 7 来证明合法的签名被正确聚合。但是，对于我们的用例来说，这种证明系统太慢（在证明者方面）。一种解决方法是证明一个更简单的陈述：提供的公钥是聚合某些公钥以及某些重数的结果。可以使用类似 Bulletproofs 的 IPAs 来设计这种自定义证明系统。

该提案需要额外的 10s，因此目前不太可能以当前形式纳入，但在我们的 p2p 优化之旅中仍然很有趣。现在已经结束了。

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