以太坊網絡 Finalize 延遲事件分析報告_以太坊

概述

5 月 11、12 日連續兩天晚上，以太坊共識層短暫異常，imToken 分析該異常主要某幾種以太坊共識層客戶端節點負載過高，使得 Validator 宕機離線，直接導致 Epoch 投票無法達到 2/3，共識層無法確認最終性，但短時間過后以太坊網絡自我恢復正常，imToken 認為這表明以太坊 PoS 共識算法具備韌性和自我修復的能力。

事件及背景

通常情況下，以太坊 PoS 共識網絡狀態會在 2 個 Epoch 被敲定（Finalized），而上周出現了兩次 Epoch 敲定的延遲。

第一次發生在 5 月 11 日，Epoch 的敲定被延遲了 3 個 Epoch，約 20 分鐘。

第二次發生在 5 月 12 日，Epoch 的敲定被延遲了 8 個 Epoch，約 51 分鐘。

在事件發生期間，以太坊網絡仍然持續產生區塊并處理交易。然而，由于 Validator（驗證節點）的投票率不足，Epoch 無法敲定（即 Epoch 得到以太坊 PoS 網絡共識級別安全保證）。Epoch 未能敲定意味著在絕大多數 Validator 作惡并出現分叉的情況下，epcoh 可能被回滾，從而導致交易被回滾。

以太坊測試網Goerli/Prater合并于8月4日開始，合并后保留Goerli名稱:7月28日消息，以太坊協議支持團隊發布Goerli–Prater合并公告，稱在最后一次測試網PoS轉換中，Goerli即將與Prater合并，且合并后的網絡將保留Goerli的名稱。其中合并過程分為兩個步驟，首先從共識層上的網絡升級Bellatrix開始，預計于UTC時間2022年8月4日12:24（北京時間8月4日20:24）開始，隨后是執行層的Paris升級，預計將在UTC時間2022年8月6日至12日之間進行（總難度10790000）。合并后，Goerli的驗證節點網絡將保持開放，供各個權益者運行測試網驗證節點。

假設在Goerli/Prater合并過程中沒有發現任何問題，一旦客戶端發布了功能完整的版本，將在主網信標鏈上為Bellatrix升級選擇插槽高度，并為主網過渡設置總難度值。然后，客戶端將發布在主網上啟用The Merge（合并）的版本。[2022/7/28 2:42:58]

實際上，在事件發生的期間，以太坊網絡并未出現分叉，而 Validator 也未進行惡意投票，只因大量 Validator 離線導致投票率不足，從而使得 Epoch 在期間無法被敲定。

經過觀察，離線的 Validator 出現 CPU 過載的異常情況，被認為是 Validator 離線的直接原因。

以太坊上Dex交易量達歷史新高:據歐科云鏈OKLink數據顯示，受市場行情波動影響，截至今日10時，以太坊上Dex的24小時交易量達40.6億美元，觸及歷史高位。

其中交易量排名前三的Dex協議分別是Uniswap?V2?14.8億美元，SushiSwap?8.4億美元以及Curve?3.9億美元。[2021/2/23 17:42:35]

在第二次事件中，Epoch 敲定被延遲了 8 個 Epoch，由于敲定延遲大于MIN_EpochS_TO_INACTIVITY_PENALTY (=4) 從而觸發了以太坊共識算法 Inactivity leak 的處理機制。

· 懲罰離線的 Validator，削減其質押資金，罰沒了約 28 個 ETH。

· 取消 Attestation 的獎勵，導致約 50 個 ETH 未被發行。

· 該機制保證在線 Validator 最終能掌握以太坊總質押資金的  ?，從而使得網絡狀態最終能被敲定

imToken 的節點服務也偵測到了此次事件，通過實時監控以太坊共識層 Validator 投票的情況，從而在 Epoch 未能正常敲定前，提前預警以太坊共識網絡的異常。下圖是第一次事件發生時的節點狀態。

分析 | 以太坊基本面表現較好 對比特幣匯率持續上升:據 TokenGazer 數據分析顯示，截止至 9?月 18 日 11 時，以太坊價格為$212.08，總市值為$22,785.44M，主流交易所交易量約為$407.20M，環比昨日增量64.73%；近期以太坊保持獨立行情，以太坊對比特幣匯率持續上升；基本面方面，以太坊鏈上交易量平穩波動、鏈上DApp交易量保持上升趨勢，算力持續增長，活躍地址數輕微下滑；以太坊 30 天開發者指數約為 2.25；以太坊與 BTC 180 天關聯度持續下行，30 天 ROI持續上行；ERC20 代幣總市值約為以太坊總市值的 57.03%，持續下滑，說明近期以太坊的市場表現優于ERC20代幣。[2019/9/18]

PoW 機制下，交易的成功是認定交易在多少連續區塊后大概率不會被回滾，PoS 則是以 Safe Head 返回的塊高作為交易成功的判定。而目前的規范中則是以 Justified Checkpoint 作為 Safe Head 的狀態認定，因此以前一 Epoch 的狀態來看，可能存在有 6.4 分鐘之久的判定延遲，這對用戶而言是很糟糕的體驗。

imToken 自研的 Safe Head 服務會基于實時的以太坊共識層數據，計算出安全的區塊用于交易確認，在保證用戶交易安全的前提下，縮短交易確認的時長。正常情況下，imToken 的 Safe Head 算法返回的塊高（如上圖黃色），會非常貼近最新的區塊高度（綠色），從而提高用戶體驗。

原因分析

分析 | 以太坊鏈上的大額轉賬系火幣內部資金流動:根據tokenview數據顯示，今天11至13時，以太坊鏈上發生了累計88萬ETH轉賬，系火幣內部以太坊歸集所致。首先從0x7ef35bb39開頭地址累計轉出78萬ETH至0x325982939開頭地址和0xb4cd0386d2db86f3開頭處理。后尾號4265的地址又收到10萬ETH轉入，共計88萬ETH。分析認為，以上轉賬應為火幣交易所內部正常資金流動，投資者無需過分緊張。[2019/6/5]

造成上述事件的直接原因是某幾種以太坊共識層客戶端節點負載過高，使得 Validator 宕機離線，從而無法正常進行共識投票。經過分析，這些節點負載過高的原因是：

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

當同時收到大量指向陳舊區塊的見證時，節點的 CPU 以及內存資源被耗光，從而導致這些 Validator 宕機離線。

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

共識層客戶端 Teku 以及 Prysm 目前推出了 patch 版本以解決該問題。具體而言，patch 版本的客戶端實現會過濾掉這些陳舊的見證，即當滿足下列條件，忽略該見證：

動態 | 以太坊未確認交易37545筆:據Etherscan.io數據顯示，當前以太坊未確認交易為37545筆，與昨日相比未確認筆數略有減少，網絡較為擁堵。[2019/1/24]

· 見證指向一個陳舊的 Slot

· 見證指向一個節點從未見過的 Checkpoint

然而，我們仍需持續觀察以太坊主網敲定的情況以確認 patch 的有效性。

共識層客戶端 Teku 以及 Prysm 的 patch 版本：

· Prysm：v4.0.3-hotfix

· Teku：v23.5.0

以太坊設計優勢

在此次事件中，以太坊保證可用性仍持續產生區塊并處理交易，而僅推遲 Epoch 敲定的關鍵在于兩點：

1. 以太坊客戶端的多樣性

2. Gasper 算法的設計

以太坊客戶端的多樣性

在此次事件中，雖然共識層客戶端 Teku 以及 Prysm 的實現出現了問題，但不影響其他共識層客戶端的正常運作。像是 Lighthouse 客戶端本次并不受影響，由于不同客戶端在實現的設計上并不相同，因此仍有 Validator 正常在運作。

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

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

保證以太坊的可用性是以太坊共識算法 Gasper 的設計出發點之一，其把以太坊區塊生產與敲定分離。因此，即使區塊敲定受阻，區塊的產生并不會隨之終止。考慮到大部分情況下，區塊敲定最終會恢復（產生的區塊最終仍會被敲定），那么對用戶影響其實會很低。對比其他 BFT 的共識算法：若區塊敲定失敗，共識節點會停止產出下個區塊。從而，導致期間整個區塊鏈不可用，即俗稱的「區塊鏈掛了」。

