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 文檔的下一步計劃。
8、EIP 編輯研討會
最后，會議提到了關于 EIP 編輯流程的專題研討會，但具體內容和時間尚未確定，可能會在后續會議中進一步詳細討論。
以太坊貓牧人（Ethereum Cat Herders）團隊將于 2025 年 1 月 17 日 16:00（UTC）舉辦一場 EIP 編輯研討會。