以太坊 2.0 主網事故回顧_ETH

https://beaconcha.in/epoch/32302

從 epoch 32302 開始，信標鏈丟失了大量區塊提議。由于 Prysm 是 Eth2 客戶端中用戶最多的，因此問題最有可能出現在 Prysm 上。一段時間之后，我們在本地重現了該錯誤。這其實是我們已知的一個與 eth1 數據投票和驗證者存款相關的問題。盡管之前已經有人向我們報告過此問題了，但是我們無法重現這個 bug 并將其視為孤立事件。而且這個問題從未在任何測試網或者主網中廣泛傳播過。這是該問題首次導致區塊提議失敗事故。

在這 18 個 epochs 內，幾乎所有 Prysm 信標節點都無法生產新區塊。Epoch 32320 又開始正常運行了，當時大家普遍認為該事故已經結束了。然而大約 24 小時后，該事故再次發生，造成了類似的影響。

關于此事故的正式事后剖析報告已發布，訪問鏈接查看：https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit

該回顧詳細介紹了事故的時間線；分析了根本原因以及列出了 Eth2 質押者和參與者需要注意的問題。

一些初步數據表明，第一次事故中，每個受影響的驗證者平均損失 122950 gwei (按文章攥寫時的價格計算為 0.3 美元)。而該次事故發生的 24 小時內，又發生了第二次相同的事故，每個受影響的驗證者損失約為 0.22 美元。

一些關鍵事實：

沒有驗證者被罰沒

對信標鏈的敲定沒有影響

參與率還是很高 (最低點也有 84.8%) （編者注，此數據與 Ben Edgington 編寫的最新一期《Eth2 進展更新》有出入。)

大多數驗證者丟失 2 到 3 個證明，不管哪個客戶端類型

這次不像是一次惡意或故意的攻擊

在整個團隊經過大約 30 個小時的努力之后，我們診斷了其根本原因，并在 UTC 時間 4 月 25 日早上 6 點為所有 Prysm 節點部署了修復版本。在節點尚未完全升級之前，類似的事故仍發生了最后一次。給節點運行者足夠的時間升級客戶端之后，此類事故沒有再發生過了，并且有證據表明該問題已得到完全解決。

以太坊合并前的最后一個區塊被用于鑄造NFT項目Vanity Blocks中的“The Last POW Block”:9月15日消息，以太坊在合并前的最后一個區塊（區塊高度15537393）僅包含一筆交易，該交易用于鑄造NFT項目VanityBlocks中的“The Last POW Block”，成本約為30ETH（48618美元）。該NFT在OpenSea上一小時前出價為10ETH。[2022/9/15 6:58:47]

成為驗證者的捷徑

此事故是否會削弱大家對 Eth2 的信心？

不會。該事故并沒有造成共識失敗，并且該事件的影響范圍與 Eth2 主網的規模相比非常小 (在第一次事故中，每個受影響的驗證者平均損失約 0.3 美元)。自創世以來，Eth2 一直都非常強大，驗證者參與率非常高，并且每個 epoch 都完成了敲定。從我們的角度來看，故障解決了之后，網絡有能力恢復到完美運行的狀態，反而增強了社區對以太坊的復原能力的信心。

此事故是否會削弱大家對 Prysmatic Labs 團隊的信心？

我們對此次事故做出的反應和解決方法與此前我們處理 Eth2 測試網中的故障時完全不同。此次事故發生后，我們團隊馬上排除了錯誤信息；量化影響；以及在等待解決方案時，給驗證者們列出了明確的應對步驟。再者，我們完全確定了解決方案之后，才去讓大家升級客戶端版本。值得注意的是，由于 Prysm 客戶端是以太坊 2.0 網絡中用戶占比最大的軟件，因此出現的任何 bug 都可能會引起更嚴重的問題。

