在 10 月 12 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) Call #172 會議。ACDE 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本周，開發者們主要關注以下議題的進展：

Cancun/Deneb（Dencun）測試

以太坊虛擬機（EVM）對象格式開發。

Dencun 測試

以太坊基金會的 DevOps 工程師 Barnabas Busa 最近分享了關於 9 月 29 日發布的 Devnet #9 的一些更新。

Devnet #9 現在的參與率為 93%，這意味著 93% 的驗證者正在積極參與網路共識。

7% 未運行的驗證器主要由 Geth (EL)/Teku (CL) 驗證器節點組成。

Erigon (EL)/Prysm (CL) 客戶端組合以及 EthereumJS (EL) 客戶端也存在問題。

Flashbots 團隊正在 Devnet #9 上測試 MEV-Boost 中繼和構建器。Busa 鼓勵其他中繼和建築商營運商與他聯繫，以便可以在 Devnet #9 上測試更多 MEV 基礎設施。

Blob 事務尚未通過 MEV-Boost 構建器進行測試。在這種情況下，Blob 被構建者丟棄，但開發人員尚不確定這是否是由於 Blob 實際上無效、不符合最低基本費用要求，或者因為其他原因而被丟棄。

Busa 和他在以太坊基金會的同事 Parithosh Jayanthi 分享了即將推出的 Devnet #10 的最新動態：

本周 Devnet #10 尚未準備就緒，但預計下周將完成準備。

對於 Devnet #10，開發人員計劃測試 EIP 4844 KZG 儀式中的可信設置文件。

Devnet #10 將擁有龐大的驗證器群，包含 33 萬個活躍驗證器。在開發網路剛剛啟動時，驗證者的存款和退出將大量湧入，預計在網路啟動後的一兩天內，驗證者的進入流失限制將從 5 次降為 4 次。雖然主網上實際的最大進入流失限制為 8，但開發人員將採用 4 的限制，以便在 Devnet #10 上測試 EIP 7514。

Busa 強調，目前開發人員仍在解決 Dencun 測試過程中的一些關鍵問題。在這些問題得到妥善解決之前，開發團隊不會啟動 Devnet #10，這很可能是在 Goerli 等公共以太坊測試網上激活升級之前的 Dencun 最終開發網。Jayanthi 在 Zoom 聊天框中概述了開發人員在啟動 Devnet #10 之前需要解決的關鍵問題：

更新 EIP 4844 KZG 儀式的可信設置文件

Blob 事務的更好可視化

MEV 管道的完善

網路穩定性的提升

在電話會議中，Jayanthi 鼓勵客戶團隊增加對 Beacon API 的支持，以提高 Blob 事務的可見性。Beiko 詢問在 Devnet #10 推出後，開發者是否願意升級 Goerli 測試網路。Busa 建議先觀察 Devnet #10 的表現，再決定後續升級測試的步驟。

另外，Jayanthi 確認在 Devnet #10 推出後的一段時間內，開發人員可能會在公共測試網路的測試工作同時進行以太坊主網的影子分叉，以進一步測試 Dencun 升級。然而，Jayanthi 指出，影子分叉的實用性可能受到限制，因為在 Dencun 測試期間發現的大多數錯誤都是在點對點網路層面上。

Geth (EL) 開發人員 Marius van der Wijden 表示，他的同事 Péter Szilágyi 成功地在 Devnet #9 上運行了自己的節點，並發現了一個與 blob 垃圾郵件相關的嚴重問題。

據悉，為了防止節點崩潰，Szilágyi 實現了一個事務處理程序來限制他在開發網路上看到的 blob 數量。Van der Wijden 建議 CL 團隊重新審視 EIP 4844 中的 3/6 最大 blob 目標/限制，並讓 EL 團隊對節點帶寬需求和解決 blob 垃圾郵件的方法進行深入考慮。

為了進一步討論這些問題，Beiko 鼓勵開發者參加 10 月 16 日舉行的 Dencun 互操作性測試電話會議。

EVM 對象格式開發

隨後，開發人員們討論了 EVM 對象格式 (EOF) 的最新進展。EOF 是一組聚焦於 EVM 更改的 EIP，而 EVM 是基於以太坊的虛擬機，用於執行智能合約代碼。EOF 的倡導者之一，Danno Ferrin，對過去幾個月來的 EOF 工作進行了概括和總結。

