Ethereum核心開發者就流程和Fusaka時間表產生爭議

Ethereum 最近一次 All Core Devs 會議討論的不僅僅是程式碼，還有流程問題：隨著 Fusaka 升級逐步推進，是否要遵守先前承諾的客戶端版本發布與首次測試網分叉之間的 30 天窗口期。一些參與者主張重申這一承諾，以便基礎設施和應用團隊有時間適應；另一些人則認為應保持彈性，以避免更廣泛的路線圖延誤。

這場辯論是在開發網絡測試結果不一的背景下展開的。根據 Dev Ops 團隊的 Barnabas Busa 所述，在 Devnet-3 上，一次計劃中的非終局性測試持續時間超出預期。“我們原本想先進行大約兩天，現在已經進入第五天了，”他說，並指出參與度曾下降，後來又回升到 50% 以上。終局性需要超過三分之二的有效質押總額達成一致。

相比之下，另一個測試網在協調重啟後迅速恢復：“我認為鏈在兩小時內就恢復了，”Busa 說。這種演練壓力測試了各種變數在實際事件中的互動，有助於 Ethereum 在危機時恢復。

閱讀更多：Ethereum 的 Fusaka 升級可能面臨延遲

隨著修復措施在未來幾天內落地，近期計劃是讓 Devnet-3 完全恢復健康，重新進行測試，然後啟動 Devnet-5。

但更大的爭議點在於公共網絡的排程紀律。Lightclient 強調了現有的承諾：“文件上確實寫著首次測試網前 30 天。”他警告不要為了方便而隨意更改目標，這是基於核心開發者對其他未參與會議團隊所需時間的評估。

實際的關注點在於如何改善硬分叉的節奏。壓縮測試間隔可以加快分叉進度，但也增加了下游團隊倉促發布更新的風險。反方則認為，過長的流程會延誤隊列中的其他事項，這可能會讓更廣泛的 Ethereum 社群感到不滿。

“我認為我們不應該根據社群的需求來選擇時間表，”Lightclient 說。“那些負責交付軟體的人表示，他們需要 30 天來交付社群將要使用的高品質軟體。”

即便如此，這場略顯激烈的討論最終傾向於維持既定流程，除非利益相關者明確要求變更。

對於每個週期都要重複討論同一問題，也有人感到沮喪。“我認為不斷讓決策改變是一個非常糟糕的先例，”Lightclient 說，並指出應用開發者和 L2 通常不會參加核心會議，他們依賴可預測的窗口來安排自己的發布計劃。

目前的共識是，繼續按照 30 天緩衝期執行，同時主動徵詢新的意見，協調人 Tim Beiko 表示。“我們應該按照[流程]文件中的內容準備排程，並同時與受影響的利益相關者確認。”如果加速進程確實獲得廣泛支持，團隊將以書面形式正式確立。