作者：Christine Kim，Galaxy；編譯：五銖，金色財經

2024 年 9 月 12 日，以太坊協議开發人員通過 Zoom 虛擬會面，召开了第 196 屆全核心开發人員執行 (ACDE) 電話會議。本周，電話會議由以太坊基金會 (EF) 協議支持負責人 Tim Beiko 主持。ACDE 電話會議是每兩周舉行一次的會議系列，开發人員在會上討論和協調對以太坊執行層 (EL) 的更改。

在 ACDE #196 上，开發人員分享了 Pectra Devnet 3 發布的最新動態，並討論了未來开發網絡上實施的各種 Pectra 代碼更改。他們認真討論了將升級分爲兩部分，以便他們可以在更快的時間表上（可能在明年 2 月之前）在 Devnet 3 上發布代碼更改。开發人員同意在下一次 ACD 電話會議上就此做出最終決定。最後，一位網名爲“pk910”的 EF 开發人員運營工程師分享了他清理以太坊公共測試網 GitHub 存儲庫並調整其結構以更易於使用的工作的最新動態。

Pectra Devnet 3

EF 开發運營工程師 Parithosh Jayanthi 介紹了 Pectra Devnet 3 的發布情況。該开發網絡於 9 月 11 日星期三啓動。它包括對 EIP 7251 中驗證器合並的修復以及 EIP 7702 的更新規範。根據迄今爲止在 Devnet 3 上的測試，EIP 7251 和 EIP 7702 似乎都按預期運行。Jayanthi 指出，在 Nethermind 和 EthereumJS 客戶端中發現了一些問題，這兩個客戶端團隊正在努力解決這些問題。Jayanthi 補充說，由於 EIP 7702 在 Devnet 3 上线，最好讓錢包开發人員測試該實現並提供他們對其使用的反饋。有關 Pectra Devnet 3 的所有信息，包括請求測試網 ETH 的水龍頭，都可以在此網站上找到。

Pectra 規範更新

Geth 开發人員 Felix Lange 已提議對 Pectra 中 EL 觸發請求的編碼進行更改。作爲背景，Pectra 將啓用 EL 上的智能合約來啓動 CL 上的驗證器提款和合並。在上次 ACD 電話會議中，Lange 分享了一項建議，以減少 EL 客戶端解析這些請求所需的工作量。自上周電話會議以來，Lange 已正式確定了他的建議以及 EL 客戶端團隊需要做的工作，以更新以下四個 EIP 的編碼：

• EIP 7685，通用執行層請求；

• EIP 7002，EL 可觸發提款；

• EIP 6110，鏈上供應驗證器存款；

• EIP 7251，增加最大有效余額。

开發人員大體上同意 Lange 的提議。然而，網名爲“Dustin”的 Nimbus 开發人員認爲，該提議“毫無意義地靈活”，並且不向前兼容 EL 序列化格式的未來變化。他還強調，需要額外的規範來明確規範 EL 客戶端的請求順序以及 EL 向 CL 提交無效請求時 CL 客戶端的行爲。Lange 同意向 Engine API 添加更多文本以指定請求的順序。他還同意 Dustin 的觀點，即應該更深入地考慮 CL 客戶端在 CL 客戶端檢測到來自 EL 客戶端的無效請求時的行爲。

以太坊基金會研究員 Peter Miller 指出，根據當前規範下 CL 客戶端的邏輯行爲，CL 客戶端應該拒絕來自 EL 的未按正確方式排序的區塊。此外，如果 EL 共享給 CL 的列表中存在無效請求，則 CL 應該簡單地處理列表中所有有效請求並忽略無效請求。Dustin 同意 Miller 的觀點，並建議开發人員在適當的文檔中指定此行爲。Beiko 表示，开發人員應該致力於解決 Lange 提案中的問題，並在下一次 ACD 調用之前完成它。

隨後，Erigon 开發人員 Andrew Ashikhmin 提出了對 EIP 7702 的更新，設置 EOA 帳戶代碼。他指出，EIP 中指定的有效性檢查與舊 EIP 中指定的有效性檢查不一致。 Geth 开發人員 Matt Garnett（又名“Lightclient”）表示，他有一個替代方案來解決一致性問題並簡化 EIP 7702 的有效性檢查。开發人員大多贊成最終確定 Lightclient 的提案並將其添加到 Pectra Devnet 4 中。

