以太坊核心開發者最新會議摘要：Dencun升級回顧、Pectra升級程式碼更改

閱讀本文需 18 分鐘

3月14日，以太坊所有核心開發人員參加了第183次All Core Developers Execution(ACDE) 電話會議。

原文標題：《Ethereum All Core Developers Execution Call #183 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的變更。本次為 ACDE 第 183 次電話會議，本次會議中，發者們就 Dencun 升級的影響進行了回顧，並討論了未來 Pectra 升級可能包含的代碼更改。

此外，開發者還就幾個 EIP 展開了討論，包括了已經獲得批准的 EIP 2537、EIP 3074 和 EIP 7547 等。一些提案引發了開發者們的爭議，例如 EIP 7645，即將 ORIGIN 操作碼重新命名為 SENDER，以及與 Dencun 升級相關的一系列議程。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

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 升級接近準備進行多客戶端測試工作時重新啟動新系列。