以太坊核心開發者最新會議摘要：2024年1月初在測試網站啟動坎昆升級

12月7日，以太坊所有核心開發人員參加了第176次All Core Developers Execution(ACDE) 電話會議。

原文標題：《Ethereum All Core Developers Execution Call #176 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論並協調對以太坊執行層（EL）的變更。本次為ACDE 第176 次電話會議，會議主要涵蓋了與Cancun/Deneb 升級、Devnet #12 的測試進度以及Prague/Electra 升級規劃等多個方面的討論。

開發者們就Cancun/Deneb 升級在Devnet #12 上的測試情況展開了討論，包括不同客戶端團隊的進展和發現的一些問題以及blob 傳播、MEV（最大可提取價值）等方面的技術挑戰。對於即將到來的Prague/Electra 升級，開發者提出了一係列可能的技術變更。

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

2023 年12 月7 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Execution (ACDE) call #176 會議。 ACDC 電話會議是一個每兩週舉行一次的係列會議，由以太坊基金會協議支持主管Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者們討論了在Devnet #12 上進行的Cancun/Deneb 升級的測試工作。他們同意在假期結束後的一月初，在以太坊Goerli 測試網路上協調升級的啟動日期。此外，他們計劃在一月初開始討論下一個以太坊升級Prague/Electra 應包含哪些程式碼變更。

Devnet #12 更新

Cancun/Deneb 升級在Devnet #12 上的測試進展順利。基金會的DevOps 工程師Parithosh Jayanthi 透露，目前已在兩個客戶端Reth 和Lighthouse 中發現了一些錯誤，兩個客戶端團隊正在緊急修復中。為了更全面地測試MEV 工作流程，DevOps 團隊正在更專注於在Devnet #12 上的更多驗證器上啟用MEV-Boost 軟體。 Jayanthi 表示，他的團隊至少發現了Flashbots 的MEV 中繼實作中的一個錯誤。以太坊基金會研究員Danny Ryan 強調，為了確保在中繼失敗時驗證器能夠切換到本地區塊構建，還需要進行額外的測試來檢查備用機製。

對於特定客戶端團隊的升級，Prysm 用戶端的開發者Terence Tsao 表示，他的團隊正在研究ACDC #122中討論的blob 傳播的更新設計。 Tsao 確認，Prysm 用戶端將準備好在下週，可能是下下週加入Devnet #12 進行測試。 Besu 用戶端的開發者Justin Florentine 表示，Besu 已準備好從Devnet #12 邁進。 Nethermind、Erigon、Lodestar 和Teku 用戶端團隊的代表也表示已準備好繼續在公共以太坊測試網路上進行升級測試。

基於客戶端的準備情況，Beiko 建議在開發者結束假期後儘快協調一個硬分叉的日期。假設在Prysm 用戶端加入後的未來幾週內在Devnet #12 上沒有發現重大錯誤，Beiko 表示Cancun/Deneb 在Goerli 上的激活可能在一月中旬左右進行。來自Teku 團隊的Ben Edgington 詢問開發者是否對將每個區塊的blob 數量從兩個更改為三個的變更感到有信心。 Ryan 建議在大規模陰影分叉和Cancun/Deneb 在Goerli 上激活期間對增加的blob 目標進行額外測試。 Beiko 確認在Goerli 上進行的升級啟動將是對每個區塊三個blob 目標的「最後一次重要測試」。假設沒有問題被發現，開發者將繼續使用增加的blob 數量進行主網啟動。

總的來說，Beiko 表示開發者將在現在和假期結束之間繼續在Devnet #12 上測試升級。 DevOps 團隊計劃在12 月底之前至少啟動一個Goerli 陰影分叉，為一月份的Goerli 真正硬分叉做準備。如若開發者在新年集結，他們將討論Goerli 硬分叉激活的日期。

Builder 覆蓋標誌

