以太坊核心開發者最新會議摘要：Devnet #12啟動、升級規劃流程

閱讀本文需 15 分鐘

11月30日，以太坊所有核心開發人員參加了第123次All Core Developers Consensus (ACDC) 電話會議。

原文標題：《Ethereum All Core Developers Consensus Call #123 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

< br>

編按：

以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論和協調對以太坊共識層（CL）的變更。本次為 ACDC 第 123 次電話會議，會議主要涵蓋了對 Cancun/Deneb 和 Devnet #12 測試更新的評估，以及對 Devnet #11 中出現的驗證者退出問題的解決。此外，開發者也針對網路規範澄清、升級規劃流程和 EIP 狀態進行了深入討論。

在對 Cancun/Deneb 的討論中，開發者強調了穩定性，並討論了是否啟動 Goerli 影子分叉。然而，由於 Prysm 用戶端尚未準備好測試，決定等待其準備就緒。對於測試工具和鏈重組的討論強調了對更全面測試覆蓋的需求，並提出了使用 Hive 和 Kurtosis 測試套件的建議。在 EIP 狀態和 CFI 標籤的問題上，Beiko 提出了是否應該保留這些標籤的疑慮，而開發者尚未就此問題達成明確的共識。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2023 年11 月30 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Consensus (ACDC) call #122 會議。 ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會議上討論和協調對以太坊共識層（CL）的更改。本週，開發者們聚焦討論Cancun/Deneb 測試的最新進展，具體包括：

· Devnet #12 的啟動：目前正在對Devnet #12 上Teku、Lodestar 和Lighthouse 用戶端軟體以及所有執行層（EL）用戶端軟體進行測試。 Prysm 團隊預計將在最新的 Devnet 上兩到三週內準備好他們的軟體進行測試。

· Devnet #11 上的驗證器退出問題：在Devnet #11 上，開發者發現了與驗證器退出有關的問題，目前由Nimbus客戶端團隊解決中。在問題解決之前，Devnet #11 將繼續正常運作。

· 網路規格澄清：開發者們討論了對「BlockByRoot」和「BlobSidecarsByRoot」請求的規格進行澄清，明確共識層（CL）節點是否應按特定順序回應這些請求。

除了對Cancun/Deneb 的更新之外，開發者們還討論了以太坊基金會協議支持負責人Tim Beiko 提出的一些流程問題，以提升對以太坊升級的協調。

Devnet #12

2023 年11 月30 日星期三，Cancun/Deneb 升級在Devnet #12 上正式啟動。以太坊基金會測試團隊的 Mario Vega 表示，目前在測試網路上運行的三個 CL 用戶端中「迄今為止沒有發現重大問題」。基金會的 DevOps 工程師 Barnabas Busa 提到，在 Lighthouse、Teku 和 Lodestar 之間，總共有 225 個驗證者分佈在三個節點上。由於 Devnet #12 的穩定性，基金會的 DevOps 工程師 Parithosh Jayanthi 詢問開發者是否應該開始計劃進行 Goerli 影子分叉以進一步測試 Cancun/Deneb。然而，考慮到目前最受歡迎的 CL 用戶端 Prysm 尚未加入 Devnet #12，開發者決定在 Prysm 用戶端軟體準備好進行測試之前暫時擱置計劃進行 Goerli 影子分叉。 Beiko 建議在年底之前的某個時候著手進行 Goerli 影子分叉。由於 Devnet #12 的穩定性，暫時擱置計劃，直到 Prysm 用戶端軟體準備好進行測試。

Devnet #11

網名「Dustin」的Nimbus 開發者介紹了他的團隊正在解決的Devnet #11 的問題細節。這些問題在開發者將 Devnet #11 的三分之一驗證者退出，以在 Devnet #12 上使用時首次發現。 Ryan 詢問 Dustin 是否可以透過額外的測試來發現這些問題。 Dustin 回應稱，在他看來，這些錯誤的性質是由共識規範範圍之外的實現細節引起的。然而，他也承認在為了測試覆蓋的好處而嚴格按照 CL 規範編寫客戶端軟體與為了獲得更好的節點性能而涉足規範的灰色區域之間存在「明顯的緊張關係」。

「我是說更多的測試總是好的，但更有系統地找出如何將更多的客戶端功能納入運行的測試中，也許是更多的自動化方式，無論是使用Hive 還是Kurtosis 或其他什麼方式。如果這些問題能夠解決或者事情能夠很好地被分解，以便能夠納入更多這些任務，我認為那肯定是有用的，」 Dustin 也補充道，CL 開發者應該考慮解決的另一個挑戰是弄清楚CL 規範應該規定和標準化節點行為的詳細程度。「這裡的另一個挑戰是，標準化的程度，這實際上不僅僅是一個軟體工程問題，行為應該有多標準化嗎？」Dustin 問道。所有的 CL 用戶端都通過了檢查基本行為的測試，但是這些測試範圍之外的行為是模糊的。「這些是有意留下的模糊的東西嗎？什麼應該由規範真正明確規定，而什麼應該故意保持模糊？」Dustin 問道。

至少，開發者同意在未來的 Devnets 和測試網路上為 Cancun/Deneb 的大量驗證者退出增加更多的測試。 Ryan 也承認，在涉及 CL 客戶端和 CL 規範實施時，還有更嚴格和全面的測試涵蓋的空間。 Vega 建議 Dustin 創建一個 HackMD 貼文詳細說明他的關切，並在下一次 Cancun/Deneb 測試電話會議上討論這個主題。 Jayanthi 補充道，基於在 Cancun/Deneb Devnets 上最近發現的一些問題，開發者明顯需要能夠系統執行一定數量的鏈上集成相關行為的工具，比如質押 ETH 提取、驗證者退出等。為此，Jayanthi 建議使用 Hive 和 Kurtosis 測試套件的混合來建造這樣的工具。

