Hoodi 上的 Electra：证明打包

上周，新成立的 Hoodi 网络成功激活了 Electra 分叉，显著改变了证明（attestation）被打包到信标块（beacon block）中的方式，详情参见 EIP-7549。本文回顾了之前证明聚合的工作方式，以及最近的分叉如何改变了这一切，然后深入进行一些分析。

查看 Prysm 的 Terence 的文章，了解有关 Hoodi 中证明性能的详细分析。

背景

Electra 之前

之前，证明在签名数据中包含 committee_index。

• 证明只能在其特定的委员会中聚合，限制了整体聚合效率。
• 来自不同委员会的相同投票会产生不同的签名。

Electra 之后

通过 EIP-7549，证明结构发生了变化，即将 committee_index 字段移到签名数据之外。

• 现在可以聚合来自不同委员会的相同投票，从而大大减少了唯一证明的数量。
• 签名验证的效率显着提高，例如，在拥有 262,144 个验证器的网络中，获得三分之二多数所需的证明从大约 1,366 个急剧下降到 22 个左右。

虽然这些变化提供了巨大的潜力，但也存在这些变化会对性能产生负面影响的风险。在概述了这些变化之后，让我们探讨一下 Electra 在 Hoodi 上的展开情况。

分析

用于生成以下分析的原始 Jupyter notebook 可在此处获得：here。

方法论

以下参数被用于分析：

• 2 个 6 小时的时间段：
  • Electra 之前：2025-03-25T12:10:00Z 到 2025-03-25T18:10:00Z
  • Electra 之后：2025-03-27T12:10:00Z 到 2025-03-27T18:10:00Z
• 数据是使用 Xatu 从 Hoodi 网络收集的（请密切关注即将发布的 Hoodi 公共数据！）。
• 分析着眼于规范的信标块，并检查了其中包含的证明。
  • 此分析检查了证明打包效率（以及通过代理聚合性能），而不是评估证明投票的正确性。
• 我们天真地假设客户端团队正在运行他们开发的客户端。
  • 在分析期间，由 ethPandaOps 团队管理的 Nimbus 密钥专门使用了 Nimbus 信标节点客户端。
• ethPandaOps 验证器密钥使用多个信标节点客户端。

结果

每个块的唯一验证器

我们的第一个指标检查了在两个时间段内聚合的每个块中包含的唯一验证器的计数。

通过 Electra 分叉，我们期望看到每个块的唯一验证器数量大大增加，因为现在可以包含较旧的证明。请注意，此指标在设计上包括过时的证明。

🔍 点击放大

我们的分析证实了每个块的唯一验证器索引显着增加，某些块包含多达 200,000 个唯一验证器。

新鲜证明

第二个指标评估每个块的新鲜证明数量。新鲜证明定义为在任何先前块中都未见过的验证器投票。由于证明以 聚合 的方式进入信标块，因此不可避免地会包含一些过时的证明，因为可能会发生重叠。但是，我们希望尽可能多地包含新鲜证明。

🔍 点击放大

该分析证实，由于 EIP-7549，容量明显且大幅增加。在 Hoodi 上拥有 108 万个验证器的情况下，每个插槽（slot）大约可以发生 33.7k 个证明。Electra 块的第 80 个百分位数与此数字非常吻合，而在第 90 个百分位数处显着跃升至大约 60k 个证明——大概是在错过一个插槽之后。

令人惊讶的是，一些块包含多达 120k 个新鲜证明。虽然容量增加很好，但这也表明网络可能正在遇到问题。从统计上讲，在 90% 的参与度下观察到连续四个错过插槽的机会约为 1/10,000。鉴于我们的分析仅涵盖 3,276 个块，因此我们不太可能观察到这样的事件。

🔍 点击放大

确认我们没有看到任何连续错过 4 个插槽的块，我们现在可以问一个问题：为什么区块提议者有机会包含比 1、2 或 3 个错过插槽更旧的新鲜证明？

包含距离

包含距离衡量证明的创建与其包含在块中的插槽数。在理想情况下，包含距离应为一个插槽。

🔍 点击放大

该分析显示，Electra 之后，Nimbus 客户端块的包含距离显着增加，这表明打包策略可能有所改进。

最佳包含距离

最佳包含距离指标计算块中包含距离仅为一个插槽的证明数量，突出了区块提议者捕获最新证明的能力。

注意：这与 ethdo's 加粗head timely加粗 指标略有不同，后者还考察了投票的正确性。

🔍 点击放大

Nimbus 的退步幅度似乎大于其他客户端，这需要进一步调查。Grandine 的表现似乎也比其他客户端差，尽管分叉前/后的变化没有那么大。

🔍 点击放大

深入研究仅 Nimbus 产生的块，我们可以看到大约 40% 的块未能包含任何最新的证明。这个异常值暗示 Nimbus 证明打包策略可能还有改进的空间。

🔍 点击放大

在排除 Nimbus 的情况下，在网络级别查看相同的指标，我们发现性能仍然下降了约 6%。

这有点令人担忧。很难将其归因于网络参与度的下降，在分叉之前和之后，网络参与度保持在 90% 左右。这可能暗示在证明到达区块提议者之前，整个网络的证明聚合存在潜在的效率低下问题，但这超出了本文分析的范围。客户端很可能仍在微调其证明打包策略，我们预计随着时间的推移，该指标会有所改善，尤其是在 Electra 进入主网之前。

结论

Electra 分叉增强了包含在信标块中的证明的容量。但是，这些进步突出了高效聚合和主动打包策略的日益重要性。

虽然我们观察到了一些好坏参半的结果，但 EIP-7549 中引入的更改很有希望，我们预计从长远来看，这些更改将对信标链产生净积极影响，尤其是在动荡时期。

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