接著，Tsao 詢問了客戶端團隊在實作Builder 覆蓋標誌方面的進展。 Builder 覆蓋標誌是Cancun 升級中的一個新的布林字段，執行層用戶端可以使用它來向共識層用戶端指示，當Builder 檢測到審查活動時，驗證者應該回退到本地區塊生成，而不是使用第三方Builder。正如Tsao 所強調的，關於如何檢測Builder 的審查活動的實作細節是主觀的，並且故意留給客戶端團隊設計。有關Builder 覆蓋標誌的更多信息，請參考ACDC#112和ACDE#165的會議記錄。

網名「Lightclient」的Geth 用戶端團隊開發者表示，他的團隊已經實現了該標誌，但在「不久的將來」內不會在官方發布中合併。 Besu 和Nethermind 團隊的代表表示，他們的客戶端中尚未實作這個可選標誌。 Tsao 強調該標誌可能是一個有用的工具，最好儘早實現，以阻止和打擊質押池或大型驗證者節點運營商參與某些「時間遊戲」。 Tsao 解釋說，驗證者可以透過延遲區塊傳播來獲得更多的MEV（最大可提取價值），而在Cancun 升級後引入blobs 之後，將會產生對區塊傳播的延遲。在這些延遲期間，驗證者可能選擇在區塊中包含更具利潤的MEV 交易，這對及時的blob 傳播來說是次優的。

確認blob 交易將不得不與常規交易競爭，Prysm 團隊的一位化名開發者，以Potuz 為屏幕名的開發者補充道：“Blobs 不僅需要與費用競爭，而且還需要與延遲本身以及通過延遲區塊獲得的所有MEV 競爭。在設計blobs 的費用機製時，我認為這是一個沒有被阻止或考慮到的市場。」Tsao 表示他將在Ethereum Research Discord 中再次提出這個問題進行進一步討論。此外，Ryan 強調了Ethereum Foundation 研究員Caspar Schwarz-Schilling 和Mike Neuder 在Ethresearch 網站上關於「timing games」的最新貼文。

專案進度

接下來，Beiko 分享了三個與以太坊升級規劃過程相關的更新。首先，正如在ACDC #123上討論的那樣，Beiko 已經為Cancun/Deneb 升級創建了一個Meta EIP 文檔，該文檔列出了已包含在Cancun/Deneb 中的所有以太坊改進提案（EIPs）。它已經在GitHub 上創建，EIP 編號為7569。此外，Beiko 還創建了EIP 7568，作為所有先前升級的Meta EIP 文檔，開發者沒有創建專門的文檔來追蹤升級中包含的EIP 清單。 EIP 7568 將連結到升級程式碼規格。

其次，Beiko 宣布他已在Ethereum Magicians 網站上創建了一個新的討論主題，以確定下一個網路升級，即Prague/Electra。他要求開發者在是否像過去兩次硬分叉一樣將執行層（EL）和共識層（CL）的升級捆綁在一起方面進行批判性思考。某些代碼變更的激活，如EIP 7002，將需要對EL 和CL 都進行更改，因此將需要同時協調Prague 和Electra 升級。然而，對於其他程式碼更改，如Verkle 樹，有方法重新設計實現，隻需要對CL 進行升級。

Ryan 指出，與Verkle 樹同時進行的共識層（CL）開發者也正在進行支援資料可用性抽樣的程式碼變更。 Beiko 建議開發者不要在Prague/Electra 升級中詳細討論所有他們希望看到的EIPs 的細節，而是建議他們在假期期間審查所有候選代碼更改，並在一月份準備好認真討論這些更改。 Potuz 同意這種觀點，並補充說，一個旨在解決以太坊驗證者集大小增長問題的EIP 將是Prague/Electra 中的一個重要程式碼變更。基於程式碼變更的複雜性，Beiko 建議對於某些EIPs，如Verkle 或資料可用性抽樣，開發者在假期之後組織專門的會議，詳細討論這些更大的協定變更。