編者註：2020 年8 月15 日，Medalla 測試網出現了驗證者參與率的大幅下降，起因是Prysm 客戶端默認使用Cloudflare 公司的roughtime 服務來較準節點的本地時間，但當時的roughtime 服務出了錯，導致所有Prysm 節點的本地時間都快了4 個小時，如此一來，Prysm 節點就與使用其它客戶端的節點隔絕開來了。事發之後，Prysm 客戶端團隊迅速推出了緊急修復並密切跟踪事態。但Medalla 測試網仍因為各種原因而繼續動盪，無法敲定epoch。事實上，事發之後，截至發文之時，Medalla 測試網僅在北京時間2020 年8 月20 日凌晨曾敲定區塊，隨後驗證者參與度又降到了66% 以下，未能敲定區塊。事實雖然令人不安，但它恰好提供了一個我們審視Eth2 網絡、審視節點行為的機會—— 絕不應放過這樣的審視和反思的機會，否則我們仍有可能重蹈覆轍。我們選擇了多份材料，嘗試多角度、多層次地複現完整的事實、囊括盡可能多不應被忽略的因素。誠然，我們缺乏能觀察到去中心化網絡全局情形的上帝之眼，認知的深度必定有其邊界，但我們仍然希望，對陷入混沌的網絡的恢復過程和參與者在此過程中的激勵因素，能有一個完整的描述。到目前為止，這個目標還未實現。第一份材料，來自Prysm 客戶端工程師prestonvanloon.eth 在推特上對事件的報告。
Medalla 測試網全局性故障初探
phil.eth：
ETH 2.0 測試網Medalla 目前無法敲定區塊，因為Prysm 客戶端的roughtime 時鐘同步出了問題。目前已經有了修復方案。請Prysm 用戶更新並重啟你們的客戶端。這一突發情況再次表明了客戶端多樣性以及測試網的重要性。
prestonvanloon.eth：
今天（8 月15 日）早些時候，Prysm 出現了全局性故障，持續時間將近90 分鐘。本次事件的始末如下：
世界協調時17:30（北京時間凌晨1:30）左右，@terencechain 發現其客戶端的時鐘提前了4 小時。很快，出現時鐘偏移報警，discord 頻道也被大量用戶報告淹沒。
Prysm 客戶端確實出了問題。
Medalla 測試網上的驗證者參與度驟降，其下降速度甚至超越了$YAM 的歸零速度，從75% 降至5% 以下。 Prysmatic Labs 團隊立即展開了緊急行動。
我們決定將軟件改成默認禁用roughtime 時鐘同步，取而代之的是可選擇的功能切換（feature flag）。這樣可以防止此類問題再次大規模爆發。從現在開始，roughtime 的結果將僅供客戶端軟件參考，不再用於自動時鐘校準。
下圖是Prysm 節點出現超過2 秒的時鐘偏移（clock skew）的時間段，從北京時間凌晨1:30 至3:00 持續了大約90 分鐘。 （注：下圖是太平洋標準時間。）
- 圖片來源：@prestonvanloon.eth -
現在，我們正看著這個數據思考一個問題“roughtime 服務器怎麼會偏差這麼大？” 數據顯示，所有Prysm 服務器報告的偏移量都在0.1 秒不到。最後為什麼會提前4 小時？ ？
- 圖片來源：@prestonvanloon.eth -
我們還在調查這個問題！肯定是roughtime 的增量計算出了bug ，我們希望能盡快找到它。無論調查結果如何，我們認為應該將自動時間校準作為可選項，甚至徹底取消掉。
歡迎閱讀完整的事後調查報告，了解最新的調查進展。
在主網上線之前，測試網就是用來發現這類問題的。面對這種情況，多幾個客戶端選擇對用戶更為有利。
（完）
原文鏈接:
https://twitter.com/preston_vanloon/status/1294392007599652865
作者: prestonvanloon.eth
翻譯&校對: 閔敏 & 阿劍
編者註：第二份材料來自Prysm 客戶端團隊的分析報告，有詳盡的時間線記錄。從中我們可以知曉Prysm 客戶端發布緊急修復的整個過程，以及緊急修復帶來的連帶影響（緊急修復自身也帶來了問題）。截至本譯稿發表之時，該分析報告表示已經找到了故障的具體原因。值得一提的是，報告原文所用的都是UTC 時間（世界協調時），我們一律轉換成了北京時間。
“roughtime” 事件分析報告
作者：Terence、Raul、Preston
狀態：等待決議。根本原因已找到，問題已緩解。
網絡：Medalla
總結：Cloudflare 的roughtime 服務器全都返回錯誤信息，而Prysm 節點並沒有採取適當的應急措施。這個bug 導致所有Prysm 節點出現時鐘偏移（clock skew）。在時鐘偏移的影響下，驗證者為超前的slot（時隙）提議區塊並生成見證消息。
影響：由於roughtime 響應錯誤以及出現時鐘偏移，驗證者計算slot 錯誤，提議的區塊和生成的見證消息均無效。這個問題影響到了全局參與度。在北京時間凌晨1:30 至2:45 之間，所有Prysm 節點都受到了影響。
根本原因：來自Cloudflare 服務器的roughtime 響應出錯。具體來說，是因為“ticktock” 報告了一個24 小時之後的時間。這個時間戳，再經過所有6 個服務器的數據取平均值，是的所有Prysm 節點都產生了+4 小時的時間調整。
解決方案：在我們評估roughtime 響應錯誤所引發的潛在問題時，先將roughtime 時鐘同步設為可選項。
發現：Terence 最先發現了這個問題。他注意到一個本地信標鏈節點一直在拒絕超前的區塊和見證消息。幾分鐘之後，由於roughtime 時鐘偏移量較高，產生了報警。同時， #general 和#bug-report 頻道的用戶開始報告本地節點拒絕超前區塊和見證信息的問題。
經驗教訓
哪裡出了問題
我們誤以為，對於roughtime 服務器故障的問題，我們有適當的應急方案。網絡中的每個Prysm 節點同時受到影響，導致驗證者參與率大幅降低。 Prysmatic Labs 團隊原以為，NTP 服務器本身較為分散，而且每個服務器都開放6 個端口，不會出現全局故障的問題。
萬幸的是
一位貢獻者已經向我們提交了一個Pull Request（感謝@ncitron），把roughtime 時間校准設為可以選擇退出的功能。我們已經可以用命令行功能標籤（flag）立即選擇取消roughtime 時鐘校準，這讓修復措施變得簡單，而且只需一次Pull Requtest 就能驗證。用戶在Discord 上積極參與討論。當節點出現問題時，有大量用戶提供了詳細報告和重要指標。我們有一個持續不斷的重同步機制，當它發現時鐘偏移量超過2 秒時，它會不斷更新節點本地的時間。我們一直在重新校準roughtime 時鐘，以便更快解決這一問題。這可能讓這次事件提前了大約30 分鐘至1 小時結束。 roughtime 時鐘同步問題似乎在大約90 分鐘後就解決了，而且在我們能夠緊急發布新版本前，這個事件就已經結束了。
時間線（北京時間）
2020/08/15
1:25 AM ：Terence 發現他的本地節點由於一直拒絕超前區塊，收到了大量報警。這些區塊的slot 都超前了4 個多小時。
1:28 AM ：Prometheus（普羅米修斯）監控報警系統收到了roughtime 偏移量高的報警。那時，距離網絡最後一次敲定區塊過去了10 epoch（時段）。
1:35 AM ：至少有30 名用戶在Discord 頻道表示他們開始收到下方報警：WARN roughtime: Roughtime reports your clock is off by more than 2 seconds offset=4h0m0.028854657s （roughtime 警報：Roughtime 報告你的時鐘誤差超過2 秒，偏移量= 4h0m0.028854657s）
1:43 AM ：Terence 在#war-room 頻道群發了告警消息，稱這是一個PS0 級別的事件，需要大家共渡難關。
1:45 AM ：Discord 頻道的用戶提出，重啟信標鏈節點和驗證者客戶端無法暫時解決這個問題。最可行的方案是將roughtime 時鐘同步設為可選禁用的功能。
1:51 AM ：問題上升到了多客戶端聊天室
1:52 AM ：Ivan 完成了https://github.com/prysmaticlabs/prysm/pull/6898
2:00 AM ：Terence 與512 位驗證者一起在本地測試了6898 號Pull Request 。
2:20 AM ：據已捕獲的調試日誌顯示，“ticktock” 服務器有段時間一直在報告24 小時之後的時間。
2:27 AM ：Raul 聯絡了Preston 。 Preston 將在1 小時內回來構建新版本。同時，我們將發布docker 鏡像。
2:40 AM ：Preston 指出只靠緊急修復還不夠，我們需要取消將roughtime 時鐘同步作為默認項。
2:42 AM ：Raul 開始調查Kibana ，並使用fluentd 中的filter（過濾器）分析來自roughtime 的調試日誌響應。
2:43 AM ：Terence 交叉檢查了信標鏈命名空間中所有pod 的kubectl 日誌。正如預期的那樣，pod 確實存在roughtime 時鐘偏移問題。
2:46 AM ：Raul 向6898 號PR 提交了正確的修復程序。
3:05 AM ：Raul 確認該修復程序可以讓節點在本地工作。如果存在時鐘偏移，修復程序會產生告警日誌，但是不會試圖基於roughtime 服務器更新時間。
3:08 AM ：Terence 在我們的discord 頻道向所有人宣布：“Prysm 節點出現roughtime 響應錯誤，應急措施沒有達到預期效果。我們已經找到了故障所在，很快就會進行緊急修復，並在1 小時內上線新版本。在即將發布的新版本中，roughtime 時鐘同步將不再是默認項。”
3:18 AM ：Buildkite 單元測試、規範測試、docker 鏡像構建成功。 e2e 測試尚未完成。 Preston 準備啟動上線流程。
3:22 AM ：新版本生成：https://github.com/prysmaticlabs/prysm/commit/d24f99d66db22691b69c76bc57c7509e7f3ba8fe。 Terence 確認這個方法可以修復其驗證者節點。 Preston 開始使用新的docker 鏡像依次重啟我們的有狀態集合中的pod 。集群驗證者會基於新的鏡像進行更新（不保留臨時磁盤）。
3:34 AM ：Docker 鏡像被標記成alpha 21 版本，穩定性好，二進製文件已經構建完成
3:34 AM ：對有狀態集合中pod 的健康狀態進行監控，確保滾動更新成功
3:36 AM ：使用新的docker 鏡像對我們的驗證者pod 進行滾動啟動。
4:29 AM ：在日誌上查看返回的延時值。平均來看，這些值似乎都在0.1 秒以下。延遲不是調查的關鍵指標。準確來說，“中點（midpoint）” 才是需要研究的地方。注：下表時間是太平洋標準時間。 https://kibana.prylabs.network/goto/e5f5f64a4426c85aee1d76abc2d994be
- 圖片來源：@prestonvanloon.eth -
5:32 AM ：查看高於2 秒的偏移量。從該數據中可以看出，在長達90 分鐘的全局故障期間，Prylabs 出塊節點的偏移量大約是14000 秒。注：下表時間是太平洋標準時間。 https://kibana.prylabs.network/goto/6ce2d73c13c0eef600b604fee6d8f4f4
- 圖片來源：@prestonvanloon.eth -
4:41 AM ：通過Prometheus 報警系統關於平均偏移量的數據，我們可以明顯看出在北京時間凌晨1:30 至2:45 之間確實存在時鐘偏移問題，之後偏移量開始下降並恢復正常。
（圖片無法複製，請至原文觀看）
4:52 AM ：即時調查結束。這次時鐘偏移故障顯然已經結束，而且修復程序已經發布。已經更新的節點將立即恢復，還沒有更新的節點需要過段時間恢復。監控系統顯示，驗證者參與度在逐步回升。
6:20 AM ：用戶報告說罰沒保護機制已經啟動。這是因為之前的時鐘偏移導致驗證者超前4 小時提議區塊並生成見證消息。為了避免遭到罰沒，Prysm 驗證者沒有繼續提議無效區塊。
8:13 AM ：再次故障
8:13 AM ：Nishant 注意到6898 號PR中存在嚴重缺陷。只有在roughtime 功能標記開啟的情況下，用戶才能設置它的功能。
8:16 AM ：Preston 更新了“最新的” 二進製文件，使其指向alpha 20 版本來實現臨時回滾，並建議用戶回滾至alpha 20 版本。我們現在正在等待合併7004 號PR 作為alpha 22 版本的候選。
8:45 AM ：值班團隊正在評估是否擴大熱狀態緩存的大小，以便alpha 22 版本能夠更快讓網絡重新開始敲定區塊。當前默認的熱狀態緩存大小為8 個epoch ，但是Medalla 測試網距離上一次敲定區塊已經過去了將近100 個epoch 。
9:12 AM ：值班團隊決定將默認緩衝大小更新至64 epoch ，並使其可以通過功能標記來配置。經過初步測試，這有可能會使內存使用量增加1.5G 。等網絡重新開始敲定區塊後，緩衝大小還可以調整。
9:57 AM ：所有Prysmatic Labs 驗證者節點都生成了會被罰沒的見證消息。緊急修復程序刪除了Prylabs 驗證者節點的本地存儲。沒有任何外部的罰沒保護機制在運行。具體情形尚待確認……在1024 名驗證者中，至少有800 名驗證者已經或即將遭到罰沒。
10:37 AM ：多名用戶報告稱無法同步區塊鏈。目前的問題是，網絡中有太多節點在同一時間進行同步。 Alpha 22 版本被推遲，需要等待進一步通知。
10:46 AM ：Prylabs 團隊認為現在最好的辦法就是等待。用戶應該運行alpha 20 版本或最新的docker 鏡像。
2020/08/16
2:12 AM ：正在對同步難的問題進行調查。
11:36 AM ：Nishant 和Victor 發布初始同步修復程序。參見Pull Request 7012 。
2020/8/17
1:51 AM ：合併拉取7012 號PR。一些用戶報告說同步成功。 Prysmatic Labs 開始將7012 部署到出塊節點上。
5:15 AM ：從commit 0be1957c2897909b943b80fdd028f5346ae6cde6 開始開發Alpha.22 版本
5:33 AM ：Alpha 22 版本發布。鏈接：https://github.com/prysmaticlabs/prysm/releases/tag/v1.0.0-alpha.22
5:40 AM ：通過Discord 頻道宣布Alpha 22 版本上線。 Prysmatic 的值班團隊繼續監控同步情況，以便進行優化。與此同時，越來越多用戶同步至最新區塊。
12:53 AM ：Alpha 23 版本上線，已在Discord 頻道宣布該消息。 Alpha 23 版本包含一些同步修復程序，有望解決Medalla 測試網的問題。建議用戶在運行時開啟“--dev” 標記，以便獲得更好的體驗。
（完）
（文內有許多超鏈接，可點擊左下”閱讀原文“ 從EthFans 網站上獲取）
原文鏈接:
https://docs.google.com/document/d/11RmitNRui10LcLCyoXY6B1INCZZKq30gEU6BEg3EWfk/edit#
作者: Prysmatic Labs
翻譯&校對:
閔敏 &阿劍