對于核心開發者來說，工作的關鍵是要“約束復雜性” (bound complexity)。諸如 Eth2 之類的分布式系統具有如此多的變量，我們每個團隊都盡一切努力以減少其出 bug 的可能性。當然，在這個的軟件中，出現 bug 是不可避免的，并且我們承認，Prysmatic Labs 確實出錯了。但是我們希望可以展現出我們團隊解決問題的動力與能力，同時為驗證者平衡速度和準確性之間的問題。

事故根本原因總結

Eth2 和 Eth1 鏈松散地連接著，Eth2 僅在驗證者存款驗證時需要用到 Eth1。也就是說，即使驗證者對垃圾數據進行了投票，Eth2 PoS 鏈也可以繼續運行。而唯一會影響到的事就是，新的驗證者存款無法添加，直到 PoS 鏈再次對正確的 Eth1 數據進行投票。此“投票”是在“投票周期”中完成的，目前主網上將該周期設置為 64 epochs (大約 6.8 小時)。

PoS基礎設施服務商stakefish上線以太坊2.0 Staking平臺，支持批量建立驗證節點:11月24日消息，PoS基礎設施服務商stakefish已正式上線以太坊2.0的非托管類Staking平臺，該平臺為以太坊社區首個支持批量建立節點的staking平臺，最多一次性存入100個以太坊2.0驗證節點，智能合約已經通過Runtime Verification審計。stakefish已于不久前開源了其開發的批量存儲合約。目前，平臺上線約15小時已經成功創建680個驗證節點，Staking ETH數額達到21760 ETH。[2020/11/24 21:56:33]

投票的方式為一個簡單的“絕對多數”原則，Eth2 驗證者規范中有解釋其運作方式。不幸的是，Prysm 在實行該原則 (按照絕對多數原則投票) 時，丟失了一些驗證。該事故中，由于 Prysm 出現了 bug，導致一名區塊提議者創建了一個完全無效的 Eth1 存款樹根，而其他 Prysm 節點首先發現了該區塊提議。隨后，他們對此投了有效票，因為 Prysm 客戶端遵循的是簡單的“絕對多數投票”原則，而沒有做明確的驗證。

然后，所有 Prysm 節點”滾雪球“般地對無效信息投票，導致了區塊提議者無法將具有存款的區塊打包進鏈。這是因為，這些存款對節點的 Eth1 存款樹根未進行驗證，所以區塊提議會失敗。而在投票期結束之后，該問題就自動解決了，但如果 bug 未修復，將再次出現這種問題。

實際上，這次出現無效 Eth1 存款數據樹根的根本原因是，存款緩存初始化中出現了 bug，但僅影響了使用 Prysm 客戶端的一部分信標節點。這導致這些節點生產錯誤的存款樹根，而其他 Prysm 節點對其進行投票，從而造成了此次事故。

注意，下面是技術細節！大家可以跳到下一部分，閱讀解決方案以及該次事故帶來的經驗教訓。

區塊提議失敗

Epoch 32302 開始出現區塊提議丟失的問題。

Nishant 通知了團隊，并召開了全體會議。然后，我們通過本地的主網信標節點重現事故，并開始了調查。

調查顯示，Prysm 對奇怪的、錯誤的 eth1 存款樹根投票

以太坊研究者：銷毀ETH可成為DApp的激勵方式 并創造新的DeFi指標:7月29日早間，以太坊研究者Justin Drake發推稱，銷毀ETH（在EIP-1559提案涉及的交易費銷毀之上）是一種簡單的激勵方式，能夠幫助DApp集合以太坊營銷機器獲得額外增長，并使得和鎖定總價值（TVL）一樣，銷毀總價值（TVB）可以成為主要的DeFi指標。[2020/7/29]

我們注意到 Prysm 的節點正對奇怪的樹根投票，該默克爾根用于驗證 PoS 鏈中的驗證者存款合約的存款完整性。在公共瀏覽器上查看了最初的區塊提議者的歷史信息之后 (為了保護該驗證者，就不公布其身份了)，我們推斷這并不是一起攻擊事件。

排除法

