Prysm 详情 Fusaka 主网宕机与 382 ETH 损失

在 Fusaka 期间，Prysm 节点在重负载的验证任务下失败，导致约 18.5% 的插槽未被确认，参与度低下，损失了 382 ETH。

不同步的验证任务迫使 Prysm 重放旧的信标状态，触发了数千次昂贵的重计算和资源耗尽。

Prysm 通过配置标志和后续版本缓解了该问题，更新了验证逻辑以避免历史状态的重放。

以太坊的 Fusaka 主网升级在 2025 年 12 月 4 日遇到中断，原因是在验证任务处理过程中 Prysm 节点失败。该问题发生在 Fusaka 升级窗口期间的以太坊主网，涉及 Prysm 共识客户端团队。问题源于资源耗尽，导致验证者响应延迟，错过了纪元，参与度下降，验证者奖励损失。

资源耗尽中断 Fusaka 纪元

在事件期间，几乎所有 Prysm 信标节点在高负载下难以处理特定的验证任务。值得注意的是，问题影响了从 411439 纪元到 411480 纪元的约 42 个纪元。然而，节点未能及时响应验证者请求，导致区块和验证任务的遗漏。

在此范围内，网络丢失了 1,344 个插槽中的 248 个区块。因此，未确认插槽的比例大约为 18.5%。网络参与度也大幅下降，在高峰期间降至接近 75%。

验证者在减速期间遭受了可衡量的损失。根据 Prysm 团队的说法，未确认的验证奖励总计约为 382 ETH。这些损失随着验证者无法及时提交证明而累积。

不同步的证明导致大量重计算

根据 Prysm 的报告，根本原因涉及可能不同步的节点发出的验证任务。这些证明引用了前一纪元的区块根，而非当前链的视图。然而，Prysm 试图进行完整验证以符合以太坊共识规则。

为了验证每个证明，Prysm 不断重建较旧的信标状态。这个过程需要重放过去的区块并执行昂贵的纪元转换。在高并发情况下，节点试图同时进行数百次此类重算。

一个例子涉及引用纪元 411441 中的区块 0xc6e4ff 的验证任务。Prysm 重放了多次状态转换以进行验证。值得注意的是，工程师在基础设施中观察到这种行为近 4,000 次。

修复、检测与持续监控

在事件期间，Prysm 团队建议用户在版本 7.0.0 中启用 --disable-last-epoch-target 标志。这一临时措施减轻了状态重算的压力。重要的是，这避免了紧急客户端版本的发布。

随后，版本 7.0.1 和 7.1.0 引入了永久性修复。这些更新将验证任务的验证改为依赖于头状态，避免了历史重放。团队警告不要使用 --ignore-unviable-attestations 标志。

检测主要通过核心开发者和用户的报告实现。指标显示重放次数上升、资源使用率高企，以及 gRPC 请求失败。根据 Prysm 引用的 Miga Labs 数据，客户端分布在恢复过程中发生了变化，凸显了持续的多样性问题。

“Prysm 详细介绍 Fusaka 主网故障及 382 ETH 损失”一文刊载于 Crypto Front News。访问我们的网站，阅读更多关于加密货币、区块链技术和数字资产的精彩文章。