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

近日，以太坊共識層出現短暫異常，引發業內廣泛關注。本文將對該事件進行深入分析。

事件概述

5月11日和12日連續兩個晚上，以太坊共識層出現短暫異常。分析顯示，這主要是由於某些以太坊共識層客戶端節點負載過高，導致驗證節點(Validator)宕機離線。這直接影響了Epoch投票，使其無法達到所需的2/3閾值，導致共識層無法確認最終性。

值得注意的是，盡管出現異常，以太坊網路在短時間內就自我恢復正常。這體現了以太坊PoS共識算法的韌性和自我修復能力。

事件細節

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

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

盡管Epoch未能按時敲定，以太坊網路仍然持續產生區塊並處理交易。然而，由於驗證節點的投票率不足，Epoch無法獲得以太坊PoS網路的共識級別安全保證。

值得一提的是，在第二次事件中，由於敲定延遲超過了預設閾值，觸發了以太坊共識算法的Inactivity leak機制。這導致了約28個ETH被罰沒，約50個ETH未被發行。

原因分析

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

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

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

3. 雖然這類問題可以通過基於見證指向區塊的緩存來解決，但由於驗證節點規模增長和大量此類attestation的出現，導致出問題的客戶端實現的緩存被擊穿。

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

以太坊設計優勢

在此次事件中，以太坊展現了其設計優勢：

1. 客戶端多樣性：不同客戶端的實現設計不同，即使某些客戶端出現問題，也不會影響其他客戶端的正常運作。

2. Gasper算法設計：將區塊生產與敲定分離，即使區塊敲定受阻，區塊的產生也不會停止，保證了網路的可用性。

經驗與啓示

1. 客戶端多樣性仍需加強：目前以太坊客戶端多樣性仍有提升空間，特別是執行層客戶端集中在Geth，佔比高達61%，存在潛在風險。

2. 客戶端切換機制需完善：當某個客戶端實現出問題時，如何安全地切換到正常的客戶端實現仍是一個挑戰。

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

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

5. 應用層需做好應對：Layer2、交易所、Oracle等應用需要正確處理網路不穩定的場景，如適當延長確認時間或暫停服務。

總結

這次事件展示了以太坊PoS共識算法的韌性和自我修復能力，同時也暴露了一些需要改進的方面。未來，以太坊生態需要在客戶端多樣性、網路監控、用戶教育等方面持續投入，以提升整個網路的穩定性和可靠性。