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 提供反饋。

原文連結