原文標題：《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 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
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，這佔用了團隊的資源和時間。 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 C ar 機制（例如用於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 可以進行實驗並變得更加瘋狂。我認為在實踐中我們看到的是，他們中的大多數人決定不這樣做，甚至或至少可能開始這樣做，然後隨著時間的推移，大多數人停止了。發展的最佳方式，我們至少欠Layer 2 明確的指導和溝通，就像這裡的最佳前進道路一樣。
