以太坊核心開發者最新會議摘要：EIP-7702納入疑慮、坊執行層序列化方法轉換

原文標題：《Ethereum All Core Developers Execution Call #187 Writeup》原文作者：Christine Kim原文編譯：Luccy，BlockBeats

編者按：以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的更改。本次爲 ACDE 第 187 次電話會議，本次會議上，開發者們就 Pectra Devnet 0 的準備工作、EIP 3074 的實施更新以及將執行層的序列化方法從 MPT 轉換爲 SSZ 的緊迫性進行了討論。除了針對 Pectra Devnet 0 的準備工作外，開發者們還探討了新的 EIP 提案、對現有 EIP 的討論和分析，以及對智能合約和交易的影響分析等。其中，對 EIP 7702 的討論引起了與會者的廣泛關注，該提案被視爲取代 EIP 3074 的潛在方案。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2024 年 5 月 9 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #187 會議。ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者討論了 Pectra Devnet 0 的準備工作，EIP 3074 實現的更新，以及將 EL 上的序列化方法從 MPT 轉換爲 SSZ 的緊迫性。

Pectra Devnet-0 更新

以太坊基金會開發者運營工程師 Barnabas Busa 表示，他的團隊正在測試第一個 Pectra 開發者專注的測試網絡的客戶端配置，並將在 5 月 13 日星期一之前努力確保 Pectra Devnet 0 的穩定配置。根據 Pectra Devnet 0 的準備情況追蹤器，Geth、Nethermind 和 EthereumJS 客戶端團隊已完全實現了 Pectra 代碼規範。

在電話會議上，Besu 的開發者 Justine Florentine 表示，所有 Pectra EIP 已經在 Besu 上實現，但他的團隊仍在努力調試代碼。Erigon 的開發者 Andrew Ashikhmin 表示，他的團隊已經開始處理除了 EIP 7002 之外的所有 EIP，即 EL 可觸發式提款。Reth 團隊在 Zoom 聊天中發佈了他們的實現追蹤器的鏈接，顯示他們對 EIP 7002 的工作與 Erigon 團隊一樣仍在等待中。

在 CL 客戶端方面，Grandine 的開發者 Saulius Grigaitis 表示，所有 EIP 都已經實現，但當與 EL 客戶端一起運行時，他的團隊遇到了一些錯誤。來自 Lighthouse 團隊的代表表示，他們即將爲 Pectra Devnet 0 準備好一個完整的實現，並指出引擎 API 中的規範需要更新。Teku 的開發者 Mikhail Kalinin 表示，他正在努力將這些更新添加到引擎 API 規範中。

來自 EF 測試團隊的 Mario Vegas 表示，開發者正在處理爲 EIP 3074、AUTH 和 AUTHCALL 操作碼以及其他幾個 EIP 添加測試用例的工作。

EIP-3074 更新

儘管開發者們同意將 EIP 3074 保留在 Pectra Devnet 0 的規範中，但已經討論了一種替代性 EIP 來取代它，即 EIP 7702。Geth 開發者「Lightclient」總結了關於 EIP 3074 的最新分組會議，在這次會議中，參與者討論了在 Pectra 升級中優先考慮哪些改變與提高用戶控制賬戶可編程性有關。根據 Lightclient 的說法，所有參與者都同意完全本地賬戶抽象化距離在以太坊上實現還需要幾年的時間。然而，對於這是否意味着優先考慮對外部擁有賬戶（EOAs）功能的變更，或者將 EOAs 遷移到智能合約錢包上，存在分歧。在這次 ACDE 電話會議的前一天，即 5 月 8 日，以太坊聯合創始人 Vitalik Buterin 提出了一個新的 EIP，即 EIP 7702，該 EIP 將使以太坊支持一種新的交易類型，以支持 EOAs 在單個交易期間像智能合約錢包一樣運行。Lightclient 表示，來自 EIP 3074 分組會議的參與者普遍對 EIP 7702 持積極態度。然而，他後來補充說，關於 EIP 7702 仍有重要細節需要解決。例如，有關如何撤銷 EIP 7702 交易以及如何縮放這類交易的 gas 成本的詳細信息仍不清楚。

如果 EIP 7702 被接受並納入 Pectra 升級，那麼就會考慮用它替代 EIP 3074，因爲 EIP 7702 實現了與 EIP 3074 類似的結果，但卻不會在以太坊上創建新的操作碼，並且提高了對新 EOA 行爲進行靜態分析的便利性。EF 研究員 Ansgar Dietrichs 在 Zoom 聊天中建議考慮將 EIP 7702 納入 Pectra，並在大約 2 到 4 周後正式決定是否用 7702 替換 EIP 3074。從開發者在電話會議上對 EIP 7702 的討論可以清楚地看出，在將該提案認爲已經準備好實施之前，還需要進一步工作。Nethermind 開發者 Ahmad Mazen Bitar 指出，已經爲 EIP 3074 所做的工作可能不太可能被重用來實施 7702。Beiko 確認，開發者仍應繼續推進 EIP 3074 的實施，用於 Devnet 0，並稍後重新討論 Devnet-1 的規範。

EIP-7685, SSZ, 和 EIP-6110

然後，開發者們討論了 Nimbus 開發者 Etan Kissling 對 EIP 7685 提出的一些擔憂，即通用的執行層請求。在本週電話會議議程下的 GitHub 評論中，Kissling 問道是否需要通用執行層請求的提議設計，以及如果這個機會是否可以更好地用於切換到 SSZ，這是開發者們自合併升級以來一直希望在執行層上更新的序列化格式。電話會議上的大多數執行層客戶端團隊支持將 EIP 7685 保留在 Pectra 中，如果從將 EIP 包含在操作中出現任何阻礙，比如客戶端的樂觀同步，那麼重新審視這個設計。

