由于状态过时风险，以太坊验证者被告知禁用 Prysm。

使用 Prysm 共识客户端的以太坊验证节点运营商于 12 月 4 日收到紧急警报。Prysm 团队确认，部分节点正在生成旧状态以处理过时的证明。如果不加以控制，这可能导致错误的验证行为。为防止这种情况发生，Prysm 已通知所有运营商立即在其信标节点中添加一个标志来禁用特定功能。此修复无需客户端完全升级，也不会影响验证节点客户端。

团队指示运维人员添加以下行： `--disable-last-epoch-targets`。此标志适用于 Prysm v7.0.0，这意味着大多数节点可以在几分钟内应用此修复。该警告迅速引发了验证者社区的响应。这凸显了 Prysm 在以太坊共识层中的重要作用。

Prysm的市场份额使此次事件成为网络级事件。

MigaLabs 的数据显示，Prysm 控制着以太坊共识客户端近 20% 的市场份额，使其成为仅次于 Lighthouse 的第二大客户端。正是这种规模使得一个客户端漏洞演变成全链问题。当一个拥有如此重要权重的客户端处理过时的状态数据时，它不仅仅影响一个验证者，而是会波及到：

• 缺失的证明
• 错误的叉选信号
• 极端情况下，处罚或减薪的风险增加。

目前为止，尚无证据表明此次事件导致实时供应链中断或最终性失效。然而，此次事件的关注点在于风险预防，而非事后补救。Prysm 在事态升级前就采取了行动。换句话说，这是一次预防性演练，而非事后补救。

棱镜内部究竟出了什么问题？

据 Prysm 团队称，受影响的节点在尝试处理来自早期纪元的过时证明时，会产生不必要的旧状态。这种行为会增加 CPU 和内存压力，并可能扭曲节点在压力下跟踪链进度的方式。这种行为在以太坊历史上并非首次出现。类似的状态处理问题曾在以下时期出现：

• 2023年5月最终事件
• 先前数据库索引损坏漏洞
• 过去多个客户端都出现过内存峰值问题

这次的关键区别在于速度。Prysm 及早发现了问题，并发布了一步到位的临时解决方案。此外，也避免了强迫数千个验证节点仓促进行全面升级。

验证者现在应该做什么

如果你运行的是 Prysm，那么检查清单很短，而且很紧急：

• 添加–disable-last-epoch-targets标志
• 重启信标节点
• 验证日志以确认认证流程正常。
• 重启后监控内存和 CPU 使用情况

无需更改验证器密钥，无需重新同步，也无需退出。对于整个以太坊而言，此次事件再次印证了一个早已为人熟知的道理：客户端多样性依然至关重要。当一个客户端占据近 20% 的网络份额时，即使是可控的漏洞也会成为头条新闻。然而，此次事件也展现了以太坊的运营成熟度。问题在数小时内而非数天内就被识别、披露并得到缓解。这正是一个运行中、价值超过 4000 亿美元的结算层保持稳健的原因。目前，区块链依然稳定。唯一真正的期限是 Prysm 运营商迅速采取行动，启动安全开关。