在演講伊始，Ferrin 強調，他希望 EOF 能成為繼 Cancun/Deneb（稱為 Prague/Electra）之後的升級中的主要代碼更改。Ferrin 表示，目前有四個主要團隊正在致力於 EOF：

Team Ipsilon：由以太坊基金會資助的開發團隊，專注於 EVM 的改進

EL 客戶端團隊：例如 Geth、Besu 和 Nethermind

高級語言編譯器團隊：例如 Solidity 和 Vyper

智能合約開發者：例如 SSTORE2 操作碼的倡導者。

總的來說，各個團隊正為 EOF 的發展做出貢獻，共同推進以太坊網路的技術進步。

EOF 的主要目標是為 EVM 代碼創建新的容器格式。這種容器格式將清晰地區分代碼和數據，這在當前的格式中是無法實現的。它還允許引入新的操作碼，幫助智能合約開發者更有效地設計應用程序，並提供更高的代碼安全保障。EOF 需要為 EVM 代碼創建新的容器格式，同時保持現有格式。

為了方便圍繞 EVM 進行這些更改的實施和測試，Ferrin 詳細介紹了開發者可以減少使用新 EOF EVM 代碼的智能合約與不使用新 EOF EVM 代碼的舊智能合約之間依賴關係的方法。儘管客戶端團隊需要維護兩個版本的 EVM，但 Ferrin 認為新版本比當前的 EVM 更容易更新。他還表示，隨著時間的推移，隨著越來越多的智能合約開發者採用 EOF，當前的 EVM 可能會逐漸被淘汰。

Ferrin 在演講中提到的 EOF 相關 EIP 包括：

EIP 3540：EVM 代碼的新容器格式。

EIP 4200：引入靜態跳轉的三個新 EVM 跳轉指令。

EIP 4750：兩個新操作碼將消除對動態跳轉的需求並將其禁止。

EIP 663：兩條新指令允許訪問 256（而非 16）的堆棧深度。

EIP 7480：四個新指令，用於啟用 EOF 容器數據部分的讀取功能。

EIP 7069：三個新的調用指令，用於簡化 Gas 使用和費用相關的語義。

EIP 5450：在合約執行期間引入 EOF 格式智能合約的驗證。

EIP 3670：在合約創建時引入 EOF 格式智能合約的驗證。

要查看關於 EOF 操作碼更改的完整列表，請參閱 Ferrin 演示文稿中的以下圖表。

關於 EOF 的測試進展，Ferrin 解釋說，由於 EOF 規範尚未最終敲定，這也是目前還沒有客戶端實施升級的原因。然而，他預計 EOF 的測試將非常"獨立"且相對簡單，因為 EOF 的關注點僅在於對 EVM 執行的更改。他表示：「我們不需要擔心網路交互，也無需擔心與不同 CL/EL 組合的配對。我認為我們不需要同等級別的開發網路和測試網路，因為我們將能夠對其進行測試。」Ferrin 補充說：「我們將編寫明確的參考測試……此外，我們擁有的一大優勢是一直在進行的差分 EVM 測試。」

在演講結束時，Ferrin 重申了他希望看到 EOF 作為 Prague/Electra 升級中的主要代碼更改。他還表示，在 Dencun 升級完成後的三到六個月內，在主網上進行 EOF 一系列代碼更改的測試和執行是可行的。EOF 的最新規範可以在此處。關於這些規範的未解決問題已由 Ipsilon 團隊在此處整理。EOF 規範的某些部分尚待完善。我們鼓勵參加電話會議的開發人員在以太坊研究與開發 Discord 的「#EVM」頻道中分享他們對 EOF 最新發展和規範的看法。

EVM 對象格式爭論

Ferrin 的演講引起了開發人員的廣泛討論。在電話會議上，開發人員對 EOF 的主要擔憂有以下幾點：

時間安排：包括 Tim Beiko 在內的幾位開發人員對 Dencun 升級後 EOF 實施的三至六個月的時間表感到猶豫不決。

