撰文：Christine Kim
編譯：Luccy，BlockBeats
除了針對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 ，但你不知道哪個地址會發布數據，數據最終會在哪裡。
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 提供回饋。