概述
概述
一級標題
事件及背景
一級標題
第一次一級標題
第二次一級標題
事件及背景
通常情況下，以太坊PoS 共識網絡狀態會在2 個Epoch 被敲定（Finalized），而上週出現了兩次Epoch 敲定的延遲。
第一次
發生在5 月11 日，Epoch 的敲定被延遲了3 個Epoch，約20 分鐘。MIN_EpochS_TO_INACTIVITY_PENALTY第二次Inactivity leak發生在5 月12 日，Epoch 的敲定被延遲了8 個Epoch，約51 分鐘。
在事件發生期間，以太坊網絡仍然持續產生區塊並處理交易。然而，由於Validator（驗證節點）的投票率不足，Epoch 無法敲定（即Epoch 得到以太坊PoS 網絡共識級別安全保證）。 Epoch 未能敲定意味著在絕大多數Validator 作惡並出現分叉的情況下，epcoh 可能被回滾，從而導致交易被回滾。實際上，在事件發生的期間，以太坊網絡並未出現分叉，而Validator 也未進行惡意投票，只因大量Validator 離線導致投票率不足，從而使得Epoch 在期間無法被敲定。。
經過觀察，離線的Validator 出現CPU 過載的異常情況，被認為是Validator 離線的直接原因。在第二次事件中，Epoch 敲定被延遲了8 個Epoch，由於敲定延遲大於。
(= 4) 從而觸發了以太坊共識算法
的處理機制。
懲罰離線的Validator，削減其質押資金，
罰沒了約28 個ETH
取消Attestation 的獎勵，導致
原因分析
imToken 自研的Safe Head 服務會基於實時的以太坊共識層數據，計算出安全的區塊用於交易確認，在保證用戶交易安全的前提下，縮短交易確認的時長。正常情況下，imToken 的Safe Head 算法返回的塊高（如上圖黃色），會非常貼近最新的區塊高度（綠色），從而提高用戶體驗。
更多關於Safe Head 機制的資料：
以太坊：Safe Head 機制介紹（一）
原因分析
一級標題
原因分析
造成上述事件的直接原因是某幾種以太坊共識層客戶端節點負載過高，使得Validator 宕機離線，從而無法正常進行共識投票。經過分析，這些節點負載過高的原因是：
本來此類問題可以通過基於見證指向區塊的緩存來解決，然而由於Validator 的規模增長以及大量此類attestation 的出現，導致出問題的客戶端實現的緩存被擊穿，節點不得不消耗大量資源重新計算信標鏈狀態。
一級標題
Prysm：v 4.0.3-hotfix
Teku：v2 3.5.0
共識層客戶端Teku 以及Prysm 目前推出了patch 版本以解決該問題。具體而言，patch 版本的客戶端實現會過濾掉這些陳舊的見證，即當滿足下列條件，忽略該見證：
見證指向一個陳舊的Slot
一級標題
二級標題
一級標題
以太坊設計優勢在此次事件中，以太坊保證可用性仍持續產生區塊並處理交易，而僅推遲Epoch 敲定的關鍵在於兩點：二級標題
二級標題
以太坊客戶端的多樣性
二級標題
一級標題
二級標題
一級標題
圖片描述
一級標題https://clientdiversity.org/#distribution
二級標題
二級標題
以太坊多客戶端的挑戰
圖片描述
可以看到，以太坊客戶端多樣性仍需繼續推廣和宣傳。可以想像，如果客戶端實現足夠多樣，使得Prysm 以及Teku 的佔比小於⅓，那麼這次事件甚至不會發生（⅔ 客戶端正常運作足以敲定Epoch）。另外，當前執行層的客戶端集中在Geth，佔比高達61% 。這實際上存在著潛在風險：如果Geth 運作不當，以太坊會受到很大的影響。
二級標題
除了以太坊客戶端多樣性需要進一步努力外，以太坊客戶端切換也是此次事件暴露的一個痛點：當某個客戶端實現出問題時，Validator 如何切換到正常的客戶端實現之上。此過程涉及：
新舊客戶端分別對分叉兩側的Checkpoint 進行投票，從而被Slash二級標題。
以太坊共識的監控
二級標題
需要類似Safe Head 類似的服務持續監控以太坊PoS 網絡的實時狀態，提前發現並預警該類事件，而非等到Epoch 無法按預期敲定才得知網絡狀態異常。相關的最新研究可見
二級標題
Layer 1 ->二級標題
以太坊共識算法的科普
Oracle 鏈上報價存在被回滾的風險，因此依賴其的高價值服務要適當暫停。
總結
總結
參考鏈接
