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

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

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

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編按：

以太坊所有核心開發者共識電話（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 標籤的話題沒有明確的決定。