在轉向 SSZ 的話題上，Kissling 解釋說，通用執行層請求的新設計格式是基於傳統的序列化格式 MPT 和 RLP，因此當開發者過渡到 SSZ 時，它將必須進行更新。他指出，如果開發者繼續創建新的 MPT/RLP 數據結構，推遲轉向 SSZ 只會給開發者帶來更多的工作。然而，並沒有得到執行層客戶端團隊的強烈支持將 EIP 7495，即 SSZ 穩定容器，納入 Pectra 中。一位名叫「Dustin」的開發者在 Zoom 聊天中寫道，推遲 SSZ 過渡的決定「瘋狂」，而 EL 中 SSZ 庫工作不良的問題是「一個嚴重問題」。

關於 EIP 6110，即鏈上的供應驗證器存款，Kissling 提出了有關存款排序的問題。Kalinin 表示同意這個問題是「一個重大關切」，他將與主要的質押池合作進行更深入的調查。

EOF 更新

獨立的以太坊協議開發者 Danno Ferrin 和 EF Solidity 研究負責人 Alex Beregszaszi 分享了有關 EOF 實施工作的更新。背景是，EOF 是一系列改進以太坊虛擬機（EVM）的代碼更改，開發者正在考慮將其納入 Pectra 升級。EOF 的元 EIP 已經最終確定。開發者還簡化了 EOF 中的交易創建過程，並正在進行 EOF 的客戶端實現工作。

EIP-7623 更新

一位在電話會議上以「William Morris」爲屏幕名稱的開發者提出了有關 EIP 7623 中 calldata 存儲的 gas 成本變更的擔憂。他解釋說，這些變更將允許一些用戶通過合併他們的交易以降低費率來進行交易，從而鼓勵爲 gas 折扣創建二級市場，以便二層 rollup（L2s）和其他參與者可以更便宜地在網絡上進行交易。他推薦了一種另一種 EIP，即 EIP 7703，它以固定費率增加 calldata 成本以解決這些問題。

Buterin 表示，儘管 Morris 的擔憂是合理的，但實際上由於 EIP 7623 而創建 calldata 的二級市場的可能性並不高，因爲選擇參與這種市場的用戶數量將極其有限。Buterin 指出，受 EIP 7623 影響的主要參與者是二層開發團隊 Starkware 和銘文創作者。他補充說，雖然二級 calldata 市場的總可尋址市場很小，但通過 calldata 增加限制最大塊大小的上漲空間極高，因爲它可以允許開發者提高 blobgas 限制，從而擴展以太坊支持 L2 的能力。Vitalik 還表示，正如 Morris 建議的那樣，對 calldata 成本進行平坦增加也會對 L2 和其他利益相關者產生比當前 EIP 更嚴厲的影響。Buterin 在電話會議之前的博客文章中分享了更多關於 blob 的 gas 定價的思考。

EIP 7623 的共同作者 Toni Wahrstätter 同意 Buterin 的觀點，他表示他認爲從實用性的角度來看，大多數 L2 並不會創建 calldata 的二級市場。「從實用性的角度來看，這並不是非常可行的，特別是考慮到這樣的市場需要參與者之間的信任和高度的協調。想象一下，作爲 L2，你想把你的數據發佈到 L1，但你不知道哪個地址會發布數據，數據最終會在哪裏。從實用性的角度來看，你需要定製索引等等。所以，我不認爲這是非常可行的，」Wahrstätter 說。

Reth 開發者 Georgios Konstantopoulos 問道，如果 EIP 7623 被納入 Pectra，開發者是否正在研究增加 blobgas 限制的可能性。如果沒有隨着 EIP 7623 的增加而增加 blob gas 限制，Konstantopoulos 表示該 EIP「解決不了太多問題」。EF 研究員 Dankrad Feist 建議將 blob gas 限制提高到以太坊最大塊大小不變的程度，這意味着隨着 calldata 成本的增加而釋放的空間將被 blob（二進制大對象）填滿。EF 研究員 Ansgar Dietrichs 表示，該 EIP 不僅在與 blob gas 限制的增加相結合時有用，而且從安全的角度來看也是有用的，因爲它可能確保網絡不會因包含最大數量的交易和 blob 的區塊而不穩定。

對於 EIP 7623 對智能合約和交易的影響分析的問題，Wahrstätter 表示，他提出的提案對 98% 的用戶不會產生影響。Beiko 還提到，EF 開發者運營工程師 Parithosh Jayanthi 可能正在對提高 blobgas 限制的具體程度進行更深入的分析，考慮到 EIP 7623。

EIP 7609 的新替代方案

在電話會議上，一位以「Charles C」爲屏幕名稱的開發者提出了一個新的 EIP，用於防止智能合約中的重入攻擊。Charles 表示，該提案創建了兩個新的操作碼來保護智能合約，是他之前提交的一項名爲 EIP 7609 的提案的替代方案，EIP 7609 旨在減少 Pectra 中 TLOAD/TSTORE 的基本成本。Charles 表示，他不確定爲什麼 EIP 7609 沒有被考慮納入 Pectra，並且仍在從開發者那裏收集關於以一種成本有效的方式防止重入的反饋。他指出，當前的解決方案，如 OpenZeppelin 的 Reentrancy Guard 和 TLOAD/TSTORE 操作碼，對於去中心化應用程序開發者來說成本太高，無法默認使用。Beiko 建議開發者在以太坊魔術師論壇上就這個新的 EIP 給 Charles 提供反饋。