以太坊核心開發者最新會議摘要：準備實施 EIP 3074、Rollup 路線圖

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

原文作者：Christine Kim

原文編譯：Frost，BlockBeats

編者按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的更改。本次為 ACDE 第 186 次電話會議，本次會議上，開發人員討論了 Pectra Devnet 0 和 EIP 3074 實施的準備工作。他們詳細介紹了各客戶團隊在準備 Pectra Devnet 0 方面的進展，並討論了關於 EIP 3074 規範的修改建議以及相關的測試進展。

另外，本文還提及了其他重要議題，如對 Pectra 升級中可能包含的其他代碼更改的討論，以及對以太坊 EIP 流程的更改如何受到 L2/RIP 流程的影響的討論。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeats 將原文編譯如下：

2024 年 4 月 25 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution ( ACDE ) call #186 會議。 ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（ EL ）的更改。本週，開發人員討論了 Pectra Devnet 0 和 EIP 3074 實施的準備工作。他們還討論了應考慮將哪些其他 EIP 納入 Pectra 升級，以及考慮到以太坊「以 Rollup 為中心的路線圖」對治理變革的廣泛思考。

Pectra Devnet 0 最新進展

Beiko 在電話會議上要求客戶團隊分享 Pectra Devnet 0 的最新進展。 Nethermind 團隊的 Marek Moraczyński 表示， Nethermind 已經實現了所有 Pectra EIP ，正在對其進行測試工作。 Besu 團隊的 Justin Florentine 表示， Besu 正在實施 Pectra EIP ，並與他們一起準備 Devnet 0 的推出。 Erigon 團隊的 Andrew Ashikhmin 說，「我不確定 Erigon 是否準備好全套套件 Devnet 0 的 EIP 的數量，一部分原因是這些 EIP 的規範仍在不斷變化，而且 Erigon 客戶端正在過渡到新的主要版本 Erigon 3，這佔用了團隊的資源和時間。 Erigon 3 和 Pectra EIP 將最終確定並一起內置到 Erigon 客戶端中。」。 Geth 團隊的「 Lightclient 」表示， Geth 距離為 Devnet 0 做好準備還有「幾天的時間」。 Ethereum JS 團隊的 Gajinder Singh 表示， Ethereum JS 也將為 Devnet 0「做好準備」。

EIP -7685

Lightclient 合併了 EIP 7685，它創建了一個通用框架，用於將 EL 觸發的請求存儲到共識層 ( CL ) 及其對 EIP 6110 和 7002 的影響。 Beiko 表示，開發人員應該在其 Devnet 0 版本中加入此 EIP ，並不斷完善 Pectra EIP 。

在測試方面， EF 測試團隊的 Mario Vega 表示， EIP 6110 和 2537 的測試已經完成， EIP 7002 和 EIP 2935 的測試將在本週或下週完成。 EIP 3074 的測試尚未準備好用於 Devnet 0。 EF 研究員 Antonio Sanso 表示， EIP 2537 規範已更新，並且 GitHub 存儲庫中添加了新的測試向量，他建議大家都去 GitHub 上看看。 EF 研究員 Hsiao Wei Wang 指出 CL 規範測試向量中存在錯誤，於是錯誤很快就被修正，並且發布了新版本。

EIP -3074 的更新

本週的 ACDE 對 EIP 3074 規範的調用提出了幾項更改。 Ahmad Mazen Bitar 建議更改 EIP 3074 的行為，以允許在 AUTH CALL 之前進行 DELEGATECALL ，這樣可以擴大 EIP 的用例。區塊鏈錢包操作系統 ZeroDev 的創始人兼首席執行官 Derek Jiang 建議創建一個「 noncemanager 」，以便在需要時促進全球撤銷 AUTH 消息和其他更改。一些參加電話會議的開發人員認為應該推遲對 EIP 3074 的更改，因為這將大大增加其實現的難度。

