第203次以太坊ACDE會議要點總結：Pectra升級將會帶來哪些影響？

白话区块链｜2025-01-20 16:00

第203 次以太坊ACDE 會議聚焦於Pectra Devnet 5 的啟動、規範更新及測試網升級計劃，推動主網升級與生態協作邁向新階段。

編譯：白話區塊鏈

2025 年1 月16 日，以太坊協議開發者透過Zoom 舉行了第203 次All Core Developers Execution（ACDE）會議。本週的會議由以太坊基金會（EF）協議支持負責人Tim Beiko 主持。 ACDE 會議是一個雙週例會系列，開發者們在會議中討論並協調以太坊執行層（EL）的相關變更。

在第203 次ACDE 會議上，開發者們討論了Pectra Devnet 5 的啟動以及未完成的Pectra 規格更新。他們還討論了在Holesky 測試網對提高Gas 上限進行測試的下一步計劃、RPC 標準化的進展，以及節點最低硬體和頻寬要求的規範。

1、Pectra Devnet 5 啟動

開發者在會議開始前半小時啟動了Pectra Devnet 5。以太坊基金會開發者營運工程師Parithosh Jayanthi 表示，他發現開發網路中存在Gas 估算問題，並計劃收集相關日誌，將問題分享到以太坊研發Discord 頻道。

2、Pectra 規範更新

開發者們討論了Pectra 程式碼規範的五項未完成更新：

1）EIP 7623：增加Calldata 成本第一個更新是對EIP 7623 的修改，用於澄清Gas 退款的處理方式。該更新已在GitHub 上合併，並納入了Pectra Devnet 5 的測試中。

2）EIP 7840：新增Blob 調度到執行客戶端設定檔第二項更新涉及EIP 7840 中的基礎費用分數問題。會議中沒有反對意見，開發者同意在1 月20 日（下週一）的Pectra 測試會議之前，將相關變更合併到GitHub 中。

3）Blob 基本費用的更新第三項更新同樣與Blob 基本費用有關，涉及在Pectra 啟動期間如何計算過量Gas。以太坊基金會研究負責人Alex Stokes 解釋，計算依賴前一區塊頭的資訊。如果Blob 容量的更改在分叉邊界（Pectra 激活區塊）上激活，則過量Gas 計算將基於使用舊分叉規則構建的前一區塊的資訊。 Stokes 認為，需要明確Blob 容量增加是在分叉邊界激活，還是在分叉邊界後的一個區塊激活。他表示：「無論選擇哪種方式並不重要，但我們需要統一做法。」開發者一致同意澄清EIP 7691，將Blob 容量增加的生效時間設定為分叉邊界後的區塊，從而只使用新分叉規則進行計算。以太坊測試開發者Mario Vega 表示，客戶端正在測試這種邏輯。 Geth 開發者「Lightclient」承諾將在下週一的測試會議前更新EIP 7691。

4）EIP 2537：BLS12-381 曲線運算的預編譯成本計算第四項更新與EIP 2537 中乘法成本計算相關。開發者們同意在EIP 中明確將計算指定為整數除法。通過Pectra Devnet 5 測試的用戶端團隊應已經在程式碼中實現了此邏輯，因此僅需要在規範上進行修改。以太坊虛擬機器開發者Paweł Bylica 表示，他將在GitHub 上對EIP 進行更改，並在下週一的測試會議前完成。

透過這些更新，開發者們持續推動Pectra 相關工作的完善和協調，為未來的以太坊主網升級鋪路。

5）最後，第五項更新與EIP 7702 相關，該提案旨在新增一種交易類型，使外部帳戶（EOA）可以永久設定代碼。 Otim Labs 營運長Julian Rachman 提出了對此EIP 的行為修改建議，即啟用程式碼內省功能。根據Otim Labs 團隊撰寫的文檔，程式碼內省指的是舊版合約能夠檢查自身字節碼或外部合約的字節碼，並基於該資訊調整行為的能力。

