原文標題：《Ethereum All Core Developers Execution Call #180 Writeup》
原文作者：Christine Kim
編按：
以太坊所有核心開發者共識電話（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 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
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 升級的範圍。
「原文連結」
區塊財經BOTD – 廣播組
追蹤BOTD Instagram，獲取最新區塊鏈消息
▸https://www.instagram.com/botd_news/
免責聲明：本文內容僅供參考，投資人應獨立判斷，審慎投資，並自負風險，本文不提供或嘗試遊說觀眾做交易或投資之依據。
