編按：
以太坊所有核心開發者協商電話（ACDE）每週一召開一次，主要討論和協商對以太坊執行層（EL）的變更。本次為 ACDE 第 180 次電話會議，次本會議主要討論了三個重要的程式碼變更：Verkle，以太坊虛擬機器物件格式（EOF）和歷史過渡。他們決定將Verkle 安排在布拉格升級之後，即大阪。此外，還討論了Dencun 升級的最新動態，包括Sepolia 和Holesky 硬分叉，以及與Dencun相關的其他測試和問題。
開發者對 Verkle 進行了初步測試，並對其複雜性提出了一些擔憂，強調了其在主網實施準備情況的研究。EOF 計劃在 2024 年第四季度的 Devcon 期間進行主網激活。他們決定延遲設定Dencun升級的主網啟動日期，以確保處理兩個尚未解決的問題。最後，會議簡要提到了EIP-7523、EIP-7587等倡議，以及針對布拉格升級的進一步規劃。
Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將編譯如下：
2024年2月1日，以太坊開發人員齊聚Zoom參加了All Core Developers Execution (ACDE) call #180會議。ACDE電話會議是一個每週六舉行一次的系列會議，由以太坊基金會協議支持主管Tim Beiko 主持，開發人員在會議上討論和協商以太執行層（EL）的更改。本週，開發人員主要討論了三個重要的變更代碼坊：Verkle、以太坊虛擬機物件格式（EOF）和他們決定將Verkle安排在布拉格升級之後，即大阪升級的EL升級中實施。同時，他們也同意在布拉格升級的同時繼續努力開發歷史耗電所需的模組網絡，被稱為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 節點的故障並沒有在實體上影響網路健康或乾擾網路活動。
鄧存更新
以太坊基金會（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 團隊在 Goerli 上測試流失限制增加之前進行 blob 垃圾郵件等待。
除了 Nethermind 的錯誤外，Prysm 開發者「Potuz」表示，他的團隊正在調查有關 Sepolia 的一個早期區塊鏈計劃的異常活動，該計劃不包含任何 blob 交易。
由於開發者需要與Dencun調查相關的這兩個未解決的問題，他們同意在下一次ACD電話會議之前暫時不確定升級的主網激活日期，該電話會議計劃於下週四，即2月8日舉行Potuz補充說，他希望在主網啟動之前從Layer2 Rollup團隊那裡得到更多關於Dencun升級的回饋。Beiko表示同意。
布拉格提案
在通話的大部分時間裡，開發者們討論了三個主要程式碼變更的實作細節：Verkle、EOF 和歷史故障。
由於Verkle的複雜性以及本身實施需要更多研究，Rozmej和其他開發者對在布拉格升級中承諾發布代碼變更表示了擔憂。Ballet同意Verkle可能不會在布拉格中準備好實施，但他擔心如果不將Verkle計劃進行升級，無論是布拉格還是大阪，客戶端團隊都會沒有複雜的動力去開發它。芭蕾舞表示，以太坊狀態每年大約增長25%，開發者等待在主網上執行Verkle的時間越長，在Verkle過渡期間需要徹底改進的舊資料精度多。
「在我看來，要交付還需要一年的時間，」Rozmej 說。
他們在 2024 年第三季在測試網路上啟動 EOF，希望在 2024 年第四季的 Devcon 期間啟動主網。「我認為，在未來幾年內，對於解決 EVM 的許多技術計劃來說，這些基本變更是關鍵的。所有關於『我們無法增加程式碼大小』等問題的抱怨，在EOF 的工作方式中都得到了解決，」Ferrin 表示。Erigon 開發者Andrew Ashikhmin 表示支持在布拉格中包括EOF。Ballet表示，他首先希望在Verkle 激活的測試網絡上運行時看到EOF，以了解這兩個升級將如何相互影響。Reth 開發者Dragan Rakita 表示，他並不認為兩者之間存在一定的依賴關係，並補充說：“總體來說，EOF 似乎更適合Verkle 跟踪而不是傳統的EVM。”
啟動歷史故障所需的工具，Geth 開發者「Lightclient」表示：「我們真的只需要繼續執行規範並開始嘗試讓能夠提供這些數據，因為規範本身，關於導出數據、驗證數據、導入數據等好，但是在資料可用之前，我們實際上無法繼續透過P2P網路刪除資料。」Lightclient補充說，一旦Portal上的資料可用並由網路上的資料開始提供服務，開發者應該差不多等待一年才停止在以太坊的P2P層中提供這些數據的服務。雖然在P2P層上更新提供歷史區塊數據不需要硬分叉，但是將是客戶端團隊希望一致完成的更新，最有可能是透過對以太坊坊Wire Protocol的升級來實現。
在討論完三個主要的程式碼更改後，開發者們討論瞭如何在主網上安排它們的實施。Lightclient鼓勵客戶端團隊立即開始研究EIP 4444，它因為不需要對坊以太坊的核心協議進行重大更改，並且對增強以太坊節點的資料負載具有重大益處。Lightclient表示，他將與Nethermind和Besu客戶端團隊合作，啟動歷史故障的參考工作。
Ashikhmin 指出，從 Erigon 團隊的角度來看，歷史故障的實施將不得不等待幾個月，直到他們的 Erigon V3 版本發布，因為他們的客戶端目前會重新執行從以太坊起源開始的區塊，因此需要存取所有歷史區塊資料來完成此過程。Ashikhmin 補充說，他更傾向於在布拉格中包含EOF，但如果它與Verkle 存在兼容性問題，他在配電板升級中刪除它。
Beiko詢問是否有人反對將Verkle安排在大阪升級中。沒有反對意見。以太坊基金會研究員Ansgar Dietrichs建議，在可能超過一年的情況下，對大阪升級的範圍保持靈活，對Verkle仍然需要進一步的研究，以正確評估其在主網實施上的準備。
其他事項
在通話的最後三分之一中，Beiko 簡要介紹了 ACDE＃180 的最後三個事項。
在引擎 API 執行指定客戶端版本 #517：這是一個旨在改進驗證人節點運營商使用的執行層（EL）客戶端追蹤的開放 PR。目前，由於大多數驗證人使用 MEV-Boost 軟體，無法透過分析區塊資料來確定節點運營商使用的EL 用戶端類型。因此，準確報告EL 用戶端多樣性需要節點運營商自行報告。此PR 建議在節點的「塗鴉」欄位中預設嵌入用於運行節點的客戶端和版本。這是一些CL 用戶端已經實施的做法。Beiko 鼓勵客戶端團隊查看此PR，並發表他們的意見。
EIP-7523空帳戶廢棄用：正如在ACDE＃173上基金會討論的那樣，有一個EIP旨在減少由空帳戶引起的坊以太測試網絡的技術債務。以太坊開發者Paweł Bylica此EIP的下前面提出了問題。Beiko 鼓勵Bylica 在以太坊R&D Discord 頻道中分享這些問題。
EIP-7587 為 RIP 保留預編譯位址範圍：正如在 ACDE＃178 上討論的那樣，開發者們計劃為 Layer-2 rollup 團隊保留一組預編譯位址。為 rollups 保留預編譯位址範圍的 EIP 正在進入「最後通話」階段。Beiko 鼓勵開發者在該階段提出任何最後一刻的評論或對EIP 的反對意見。
對於下一次 ACDE 通話，Beiko 表示，開發者將專注於進一步確定布拉格升級的範圍。