緊迫性：開發人員正在考慮將 Verkle 納入布拉格/伊萊克特拉的另一個主要代碼更改。8 月初，以太坊基金會開發者 Guillaume Ballet 分享了 Verkle 的最新進展。在本周的電話會議上，Ballet 強調，相較於 EOF，Verkle 是以太坊更緊迫的升級，因此應該優先考慮。Ballet 還表示，如果能降低 EOF 的複雜性並減少代碼更改的數量，使其實現不會影響 Verkle 的時間表，那麼他將支持升級。

好處：Van der Wijden 和 Nethermind (EL) 開發人員 Lukasz Rozmej 等人質疑 EOF 的直接好處與升級複雜性之間的權衡。對於缺乏對 EVM 如此大的改變的強烈需求的擔憂，Ferrin 表示 EVM 是由以太坊最初的開發團隊「在周末」編寫的，可以進行大量改進以確保 EVM 保持與競爭對手的競爭力，如新的替代 Layer-1 區塊鏈 Sui。「這不是安全風險，」Ferrin 說。「這更像是一項存在主義的交易。」

增加複雜性和風險：Van der Wijden 強調了 EOF 會增加協議複雜性和風險的方式。客戶團隊的負擔將會增加，他們必須維護 EVM 的兩個版本，並確保在未來的硬分叉期間考慮到它們之間的相互依賴性。Wijden 認為，Layer-2 團隊不應嘗試將維護 EVM 和 EOF 的工作並行「推」給客戶端團隊，而應致力於在自己的協議上實施對 EVM 的改進。

向後兼容性：EOF 的另一個主要問題是，它可能會給遺留智能合約帶來向後兼容性問題。EOF 的設計方式將確保繼續支持不使用 EOF 容器的遺留智能合約。然而，Ferrin 和以太坊基金會研究員 Ansgar Dietrichs 等開發人員建議，隨著時間的推移，可能會淘汰舊的智能合約功能，並專門針對 EOF 進行升級。

EVM 治理：Dietrichs 還對 EOF 對 EVM 治理的影響表示擔憂。以太坊正在不斷發展，以支持在稱為 Layer-2 的替代網路上執行智能合約。假設未來大多數用戶活動和智能合約執行都發生在鏈外，並且以太坊主要用作數據可用性層，那麼 EVM 的更改應該對第 2 層協議最重要，而不是以太坊主網。Dietrichs 建議開發人員仔細考慮並討論如何在不斷擴大的第 2 層生態系統中決定對 EVM 進行更改。

Ferrin 等人早在 2021 年就開始致力於 EOF 的研究。今年早些時候，由於 EOF 的多階段路線圖，EOF 被上海硬分叉拒絕。為了解決這個問題，EOF 支持者通過為升級創建更新的設計，該設計將在一次大型升級中引入所有與 EOF 相關的更改。然而，此次升級的複雜性是本周電話會議上提出的對 EOF 的主要擔憂之一。van der Wijden 強調，這次開發人員應該仔細考慮 EOF 是否應該在以太坊上實現，而不是繼續推遲有關 EOF 的決定。

「我知道 Ipsilon 團隊和 Danno 花了很多時間來解決這個問題，說這麼久之後我們可能不會交付它是相當嚴厲的，但我認為更糟糕的是說，『讓我們看看』，然後我們又推遲了兩年，然後我們說，『哦，我們畢竟不會發貨了。』因此，我認為我們應該在 Devconnect 上做出決定，」van der Wijden 說道，並補充道，「如果這是我們想要做的事情，那麼我們就會這麼做，除非遇到類似的技術挑戰，如果我們說這是我們不做的事情，那麼我們就會這樣做。我認為這不會發生，對於一直以來努力工作的團隊來說，每個人都做出明確的決定是公平的。」

Rozmej 補充說，除了 EOF 和 Verkle 之外，開發人員也許應該重新考慮 EIP 4444 等代碼更改，以解決歷史鏈數據增長日益嚴重的問題。據 Rozmej 稱，歷史鏈數據增長速度為每月 20GB。Beiko 同意開發人員應該在 Devconnect 上繼續討論 EOF、Verkle 和 Prague/Electra。Beiko 還強調，將於 10 月 18 日星期三專門召集類似 EVM 的第 2 層協議，以鼓勵這些團隊之間的協作。同一天還將召開 EOF 實施者電話會議。最後，Beiko 提到了由 L2Beat 在 Devconnect 組織的專門 Layer2 日活動。

原文連結