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

近日，以太坊共識層連續兩個晚上出現短暫異常。分析顯示，這主要是由於某些以太坊共識層客戶端節點負載過高，導致驗證者節點宕機離線。這直接影響了Epoch投票無法達到所需的2/3比例，使得共識層無法確認最終性。不過，網路很快就自我恢復正常，反映出以太坊PoS共識算法具有良好的韌性和自我修復能力。

事件回顧

5月11日和12日連續兩晚，以太坊PoS共識網路的Epoch敲定出現延遲：

• 5月11日：Epoch敲定延遲約20分鍾（3個Epoch）
• 5月12日：Epoch敲定延遲約51分鍾（8個Epoch）

值得注意的是，在此期間以太坊網路仍能持續產生區塊和處理交易。異常的根本原因是大量驗證者節點離線，導致投票率不足，無法達成Epoch敲定所需的共識。

觀察發現，離線的驗證者節點出現CPU過載異常，這被認爲是節點離線的直接原因。

第二次事件中，由於Epoch敲定延遲超過了預設閾值，觸發了以太坊共識算法的懲罰機制：

• 對離線驗證者進行懲罰，削減約28個ETH質押資金
• 取消Attestation獎勵，約50個ETH未被發行
• 該機制確保在線驗證者最終能掌控2/3以上質押資金，從而使網路狀態恢復正常

原因分析

造成此次異常的直接原因是某些以太坊共識層客戶端節點負載過高，導致驗證者宕機離線，無法正常參與共識投票。具體分析如下：

1. 當節點收到指向陳舊區塊的見證（Attestation）時，需要重新計算信標鏈狀態以驗證這些見證，這會消耗大量CPU和內存資源。

2. 同時收到大量指向陳舊區塊的見證時，節點資源被耗盡，導致驗證者宕機離線。

3. 雖然可以通過緩存來解決此類問題，但由於驗證者規模增長和大量此類attestation的出現，導致某些客戶端實現的緩存被擊穿，節點不得不消耗大量資源重新計算狀態。

目前，共識層客戶端Teku和Prysm已推出修復版本來解決這一問題。修復版本會過濾掉陳舊的見證，即當見證指向陳舊Slot或節點未見過的Checkpoint時，將忽略該見證。

以太坊設計優勢

此次事件凸顯了以太坊在設計上的兩個優勢：

1. 客戶端多樣性： 不同客戶端實現的設計差異，使得部分客戶端（如Lighthouse）在此次事件中不受影響，保證了網路的持續運行。

2. Gasper共識算法設計：

   • 將區塊生產與敲定分離，即使敲定受阻，區塊生產仍能繼續。
   • Inactivity Leak機制確保在極端情況下網路仍能重新達成共識。

經驗與啓示

1. 客戶端多樣性仍需加強： 當前以太坊客戶端多樣性仍有提升空間。如果Prysm和Teku佔比小於1/3，此次事件可能就不會發生。

2. 客戶端切換機制需完善： 當某個客戶端出現問題時，如何安全高效地切換到其他正常客戶端，是一個需要解決的問題。

3. 加強共識網路監控： 需要開發類似Safe Head的服務，持續監控以太坊PoS網路狀態，及時發現並預警異常。

4. 加強用戶教育： 普及以太坊PoS共識機制知識，避免用戶產生不必要的恐慌。

5. 應用層面的影響：

   • Layer1到Layer2的存款時間可能延長
   • 交易所充值時間可能延長
   • 預言機數據可能面臨回滾風險
   • DeFi應用需要適當調整運營策略

總結

此次事件展示了以太坊PoS共識算法的韌性和自我修復能力，以及開發團隊的快速響應能力。未來以太坊生態還需在客戶端多樣性、網路監控、用戶教育和應急預案等方面繼續努力，以進一步提升網路的穩定性和可靠性。