
作者:Christine Kim ,Galaxy Digital 研究團隊副總裁 翻譯:善歐巴,比特鏈視界
2024 年 2 月 28 日,以太坊開發者通過 Zoom 召開第 182 次全核心開發者 (ACDE) 電話會議。 ACDE 電話會議是每兩周舉行一次的會議系列,供開發人員討論和協調以太坊執行層 (EL) 的更改。 本周的會議由以太坊基金會 (EF) 研究員 Danny Ryan 主持。 開發人員討論了 Dencun 升級的測試更新以及 Pectra 的幾個候選 EIP。 討論最激烈的、擬議納入 Pectra 的 EIP 與帳戶抽象化相關的代碼更改有關。 帳戶抽象化 (AA) 旨在為外部擁有帳戶 (EOA) 引入更高程度的可編程性,EOA 是以太坊上由用戶控制的帳戶,而不是智能合約代碼。
Dencun 更新
以太坊基金會開發運維 (DevOps) 工程師 Barnabas Busa 分享了 Dencun 升級最終測試的最新情況。 以太坊基金會於 2 月 27 日星期二宣布,升級現已正式計劃於 2024 年 3 月 13 日在以太坊主網上激活。 正如上周的 ACD 電話會議所討論的那樣,開發人員正在主網影子分叉上測試客戶端軟體的最終版本,影子分叉是一種測試網絡,它鏡像了以太坊主網的區塊鏈狀態和活動。 Busa 表示,開發人員已經在主網影子分叉上進行了不同類型的「垃圾郵件測試」。 節點在這些測試中表現得非常穩定,網絡參與率一直保持在接近 100%。 雖然沒有出現問題,但 Busa 指出,垃圾郵件測試確實在計算機資源方面 (特別是內存和 CPU 佔用率) 嚴重影響了節點。
Busa 然後提醒與會者,Goerli 測試網絡 (testnet) 將很快被棄用。 任何使用測試網絡的人都應該在 4 月 17 日之前將其操作轉移到其他以太坊測試網絡。 Busa 說他已經注意到 Goerli 上的一些大型驗證器節點運營商已經退役了他們的機器。 這導致了 Goerli 在 2 月 28 日的網絡最終確定出現延遲,但 Goerli 網絡似乎已經恢復。 Ryan 指出 Goerli 的網絡參與率已經相當低,徘徊在 70% 左右。 「老實說,我並不期望 [參與率] 會持續到 4 月 17 日,」Busa 說。 「但這仍然值得關注。」
Busa 詢問他的團隊什麼時候應該停止 Devnet 12,這是一個去年 11 月推出的專用測試網絡,供客戶端團隊測試他們的 Dencun 升級實施。 為了以防萬一需要測試任何用於 Dencun 的最後一分鐘客戶端版本,開發人員同意在 Dencun 升級上線以太坊主網後不久關閉 Devnet 12。
Pectra 升級的追溯性 EIP
接下來,開發人員討論了 Pectra 升級的兩個追溯性以太坊改進提案 (EIP)。 追溯性 EIP 是代碼更改,可追溯地向以太坊協議添加約束,這些約束在很大程度上已經存在,但需要澄清以解決特定邊緣案例。 第一個追溯性 EIP,EIP 7610,擴展了一項規則,限制智能合約的創建僅限於具有預存在存儲空間的地址。 有關此代碼更改的更多背景信息,請參閱此處的前一次會議記錄。
有關 EIP 7610 的一個擔憂是它是否會影響 Verkle,這是一項代碼更改,開發人員正在為 Pectra 之後的升級做準備。 Geth 開發者 Gary Rong 解釋了 EIP 7610 如何在未來對 Verkle 升級不構成任何問題。 Hedera Hashgraph 工程師和 Besu 客戶端維護者 Danno Ferrin 對 EIP 7610 可能如何影響 Verkle 提出了一些未解決的擔憂,他表示他將在以太坊改進提案 7610 的「以太坊魔術師」討論板上分享這些擔憂。
開發人員討論的第二個追溯性 EIP 是 EIP 7523,它將正式禁止空帳戶出現在以太坊和以太坊測試網絡的狀態中。 Ryan 表示,他將仔細檢查誰正在進行分析,以確保實施該規則後任何以太坊網絡(主網或測試網)上的帳戶都不會受到影響,並將在下一次 ACDE 電話會議上再次討論這個問題。
用於 Pectra 的帳戶抽象化 EIP
接下來,開發人員討論了包含在 Pectra 中的潛在帳戶抽象化 EIP。 2 月 28 日,一部分開發人員參加了專門的 AA 會議,討論了該計劃的宏觀目標以及可以在短期和長期內實施以實現這些目標的各種 EIP。 以太坊聯合創始人 Vitalik Buterin 在談到 AA 的目標時表示,「因此,長期的 [目標是] 這個基本願望,即最終我們必須擁有一些類型的帳戶系統,該系統一方面允許密鑰輪換和 [另一方面] 密鑰棄用,以使我們能夠抵抗量子計算。 三、允許批量處理……[並且] 允許 sponsor 交易和其他一些較小的功能,其中當然,前兩個目標顯然無法通過 EOA 實現,因此提出了一個相當清晰的案例,將生態系統轉移到一個超越以太坊帳戶為中心的的地方,但是然後討論轉向了實現這些目標的實際手段是什麼,以及一些不太明確的具體細節,以及短期路線圖實際上是什麼,它可以為人們在短期內想要的帶來收益,但同時又與那些長期的 [目標] 兼容。」
短期內,開發人員正在評估三個主要的 AA EIP,分別是 EIP 3074、5806 和 7377。 對於 EIP 3074 和 5806 之間的優缺點,參與電話會議的開發人員意見分歧。 爭論的焦點之一在於 EIP 3074 在多大程度上要求用戶對交易進行雙重籤名並依賴去中心化方式發起交易的協議外 AA 標準 ERC 4337,以及其他關於 EIP 3074 與 5806 相比的相對複雜性和安全性方面的辯論。 開發人員普遍認為 EIP 7377 是爭議最少的 AA EIP,因為它在用例方面與其他兩個 AA EIP 正交。 EIP 7377旨在幫助用戶輕鬆地將他們的資產從以太坊帳戶遷移到新的智能合約錢包,而其他兩個 EIP 則主要側重於創建新的 AA 功能,這些功能支持批量交易授權和 gas 費用贊助。
開發人員沒有就這三個 EIP 達成共識,並同意在未來幾周內繼續討論它們。
Pectra 的其他 EIP 提案
除了帳戶抽象化 EIP 之外,開發人員還簡要討論了幾個其他擬議納入 Pectra 升級的 EIP:
-
EIP 7623:增加 calldata gas 費用:該提案建議提高以太坊上主要用於數據可用性的常規交易成本。通過調整以太坊上的 calldata gas 費用,該 EIP 減少了可以合理放入一個區塊的調用數據交易數量,從而降低了區塊的最大尺寸。 減少區塊大小可以允許更多的 blob 交易。 Danny Ryan 建議參與討論的開發人員在未來幾周內審查該 EIP。
-
EIP 2537:BLS12-381 曲線運算預編譯:該提案引入新的密碼籤名方案到以太坊,已被批准納入 Pectra 升級。 該提案的作者之一 Antonio Sanso 提出了一些關於其實施的問題。 Danny Ryan 建議將問題記錄下來並在通話之外分發給開發人員進一步討論。
-
EIP 5920:PAY 操作碼:該提案創建了一個新的操作,允許用戶向地址發送 ETH,而不觸發任何地址的函數。 Geth 開發者 Marius van der Wijden 表示,經過與其他團隊進一步討論該 EIP 後,發現該提案的測試比預期的更加複雜。 Van der Wijden 還指出該提案的規範尚不完善。 Ferrin 補充說,PAY 操作碼目前被指定使用與另一個操作碼 (AUTH opcode) 相同的代碼編號,因此需要由其作者糾正。
-
EIP 7609:降低臨時存儲定價:該提案建議降低智能合約常見用例(例如維護可重入日誌)的臨時存儲操作碼價格。 Van der Wijden 和 Ryan 都同意在 Dencun 升級上線後先收集有關臨時存儲操作碼如何使用的數據,然後重新討論其定價。
-
EIP 7639:停止提供權益證明之前的歷史數據:該提案為執行層 (EL) 客戶端制定了一個時間表,以便它們停止提供合併升級之前的歷史數據。 此代碼更改的動機是為了減少以太坊節點需要永久存儲的數據量。 該提案還承諾節點以標準化方式構建合併之前歷史數據並從外部源檢索它們。 Teku 開發者 Mikhail Kalinin 指出,該 EIP 依賴於另一個 EIP (EIP 6110),後者在先前的一次 ACD 電話會議上被批准納入 Pectra 升級。 開發人員同意在未來幾周內更詳細地審查 EIP 7639。
引擎 API 和 JSON RPC 更改
除了上述議題,以太坊核心開發者還就引擎 API 和 JSON RPC 變更進行了討論。
Teku 開發者 Mikhail Kalinin 提出了一些與確認規則實施相關的問題,該規則是一種 CL 機制,可以在大約 12 秒(一個插槽)的時間內確認某個區塊在特定假設下是否會留在規範鏈並最終確定。 這是一個強大的功能,因為許多建立在以太坊上的應用程式可以利用早期區塊確認的信息來進行操作。 但是,要公開有關早期區塊確認的數據,需要對以太坊引擎 API 和 JSON RPC 進行一些更改。 由於通話時間有限,Ryan 建議在下周或下下周的 ACD 電話會議上更詳細地討論這些更改。
輕客戶端分 breakout room 會議
Ryan 提醒開發人員,下周三 (3 月 6 日) 將有一場專門的會議來討論 Pectra 升級的輕客戶端路線圖。 有關輕客戶端討論的背景信息,請參閱前一次會議記錄。
新的以太坊客戶端版本提案
最後,van der Wijden 提出了一項建議,即構建一個新的以太坊客戶端版本,以在初始同步過程中為節點節省 550GB 的帶寬。 Van der Wijden 表示他正在為新版本準備正式的 EIP,但其規範的草稿可以在此處找到。 Ryan 鼓勵開發人員查看草稿並在 Discord 上提出任何問題。