原文標題：《Ethereum All Core Developers Execution Call #186 Writeup》
原文作者：Christine Kim
編者按：
以太坊所有核心開發者共識電話（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 做好準備還有「幾天的時間」。 EthereumJS 團隊的 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 的行為，以允許在 AUTHCALL 之前進行 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 說道，並補充，「我們不想轉向製造有爭議的硬分叉領域。…我認為最好了解其他利益相關者的看法以及他們如何看待這個提案。 Chiang 建議先召開 EIP 3074 分組會議，深入討論 EIP 的技術規範，然後決定是否應該保留在 Pectra 升級中。 EF 研究員 Ansgar Dietrichs 表示「我們應該明白，除非我們有足夠的進展，否則 EIP 3074 將會被撤出。」
以太坊聯合創始人Vitalik Buterin 補充說，「未來幾年用戶的帳戶功能即將發生變化，特別是外部擁有帳戶(EOA)。激活帳戶抽象相關的EIP ，例如EIP 3074 等。將哪些其他程式碼變更包含在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 將建立一個新的預編譯，在 secp256r1 橢圓曲線中執行簽名驗證。這可以與支援用戶生物特徵識別的硬體設備一起使用。 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 明確的指導和溝通，就像這裡的最佳前進道路一樣。
區塊財經BOTD – 廣播組
追蹤BOTD Instagram，獲取最新區塊鏈消息
▸https://www.instagram.com/botd_news/
免責聲明：本文內容僅供參考，投資人應獨立判斷，審慎投資，並自負風險，本文不提供或嘗試遊說觀眾做交易或投資之依據。