Beiko 建議開發人員在單獨的分組會議上討論對 EIP 3074 的擬議更改。他指出，為了有足夠的時間在 Pectra 中實施 EIP 3074，開發人員應該嘗試「在未來一兩個月內」確定其最終規範。 Lightclient 同意組織 EIP 3074 分組會議。對於 Devnet 0， Beiko 確認客戶團隊應該在不進行任何更改的情況下實施 EIP 3074，即使開發人員可能決定未來的 devnet 以不同的方式實施 EIP 或從升級中將其全部刪除。

除了 EIP 3074 的實現細節之外，開發者們還認真討論了 EIP 是否有足夠的社區支持。一位顯示名為「 Siri 」的開發人員在電話會議中表示擔心，「 EIP 3074 原則上很糟糕，會減慢我們實現完全帳戶抽象的速度」。 Beiko 回應稱，根據以太坊魔術師和 ACD 通話討論，客戶團隊似乎支持 EIP 3074，而不是其他與帳戶抽象 ( AA ) 相關的提案。 Beiko 表示：「這似乎是短期內最有共識的提案，我們實際上可以在下一個分叉中改善 EOA 的狀態。」對此 Siri 認為客戶團隊不應該孤立地做出這個決定。「我們應該聽取其他利益相關者的意見，」 Siri 說道，並補充，「我們不想轉向製造有爭議的硬分叉領域。……我認為最好了解一下其他利益相關者的看法以及他們如何看待這個提案。」

Beiko 和 Siri 還討論了在 ACD 通話之外應如何為 EIP 建立更廣泛的共識。 Chiang 建議首先召開 EIP 3074 分組會議，深入討論 EIP 的技術規範，然後決定是否應該保留在 Pectra 升級中。 EF 研究員 Ansgar Dietrichs 表示「我們應該明白，除非我們取得足夠的進展，否則 EIP 3074 將會被撤出。」

以太坊聯合創始人 Vitalik Buterin 補充說，「未來幾年用戶的帳戶功能即將發生變化，特別是外部擁有帳戶 ( EOA )。激活帳戶抽象相關的 EIP ，例如 EIP 3074 等。」

其他 Pectra 提案

開發人員繼續討論應考慮將哪些其他代碼更改包含在 Pectra 升級中。 Geth 開發者 Marius van der Wijden 表示，這應該取決於像 EOF 這樣複雜度較高的 EIP 是否會進入 Pectra 。「如果我們要包括 EOF ，那麼會導致分叉飽和。如果我們不包括 EOF ，也許我們可以包括更多內容，」 van der Wijden 說道。

Siri 對未經安全審核就將 EIP 3074 納入 Pectra 表示擔憂。 Beiko 建議擱置此討論，直到 EIP 3074 的規範最終確定。

Bitar 表示，他希望看到 Pectra 中添加 EIP 7212。 EIP 7212 將創建一個新的預編譯，在 secp256 r1 橢圓曲線中執行簽名驗證。這可以與支持用戶生物特徵識別的硬件設備一起使用。 Bitar 表示，支持生物識別來簽署以太坊交易將是用戶體驗的重大改進。阿希赫明表示，他也贊成這一提議。 Dietrichs 指出，這是唯一一個通過「 Rollup 改進提案」（ RIP ）流程被 Layer -2 Rollups 批准實施的方案。

其他開發者包括 Dietrichs 、 van der Wijden 和 Moraczyński 都表達了對 EIP 7623 的支持，這將增加通話數據的成本，從而限制最大區塊大小。 Beiko 建議將 EIP 7623 和 EIP 7212 標記為「考慮納入」或 CFI 進入 Pectra ，並在 Devnet 0 啟動後重新審視客戶團隊的帶寬以支持這兩個改進提案。

關於與將 EL 的序列化方法更新為 SSZ 相關的 EIP 捆綁包， van der Wijden 表示擔心這些在 Pectra 中運輸太困難。他在 Geth 團隊 Guillaume Ballet 的同事也同意這一評估。 Buterin 插話道，「至少更新交易收據的序列化方法將具有超越以太坊本身的「重大價值」，因為它消除了以太坊上構建的第 2 層 Rollup 的額外安全審計開銷。」。 SSZ 相關 EIP 的主要支持者、來自 Nimbus 團隊的 Etan Kissling 沒有出席電話會議，但他在 GitHub 上寫了一份詳細的解釋，講述了為什麼這些代碼更改很重要，並且應該考慮將其包含在 Pectra 中。

