以太坊核心開發者最新會議摘要：在 Pectra 升級中加入 EOF 和 EIP-7702
本次會議開發者們就 Pectra 升級中的一些重要議題展開了討論，包括包含 EOF 和 EIP 7702 在內的改動、改進 Pectra 範圍、以及準備 Verkle 過渡等方面。原文標題：《Ethereum All Core Developers Execution Call #189 Writeup》
作者：Christine Kim
編譯：Luccy，BlockBeats
編者按：
以太坊所有核心開發者執行電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的更改。本次為 ACDE 第 189 次電話會議，本次會議上，開發者們就 Pectra 升級中的一些重要議題展開了討論，包括包含 EOF 和 EIP 7702 在內的改動、改進 Pectra 範圍、以及準備 Verkle 過渡等方面。
會議還討論了如何將 EOF 和其他 Pectra EIPs 打包，以及如何測試這些代碼變更。此外，還介紹了一些提議，旨在改進以太坊網絡升級流程，包括對 ACD 電話會議議題討論頻率的調整，以及新的 EIP 標籤提案。對於 EIP 4444 和 Portal Network 的集成進展也有所提及。
Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
2024 年 6 月 6 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #189 會議。ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者們同意將 EOF 和 EIP 7702 包含在 Pectra 升級中。為了避免由於這些代碼變更而導致的多客戶端測試升級延遲，開發者們同意在後期開發網絡上激活 EOF，並可能在不同於其他 EIP 的激活周期內激活，就像開發者計劃測試 PeerDAS一樣。他們還討論了在 Osaka 升級中如何停用 EIP 158 以準備 Verkle，並通過與 Portal Network 的集成來實施 EIP 4444 的下一步。最後，Beiko 和 EF 開發者運營（DevOps）團隊分享了治理流程和規劃以太坊升級的溝通渠道的最新更新。
Pectra 的範圍
在本週的 ACD 會議之前，各個 EL 客戶端團隊和 EF DevOps 團隊分享了他們對 Pectra 範圍的看法。
根據會前分享的觀點，顯然大多數客戶端團隊都支持在 Pectra 中包含 EOF 。唯一強烈反對 EOF 的客戶端團隊是 Geth 。 Geth 開發者 Guillaume Ballet 說：「我擔心我們等得越久， Verkle 轉換所需的時間就會越長。 EOF 真的那麼緊急嗎？我不這麼認為。我讀了幾篇關於在 Prague 發布 EOF 的論點。讀得越多，我越意識到，沒有什麼真正能證明 EOF 是必要的。」對此，幾位開發者提出了反對意見。
一位名叫「Kamil Sliwak」的開發者表示，從與以太坊智能合約編程語言 Solidity 的編譯器交互的用戶角度來看，EOF 將是「一項巨大的改進」。Reth 開發者 Dragan Rakita 補充說，認為 EOF 會顯著延遲 Verkle 轉換是不誠實的。「我們談論的是 10% 到 20% 的轉換時間延長。EOF 不會增加狀態，額外的三個月來發布額外的部分分叉，不會顯著延遲 Verkle」Rakita 說。關於 EOF 是什麼以及它將如何改進以太坊虛擬機（EVM）的更多信息，請收聽《無限叢林》播客的這一集。
Beiko 詢問開發者是否更願意將 EOF 與其他 Pectra 的 EIP 捆綁在一起，還是將 Pectra 的 EIP 分成兩個硬分叉。 Erigon 開發者 Andrew Ashikhmin 表示，他認為開發者應該嘗試將所有 Pectra 的 EIP 一起發布，或者推遲 EOF 直到 Verkle 轉換之後。「我最不希望的是，在 Pectra 和 Verkle 之間進行一次分叉以發布 EOF 。因為我同意 Guillaume 的觀點，即狀態正在增長，我認為 Verkle 比 EOF 更重要。所以在我看來，這是最糟糕的結果，」 Ashikhmin 說。 Beiko 建議將所有 Pectra 的 EIP ，包括 EOF ，在一個客戶端版本中發布。然而，為了測試的目的，他表示開發者應該考慮使用開發網絡來分階段實施這些代碼變更。「使用開發網絡作為我們在多客戶端測試方面優先考慮的方式，然後如果我們看到 EOF 會長時間延遲事情，我們可以決定將其分開，」 Beiko 說。
在這些關於如何將 EOF 納入 Pectra 的討論中， Geth 開發者在 Zoom 聊天和整個會議中繼續表達了對是否應該將 EOF 包含在升級中的質疑。為了應對 Geth 團隊對 EOF 的持續爭論， Reth 開發者 George Konstantinopoulos 說：「讓我們直接做吧。對話的走向有點令人困惑。我們不介意將 Verkle 轉換延長幾天。數據顯示狀態正在下降，所以這是一個令人困惑的論點，而且你有一堆應用程序告訴你這是一個好功能。既然大多數人都表示支持，我們為什麼還要考慮不做呢，這很令人困惑。」
Beiko 同意這一觀點，並重申 EOF 應該包含在 Pectra 中，但要在開發網絡上分階段測試，這意味著客戶端團隊應在 Devnet 1 上測試已經在 Devnet 0 上實現的 EIP 。然後，在未來的開發網絡上，再添加 EOF 進行測試。這一策略將確保客戶端團隊在相同的時間線專注於發布一部分 Pectra 的 EIP ，並能夠在多客戶端開發網絡上繼續取得進展。以太坊基金會（ EF ） DevOps 工程師 Mario Vega 表示，他預計在兩個月內準備好 EOF 的執行層（ EL ）規範測試。 EF DevOps 工程師 Parithosh Jayanthi 表示， EOF 可以與 Pectra 中的其他執行層（ EL ） EIP 分開測試。然而，他擔心 Pectra 中的共識層（ CL ） EIP 之間的相互依賴性以及測試這些代碼變更的複雜性。
Vyper 編譯器開發者 Charles Cooper 表示，在他看來， EOF 並不像他提議的代碼變更那樣緊急，這些更改旨在使防止重入攻擊的保護變得廉價和普遍。 Beiko 提醒 Cooper ，雖然對 EOF 的廣泛共識是明確的，但不清楚客戶端團隊是否有足夠的精力添加更多的代碼變更，例如與重入攻擊相關的更改。「我認為很清楚的是，如果我們推進 EOF ，就幾乎沒有精力去做其他事情了。這已經將是迄今為止最大的分叉，」 Beiko 說。
除了包含 EOF，開發者們還同意將 EIP 7702 作為 EIP 3074 的替代方案。開發者們仍在單獨的小組會議中討論 EIP 7702 的規範。Beiko 建議對 EIP 7702 採用與 EOF 類似的方法。「我會將它包含在分叉中，但如果我們對規範不太滿意，就不將它作為 Devnet 1 或 2 的一部分，然後花下個月的時間真正理清規範，這樣我們就有了一個比現在提議的更好的撤銷機制。稍後在過程中添加一個不算太大的 EIP，」Beiko 說。Geth 開發者「Lightclient」表示，如果客戶端團隊準備好了，他們應該儘快實施 EIP 7702。沒有任何人反對在下一個緊急的 Pectra 開發網絡 Devnet 1 中包含 EIP 7702。
Pectra 規範
隨後，Teku 開發者 Mikhail Kalinin 分享了一些現有 Pectra EIP 規範的更新。第一個是建議通過側車機制處理觸發共識層（CL）請求，而不是直接在執行層（EL）區塊中處理。Prysm 開發者「Potuz」指出，這一策略會破壞未來代碼變更所需的邏輯，即明確的提議者構建者分離（ePBS）。「信標塊不應該依賴於有效負載已經存在。所以，無論是提款還是存款，你都不希望信標塊依賴於有效負載中的內容，因為這會破壞 ePBS 的流程，」Potuz 說。由於這個問題，Kalinin 同意撤回他的建議並關閉 GitHub 上的拉取請求。
Kalinin 分享了幾項關於 Pectra 的 EL 和引擎 API 規範的其他變更，其中之一是啟用 EIP 7251 下的 EL 觸發合併，增加 MAXEFFECTIVEBalance。Beiko 建議開發者在下一次 ACD 電話會議之前審查這些變更，以便它們可以在 Devnet 1 中進行測試前完成和準備好。
Verkle 準備
根據他為 Verkle 過渡所做的工作， Ballet 表示， EIP 158 將導致與已棄用的操作碼 SELFDESTRUCT 類似的問題。為了在過渡後避免網絡上的複雜情況， Ballet 建議在 Pectra 升級中停用 EIP 158。然而，他指出，如果在 Pectra 中對 EIP 7702 的實施進行了微調，那麼停用 EIP 158 可能會被推遲，並與 Verkle 過渡同時發生。 Beiko 建議 Guillaume 開始起草他的停用 EIP 158 的提案。
歷史到期
除了 Pectra 和 Verkle，以太坊協議開發者還致力於 EIP 4444，歷史到期。正如EIP 4444 計劃和摘要文件所述，進行這種代碼變更的原因是「區塊歷史佔據了節點大量的空間，而一旦該區塊已經完成，它只需要用於有限的非共識關鍵用例。」文件繼續說明，「區塊歷史將不再由全節點永久存儲。一段時間後，它將從節點中刪除，並且需要它的實體將需要從其他地方查詢。」Portal Network 是一個替代的、分散的網絡，用於節點查詢以太坊歷史數據。
Merriam 重申他的團隊願意為 EL 客戶團隊提供與 Portal Network 的集成支持。他說，如果沒有任何支持，集成大約需要 6 個月的時間來開發完畢。然而，通過指導和密切合作，他樂觀地認為在接下來的兩個月內可以在 EIP 4444 上取得有意義的進展。 Jayanthi 詢問是否對 Portal Network 規範進行了安全審計。 Merriam 表示沒有。以太坊基金會研究員 Ansgar Dietrichs 問客戶團隊是否可以自行決定如何與網絡進行接口，包括將集成與現有客戶端捆綁、構建新客戶端，或者乾脆不進行任何集成。 Merriam 確認這一決定由客戶團隊自行決定。
Merriam 詢問電話會議中的 EL 客戶團隊有關他們在 EIP 4444 上的進展和意圖。 Nethermind 開發者Ł ukasz Rozmej 表示：「總體而言，這是一個優先事項。我們甚至昨天與 Portal 團隊開了會議。問題是有太多的優先事項。有時候很難正確地平衡所有事情。因此，與例如硬分叉相比，它是不那麼緊急的優先事項，但 Nethermind 將會著手處理，並且我們將予以優先考慮。」 Besu 開發者 Matt Nelson 表示他的看法是一樣的。 Geth 開發者 Guillaume Ballet 表示他的團隊還沒有討論過 Portal Network 的集成。
ACD 流程改進
ACD 流程改進 接著， Beiko 分享了幾項改進以太坊網絡升級流程的建議。他首先建議減少 ACD 電話會議上討論客戶團隊尚未詳細審查的話題的頻率。 Beiko 建議，在允許開發者進行專業討論之前，先在 ACD 電話會議上標記這些話題進行審查，然後根據需要在隨後的 ACD 電話會議上更詳細地討論這些話題。
Beiko 提出的第二個建議涉及通常附加在考慮納入硬分叉的以太坊改進提案（ EIP ）上的「考慮納入」（ CFI ）狀態。這個狀態在歷史上並沒有有效地指示哪些 EIP 更有可能被納入硬分叉中。 Beiko 建議創建另一個標籤「擬納入」（ PFI ），以便開發者能夠更好地區分哪些 EIP 更有可能被納入硬分叉，而哪些不會。
以太坊基金會研究員 Ansgar Dietrichs 在 Zoom 聊天中寫道，為 EIP 創建新標籤是「錯誤的方向」，只會導致 CFI 標籤變得「完全無用」。 Beiko 表示，開發者可以繼續在 GitHub 和 EthMagicians 上討論改進網絡升級流程的問題。
此外，以太坊基金會的 DevOps 工程師 Mario Vega 表示，他希望為與測試相關的更新創建一個新的 Discord 子頻道。維加表示，目前在以太坊研發 Discord 中，測試發布信息分散在多個頻道中。然而，他希望這個新的論壇能夠成為客戶團隊從以太坊基金會 DevOps 團隊獲取測試更新的「一站式」參考。他要求客戶團隊就此提出反饋意見。
最後， Beiko 提醒開發者，接下來幾天安排了兩次小組會議，一次是關於 ePBS 的，將於 6 月 7 日舉行，另一次是關於 PeerDAS 的，將於 6 月 11 日舉行。
