2 月 1 日，以太坊核心開發者參與了第 180 次的 All Core Developers Execution（ACDE）電話會議，安盤了三個重要程式碼的變更包含：Dencun 更新、Prague 提案和 Verkle 以太坊虛擬機物件格式。本文源自 Christine Kim 的會議摘要《Ethereum All Core Developers Execution Call #180 Writeup》，由 Block Beats 整理、編譯及整理。
（前情提要：以太坊坎昆升級(Dencun)在Sepolia測試網啟動，下週Holesky接棒、ETH叩關2400）
（背景補充：以太坊核心開發者最新會議：Deneb升級資訊、Electra升級先考慮的EIP）
以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的更改。本次為 ACDE 第 180 次電話會議，本次會議主要討論了三個重要的程式碼更改：Verkle，以太坊虛擬機器物件格式（EOF）和歷史過期。他們決定將 Verkle 安排在 Prague 升級之後，即 Osaka。此外，還討論了 Dencun 升級的最新動態，包括 Sepolia 和 Holesky 硬分叉，以及與 Dencun 相關的其他測試和問題。
開發者們對 Verkle 進行了初步測試，並對其複雜性提出了一些擔憂，強調了對其在主網實施準備情況的研究。EOF 計劃在 2024 年第四季度的 Devcon 期間進行主網啟用。開發者們決定推遲設定 Dencun 升級的主網啟用日期，以確保處理兩個尚未解決的問題。最後，會議簡要提到了 EIP-7523、EIP-7587 等提議，以及對 Prague 升級的進一步規劃。
Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，將原文編譯如下：
2024 年 2 月 1 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #180 會議。ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支援主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者主要討論了三個重要的程式碼變更：Verkle、以太坊虛擬機器物件格式（EOF）和歷史失效。他們決定將 Verkle 安排在 Prague 升級之後，即 Osaka 升級的 EL 升級中實施。同時，他們還同意在 Prague 升級的同時繼續努力開發歷史失效所需的並行網路，被稱為 Portal Network。關於下一個即將到來的以太坊升級 Dencun，開發者表示他們將在下週四的 ACDC 電話會議上討論升級的主網啟用日期。
Besu 1 月 6 日主網事件
Besu 的開發者 Matt Nelson 詳細介紹了今年初在以太坊上發生的大約 70% Besu 節點故障的情況。Besu 團隊在他們的部落格上分享了該事件的詳細事後分析。Nelson 解釋說，故障是由於 Besu 的 Bonsai 狀態儲存格式中的一個錯誤引起的，具體來說，是 Bonsai 如何編碼狀態更改的問題。已經推出了對 Besu 客戶端的緊急修復，Nelson 強調了他對 1 月 6 日事件中 EL 客戶端多樣性的讚賞。由於以太坊節點運營商還運行了其他客戶端，如 Geth、Nethermind 和 Erigon，Besu 節點的故障並沒有在實質上影響網路健康或干擾網路活動。
Dencun 更新
以太坊基金會（EF）的開發者運維工程師 Parithosh Jayanthi 分享了關於 Sepolia 硬分叉的最新動態，該分叉於 1 月 30 日星期二發生。Jayanthi 表示：「這是一次平穩的分叉。我們看到了網路的最終確認，資料塊也準確地出現在我們希望的位置。」Beiko 提醒團隊，Holesky 硬分叉計劃在下週三，即 2 月 7 日啟用。Holesky 將是最後一個在以太坊主網之前升級的公共以太坊測試網。
關於 Dencun 升級除了 Holesky 分叉之外需要進一步測試的問題，Nethermind 開發者Łukasz Rozmej 表示，他們的團隊正在調查他們客戶端中導致 blob 記憶體池增長超出指定限制的一個錯誤。在對 Devnet-12 進行進一步調查時，Nethermind 團隊向網路傳送了大量的 blob 交易，注意到由於這個 bug，驗證者參與率下降了超過 20%。該團隊計劃在接下來的步驟中向 Goerli 測試網路傳送 blob 交易。以太坊基金會（EF）的開發者運維工程師 Barnabas Busa 要求 Nethermind 團隊在進行 blob 垃圾郵件之前等待在 Goerli 上測試 churn 限制的增加。
除了 Nethermind 的錯誤外，Prysm 開發者「Potuz」表示，他的團隊正在調查有關 Sepolia 的一個晚期區塊提案的異常活動，該提案沒有包含任何 blob 交易。
由於開發者需要調查與 Dencun 相關的這兩個未解決的問題，他們同意在下一次 ACD 電話會議之前暫時不確定升級的主網啟用日期，該電話會議計劃於下週四，即 2 月 8 日舉行。Potuz 補充說，他希望在主網啟用之前從 Layer2 Rollup 團隊那裡得到更多關於 Dencun 升級的回饋。Beiko 表示同意。
Prague 提案
在通話的大部分時間內，開發者們討論了三個主要程式碼變更的實現細節：Verkle、EOF 和歷史失效。
· Verkle：以太坊基金會的研究員 Joshua Rudolf 和 Guillaume Ballet 展示了他們在 Verkle 上的最新工作，這是對以太坊資料儲存和檢索方式進行的重大改革。他們強調了升級中仍需研究的領域，如 Verkle 同步和 gas 計劃更新。基於初步測試，他們估計轉換到 Verkle 將耗時大約兩週，並使交易執行時間變慢約 10%。Rozmej 評論說，這些初步測試應該「持保留態度」，因為它們尚未通過更完整的主網影子分叉進行測試。
由於 Verkle 的複雜性以及對其實施需要更多研究，Rozmej 和其他開發者對在 Prague 升級中承諾釋出程式碼變更表示了擔憂。Ballet 同意 Verkle 可能不會在 Prague 中準備好實施，但他擔心如果不將 Verkle 計劃為升級，無論是 Prague 還是 Osaka，客戶端團隊都將沒有太大的動力去開發它。Ballet 表示，以太坊狀態每年大約增長 25%，開發者等待在主網上執行 Verkle 的時間越長，在 Verkle 過渡期間需要徹底改進的舊資料就越多。
「在我看來，要交付還需要超過一年的時間，」Rozmej 說道。
· EOF：Swirlds Labs 的首席軟體工程師 Danno Ferrin 分享了關於 EOF 開發的最新進展，這是對以太坊虛擬機器（EVM）的一系列程式碼更改，開發者們曾推遲將其納入之前的 Shanghai 和 Cancun 升級。「我們已經進入『交付』模式。我們正在試圖儘可能關閉所有存在的規範可能性的大門，」Ferrin 表示。負責 EOF 開發的團隊已開始制定一個實施矩陣，評估與 EOF 相關的以太坊改進提案（EIPs）的最終狀態，並完成相應的參考測試。
他們計劃在 2024 年第三季度在測試網路上啟用 EOF，希望在 2024 年第四季度的 Devcon 期間啟用主網。「我認為，在未來幾年內，對於解決 EVM 的許多技術債務來說，這些基本變更是至關重要的。所有關於『我們無法增加程式碼大小』等問題的抱怨，在 EOF 的工作方式中都得到了解決，」Ferrin 表示。Erigon 開發者 Andrew Ashikhmin 表示支援在 Prague 中包括 EOF。Ballet 表示，他首先想要看到 EOF 在 Verkle 啟用的測試網路上執行，以瞭解這兩個升級將如何相互影響。Reth 開發者 Dragan Rakita 表示，他並不認為兩者之間一定存在依賴關係，並補充說：「總體而言，EOF 似乎更適合於 Verkle 追蹤而不是傳統的 EVM。」
・歷史失效（History Expiry）： 以太坊基金會開發者 Kolby Moroz Liebl 介紹了歷史失效。根據 EIP 4444 的定義，歷史失效意味著執行層（EL）客戶端在一定時期後，例如一年後，將停止在點對點層提供歷史區塊頭、區塊體和收據。相反，這些資料將通過一種名為 Portal Network 的替代去中心化網路為使用者提供服務。Liebl 已釋出了有關 Portal 的 FAQ 文件。
關於啟動歷史失效所需的工具，Geth 開發者「Lightclient」表示：「我們真的只需要繼續執行規範並開始嘗試讓提供商提供這些資料，因為規範本身，匯出資料，驗證資料，匯入資料都很好，但在資料可用之前，我們實際上無法繼續通過 P2P 網路刪除資料。」Lightclient 補充說，一旦資料在 Portal 上可用並由網路上的資料提供商提供服務，開發者應該等待大約一年才停止在以太坊的 P2P 層中提供這些資料的服務。雖然更新在 P2P 層上提供歷史區塊資料不需要硬分叉，但這將是客戶端團隊希望一致完成的更新，最有可能是通過對以太坊 Wire Protocol 的升級來實現。
在討論完三個主要的程式碼更改後，開發者們討論瞭如何在主網上安排它們的實施。Lightclient 鼓勵客戶端團隊立即開始研究 EIP 4444，因為它不需要對以太坊的核心協議進行重大更改，並且對減輕以太坊節點的資料負載具有重大益處。Lightclient 表示，他將與 Nethermind 和 Besu 客戶端團隊合作，啟動歷史失效的初步工作。
Ashikhmin 指出，從 Erigon 團隊的角度來看，歷史失效的實施將不得不等待幾個月，直到他們的 Erigon V3 版本釋出，因為他們的客戶端目前會重新執行從以太坊起源開始的區塊，因此需要訪問所有歷史區塊資料來完成此過程。Ashikhmin 補充說，他更傾向於在 Prague 中包含 EOF，但如果它與 Verkle 存在相容性問題，他將從升級中刪除它。
Beiko 詢問是否有人反對將 Verkle 安排在 Osaka 升級中。沒有反對意見。以太坊基金會研究員 Ansgar Dietrichs 建議，在可能超過一年的情況下，對 Osaka 升級的範圍保持靈活，對 Verkle 仍然需要進一步的研究，以正確評估其在主網實施上的準備情況。
其他事項
在通話的最後幾分鐘，Beiko 簡要介紹了 ACDE＃180 的最後三個議程事項。
在引擎 API 執行指定客戶端版本 #517：這是一個旨在改進驗證人節點運營商使用的執行層（EL）客戶端追蹤的開放 PR。目前，由於大多數驗證人使用 MEV-Boost 軟體，無法通過分析區塊資料來確定節點運營商使用的 EL 客戶端型別。因此，準確報告 EL 客戶端多樣性需要節點運營商自行報告。該 PR 建議在節點的「graffiti」欄位中預設嵌入用於執行節點的客戶端和版本。這是一些 CL 客戶端已經實施的做法。Beiko 鼓勵客戶端團隊檢視此 PR，並發表他們的意見。
EIP-7523 空帳戶棄用：正如在 ACDE＃173 上討論的那樣，有一個 EIP 旨在減少由空帳戶引起的以太坊測試網路的技術債務。以太坊基金會開發者 Paweł Bylica 對此 EIP 的下一步提出了問題。Beiko 鼓勵 Bylica 在 Ethereum R&D Discord 頻道中分享這些問題。
EIP-7587 為 RIP 保留預編譯地址範圍：正如在 ACDE＃178 上討論的那樣，開發者們計劃為 Layer-2 rollup 團隊保留一組預編譯地址。為 rollups 保留預編譯地址範圍的 EIP 正在進入「最後通話」階段。Beiko 鼓勵開發者在這一階段提出任何最後一刻的評論或對 EIP 的反對意見。
對於下一次 ACDE 通話，Beiko 表示，開發者將專注於進一步確定 Prague 升級的範圍。
📍相關報導📍
TVL超36億美元》盤點6大以太坊再質押協議：EigenLayer、ether.fi..
