ETH研討會核心開發人員最新會議摘要：2024 年 1 月初在測試網上啟動坎昆升級

原標題：乙太坊所有核心開發人員 ution 調用 #176 寫

克裡斯汀·金的原創文章

原創合輯：Luccy， BlockBeats

編者按：

ETH研討會 所有核心開發人員共識電話會議 （ACDE） 每兩周舉行一次，以討論和協調對ETH研討會執行層 （EL） 的更改。 這是ACDE的第176次電話會議，它將涵蓋坎昆/Deneb升級的討論，測試Devnet #12的進展以及布拉格/伊萊克特拉升級計劃。

開發人員討論了如何在 Devnet #12 上測試坎昆/Deneb 升級，包括不同客戶團隊發現的進展和一些問題，以及 blob 傳播、MEV（最大可提取價值）等方面的技術挑戰。 對於即將到來的布拉格/伊萊克特拉升級，開發人員提出了一系列可能的技術更改。

Galaxy Digital研究VP Christine Kim詳細介紹了會議的亮點，BlockBeasts彙編如下：

2023 年 12 月 7 日，ETH開發人員聚集在 Zoom 面向所有核心開發人員 ution （ACDE） 電話 #176。 ACDC電話會議是由ETH基金會協定支援主管Tim Beiko領導的每兩週一次的系列會議，開發人員討論和協調對ETH Place執行層（EL）的更改。 本周，開發人員討論了在Devnet #12上測試Cancun/Deneb升級。 他們同意在假期結束后ETH 1月初協調Goerli測試網路上升級的啟動日期。 此外，他們計劃在1月初開始討論下一個ETH車間升級（布拉格/伊萊克特拉）應包含哪些代碼更改。

開發網 #12 更新

在Devnet #12上測試坎昆/Deneb升級進展順利。 基金會的DevOps工程師Parithosh Jayanthi透露，在兩個用戶端Reth和Lighthouse中發現了一些錯誤，兩個客戶團隊正在進行緊急修復。 為了更徹底地測試MEV工作流程，DevOps團隊更專注於在Devnet #12上的更多驗證器上啟用MEV-Boost軟體。 根據Jayanthi的說法，他的團隊在Flashbots的MEV中繼實現中至少發現了一個錯誤。 ETH基金會研究員Danny Ryan強調，為了確保驗證者在中繼發生故障時可以切換到本地區塊構建，需要額外的測試來檢查替代機制。

對於特定於用戶端的團隊升級，Prysm用戶端的開發人員Terence Tsao表示，他的團隊正在為ACDC #122中讨论的 blob傳播進行更新設計。 Tsao證實，Prysm用戶端將準備在下周加入Devnet #12進行測試，可能是下周。 Besu用戶端的開發人員Justin Florentine表示，Besu已準備好從Devnet #12遷移。 來自Nethermind，Erigon，Lodestar和Teku客戶團隊的代表也表示，他們準備繼續在公共ETH測試網上測試升級。

根據客戶的準備情況，Beiko建議在開發人員放假后立即協調硬分叉日期。 假設在 Prysm 用戶端加入後的幾周內在 Devnet #12 上沒有發現重大錯誤，Beiko 表示 Goerli 上的坎昆/Deneb 啟動可能會在 1 月中旬左右發生。 來自Teku團隊的Ben Edgington詢問開發人員，他們是否有信心將每個塊的blob數量從兩個更改為三個。 Ryan建議在Goerli上的大規模陰影分叉和坎昆/Deneb啟動期間對增加的斑點目標進行額外測試。 Beiko證實，Goerli上的升級啟動將是每個區塊三個blob目標的“最後一次重大測試”。 假設未發現任何問題，開發人員將繼續使用增加的 blob 數量進行主網啟動。

總體而言，Beiko表示，從現在到假期結束，開發人員將繼續在Devnet #12上測試升級。 DevOps 團隊計劃在 12 月底之前啟動至少一個 Goerli 影子分叉，為 1 月份真正的 Goerli 硬分叉做準備。 如果開發人員在新的一年裡聚集在一起，他們將討論Goerli硬分叉的啟動日期。

產生器覆蓋標誌

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

網名為“Lightclient”的Geth用戶端團隊的開發人員表示，他的團隊已經實現了該標誌，但“在不久的將來”不會將其合併到官方版本中。 Besu和Nethermind團隊的代表表示，這個可選標誌尚未在他們的客戶中實施。 曹強調，標誌可以是一個有用的工具，最好儘早實施，以阻止和阻止質押池或大型驗證節點運營商參與某些“時間遊戲”。 Tsao解釋說，驗證者可以通過延遲區塊傳播來獲得更多的MEV（最大可提取值），並且在坎昆升級后引入blob后，區塊傳播將出現延遲。 在這些延遲期間，驗證者可能會選擇在區塊中包含更有利可圖的MEV交易，這對於及時的blob傳播來說是次優的。

確認blob交易將不得不與常規交易競爭，Prysm團隊的一位化名開發人員（螢幕名稱為Potuz）補充說：“Blob不僅需要與費用競爭，還需要與延遲本身以及通過延遲塊獲得的所有MEV競爭。 在設計 blob 的費用機制時，我認為這是一個沒有被阻止或考慮的市場。 Tsao表示，他將在乙太坊研究不和諧中再次提出這個問題以供進一步討論。 此外，Ryan還強調了乙太坊基金會研究人員Caspar Schwarz-Schilling和Mike Neuder在Ethresearch網站上關於“計時遊戲”的最新文章。

項目進度

接下來，Beiko分享了與ETH車間升級規劃過程相關的三個更新。 首先，與ACDC #123上讨论的那样 一樣，Beiko為坎昆/Deneb升級創建了一個Meta EIP文檔，其中列出了坎昆/Deneb中包含的所有ETH改進提案（EIP）。 它是在 GitHub 上創建的，EIP 編號為 7569。 此外，北光創建了 EIP 7568 作為之前所有升級的元 EIP 文檔，開發人員沒有創建專用文檔來跟蹤升級中包含的 EIP 清單。 EIP 7568 與升級代碼規格相關聯。

其次，Beiko宣佈他已經在乙太坊魔術師網站上創建了一個新的討論線程，以確定下一個網路升級，布拉格/伊萊克特拉。 他要求開發人員批判性地思考是否像過去兩個硬分叉那樣將執行層（EL）和共識層（CL）升級捆綁在一起。 某些代碼更改（例如EIP 7002）的啟動將需要對EL和CL進行更改，因此布拉格和Electra的升級都需要協調。 但是，對於其他代碼更改，例如 Verkle 樹，有一種方法可以重新設計實現，只需要升級 CL。

Ryan指出，與Verkle樹並行工作的共識層（CL）開發人員也在進行代碼更改，以支持數據可用性採樣。 Beiko建議開發人員不要詳細說明他們希望在布拉格/伊萊克特拉升級中看到的所有EIP，而是在假期期間審查所有候選代碼更改，並準備好在一月份認真討論它們。 Potuz對此表示同意，並補充說，旨在解決日益嚴重的ETH驗證器集大小問題的EIP將是布拉格/伊萊克特拉的一個重要代碼更改。 基於代碼更改的複雜性，Beiko 建議對於某些 EIP，例如 Verkle 或數據可用性採樣，開發人員在假期後組織專門會議，詳細討論這些較大的協定更改。