分析了以太坊 2.0 Prysm 客戶端事故的根本原因,並列出了以太坊 2.0 質押者需要注意的問題。

原文標題:《以太坊 2.0 主網事故回顧》
撰文: Raul Jordan,Prysmatic Labs 聯合創始人

以太坊 2.0 Prysm 事件回顧:發生了什麼?學到了什麼?https://beaconcha.in/epoch/32302

事故概要

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

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

關於此事故的正式事後剖析報告已發佈,訪問鏈接 查看

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

影響

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

一些關鍵事實:

  • 沒有驗證者被罰沒
  • 對信標鏈的敲定沒有影響
  • 參與率還是很高 (最低點也有 84.8%) (編者注,此數據與 Ben Edgington 編寫的最新一期《Eth2 進展更新》有出入。)
  • 大多數驗證者丟失 2 到 3 個證明,不管哪個客戶端類型
  • 這次不像是一次惡意或故意的攻擊

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

問題解答

成爲驗證者的捷徑

此事故是否會削弱大家對 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 小時)。

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

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

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

事件時間線

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

區塊提議失敗

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

以太坊 2.0 Prysm 事件回顧:發生了什麼?學到了什麼?

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

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

我們注意到 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. 爲什麼這個問題在一些節點中是可以重現的,而其他節點不可以
  3. 爲什麼 Prysm 節點在確定區塊中的存款數量時,出現了「off-by-one」錯誤

修復問題

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

以太坊 2.0 Prysm 事件回顧:發生了什麼?學到了什麼?問題根源

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

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

以太坊 2.0 Prysm 事件回顧:發生了什麼?學到了什麼?

問題解決

根本原因總結

  • Prysm 把 Eth1 數據保存在磁盤上,以防止用戶在每次重啓進程時都必須對驗證者存款合約日誌發出請求。
  • 如果一個節點重啓並把 Eth1 數據保存在磁盤上,我們會從這些數據初始化我們的存款緩存,但由於我們的稀疏默克爾樹 (sparse merkle tree,SMT) 協助程序包的工作方式與從磁盤上的數據初始化此緩存的代碼路徑不相同,我們會跳過把第 0 筆存款嵌入存款樹,造成無效存款樹根。這個代碼路徑隻影響那些創世以來還沒有數據庫的節點,後來被修復了。
  • 在官方規範裏,Prysm 節點遵循「絕對多數」的原則執行一個 Eth1 數據投票算法,但是,Prysm 並沒有完全實現該算法的一些有效條件。Prysm 節點隨絕對多數 Eth1 數據投票進行投票,該投票數據引用的是一個現存的區塊根,這可能導致 Prysm 節點投票給一個由有問題的存款樹生成的存款樹哈希值,因爲這些存款是未被驗證的。
  • 由於網絡裏大部分的節點都是 Prysm 節點,隨絕對多數原則投票給有問題存款根這個問題的滾雪球效應發展成一個嚴重問題,因爲 Prysm 節點在隨後一段時間裏無法在主網上生成區塊。
  • 一旦 Eth1 數據投票期重置了,Prysm 節點又可以正確地提議區塊了,直到在未來又遇到該漏洞。

解決方案

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

以太坊 2.0 Prysm 事件回顧:發生了什麼?學到了什麼?

吸取教訓

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

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

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

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

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

Eth2 測試網不等於主網

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

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

質押者應該思考什麼

爲什麼使用 Prysm 客戶端做質押

以太坊 2.0 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 驗證者在今天佔了大多數。

以太坊 2.0 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

來源鏈接:medium.com