速讀 Evmos 升級失敗官方分析報告及解決方案

作者：Evmos 官方團隊

編譯：Lukie

3 月 7 日上午，Cosmos EVM 兼容中心 Evmos 在 Discord 官方群表示，網絡升級失敗，並將暫停 24-48 小時。3 月 8 日下午，Cosmos EVM 兼容中心 Evmos 在推特發文稱，「鑒於社區反饋，Evmos 至少在接下來的幾天內都不會上線」。

今日 15：27（GMT+8）時，Evmos 團隊在 Github 上發表了升級失敗報告，對網絡升級失敗的核心問題進行了解讀。

為什麼鏈停止運行了？

・核心團隊在主網上發布了部分測試的升級程序代碼

・發生共識錯誤之後協調失誤，團隊安排的時間太緊湊，只有幾個小時可用於進行升級部署

・升級的複雜性達到了一個極端 —— 需要徹底重啟整個網絡並完成同步

・5 個驗證者雙簽，導致它們被 tombstoned（Foresight News 註：tombstone 指驗證節點如果驗證錯誤就會被懲罰。）

1）當驗證者被 tombstone 后，他們將不能再次成為驗證節點。

2）這是一個嚴重的錯誤。tombstone 本質上是永久封禁，所有的委託都需要手動解除綁定，這對委託人來說也是一個可怕的場景。

・考慮到受影響的驗證節點和用戶（比例非常大），暫停這條鏈是可以接受的。

・在嘗試恢復網絡數小時后，我們目睹了多個驗證節點被 tombstone。驗證者社區和核心團隊認為這是不對的，於是決定停止網絡，直到新版本測試達到可用於生產的狀況后再重啟。

為什麼會出現 5 個驗證者雙簽？

・他們在共識停止期間運行 unsafe-reset-all ，導致他們破壞了 priv_validator_state.json 文件。此外，一些節點在遷移到其他機器的過程中，並忘記拷貝遷移 priv_validator_state.json 文件

・他們不知道必須備份並遷移 priv_validator_state.json，因為當鏈正常運行時這通常都不是問題，大多數塊將在一輪內達成共識，並且在說明手冊中沒有明確說明一定要這樣做。

為什麼有這麼多驗證者運行 unsafe-reset-all 而不保留他們的 priv_validator_state.json ?

・驗證者必須從快照中恢復，因為如果他們在升級期間重新啟動節點，他們將不再參與共識，所以在這樣做時，它們要麼完全刪除 $EVMOSD _ home/data，要麼運行 unsafe-reset-all。在共識停止期間執行此操作時，它是不安全的（正如在其標題中指出的命令那樣），並且如果沒有備份 priv_validator_state.json，則不完全了解如何恢復。

・關於 priv_validator_state.json 有很多誤解

・關於這個文件在重新同步時的影響，沒有明確的答案（驗證節點對共識的運行機制缺乏理解，同一區塊每一輪共識的達成都意味着提議者的變更，如果提議者回來並重新運行此輪共識流程，就像 5 位雙重簽名者所做的那樣，他們將拋出兩個區塊。）

為什麼驗證者必須從快照中恢復？

・當鏈停止運行並且人們在停止期間重新啟動他們的驗證節點時，驗證節點不會自動恢復參與共識流程。（當驗證者開始使用 v2.0.1 版本時，許多人認為 peer 存在問題，因為這在 Cosmos 生態系統中很常見。在停止其節點修改 peer 列表和 / 或增加連接的 peer 數量之後，它們重新啟動其節點。我們認為這導致了 Tendermint 的不確定狀態。正如我們所說的，這種不確定狀態是指 Tendermint 不知道它應該處於塊同步模式還是共識模式，從而導致節點無法繼續運行。）

・因此，解決方案是使用快照重新啟動一個新的數據庫。

・在這段時間裡，許多人超量訪問 Polkachu 端點，但是在從頭開始下載或同步節點之後，操作人員設法啟動了 Polkachu 快照的鏡像。

・雙簽的人和該區塊提交者有很強的關聯性。

以下是在區塊高度 58701 的共識流程中違反拜占庭規則的行為：

BF5FC06E32A4168817A16D69692F36C8F7A5DA37, proposed round 0, and double signed round 0.

FF9F24A7DB626386EBA92D1E8D058474CEC40C26, proposed round 2, and double signed round 2.

4F8EDD442959D0BB78F8CE0012BAD23AFEE6E08C, proposed round 4, and double signed round 4.

76692115F93AE444FA857C7BA963F125D8C2E6C6, proposed round 8, and double signed round 8.

9BA4035E5B58DAB71B6573791FDAA3D9E1C78A00, proposed round 10, and double signed round 10.

