一文了解Medalla測試網“崩潰”事件始末
作者| Ben Edgington
來源|
來源|上期。
譯者註：請運行Prysm客戶端的用戶盡快升級到
上期
上期
上期
一級標題
然而周五的傍晚，我在控制板中目睹了驗證者參與率突然斷崖式下降。在幾分鐘之內，活躍驗證者從22000降低到5000左右，網絡中約80%的驗證者都消失了。一級標題因此，本文將對此事件進行回顧，包括其後果和下一步的措施。
一級標題Roughtime究竟發生了什麼？
我們發現，網絡中每個運行Prysm客戶端的驗證者都突然消失了。由於Prysm是使用度最高的客戶端，其後果嚴重性可想而知。
Prysmatic團隊在此次事件中開放了一個
文檔報告
，並且持續在其中更新事件細節以及團隊響應。以下是一些重點內容以及我的註釋。
事件起因是時鐘同步(clock sync) 出現問題。 Prysm客戶端的配置使用了Cloudflare的
來計算時間。 (在我看來) 其起因還不是非常明確，但很顯然Roughtime將時間推移到了未來的四小時，並且持續了一個多小時。 Prysm客戶端驗證者們突然發現他們的時間快了四個小時，並且繼續為尚不存在的區塊鏈生成區塊和證明。
就其本身而言，還不足以造成災難性的後果。即使有許多區塊丟失，並且面臨大量來自未來的證明，剩下的客戶端仍然能夠在原鏈上進行建設。漸漸地，隨著Prysm節點的時鐘調整回來，他們開始回到網絡中，並且驗證者參與率也開始回升。網絡似乎在恢復正常。 Eth2Stats但幾小時之後，情形又急轉直下。
在初始時間發生的四小時之後，又發生了兩件事。首先，所有Prysm客戶端在未來生成的證明都開始具備有效性。其次，重新加入網絡的Prysm節點又開始消失了，原因是為了防止他們生成任何相悖的證明，罰沒保護機制被觸發了。
這兩件事同時發生，讓網絡陷入了混亂。剩下的客戶端仍在努力地處理他們所接收到的信息，信標鏈變成了不停分支的叢林。 (Prysmatic團隊的Raul告訴我，Prysm首次修復中的一個bug使得情況惡化)
在一段時間之內，網絡中的信息仍處於可控範圍內。但在接下來的24小時左右，要導航愈加複雜混亂的分叉，所需的內存和CPU變得難以負擔。我看到一個Lighthouse客戶端使用了30GB內存(約為通常情況下的100倍)，對於Teku客戶端來說，即使使用12GB的Java內存堆並最大化處理器，也遇到了麻煩。
請注意，這一切都發生在周末。感謝所有奮戰在一線的客戶團隊們，為了使節點能夠應對混亂的網絡，他們需要不停地優化內存和效率。
到目前為止，網絡正在逐漸恢復。用戶報告不盡相同，但是Prysm和Lighthouse的新版本剛好能夠找到正確的鏈頭並繼續構建信標鏈。
當前顯示鏈頭或附近的Lighthouse、Prysm和Teku節點的一些節點。我們會繼續優化Teku，減少其在同步時所需的資源。沒有發生共識失敗。
有一點需要明確的是，客戶端之間沒有發生共識失敗，也就是說網絡恢復時，所有客戶端都能就鏈頭狀態達成共識，也就意味著信標鏈不會從根本上失敗，也不需要進行任何硬分叉。
Lessons 經驗
我們將會花更多時間對這個插曲進行全面反思和總結，以下是我個人的一些陋見。
時間同步的重要性
高度依賴第三方時間服務對於網絡來說是一個致命點。碰巧的是，ConsenSys TX/RX研究團隊的Alex Vlasov之前就撰文詳盡闡釋了時間同步及其在以太坊2.0網絡中的重要性。他的工作在飛速進展當中，或許這也是一次讓大家關注到這個方面的契機。此處是他的
相關文章和ethresear.ch貼文客戶端多樣性的意義就算我們無法達到這種理想情況，但是降低單個客戶端的極高使用率也能使得網絡更加強健。假設這次只有50%的驗證者下線而非80%，網絡也會更容易恢復。這是因為當客戶端出現問題時，會影響網絡的區塊產生、證明打包、廣播效率、點對點通信以及同步，而這些因素也會對剩餘的驗證者產生連帶效應。
新的API
備用方案的有效性
一些質押者能夠切換簽名密鑰到其他客戶端的熱備份節點。這無疑使非常棒的安全網絡，雖然需要當心避免被罰沒：新驗證者可能對於既有驗證者的投票歷史一無所知，因此可能做出相悖的投票。
在將來，一旦我們完成了
新的API，應該可以實現在不同的信標節點之間切換驗證者客戶端的能力，而不僅僅是密鑰。例如，一個Prysm驗證者能夠輕易地脫離Prysm信標節點，並且重新連接到Teku信標節點。這能夠解決上面提到的罰沒問題。質押者的責任感
目前參與Eth2並不是“一勞永逸”的事。質押者們需要保持一定注意力，遊走於論壇之間，為開發者提供反饋並且能夠在短時內更新客戶端。我非常支持大家運行自己的個人驗證者，但前提是對自己應承擔的責任有所意識。
欲速則不達
為什麼總是在周五傍晚出岔子？
即使發生在這個時間，Prysmatic團隊做出的響應令人驚嘆。詳情請參閱該團隊的
事件報告
。我以下的表述並非意在給Prysmatic團隊帶來不良影響，他們的工作的確非常出色，而是為Teku團隊在面臨相似處境的時候提供經驗。
當有這麼多用戶失去資產的時候(即使只是測試幣)，並且網絡處於高壓狀態下，自然而然會想要做出迅速的反應，但是有時可能欲速則不達。
這次事件中有兩件事是可以避免的。首先，在初始修復版本Alpha.21中有一個缺陷，導致要求用戶在17小時後進行回滾。據Prysmatic團隊Raul的說法，此缺陷是造成隨後出現網絡混亂的原因。其次，團隊在處理情況時無意中刪除了其1024個驗證者的防罰沒記錄數據庫，導致大部分驗證者被罰沒。暴露問題以絕後患
The Block在文章中
最後，這次插曲其實是有必要的。如果測試網中什麼都沒測試出來，那它有何意義？一直處於順滑運行的狀態顯然是不現實的。
這次是一場了不起的考驗！這也許是網絡所能遭受的最嚴重的一類衝擊，就算讓我們自己來設計，可能也設計不出這樣的測試。讓測試網遭受這種程度的衝擊正是我們強化客戶端所需的必備條件。The Block在文章中。
下一步是什麼？
下一步是什麼？
下一步是什麼？
網站：ethereum.cn
更多以太坊資訊請關注：
下一步是什麼？
網站：ethereum.cn
網站：ethereum.cnethereumcn@gmail.com更多以太坊資訊請關注：
