作者：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 存儲庫並調整其結構以更易於使用。他要求客戶團隊檢查以太坊主網和測試網的節點配置，並將任何缺失的信息添加到相應的存儲庫中。