接下來與 Pectra 相關的討論是關於 EIP 2537 下 BLS 預編譯的定價。Geth 开發人員 Jared Wasinger 表示，根據他的基准分析，BLS 預編譯的價格應該是目前規定的兩倍。目前，成本基於多线程執行，這不是定價其他預編譯時執行的標准。因此，基於他使用單线程執行的分析，Wasinger 建議對 EIP 2537 中操作的折扣表進行更改。Nethermind 團隊報告說，他們正在开發一種工具，以便其他客戶端團隊也可以輕松地對 EIP 進行自己的基准分析。 Beiko 建議團隊對 BLS 預編譯進行自己的基准測試，並在接下來的兩周內提出有關重新定價這些操作的想法。

Pectra EIP 補充

开發人員隨後开始討論爲 Pectra 升級添加新 EIP 的話題。在开始討論時，Beiko 警告說：“我們已經在 Pectra 中擁有大量 EIP。從 EIP 數量來看，它已經是迄今爲止最大的分叉。”根據开發人員在電話會議前分享的觀點，Beiko 表示，很明顯，EIP 7742（EL 和 CL 之間的 blob 計數分離）是仍在考慮納入升級的 EIP 列表中爭議最小的。

EF 研究員 Alex Stokes 再次提出將 Pectra 拆分爲兩個較小的硬分叉的想法。“我認爲每個人都同意這是一個非常大的分叉。因此，自然的做法就是將其一分爲二。通常，較小的分叉風險較小。特別是，現在的 Pectra 有很多跨層 EIP，這確實增加了測試、安全和審查負擔，”Stokes 說。Jayanthi 在之前的電話會議上也提出了這個想法，他說他仍然支持這個想法。“我認爲主要原因是，目前我們有很多 EIP，我們傾向於觸及堆棧的許多層，我們添加的越多，即使在當前負載下，任何一個人都很難對所有變化有一個全局的了解，”Jayanthi 說。

關於當前 Pectra EIP 可以分爲兩個分支的方式，Stokes 建議使用當前在开發網絡上運行的所有 EIP 來發布 Pectra 的第一部分，然後使用 PeerDAS、EOF 和其他一些額外的 EIP 來發布 Pectra 的第二部分。开發人員有信心，通過這樣做，他們將能夠在明年 2 月之前發布 Pectra 的第一部分。 “我認爲，如果我們仍然只在 6 月份發布前半部分，那么這種分叉將是一種失敗，”EF 研究員 Ansgar Dietrichs 在 Zoom 聊天中表示。

Beiko 贊成分叉的想法，但警告不要從开發網中刪除任何 EIP，因爲這可能會給客戶團隊帶來更多工作，並延長而不是縮短爲激活主網而准備這些代碼更改的時間线。獨立的以太坊協議开發人員 Danno Ferrin 建議盡快在 Devnet 3 上完善 EIP 以激活主網，然後從 Devnet 4 或 5 开始並行工作，將 PeerDAS 和 EOF 重新定位到 Pectra EIP 上。實際上，在 Pectra 之後的升級中，Devnet 4 或 5 將成爲 Devnet 0，而开發人員對如何命名並不確定。

在之前的電話會議上，开發人員同意以 Pectra Fusaka 的名字命名升級，但他們也同意將此升級保留給 Verkle 過渡。關於這一點，Ferrin 建議开發人員在確信代碼更改已准備好用於主網激活之前，不要提前預訂升級。這引起了 Geth 开發人員 Guillaume Ballet 的憤怒，他一直在領導 Verkle 過渡工作，並堅持認爲 Verkle 過渡“很久以前”就准備好了。爲了緩解緊張局勢，Beiko 表示，將 Pectra 一分爲二的目的最終是爲了嘗試在更快的時間表上發布 Pectra 代碼更改，這有利於爲此後的 Verkle 過渡掃清道路。

然而，存在這樣的風險：Pectra 升級的第二部分可能會隨着更多 EIP 的增加而變得更大，因此與當前 Pectra EIP 列表同時發布相比，需要更多時間才能發布。Nethermind 开發人員 Ben Adams 質疑，如果將升級分爲兩部分，Pectra 的測試過程將如何進行。鑑於這一決定將徹底改變以太坊下一次立即升級的範圍，Beiko 建議开發人員花一周時間考慮這個想法。他要求开發人員准備在下周四的全體核心开發人員共識電話會議上就此事做出最終決定。

網絡配置結構對齊

最後但並非最不重要的是，EF 开發運營工程師“pk910”分享了他的工作更新，以清理以太坊公共測試網 GitHub 存儲庫並調整其結構以更易於使用。他要求客戶團隊檢查以太坊主網和測試網的節點配置，並將任何缺失的信息添加到相應的存儲庫中。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。