另外，第二次事件還觸發到了 Inactivity Leak 的機制，其主要是為了保證以太坊在極端情況（大量 Validator 長時間離線）下仍能重新敲定區塊。

經驗與啟示

以太坊多客戶端的挑戰

當前，以太坊客戶端多樣性現狀如下圖所示：

來源: https://clientdiversity.org/#distribution

可以看到，以太坊客戶端多樣性仍需繼續推廣和宣傳。可以想象，如果客戶端實現足夠多樣，使得 Prysm 以及 Teku 的占比小于 ?，那么這次事件甚至不會發生（? 客戶端正常運作足以敲定 Epoch）。另外，當前執行層的客戶端集中在 Geth，占比高達 61%。這實際上存在著潛在風險：如果 Geth 運作不當，以太坊會受到很大的影響。

除了以太坊客戶端多樣性需要進一步努力外，以太坊客戶端切換也是此次事件暴露的一個痛點：當某個客戶端實現出問題時，Validator 如何切換到正常的客戶端實現之上。此過程涉及：

· 把出問題客戶端的 Validation key 安全地遷移到正常的客戶端之上

· 由于以太坊共識有 Slash 的規則，需要保證舊客戶端與新客戶端的行為的一致性而不被 Slash。例如：

o 新舊客戶端分別對分叉兩側的 Checkpoint 進行投票，從而被 Slash

o 新舊客戶端在同一個 Slot 產出不同的區塊，從而被 Slash

以太坊共識的監控

需要類似 Safe Head 類似的服務持續監控以太坊 PoS 網絡的實時狀態，提前發現并預警該類事件，而非等到 Epoch 無法按預期敲定才得知網絡狀態異常。相關的最新研究可見此文章。

以太坊共識算法的科普

這次事件暴露了科普以太坊 PoS 共識機制的必要性。在此次事件中，很多用戶誤以為「以太坊掛了」，從而造成不必要的恐慌。然而，實際上，以太坊網絡持續產生區塊并處理交易。以太坊共識層和執行層的組合為以太坊交易交易確認帶來雙重保障，在共識層 Epoch 無法敲定的情況下，執行層的區塊處理并不受影響，且 Epoch 敲定的異常狀況也在以太坊共識算法中有相應處理設計。面向用戶的區塊鏈知識科普仍然是從業者們需要持續努力的方向。

對以太坊應用的啟示

雖然以太坊網絡足夠健壯，但是偶爾的不穩定會對應用有著一定的影響。同時，應用要正確處理這些不穩定的場景。

· Layer1 -> Layer2 的存款時間會變長。Layer2 在 mint 的時候，一個重要前提是需要保證 L1 存款交易不會被回滾。因此，當以太坊網絡 Epoch 敲定被推遲的情況下，L1->L2 的存款時間也會相應變長。

· 類似的，交易所也需要防止鏈上充值交易被回滾的情況，因此其充值時間也會相應變長。

· Oracle 鏈上報價存在被回滾的風險，因此依賴其的高價值服務要適當暫停。

· 在此次事件中，Uniswap 不顯示余額、只能買入不可賣出，而 dYdX 暫停了存款。

總結

在這次事件中，我們可以看到以太坊 PoS 共識算法的韌性與自我修復的能力，也看到客戶端很快在發生事故后，即時響應與修正錯誤。對以太坊整個生態而言，還需在以下方面持續投入：增加客戶端多樣性，優化對網絡狀態的實時監控與預警，深度用戶教育（不僅面向普通用戶，也需面向從業者），生態參與者在網絡異常時的緊急預案準備。

參考鏈接

· Finality issue updates May 2023

· https://twitter.com/robplust/status/1657044364382846978

· https://twitter.com/superphiz/status/1656780594326405121

· https://twitter.com/terencechain/status/1657021042110631936

imToken

企業專欄

閱讀更多

金色薦讀

金色財經 善歐巴

迪新財訊

Chainlink預言機

區塊律動BlockBeats

白話區塊鏈

金色早8點

Odaily星球日報

MarsBit

Arcane Labs

Tags：以太坊NBSBSPPOC以太坊幣怎么挖礦的nbs幣發行量BSPT價格tokenpocket幣多少錢一個

fil幣價格今日行情