這次以太坊核心開發人員的電話會議主要討論了三個重要的程式碼變更：Verkle、以太坊虛擬機器物件格式（EOF）和歷史過渡。他們決定將Verkle 安排在布拉格升級之後，即大阪。也討論了Dencun 升級的最新動態，包括Sepolia 和Holesky 硬分叉，以及與Dencun 相關的其他測試和問題。開發者對Verkle 進行了初步測試，對其複雜性提出了一些擔憂。 EOF 計劃在2024 年第四季的Devcon 期間進行主網啟動。他們決定延遲設定Dencun 升級的主網啟動日期，以確保處理兩個尚未解決的問題。 Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄。
原文標題：《以太坊所有核心開發人員執行呼叫#180 Writeup》
譯者：Christine Kim
編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者協商電話（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 開發工程師s 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：以太坊基金會的研究員Joshua Rudolf 和Guillaume Ballet 展示了他們在Verkle 上的最新工作，這是對以太坊資料儲存和檢索方式進行的重大改革。他們強調了升級中仍需研究的領域，例如Verkle 同步和Gas 計畫更新。基於初步測試，他們估計轉換到Verkle 將大約完成交易，完成交易執行時間變慢約10%。 Rozmej 評測說，這些初步測試應該「持保留態度」，因為目前尚未通過更完整的主網影子分叉進行測試。
由於Verkle的複雜性以及本身實施需要更多研究，Rozmej和其他開發者對在布拉格升級中承諾發布程式碼變更表示了擔憂。 Ballet同意Verkle可能不會在布拉格中準備好實施，但他擔心如果不將Verkle計劃進行升級，無論是布拉格還是大阪，客戶端團隊都會沒有複雜的動力去開發它。芭蕾舞表示，以太坊狀態每年約成長25%，開發者等待在主網上執行Verkle的時間越長，在Verkle 過渡期間需要徹底改進的舊資料精度多。
「在我看來，要交付還需要一年的時間，」Rozmej 說。
· EOF：Swirlds Labs 的首席軟體工程師Danno Ferrin 分享了關於EOF 開發的最新進展，這是對以太坊虛擬機（EVM）的一系列程式碼更改，開發者曾推遲將其合併在上海和坎昆升級之前「我們已經進入『交付』模式。我們正在嘗試關閉所有存在的規範可能性的大門，」Ferrin 表示。負責EOF 開發的團隊已開始製定一個實施矩陣，評估與EOF 相關的以太改進坊提議（EIPs）的最終狀態，並完成相應的相關測試。
他們在2024 年第三季在測試網路上啟動EOF，希望在2024 年第四季的Devcon 期間啟動主網。 「我認為，在未來幾年內，對於解決EVM 的許多技術計劃來說，這些基本變更是關鍵的。所有關於『我們無法增加程式碼大小』等問題的抱怨，在EOF 的工作方式中都得到了解決，」Ferrin 表示。 Erigon 開發者Andrew Ashikhmin 表示支援在布拉格中包括EOF。 Ballet表示，他首先希望在Verkle 啟動的測試網路上運行時看到EOF，以了解這兩個升級將如何相互影響。 Reth 開發者Dragan Rakita 表示，他並不認為兩者之間存在一定的依賴關係，並補充說：“總體來說，EOF 似乎更適合Verkle 跟踪而不是傳統的EVM。”
· 歷史失效（History Expiry）：以太坊基金會開發者Kolby Moroz Liebl 介紹了歷史失效。根據EIP 4444的定義，歷史失效意味著在一段時間內執行層（EL）客戶端，例如一年後，將停止在點對點層提供歷史區塊頭、區塊體和收據。正好，這些數據將透過一種名為Portal Network 的替代去中心化網路為用戶提供服務。 Liebl 已發布了有關Portal 的常見問題解答文件。
啟動歷史故障所需的工具，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 表示，開發者將專注於進一步確定布拉格升級的範圍。
「原文連結」
資訊來源：0x資訊編譯自網際網路。版權所有，未經許可，不得轉載