最初的懷疑是關于 Prysm 如何在驗證者提議代碼路徑中處理 eth1 數據投票。尤其是，我們試圖排除一些問題：

1.打包存款進區塊這里有問題嗎？

2.存款日志信息獲取和 eth1 信息混了或者不確定嗎？

3.我們的存款默克爾樹出現問題了嗎？

在接下來的 16 個小時左右，我們花費了大量的時間共同努力診斷潛在的問題。我們梳理了代碼行，試圖通過單元測試來重現故障過程，并嘗試了各種方法。盡管我們已經有了一個潛在的解決方案，我們也因缺乏信心而對發布修復版本而緊張。

較合理的根本原因

此前在處理 Eth2 測試網中的 bug 時，我們得到了一些經驗教訓，光對根本原因有信心是不夠的。在高風險的情況下，在向用戶公布解決方案之前，我們需要有 100% 的信心。在事故發生后 28 小時，我們坐下來并問自己：”我們還有什么是不知道的呢？我們還可以問什么問題來讓我們更接近發生故障的根本原因呢？”然后我們知道了以下幾點：

1.我們的稀疏默克爾樹 (sparse merkle tree) 實現并沒有嚴重的 bug，因為它使用主網和 Prater 測試網的存款，與 Lighthouse 和 Protolambda 的 Eth2 zrnt 實現相匹配。

2.我們用于從 Eth1 節點檢索 Eth1 數據的代碼路徑沒有 bug，也沒有返回不正確的數據。

我們不知道的有：

1.無效的存款樹根是如何產生的

2.為什么這個問題在一些節點中是可以重現的，而其他節點不可以

動態 | 以太坊未確認交易51920筆:據Etherscan.io數據顯示，以太坊未確認交易51920筆。當前挖礦難度2535.72 TH，交易處理能力7.2 TPS。截至目前以太坊全球均價為129.19美元，最近24小時跌幅為1.48%。[2019/12/25]

3.為什么 Prysm 節點在確定區塊中的存款數量時，出現了”off-by-one“錯誤

修復問題

為了回答這些問題，我們看了初始化我們的存款樹的代碼路徑。結果發現，在早期添加了一個緩存層以避免質押者每次啟動他們的節點時都必須下載所有驗證者存款記錄。此外，我們添加了一個新功能——在客戶端內部可以從一個內嵌的創世狀態中啟動 Prysm。在填充緩存時，我們存款樹的一個錯誤預設導致信息的訛誤：

問題根源

事實證明，如果我們的存款樹是空的，函數 len(items) 將始終返回 1。這意味著當實際上我們應該把 lastReceivedMerkleIndex 的值設為 -1 時，我們會把它設為 0。上面的代碼會導致一些在該代碼路徑的 Prysm 節點跳過把第 0 筆存款嵌入到樹里。我們代碼庫的其他部分都指向問題出在我們存款樹實現的這個奇怪部分，而不是這個代碼路徑。

為了檢驗這個假設，我們嘗試使用 Protolambda 提供給我們的測試夾具盡可能地復制代碼路徑。我們直覺我們漏了將第 0 筆存款嵌入到存款樹。當然，我們能夠在一個可重復的測試中找到導致整個事件發生的、有問題的存款樹根！然后，我們圍繞該代碼路徑添加條件，以避免該條件再次出現，并準備推出最終確定的修復版本。

根本原因總結

Prysm 把 eth1 數據保存在磁盤上，以防止用戶在每次重啟進程時都必須對驗證者存款合約日志發出請求。

如果一個節點重啟并把 eth1 數據保存在磁盤上，我們會從這些數據初始化我們的存款緩存，但由于我們的稀疏默克爾樹 (sparse merkle tree，SMT) 協助程序包的工作方式與從磁盤上的數據初始化此緩存的代碼路徑不相同，我們會跳過把第 0 筆存款嵌入存款樹，造成無效存款樹根。這個代碼路徑只影響那些創世以來還沒有數據庫的節點，后來被修復了。

