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 升級的範圍。

原文連結