Prysm 詳情 Fusaka 主網故障與 382 ETH 損失

Prysm 節點在 Fusaka 期間在重負載的驗證見證中失敗，導致約 18.5% 的插槽未被確認，參與度低下以及 382 ETH 的損失。

不同步的驗證見證迫使 Prysm 重放舊的信標狀態，觸發了數千次成本高昂的重新計算和資源耗盡。

Prysm 通過配置標誌和後續版本來緩解該問題，更新驗證邏輯以避免重複重放歷史狀態。

以太坊的 Fusaka 主網升級於 2025 年 12 月 4 日遇到中斷，原因是在驗證處理期間 Prysm 節點失敗。該問題在 Fusaka 升級窗口期間發生在以太坊主網，牽涉到 Prysm 共識客戶端團隊。由於資源耗盡，導致驗證者回應延遲，並造成 epoch 遺失、參與度降低，以及驗證者獎勵損失。

資源耗盡干擾 Fusaka epoch

事件期間，幾乎所有 Prysm 信標節點在高負載下都難以處理特定的驗證見證。值得注意的是，問題影響了 epoch 411439 至 411480，跨度約 42 個 epoch。然而，節點未能及時回應驗證者請求，導致遺失區塊和驗證。

在這一範圍內，網路損失了 1,344 個插槽中的 248 個區塊。因此，遺失插槽率約為 18.5%。網路參與度也急劇下降，在高峰期間降至約 75% 的低點。

驗證者在減速期間遭受明顯損失。根據 Prysm 團隊的說法，遺失的驗證見證獎勵總計約 382 ETH。這些損失隨著驗證者無法及時提交證明而積累。

不同步的證明導致大量重計算

根據 Prysm 報告，根本原因涉及可能不同步的節點所提供的驗證見證，這些證明引用了上一個 epoch 的區塊根，而非當前鏈視圖。然而，Prysm 嘗試進行完整驗證以符合以太坊共識規則。

為了驗證每個證明，Prysm 重複構建較舊的信標狀態。這一過程需要重放過去的區塊並執行昂貴的 epoch 轉換。在高併發情況下，節點試圖同時進行數百次此類重算。

其中一個例子涉及引用 epoch 411441 的區塊 0xc6e4ff 的驗證見證。Prysm 重放了多次狀態轉換來驗證該見證。值得注意的是，工程師觀察到這種行為在基礎設施中發生了近 4,000 次。

修復、檢測與持續監控

在事件期間，Prysm 團隊建議用戶在版本 7.0.0 中啟用 --disable-last-epoch-target 標誌。這個臨時措施減少了狀態重算的壓力。重要的是，它避免了緊急客戶端版本的發布。

稍後，版本 7.0.1 和 7.1.0 引入了永久性修復。這些更新改變了驗證見證的驗證方式，改為依賴 head 狀態，避免歷史重放。團隊也警告不要使用 --ignore-unviable-attestations 標誌。

偵測則來自核心開發者和用戶的報告。指標顯示重放次數增加、資源使用率高，以及 gRPC 請求失敗。根據 Prysm 引用的 Miga Labs 數據，恢復期間客戶端分佈出現變化，凸顯持續的多樣性問題。

「Prysm 詳細 Fusaka 主網中斷及 382 ETH 損失」的文章出現在 Crypto Front News。請訪問我們的網站，閱讀更多關於加密貨幣、區塊鏈技術與數字資產的精彩文章。