分析 | 以太坊獨立地址數量增加的同時 活躍地址數量減少:據 Etherscan.io 的數據，以太坊上獨立地址在本周日超過 5000 萬個。不過，盡管以太坊獨立地址數量在增加，活躍地址的數量卻在減少，活躍的以太坊地址從 2018 年 1 月 16 日創下的 71.9 萬高點，下降至目前的 23.2 萬左右的水平。據 Coinmetrics 提供的定義，活躍地址數量指當日參與接收和發送交易的獨立地址的數量。[2018/12/17]

在官方規范里，Prysm 節點遵循“絕對多數”的原則執行一個 eth1 數據投票算法，但是，Prysm 并沒有完全實現該算法的一些有效條件。Prysm 節點隨絕對多數 eth1數據投票進行投票，該投票數據引用的是一個現存的區塊根，這可能導致 Prysm 節點投票給一個由有問題的存款樹生成的存款樹哈希值，因為這些存款是未被驗證的。

由于網絡里大部分的節點都是 Prysm 節點，隨絕對多數原則投票給有問題存款根這個問題的滾雪球效應發展成一個嚴重問題，因為 Prysm 節點在隨后一段時間里無法在主網上生成區塊。

一旦 eth1數據投票期重置了，Prysm 節點又可以正確地提議區塊了，直到在未來又遇到該漏洞。

解決方案

在北京時間 4 月 25 日周日 13:00，在不確定性中煎熬了多個小時后，我們發布了對該問題的修復。我們對這個解決方案有十足的把握，并非常有信心在節點升級后，該問題在 Eth2 中不會再出現。

吸取校訓

在事件中，對我們的解決方案有信心和與外界的謹慎溝通是至關重要的

當我們遭遇 Eth2 的 Medalla 測試網事故時，我們上了關于良好溝通的價值的重要一課。每個公共評論和語言的精確表達都會對事件的結果產生嚴重影響。在測試網的事件里，我們以為一個立即的解決方案是通過公共渠道告訴大家“重啟你們的節點”。這個草率的決定導致網絡上大部分的節點都掉線了，然后爭先恐后在一堆壞的對等節點里找好的，以實現與區塊鏈的同步。此外，我們很快發布了一個沒有 100% 信心能解決問題的軟件升級熱補丁。這給系統帶來更多的混亂，并造成節點運行商對解決方案的疑慮。

相較之下，在這次主網新事故的整個過程里，我們一直注意慎重與精確的溝通。另外，在我們對問題的根源和解決方法有 100% 的信心之前我們沒有發布熱補丁。

保持耐心與冷靜有助于解決問題

我們團隊經過了過去幾年構建 Eth2 ，學到了如何在面對逆境時保持冷靜。我們相信在解決問題過程中，保持冷靜、頻繁交流狀態報告、確保團隊感受到支持和正面的反饋是非常重要的。我們能夠花時間收集盡可能多的證據，并與我們的用戶進行細致的合作，我們將成功解決這個問題。更重要的是，我們在開始時就花時間對事件影響進行量化，以減少質押者與因缺乏信息而產生的憂慮。這個教訓對在高度緊張與睡眠不足的情況下工作非常重要。慢下來，用適當的方法解決它，并不惜一切代價避免把問題弄得更糟。

Eth2 測試網不等于主網

對于 Prysm 客戶端，我們在公共 Eth2 測試網中對 Prysm 產品前的候選版本進行了廣泛的測試和監聽。Prater 和 Pyrmont 測試網都是用戶在加入到 Eth2 主網前用來測試他們的設置的好工具。但是，這些測試網都預設四個產品級 Eth2 客戶端的占比是接近平均分的，即沒有哪個客戶端在驗證者中有明顯的多數份額。不幸的是，這可能沒有考慮到當某個客戶端為大多數人所使用時才會出現的漏洞。在未來，Prysmatic Labs 會在一個更接近主網環境、或一個 Prysm 網絡節點 50% 的環境里進行內部測試網里進行測試。