為什麼驗證者要重新啟動它們的節點？

・一些節點重新啟動，因為它「看起來卡住了」。

・其他節點重新啟動，因為沒有人能夠保持一組可靠的 peer。

・本次升級比大多數驗證者所習慣的升級都要複雜。

為什麼沒有一群穩定同步的 peer 呢？

・我們懷疑許多節點並沒有進行升級，導致升級重新啟動后的節點連接到一些沒有升級的無效節點。許多節點的 addrbook.json 因為沒有升級導致他們與新版本無法兼容。

・人們很可能連接到沒有升級的 seed，並可能傳播他們大量無效的 addrbook.json peer。

・當人們在升級過程中關閉他們的節點，導致 peer 的狀況變得更糟。

・有幾個關鍵節點直到後來才升級，這意味着許多關鍵節點都在運行舊版本。

・我們在解決，並創建了一個穩定的 peer 列表。

為什麼我們需要在 v2.0.1 之前緊急發布 v1.1.2 版本？

・在高度 58,700 它需要一個升級處理程序緊急升級鏈。我們不想通過治理進行升級，因為有一個安全漏洞還沒有被修復，否則需要等待至少 5 天的時間，這會導致大量的人利用漏洞竊取他人的資產。

為什麼我們沒有發現 v2.0.0 早期升級失敗的問題？

・沒有自動化的測試套件來捕捉錯誤，因此測試必須從頭開始構建測試工具或手動完成。手動測試一直持續到交付的最後時刻，但是並非所有團隊成員都能擁有在遷移期間快速手動測試需求的能力。

・因為我們在最後一分鐘更改了遷移邏輯以嘗試通過模塊遷移進行升級（因為這比在升級處理程序中執行的做法更安全），所以我們在升級前測試了這大約 300 個塊。我們沒有足夠的時間在幾個小時前召集可用人員並準備好進行測試，因為這是手動測試，需要對升級有深入的了解。

・當我們使用舊的升級處理邏輯（在升級處理程序中設置新參數）時，在指定塊高度使用 cosmovisor 進行升級時已經通過測試並可以正常工作，但它不符合最佳實踐，因為設置新的參數應該在模塊本身的遷移處理程序中完成。在編寫遷移處理程序時，我們試圖獲取現有參數並進行設置，當你在遷移過程中時 GetParam 將返回空字節。所以解決方法是在遷移中設置所有新參數，而不從存儲中檢索舊參數。

・當我們測試遷移邏輯並發現故障、其他 Evmos 工程師重新上線時，它已經落後了 300 個塊。到那時，已經來不及了，Evmos 不得不接受在區塊高度 58700 升級的命運。

為什麼這個升級對於驗證者來說變得如此複雜？

Evmos 團隊在協調緊急升級時出現了幾個錯誤：

・沒有對 v2.0.0 進行測試導致了第二次更新。如果沒有經過測試，則應該推遲升級。

・由於漏洞的嚴重性，發布時間很緊迫。

1）通知應至少提前 24 小時發出，區塊高度有所推遲，但在升級前幾個 小時發布的版本被限制了，這意味着驗證者必須在線交換二進制文件。

2）升級非常激進。

3）時間線是在修復之前選擇的，這不是安全事件的（合理）處理方式。

4）即使用戶資金存在風險，也應該在公開之前找到解決方案，即使是更 廣泛的驗證者組。

・在不可行的時間線上為此使用 cosmovisor，當原始設計使狀態機兼容直到分叉高度時，需要手動升級。團隊在節點運營商中過度估計了 cosmovisor 的重要性。

為什麼要花這麼多輪來嘗試升級？

・因為升級版本是最後一刻發布的，而且升級失敗了，是不能立即恢復的。

・投票權不在我們這裡，我們在爭取了 66% 的投票權，在 10 輪迴合中，也就是說持續了數小時。

為什麼人們需要依賴快照和重新同步 v1.1.2 來重新應用升級 v2.0.1？

當驗證者開始使用 v2.0.1 版本時，許多人認為 peer 存在問題，因為這在 Cosmos 生態系統中很常見。在停止運行其節點以修改對 peer 列表和 / 或增加 peer 數量之後，他們重新啟動了節點。我們認為這導致了 Tendermint 的一種不確定狀態。正如我們所說的，這種不確定狀態導致 Tendermint 不知道它應該處於塊同步模式還是共識模式，從而導致節點處於閑置狀態。要從這種不穩定狀態中恢復，用戶需要刪除他們的數據庫並從升級前的快照中恢復並同步到升級高度，然後更改到 v2.0.1.

此外，Evmos 團隊還在 Github 上發布了補救文件供開發者和驗證者參考。