以太坊連續兩晚短暫異常分析

5月11日和12日連續兩個晚上，以太坊共識層出現短暫異常。分析表明，這主要是由於某些以太坊共識層客戶端節點負載過高，導致驗證者節點宕機離線。這直接影響了Epoch投票無法達到2/3的閾值，使得共識層無法確認最終性。不過，以太坊網路在短時間內自我恢復正常，這也體現了以太坊PoS共識算法的韌性和自我修復能力。

事件回顧

通常情況下，以太坊PoS共識網路狀態會在2個Epoch內被敲定。但上周出現了兩次Epoch敲定延遲的情況:

• 5月11日:Epoch敲定延遲了3個Epoch，約20分鍾。
• 5月12日:Epoch敲定延遲了8個Epoch，約51分鍾。

在這期間，以太坊網路仍然持續產生區塊並處理交易。但由於驗證者節點的投票率不足，Epoch無法得到敲定，即無法獲得以太坊PoS網路的共識級別安全保證。這意味着在極端情況下，該epoch內的交易可能被回滾。

實際上，在此期間以太坊網路並未出現分叉，驗證者節點也未進行惡意投票。大量驗證者節點離線導致投票率不足是Epoch無法敲定的直接原因。觀察發現，離線的驗證者節點出現了CPU過載的異常情況。

在第二次事件中，由於敲定延遲超過了4個Epoch，觸發了以太坊共識算法的Inactivity leak機制:

• 懲罰離線的驗證者節點，削減其質押資金，約28個ETH被罰沒。
• 取消Attestation獎勵，約50個ETH未被發行。
• 該機制確保在線驗證者最終能掌握以太坊總質押資金的2/3，從而使網路狀態最終能被敲定。

原因分析

造成這一事件的直接原因是某幾種以太坊共識層客戶端節點負載過高，導致驗證者節點宕機離線，無法正常進行共識投票。具體分析如下:

當收到指向陳舊區塊的見證(Attestation)時，節點需要重新計算信標鏈狀態以驗證這些見證，這一過程會消耗大量CPU和內存資源。當同時收到大量指向陳舊區塊的見證時，節點的CPU和內存資源被耗盡，導致這些驗證者節點宕機離線。

理論上這類問題可以通過基於見證指向區塊的緩存來解決。然而，由於驗證者規模增長以及大量此類attestation的出現，導致出問題的客戶端實現的緩存被擊穿，節點不得不消耗大量資源重新計算信標鏈狀態。

共識層客戶端Teku和Prysm已推出補丁版本以解決該問題。補丁版本的客戶端實現會過濾掉這些陳舊的見證，即當滿足以下條件時忽略該見證:

• 見證指向一個陳舊的Slot
• 見證指向一個節點從未見過的Checkpoint

以太坊設計優勢

在此次事件中，以太坊保持了可用性，持續產生區塊並處理交易，僅推遲了Epoch敲定。這主要得益於兩點:

1. 以太坊客戶端的多樣性
2. Gasper算法的設計

以太坊客戶端的多樣性

雖然Teku和Prysm客戶端出現問題，但不影響其他共識層客戶端的正常運作。例如Lighthouse客戶端本次並不受影響。由於不同客戶端在實現設計上存在差異，因此仍有驗證者節點正常運作。

以太坊客戶端的多樣性確保了:即使某些客戶端出現問題(甚至導致Epoch不能敲定)，也不會影響正常客戶端產生區塊並處理交易，保證了以太坊的可用性。

Gasper共識算法對可用性的設計

保證以太坊的可用性是Gasper算法設計的出發點之一，它將區塊生產與敲定分離。因此，即使區塊敲定受阻，區塊的產生並不會停止。考慮到大多數情況下區塊敲定最終會恢復，對用戶的實際影響很小。

相比之下，其他BFT共識算法在區塊敲定失敗時，共識節點會停止產出下一個區塊，導致整個區塊鏈在此期間不可用。

此外，第二次事件還觸發了Inactivity Leak機制，這一機制主要是爲了保證以太坊在極端情況(大量驗證者長時間離線)下仍能重新敲定區塊。

經驗與啓示

以太坊多客戶端的挑戰

當前以太坊客戶端多樣性仍需繼續推廣和宣傳。如果客戶端實現足夠多樣，使得Prysm和Teku的佔比小於1/3，那麼這次事件甚至不會發生(2/3客戶端正常運作足以敲定Epoch)。

此外，當某個客戶端實現出問題時，驗證者節點如何安全地切換到正常的客戶端實現也是一個需要解決的問題。這個過程涉及:

• 將出問題客戶端的驗證密鑰安全遷移到正常客戶端上
• 確保舊客戶端與新客戶端的行爲一致性，避免被懲罰

以太坊共識的監控

需要類似Safe Head的服務持續監控以太坊PoS網路的實時狀態，提前發現並預警此類事件，而不是等到Epoch無法按預期敲定才發現網路狀態異常。

以太坊共識算法的科普

這次事件暴露了科普以太坊PoS共識機制的必要性。許多用戶誤以爲"以太坊掛了"，造成不必要的恐慌。實際上，以太坊網路一直在持續產生區塊並處理交易。面向用戶的區塊鏈知識科普仍然是從業者需要持續努力的方向。

對以太坊應用的啓示

雖然以太坊網路足夠健壯，但偶爾的不穩定會對應用產生一定影響。應用需要正確處理這些不穩定場景:

• Layer1到Layer2的存款時間可能變長
• 交易所的充值時間可能延長
• Oracle鏈上報價存在被回滾風險，依賴其的高價值服務應適當暫停
• 某些DeFi應用可能需要暫停部分功能

總結

這次事件展示了以太坊PoS共識算法的韌性與自我修復能力，以及客戶端團隊的快速響應與錯誤修正能力。對以太坊生態而言，還需在以下方面持續投入:增加客戶端多樣性，優化網路狀態的實時監控與預警，深化用戶教育，完善生態參與者在網路異常時的緊急預案。