原文標題：《Ethereum All Core Developers Execution Call #172 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

< br>

在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 儀式的可信任設定檔< /p>

Blob 事務的更好視覺化

MEV 管道的完善

網路穩定性的提升

< p>在電話會議中，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 的改進< /p>

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 操作碼更改摘要。資料來源：丹諾費林

關於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 說道，並補充道，「如果這是我們想要做的事情，那麼我們就會這麼做，除非遇到類似的技術挑戰，如果我們說這是我們不做的事情，那麼我們就會這樣做。我認為這不會發生，對於一直以來努力工作的團隊來說，每個人都做出明確的決定是公平的。」

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

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia