2024 年 3 月 14 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #183 會議。ACDE 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本周，開發者分享了對 Dencun 升級的回顧，該升級於 3 月 13 日星期三在主網上線。主要 Rollups，包括 Base、Optimism、zkSync 和 StarkNet，已經開始利用 Dencun 升級的 Blob 來降低用戶的交易費用。「這是一個龐大的、非常龐大的分叉，我們已經努力工作了兩年多，所以看到它順利上線真的很酷，」Beiko 評論道。開發者還討論了 Dencun 之後的下一個主要以太坊升級 Pectra 中可能包含的潛在代碼更改。

Dencun 回顧

以太坊開發者分享了 Dencun 升級對網路的早期影響的評論。由於高比例的驗證節點操作者升級了他們的軟體以支持硬分叉，網路沒有發生任何有意義的中斷或區塊處理延遲。事實上，Prysm 開發者 Terence Tsao 指出，網路似乎比他最初預期的更快地處理新的交易和 blob。儘管他預期 blob 交易會由於其大小偏大而比區塊到達更晚，但由於「私有源」中繼為了從 blob 和區塊獲得額外的 MEV 獎勵而部署的優化，實際上 blob，儘管它們的重量更大，似乎比區塊更早到達。有關 Blob 交易的更多資訊，請閱讀這份Galaxy Research 報告。有關 MEV 的更多資訊，請閱讀這份Galaxy Research 報告。有關 MEV 中繼的更多資訊，請閱讀這份Galaxy Research 報告。

Tsao 對以太坊 Dencun 升級的早期影響的第二個觀察是，他的節點每天經歷的一次區塊重組數量比升級前大約多了三到四次。Tsao 表示，在周三之前，他的節點每天大約會經歷 15 次重組，升級後的節點每天大約會看到 17 到 18 次重組。以太坊節點是連接到並驗證以太坊區塊鏈的計算機。Tsao 在電話會議上詢問其他開發人員，他們的節點是否也遇到了類似數量的重組增加。電話會議中並未立即得到對這個問題的回應。

隨著 Dencun 升級的完成，開發人員會將九個包含在升級中的以太坊改進提案（EIP）的狀態更新為「Final」。Beiko 表示，他將在接下來的一周開始提醒相關 EIP 作者進行此更新。此外，他指出，開發人員之前已經向以太坊社區宣布，Goerli 測試網路將在 Dencun 升級主網上線後不久被廢棄。雖然開發人員計劃在 2024 年 4 月 15 日之前支持該測試網路，但由於大量用戶和節點操作者在截止日期之前提前退出 Goerli，網路已經開始出現延遲最終性和干擾的情況。

Pectra EIP

隨後，開發人員討論了一些可能納入 Pectra 升級的 EIP。首先討論的 EIP 已經獲得了納入 Pectra 的批准，即 EIP 2537。EIP 2537 的一位作者，以太坊基金會研究員 Alex Stokes，提出了與該提案實施相關的三個未決問題。該提案引入了以太坊的新加密原語，智能合約開發人員可以利用這些原語來構建更安全、更高性能的去中心化應用。從技術上講，該 EIP 以 9 個新的預編譯形式引入了這些原語，這些操作直接內置到以太坊的執行環境中，而不是通過智能合約實現。

Stokes 關於 EIP 2537 的一個問題是是否應該創建額外的預編譯，以允許「點解壓縮」（point decompression），這可能是 Layer-2 rollups 和其他「數據受限環境」利用該提案引入的新加密原語的更好方式。Stokes 還指出，需要對該提案進行燃氣成本的更改，以準確定價這些新操作。在就 EIP 不同設計選擇之間的權衡進行了一些討論後，Stokes 表示他將在下一次 Rollcall 上從 Rollup 團隊獲得更多反饋，Rollcall 是主要以太坊 Rollup 之間的定期協調電話會議。下一次 Rollcall 定於世界協調時間 4 月 10 日星期三 14:00 舉行。

EIP 3074: AUTH 和 AUTHCALL 操作碼

開發者討論的與 Pectra 升級相關的第二個 EIP 是 EIP 3074。這個代碼更改是三個主要 EIP 之一，都有望納入 Pectra，它們都致力於為用戶控制的帳戶引入更大的可編程性和靈活性，也稱為外部擁有帳戶（EOA）。在支持在 Pectra 中採用 EIP 3074 時，Metamask 錢包開發者 Dan Finlay 表示：「EOA 已經被證明為對於許多人來說提供的授權系統不夠靈活，每天都有數百萬美元的資金損失。我們相信 3074 是協議層為用戶安全帶來一些機會的機會，然後可以在錢包層實施。3074 允許 EOA 持有者採用智能合約來授權其交易，這最終可能意味著完全授權的單一私鑰完全下線，並確保有更多的人使用我們繼續完善的安全性和可用性模式。」

在進一步討論 EIP 3074 的設計時，主要是該 EIP 下用戶交易的授權以及對於交易贊助的信任中繼的依賴，Beiko 建議開發人員花更多時間考慮 EIP 3074 的優點，首先考慮與 Pectra 有關的其他帳戶抽象相關的 EIP，其次考慮 Pectra 中建議納入的所有其他 EIP。如果包含在 Pectra 中，Finlay 表示，Metamask 可以在今年內某個時候快速利用這個代碼更改的功能。開發人員還簡要討論了首先為在諸如 Polygon 之類的 Rollup 上執行提案的原型的好處，以解決任何實施問題和設計細節。Geth 開發人員「Lightclient」對暫緩批准 EIP 3074 在 Pectra 中的提案直到其他 EIP 被優先考慮的想法提出了反對意見，稱這個代碼更改「是一個非常簡單的實現」，不會阻止開發人員在升級中包含其他代碼更改。儘管如此，Beiko 確認 EIP 3074 的下一步將是最終確定其規格並與客戶端和/或 Rollup 團隊原型化設計，然後重新討論是否將該代碼更改優先納入 Pectra。