此外，我們建議其他客戶端也在它們自己的內容測試中加入這樣的環境，在它們成為大多數客戶端的時候，它們也可以了解自己客戶端的潛在問題。

為什么使用 Prysm 客戶端做質押

https://launchpad.ethereum.org

人們選擇運行 Prysm 時因為從一開始我們團隊已經專注于使他們參與以太坊質押的體驗更簡單。我與我們的用戶溝通過很多次，很多人選擇一個客戶端不是因為微觀上的優化或與其他客戶端相比相對小的收益差別，而是因為我們使得他們的體驗更簡單——良好的文檔資料，一直給所有的社區成員提供重要的幫助。對于新手來說 Eth2 是可怕的，質押也充滿不確定性和風險。我們團隊的使命是讓用戶知道我們在他們身邊，以及無論他們的問題多小都會得到我們的支持。特別地，我們一直關注那些可能對命令行不太熟悉、不太了解 UNIX 操作系統的普通質押者。

在未來，你可以對我們團隊有以下期待：

提高實現規范條件的準確性，確保預設和有效條件在任何代碼被寫入前都被充分審核和質疑

我們不因要提高這個體驗，還要加倍努力，使 Prysm 比今天提升很多倍，使使用我們客戶端的質押者更容易參與網絡，包括網頁界面的改進。

Prysm 將在研發方面加倍努力，在 eth1 <> eth2 的合并前提供關鍵的功能與改進。

我們相信健康的競爭能形成一個強大的激勵機制，推動 ETH 的權益證明能有更多人參與，也因此更安全，因為所有客戶端團隊都不斷改善他們的軟件

我們團隊致力于以最高的專業水準來解決和質押者可能會遇到的問題。我們相信我們做好處理我們路上會遇到的任何問題，并向我們的社區保證我們會把質押者體驗作為我們的最高優先級。

最后，我們相信還有很多重要功能可以使 Prysm 變成參與 Eth2 的、更有吸引力的軟件，我們將朝著這個目標不斷迭代

Prysm 有一些驗證者收益的高級優化還沒對所有質押者設為默認啟動。我們相信這些功能發布后，Prysm 的質押者會看到最高水平的收益。

自 Eth2 創世以來，我們一直聽到的一個共同主題是客戶端多樣性。Eth2 是一個有世界各地的人作為驗證者參與的分布式系統。不同人用不同的軟件參與到區塊鏈的共識里，如果某個軟件出現嚴重問題，如果運行網絡的客戶端實現由一個平衡分布的話，影響會更小。

Leonardo Bautista-Gomez 早在一月的時候公布了一份數據分析，結果現實 Prysm 節點占網絡的65%，此次事件也顯示 Prysm 驗證者在今天占了大多數。

https://github.com/leobago/BSC-ETH2/tree/master/armiarma

我們建議你們客觀地看待每個客戶端：它的軟件、它的社區、還有它的韌性，然后決定選哪個軟件及其背后的團隊是最適合你的需求的。如果某個 Eth2 客戶端缺少了對你來說很重要的東西，者正式你不選他們的客戶端的理由，我們強烈推薦你提出一個功能請求。Prysmatic Labs 會繼續專注于幫助你參與到以太坊網絡，并推動區塊鏈軟件的邊界。

如果你想溝通和對本文由疑問的話，請加入我們的Discord。

參考

? 事件的溝通 https://www.reddit.com/r/ethstaker/comments/mxpz57/regarding_the_recent_beacon_chain_incident/

? 事后檢討報告 https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit?usp=sharing

? Medalla 測試網事件 https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a

https://medium.com/prysmatic-labs/tagged/blockchain)

原文鏈接：

https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c

來源 |?Prysmatic Labs

作者 |?Raul Jordan

Tags：ETHPRYETH2以太坊ETH錢包PRYZeth2.0幣價幸運以太坊

Gateio