儘管以太坊虛擬機器物件格式（EOF）開發團隊計劃在未來的以太坊升級中禁用程式碼內省，但文件和會議中提到，啟用程式碼內省以檢查EOA 的「delegate_address」並不會阻礙EOF 的開發進程。允許代碼內省檢查EIP 7702 類型交易的委託地址的好處在於，支援在啟用EIP 7702 功能（如Gas 贊助）時，安全使用中繼者和其他外部帳戶。

Geth 開發者「Lightclient」支援在Pectra 規範中加入此更新。他表示：「這項更新非常容易實現。我們已經在確定帳戶是否為EIP 7702 委託帳戶，加入指定回郵地址是非常簡單的事情。」會議主持人Beiko 建議與會者再花幾天時間審查更改內容，然後再決定是否將其納入最終規範。他建議在下週一的測試會議上重新討論這個主題。

Beiko 也要求Rachman 的團隊在GitHub 上正式提交包含所有EIP 7702 修改建議的拉取請求，供開發者在周一討論。至於這項更新是否需要開發者啟動一個新的Pectra 開發網路進行測試，Jayanthi 表示，該變更可以包含在公共測試網的影子分叉中，而無需啟動新的開發網路。 Beiko 補充說，此次會議討論的所有其他規範更新也無需新的Pectra 開發網絡，因此開發者在Pectra Devnet 5 的進一步測試完成後，可以繼續推進公共測試網的更新工作。

3、Pectra 系統合約審計更新

以太坊基金會（EF）協議安全研究員Fredrik Svantes 表示，Pectra 系統合約的所有第三方審計工作都已完成。審計未發現重大問題，相關報告將上傳至GitHub，供客戶端團隊審查。 Svantes 建議在下次ACDE 會議中安排專屬時間，由稽核人員展示其稽核結果並解答用戶端團隊的問題。

4、Pectra 測試網升級計劃

Tim Beiko 提出了測試網升級的初步時間表。他建議在接下來的兩次ACD 會議中，確定用於升級Sepolia 和Holesky 測試網的區塊高度，並在2025 年2 月3 日前準備客戶端發布版本。計劃於2 月12 日當週進行Sepolia 分叉，隨後在2 月19 日當週進行Holesky 分叉。如果沒有重大漏洞或問題，Pectra 升級可能會在3 月初至中旬上線以太坊主網，這大約是Holesky 分叉後的三到五週時間內。會議中沒有人反對這項提議，Stokes 也建議將客戶端發布與Sepolia 和Holesky 測試網升級綁定推進。

5、Holesky Gas 限制

EF 通用工程師Sophia Gold 提議，將Holesky 升級發布中的客戶端預設Gas 上限設為36 百萬（36m），並繼續提高Holesky 的預設Gas 上限，使其始終高於以太坊主網的Gas 上限。這將確保主網Gas 上限的任何提升都能在Holesky 上進行測試，會議中沒有人反對這項提案。 Teku、Besu、Prysm 和Nethermind 團隊的代表表示，他們的Holesky 用戶端發布版本已經將預設Gas 上限設定為36 百萬。

6、RPC 標準化努力

Geth 開發者Felix Lange 對用戶端團隊未對以太坊JSON-RPC 規範標準化努力給予足夠回饋感到失望。在會議上，他提到的一個問題是，缺乏關於RPC 標準化範圍以及應包含哪些生態系統利害關係人的明確定義。 Lange 在部落格文章中詳細說明了他的標準化努力及下一步建議。 Beiko 建議在Discord 上進一步討論此問題，並為此安排專題討論會。 Besu 開發者Justin Florentine 表示，他將負責協調專題討論會的時間表。

7.節點硬體和頻寬要求規範

EF 應用研究員Kevaundray Wedderburn 請求對其關於以太坊節點最低硬體和頻寬需求的文件提供回饋。 Beiko 詢問是否應將這些要求以資訊性EIP 的形式起草，以便開發者和更廣泛的以太坊社群參考。 Prysm 開發者「Potuz」指出，驗證節點和全節點的硬體需求不同，因此文件應明確區分二者。 Beiko 同意Potuz 的觀點，並建議在Discord 上進一步討論節點硬體和頻寬要求以及正式化Wedderburn 文件的下一步計劃。