談到Cancun/Deneb 升級的新測試工具，Jayanthi 指出，開發者們正在研發一種可靠地在Devnets 和測試網絡上激活鏈重組的工具。為了確保這個工具正常運作，Jayanthi 要求開發者分享在以太坊上觸發鏈重組的已知 bug 的詳細資訊。 Jayanthi 解釋說，他將使用這些 bug 來測試該工具，並確保它能夠可靠地識別重組何時發生以及何時解決。

網路規範澄清

開發者們簡要討論了以太坊基金會研究員Justin Traglia提出的一個關於CL 用戶端在收到「BlockbyRoot」或「BlobSidecarsByRoot」請求時應該回傳的回應順序的開放拉取請求。 Ryan 詢問不同 CL 用戶端團隊已經如何實現這個功能。電話會議上沒有任何開發者回答這個問題。 Ryan 建議在以太坊研究與開發 Discord 頻道上重新引起這個討論，讓更廣泛的客戶端開發者參與。 Ryan 承認這兩個請求的規範存在歧義，「可能是問題和奇怪邊緣情況的原因」「值得澄清和整理，」Ryan 肯定道。

Ryan 也提到他將在接下來的幾天發布新版本的 CL 規格。最新版本顯著增加了關於 CL 用戶端何時可以透過「byRoot」RPC 請求提供區塊和區塊的規格。有關透過「byRoot」RPC 請求檢索缺少的區塊和區塊的討論的更多背景，請參考先前的通話記錄。 Ryan 強調，最新版本中包含的 CL 規範的新新增功能不會對已在 Devnet #11 或 #12 上執行的驗證者產生任何影響程式碼的破壞性變更。

升級規劃流程

接著，開發者們討論了Beiko 提出的各種流程事項。 Beiko 表示，警告Goerli 測試網用戶在Cancun/Deneb 升級在Goerli 上激活後的3 個月內，或者在以太坊主網上激活升級後的1 個月內（以後者為準）即將棄用的博客文章將於11 月30 日在以太坊基金會部落格上發布。自電話會議結束以來，上述部落格文章已經發布，可以在這裡閱讀。

Beiko 建議在以太坊「pm」儲存庫下建立昇級專用資料夾，將與特定升級相關的各種檔案整理到一個資料夾中以備後用。電話會議上的開發者們同意了 Beiko 的建議。

Beiko 提出的第二個流程事項是關於創建一個「Meta EIP」文檔，以追蹤以太坊上已經完成的網路升級的全部範圍。「目前沒有一個好的地方可以在部署和在部落格文章中宣布之前追蹤網路升級的全部範圍，」Beiko 在一篇關於他關於 Meta EIP 提案的帖子中寫道。「對於Dencun，我們在一個難以找到的markdown 文件7 中有EL EIPs，而CL EIPs 是Beacon Chain 規範3 的一部分。這並不是很好，因為這兩者都有點難以找到，它們各自使用不同的‘格式’，而且會導致重複。由於ERC 和EIP 現在是分開的，我建議（回到）使用Meta EIPs 來追蹤包含在網路升級中的EIPs。」開發者們贊成創建這些文件。 Beiko 表示，他將在本週起草一份供 Cancun/Deneb 升級審查的文件。

最後，Beiko 提出了一個關於將擬議的代碼更改，以太坊改進提案（EIPs）標記為“考慮包含”（CFI）的實用性的問題。據 Beiko 稱，CFI 是開發者歷史上用作「軟訊號」的狀態，表示 EIP 的作者應該繼續為可能包含在未來硬分叉中的提案而努力工作。它僅用於 EL-focused 的程式碼變更和升級。「[CFI] 高於來自隨機人的隨機想法，但在分叉中被接受之前，」Beiko 說。

過去，標籤 CFI 在指示 EL 上的哪些 EIP 將在升級中實施或何時實施方面幾乎沒有起到任何效果。它已被應用於具有不同程度的程式碼準備度和客戶端團隊支援的各種 EIPs。在 EVM Object Format（EOF）提案的情況下，開發者使用這個標籤表明他們致力於在下一個即將到來的升級 Cancun/Deneb 中實施 EOF。然而，EOF 以及其他幾個也被標記為 CFI 的提案都被從 Cancun/Deneb 中拒絕，目前尚不清楚這些被標記為 CFI 的 EIP 在下一個升級 Prague/Electra 中的狀態。

Beiko 表示，如果這個狀態沒有幫助，開發者應該將其移除，但如果他們打算保留這個狀態，CL 開發者們也應該在考慮在CL 升級中實施的程式碼變更上採用相同的標籤。目前尚不清楚 CL EIP 審查過程在多大程度上反映了 EL EIP 審查過程，以及它們在未來是否應該以相同的方式發展。通常，對 CL 規範的擬議代碼變更在 ACDC 電話會議上進行討論，而對 EL 規範的擬議 EIP 則在 ACDE 電話會議上進行討論。

Swirlds Labs 的Danno Ferrin 也提出了一個想法，為所有EIPs，無論是CL 還是EL 相關，創建一個佔位符字段，用於標識它們在審查過程中的狀態，包括CFI 狀態。在這個電話會議上，關於 EIP 狀態和 CFI 標籤的話題沒有明確的決定。