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