EIP 7547: 包含列表

接着，以太坊基金會研究員 Mike Neuder 重新提出了將 EIP 7547 納入 Pectra 的論點。關於 EIP 7547 的背景，請聽這個Galaxy Research 的播客。對於該提案的動機，Neuder 表示：「我試圖表達的一點是，如果我們決定在 Electra 中不使用包含列表，我們就會讓 MEV 基礎設施在未來一年半到兩年內繼續發展，而我們卻沒有做出任何改變。在我們這邊，我認為這本身就是一個非常積極的決定，因為不做任何事情幾乎和做某事一樣強烈。所以這是我想要說明的第一點。第二點是，這個包含列表的變更範圍通常是相當受控制的。我們一直在研究這個概念驗證規範，即 POC 規範只是試圖減少風險並顯示出在共識層、執行層和引擎 API 中的變化相當小。希望這能夠激勵在這次分叉中採用它。」

Reth 客戶端團隊表示支持將 EIP 7547 納入 Electra。來自 Geth、Lighthouse、Lodestar 和 Nethermind 客戶端團隊的代表們表示，他們正在為該代碼更改製作原型。此外，Besu 開發人員 Justin Florentine 表示個人支持將該代碼更改納入下一個以太坊升級。Neuder 鼓勵開發人員查閱最新的 EIP 規範，並在包含列表的 Discord 頻道中發表任何想法或問題。他還表示，他將在下周一，3 月 18 日，世界協調時間 14:00 舉辦一次有關包含列表實施細節的分組會議。

EIP 7623: 增加 Calldata 成本

接下來，以太坊基金會研究員 Toni Wahrstätter 重新分享了他的提案，即通過增加 calldata 的成本來減少以太坊的最大區塊大小。Calldata 是以太坊交易中通常儲存來自 Rollup 的批量交易數據的地方。然而，隨著 Dencun 引入 blobs，Rollup 現在可以以比 calldata 顯着更便宜的成本暫時儲存用戶在以太坊上的交易數據。「好處在於，這種返利機制基本上強制執行，『如果你將大量的 calldata 帶入 EVM，你也需要使用它。否則就使用 blobs。』」以太坊基金會研究員 Ansgar Dietrichs 在關於 EIP 7623 的會議聊天中評論道。Wahrstätter 分享了關於增加 calldata 成本將如何影響用戶交易的新分析。他表示，成本的增加僅會影響 4.5% 的以太坊交易和 1% 的以太坊用戶。Wahrstätter 表示，他的下一步是在下一次 Rollcall 期間聯繫 Rollup 團隊，以獲得他們對他的提案的反饋。Beiko 提到，由於這個 EIP 代表了對以太坊代碼庫的微不足道的更改，開發人員不需要立即決定將其納入 Pectra，而是在接下來的幾個 ACDE 電話會議中決定。

EIP 7645: 將 ORIGIN 重命名為 SENDER

自 2014 年以來一直是以太坊的早期開發者的 Cyrus Adkisson 提議將以太坊操作碼 ORIGIN 的名稱更改為 SENDER，以修復智能合約開發者對操作碼的誤用。「ORIGIN 操作碼有點過時了。它代表了發起動作並支付交易燃料費的帳戶，這在我們獲得真正的 [帳戶抽象] 之前，一直是相同的。到 2017 年中期，普遍認為用 ORIGIN 做任何事情都是壞消息，原因有很多。一，origin 可以用一種跨站腳本的方式來竊取資產並濫用權限，如果該權限是用 TX ORIGIN 術語來界定的。ORIGIN 會破壞兼容性，因為你的合約無法被其他合約使用，而且 ORIGIN 幾乎從不有用，」Adkisson 說道。

Adkisson 的提議引起了一些開發者的反對。Besu 客戶端維護者 Danno Ferrin 表示，在沒有 EOF（這是對 EVM 的另一組代碼更改）的情況下，不可能在更改操作碼別名之前準確檢查操作碼的所有用例。Ferrin 表示，EOF 代碼規範也有望納入 Pectra，其規範已經被凍結，並且正在為該提案編寫參考測試。然而，在更改以太坊現有操作碼的別名方面，Ferrin 表示，在他看來，這似乎是「完全不可能的」，而不會對 ORIGIN 的潛在用戶產生負面影響。

自由職業以太坊開發者 Charles Cooper 同意，改變操作碼的語義是「危險的」，因為某些用戶可能依賴該操作碼進行重要用例。相反，Cooper 建議增加 ORIGIN 的燃料成本，以幫助提醒用戶其已被棄用，並阻止其使用。Cooper 表示：「從兼容性的角度來看，這可能是一個更巧妙的改變。」

ACDE 184 議程

由於時間有限，因為這些會議最長只有一個半小時，Beiko 建議將某些議程項移至下一次 ACDE 電話會議的討論前。其中一個推遲到 ACDE 184 的議程項是 Reth 客戶端團隊關於以太坊狀態增長的研究。在結束電話會議之前，Beiko 詢問開發者對於每周一的測試電話會議是否繼續進行的想法。這些電話會議旨在協調 Dencun 升級的客戶端團隊之間的測試工作。隨著 Dencun 升級的完成，開發者們同意停止定期的周一測試電話會議，並在 Pectra 升級接近準備進行多客戶端測試工作時重新啟動新系列。

原文連結