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 或數據可用性抽樣，開發者在假期之後組織專門的會議，詳細討論這些更大的協議更改。

原文連結