使用快速确认规则回放一年的主网数据

EthPandaOps 发布于 2026-05-27 阅读 153

本文介绍了ethpandaops团队构建的fcr-simulator,用于回放以太坊主网信标链历史数据,模拟Fast Confirmation Rule(FCR)在多个共识层客户端(Lighthouse、Lodestar、Grandine、Teku)中的表现。

使用快速确认规则重放一年的主网

我们构建了 fcr-simulator 来回答一个简单的问题:如果 快速确认规则 已经在主网上运行,它会做出什么判断?

为了研究这一点,我们通过 4 个共识层客户端的 FCR 实现重放了历史主网信标链数据。每个客户端都看到相同的区块、相同的证明和相同的截止规则。然后我们比较了每个实现如何对每个 slot 进行分类。

本文将介绍模拟器、数据集、用于运行重放的基础设施,以及 v0.2.0 数据集的结果。

有关 FCR 本身的背景信息,fastconfirm.it 是最佳起点。

模拟器

模拟器的功能范围被刻意收窄。它的工作是将相同的主网历史和证明数据输入到多个 FCR 实现中,然后记录每个 slot 的结果。

系统的核心是一个 orchestrator(编排器)。编排器接收任务规范,启动一个引擎(如 lighthouse),并为该引擎提供所需的数据。引擎通过 HTTP 回调编排器。

这种分离对于可重现性是一大步。编排器负责获取区块和证明,而每个客户端实现负责应用其 FCR 逻辑。这使得多客户端模拟器更易于理解,也意味着我们可以交换或重放数据源,而无需在每个客户端中重新实现数据加载。

我们还在模拟运行之前“预热”信标节点,以填充其分叉选择存储和任何缓存。对于下面的运行,我们使用 10 个 epoch 的证明预热了每个信标节点。

图表:编排器 slot 循环驱动引擎子进程

数据

模拟器使用我们从其他 ethpandaops 基础设施中已有的数据:

  • 区块
    • 来自 era 文件的标准区块,使用 Nimbus 团队的镜像
    • 来自 ethpandaops/tracoor 的孤立区块
  • 证明
    • 来自 ethpandaops/xatu 的单个证明,这些证明在 12 秒截止时间前为每个区块投票

证明数据集并非信标节点当时实际体验的完美还原。 对于某些 slot,这种网络视图报告的证明可能比普通信标节点更多。反之,对于其他 slot,这种视图的证明可能更少。这些数据也完全忽略了 aggregate (聚合)证明。我们假设在主网上证明聚合是稳定且可靠的,因为大多数节点从聚合中获得 62/64 的证明。

运行模拟

一次一个 slot 地重放一年的主网分叉选择会慢得无法使用。slot 状态转换开销很大,并且对 Xatu 数据库的重复查询会增加更多开销。

为了使实验可行,我们将其作为分片 Kubernetes 任务运行。我们还对 Xatu 执行了一次性查询,并将结果存储在我们的内部 S3 集群中。这样每个运行都有相同的输入数据,并避免了在模拟期间重复查询数据库。

图表:跨 k3s 集群的分片重放拓扑

我们以 1 到 3 个月 epoch 范围运行模拟。这主要是一个实际选择:如果某个任务在长时间运行的末尾失败,我们希望限制可能丢失或需要丢弃的工作量。

在基准测试后,我们在 6 台 Hetzner AX162 服务器上运行了 96 个信标节点。每台服务器运行 16 个信标节点。我们还将每个客户端数据库挂载到 RAMFS 中,以最小化昂贵的磁盘读写。

该工作负载高度受限于内存,但与顺序重放相比,此设置仍然为我们提供了大约 25 倍到 35 倍的加速。

结果

注意事项

大约 24 小时的 slot(占数据集的 0.27%)被排除在下面的所有图表和数字之外。这包括 8 次 Xatu 管道维护期,总计约 15.5 小时,以及 2026-04-01 的一次 8.4 小时模拟器馈送错误。

覆盖范围

