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