以太坊Fusaka升级事件解析：Prysm事后报告揭示失败根因

Prysm 开发团队近日发布事后分析报告，详细解释了 2025 年 12 月 4 日 Fusaka 升级后出现的主网异常事件。该问题一度威胁以太坊网络稳定性，但最终在客户端多样性机制的作用下得以化解。

报告显示，问题发生在 Fusaka 升级激活后的第 411,392 个 epoch（12 月 4 日 21:49 UTC）。Prysm 共识客户端在处理特定证明数据时，触发了大量历史状态的重复计算，导致 CPU 与内存资源被迅速耗尽，节点出现拒绝服务（DoS）式性能退化。这并非协议设计缺陷，而是客户端在特定边界条件下的实现问题。

受影响的 Prysm 验证节点约占全网的 15% 至 22.71%。事件期间，验证者整体参与率从正常的 95% 以上骤降至约 75%，网络连续错过 41 个 epoch，造成约 382 枚 ETH 的证明奖励损失，并一度接近失去最终性。Prysm 核心开发者 Terence Tsao 指出，历史状态回放计算量极大，多线程并行触发时会显著拖慢节点性能。

值得注意的是，Fusaka 升级本身是成功的。该升级引入了 PeerDAS（对等数据可用性采样）技术，目标是将 Layer 2 的 blob 容量提升至原来的八倍，升级过程未出现停机或共识分叉。

以太坊网络之所以避免更严重后果，关键在于客户端多样性。除 Prysm 外，Lighthouse、Teku、Nimbus 等其他十个共识客户端在整个过程中保持正常出块，使约 75% 至 85% 的验证者持续在线，确保网络最终性未被破坏。若类似问题发生在占比更高的客户端上，后果可能更为严重，包括 Layer 2 汇总暂停和验证者提现受阻。

事件发生后，以太坊基金会迅速发布应急指引，Prysm 团队先行部署临时运行时修复，并在 v7.0.1 与 v7.1.0 中推出永久性解决方案。到 12 月 5 日，网络参与率已恢复至接近 99%，以太坊主网在 24 小时内全面恢复正常运行。