客户端 Epoch 范围 日期 (UTC) Slots
Lighthouse 369,000 到 449,000 2025-05-29 到 2026-05-20 2,560,000
Lodestar 417,500 到 449,000 2025-12-31 到 2026-05-20 1,008,000
Grandine 423,800 到 449,000 2026-01-28 到 2026-05-20 806,400
Teku 423,800 到 449,000 2026-01-28 到 2026-05-20 806,400

各客户端的月度 1-slot FCR 率

延迟 1 个 slot 时快速确认的 slot 百分比,按日历月(UTC)分组

LighthouseLodestarGrandineTeku

2025-052025-062025-072025-082025-092025-102025-112025-122026-012026-022026-032026-042026-0590.9%93.9%96.9%99.2%Fusaka 不稳定期

来源:v0.2.0 fcr-simulator 数据集的各 CSV 月度聚合。在块边界处覆盖不完整的月份仅包含该月出现的 slot。

确认距离分布

在头部 X 个 slot 内快速确认的 slot 百分比 — 每个客户端的完整窗口

Y 轴linear(线性)log(对数)

标记P90P99P99.9P99.99

LighthouseLodestarGrandineTeku

19172532confirmation_delay_slots(确认延迟 slot 数)1e-4%1e-3%0.01%0.10%1.00%10.00%100.00%未确认百分比 (100 - CDF, log)

Lighthouse · P99

≤ 3 slots

Lodestar · P99

≤ 3 slots

Grandine · P99

≤ 3 slots

Teku · P99

≤ 2 slots

CDF 根据每个客户端 CSV 窗口中的每个 slot 计算。对数模式绘制未确认尾部 (100 - CDF),以便显示重尾。

随时间变化的确认距离

每日汇总。空白处是已知 xatu 管道中断窗口内的天数(这些天数从基础数据中移除)。

指标P50 延迟P95 延迟P99 延迟1-slot FCR 率

LighthouseLodestarGrandineTeku

2025-062025-072025-082025-092025-102025-112025-122026-012026-022026-032026-042026-0565.0%74.0%83.0%92.0%100.0%Fusaka 不稳定期

线条中的空白是位于 xatu 管道中断窗口内的天数。

我们的发现

最重要的数字是:零次错误确认。在 515 万个 slot 评估中,所有四个客户端没有任何实现快速确认了一个最终被证明在最终链上非标准的区块。模拟器在合并步骤中检查每个引擎的 confirmed_root 与 ERA 文件中该 slot 的标准区块,在整个 12 个月期间(包括 2025 年 12 月 4 日的 Fusaka 主网不稳定期),都没有发现任何不匹配。

总体比率:在可比窗口内的 80 万个主网 slot 中,大约 每 100 个 slot 中有 96 个会在 12 秒内被快速确认

四个客户端中有三个在哪些 slot 符合条件上几乎完全一致。Lighthouse 和 Grandine 报告的 1-slot 比率精确到小数点后四位(95.6929%),并且在共享窗口中的每个 slot 上都一致。Lodestar 的比率为 95.6896%,在 80 万 slot 中仅有 26 个 slot 的差异。基本上是噪声。

Teku 是个例外。 它报告了 97.2658%,在相同窗口内将比其他人多 12,575 个 slot 标记为快速确认。

可重现性

v0.2.0 版本中的每个 CSV 都固定到特定的引擎镜像标签。每个引擎镜像标签固定到上游 git 引用。

完整的映射在发布版本的 METADATA.json 中,包括:

  • 模式
  • 运行参数
  • 证明源模式
  • 每个 CSV 的镜像 SHA
  • 每个引擎的上游提交

你可以使用以下命令下载数据集:

curl -L https://github.com/ethpandaops/fcr-simulator/releases/download/v0.2.0/fcr-data-2026-05-26.tar -o fcr-data.tar
tar -xf fcr-data.tar

编排器和引擎可在 https://github.com/ethpandaops/fcr-simulator 获取。

爱你的,

EthPandaOps 团队

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

相关文章

0 条评论