開發人員還重新討論了 EOF 。獨立以太坊協議開發人員 Danno Ferrin 表示， EOF 團隊正在針對代碼更改進行 EL 規範測試。 EVMOne 和 Reth 是兩個 EL 客戶端團隊，據報導已經完成了 EOF 實現。 Ferrin 表示， Geth 團隊在實施方面取得了「良好進展」。 Ferrin 補充說， Ballet 正在與 Solidity 團隊的「 Daniel 」合作，以解決對 EOF 和 Verkle 兼容性的擔憂。

Ballet 指出，根據他與 Daniel 和 Dietrichs 等其他開發人員的對話，很難在不違背其目的的情況下縮小 EOF 的範圍，並為開發人員今後實現另一組類似 EOF 的代碼更改創造更多工作。

一位螢幕名為「 Charles C 」的開發人員建議尋找一種通過 Side Car 機制（例如用於 Blob 事務的機制）輕鬆迭代地實現 EOF 的方法，而不是在小型或大型 EOF 升級之間進行選擇。 Dietrichs 在聊天中詢問，如果降低 Pectra 的 EOF 複雜性，客戶團隊是否會對它有更大的興趣。 Ipsilon 團隊指出，導致 EOF 中最高複雜性的代碼更改（例如「 TX create 」）已經得到解決，刪除「 EOF create 」等功能的特定請求不會大大降低整體 EOF 複雜性。作為背景， Ipsilon 是 EF 資助的 EVM 研發團隊的名稱。 Beiko 建議開發人員在反復出現的 EOF 分組討論中繼續討論 EOF 實現。

ACD / EIP 和 L2 / RIP

作為 ACDE #186 討論的最後一個主題，開發人員討論了考慮新的 RIP 流程對以太坊 EIP 流程的更改。 Dietrichs 指出，自開發人員啟動 Rollup 協調、 RollCall 和 RIP 流程的會議系列以來，已經過去六個月了。關於這些流程將如何以及應該如何影響以太坊 EIP 流程，目前還存在一些懸而未決的問題。 Dietrichs 表示， L2 中正在進行的一個研究問題是，對於 Rollup 而言，與以太坊虛擬機（ EVM ）的長期等效是否是可取的。他還補充說，一個懸而未決的問題是， L2 上實施的更改最終會在多大程度上影響以太坊第 1 層的協議決策。

Geth 開發人員 Péter Szilágyi 表示， L2 上提供的某些功能可能不適合在 L1 上提供，並且在某些情況下，即使遵循 L2 上提供的功能， L2 之間也可能有所不同，這可能會給以太坊協議開發人員帶來困惑。 EF 研究員 Carl Beekhuizen 指出， RollCalls 和 RIP 流程不需要以太坊協議開發人員在 L2 上發布任何功能，而是改善 Rollups 和以太坊開發人員之間的通信，以便避免像 Szilágyi 描述的那樣令人困惑的情況。 Van der Wijden 對協議開發人員花時間支持在 L2 上實施的更改表示擔憂，而這些更改最終會變得過時或不必要，因為 L2 本身會關閉或停止使用。

對於這些擔憂， Dietrichs 表示：「我認為人們一直認為 Layer 2 可以進行實驗並變得更加瘋狂。我認為在實踐中我們看到的是，他們中的大多數人決定不這樣做，甚至或至少可能開始這樣做，然後隨著時間的推移，大多數人停止了。所以現在他們實際上主要遵循第一層規範。我認為至少考慮到以 Rollup 為中心的路線圖，或者我們都認為這是生態系統發展的最佳方式，我們至少欠 Layer 2 明確的指導和溝通，就像這裡的最佳前進道路一樣。」