以太坊核心開發者最新會議摘要：Pectra修復與籌備、PeerDAS進展

閱讀本文需 13 分鐘

8月8日，以太坊所有核心開發人員參加了第139次All Core Developers Consensus(ACDC) 電話會議。

原文標題：《Ethereum All Core Developers Consensus Call #139 Writeup》

原文作者：Christine Kim

原文編譯：Ladyfinger，BlockBeats

編按：

以太坊所有核心開發者共識電話（ACDC）是每兩週舉行一次的系列會議，專注於討論和協調以太坊共識層（CL），也就是信標鏈的變更。第 139 次 ACDC 電話會議由以太坊基金會（EF）研究員 Alex Stokes 主持，會議內容涵蓋了 Pectra Devnet 2 的修復、Devnet 3 的準備、PeerDAS 實施進度以及以太坊節點分佈的新數據。

在會議期間，開發者們審議了Pectra Devnet 2 的穩定性和存在的問題，討論了即將到來的Devnet 3 的準備工作，並就PeerDAS 的實施進展進行了深入探討。此外，EIP 7688 的提案也引起了與會者的廣泛討論，這項提案旨在引入一種向前相容的資料結構，以支援以太坊資料序列化方法的潛在變更。 Galaxy Digital 研究副總裁Christine Kim 對本次會議進行了詳細記錄，BlockBeats 將原文編譯如下：

2024 年8 月8 日，以太坊開發者們透過Zoom 舉行了第139 次核心開發者共識電話會議（ACDC）。 ACDC 電話會議是每兩週舉行一次的系列會議，開發者們在此討論並協調以太坊共識層（CL），也稱為信標鏈的變更。本週的電話會議由以太坊基金會（EF）研究員 Alex Stokes 主持。開發者們討論了 Pectra Devnet 2 的修復、Devnet 3 的準備、PeerDAS 實施進度以及以太坊節點分佈的新資料。

Pectra 更新

Stokes 宣布，EF 的研究員Hsiao Wei Wang 即將推出Pectra 共識層（CL）規範的官方更新版本alpha.4，該版本包含了對前一版的多項改進，並計劃在近期發布。

關於 Pectra Devnet 2 的話題，EF 開發者營運工程師 Barnabas Busa 表示，網路穩定，並已達到 85% 的網路參與度。在執行層（EL）客戶端還有一些需要解決的小問題，主要是 EthereumJS 和 Erigon。大多數 CL 用戶端在 Devnet 2 上是穩定的。然而，Busa 提到了 Prysm 用戶端需要進一步調查的小問題。 EF DevOps 工程師 Parithosh Jayanthi 補充說，還需要客戶端團隊調查 Lighthouse、Teku 和 Besu 節點之間的問題。

隨後，開發者們討論如何改善 devnet 啟動的通訊流程。 Prysm 的開發者 Kasey Kirkham 在 Zoom 聊天中指出了自己對 Devnet 2 啟動時間的不知。為確保 Devnet 3 的啟動訊息能準確傳達給所有客戶端團隊，開發者決定設立一個定期的週會議，用於更新 Pectra 的測試進度。儘管具體時間尚未確定，但這些會議預計將在每週一舉行，類似於 Dencun 升級前的測試電話會議。 Jayanthi 提出，這些會議將簡短高效，時長控制在 15 至 30 分鐘之間，專注於討論 Pectra 相關的 devnet 測試更新，涵蓋 PeerDAS 和 EOF devnets 等議題。

在討論 Pectra Devnet 3 的議題時，開發者們重申了它將沿用與 Devnet 2 一致的 EIP 配置。此外，Devnet 3 將首次整合最新設計的EIP 7702 ，團隊將對其進行細緻的測試，以確保其與Pectra 核心EIPs 的兼容性。 Lodestar 團隊的 Gajinder Singh 提到，在 Devnet 2 中發現的 EIP 7251，即 MaxEB 提案中的問題，儘管已經進行了調試，但仍需在接下來的 Pectra devnet 上進行更深入的測試以驗證解決方案。

如ACDE #193上討論的，有一個新的Engine API 規範，它允許CL 用戶端從EL blob 交易記憶體池中獲取blobs。此方法稱為「getBlobsV1」。為了避免濫用，Teku 開發者Enrico del Fante 提出了一些對CL 規範的澄清。 Stokes 建議開發者們審查這些澄清，並計劃在 Pectra Devnet 3 上測試這種方法的使用。

開發者就mplex協議的棄用進行了討論。 Mplex 曾是 CL 用戶端用於單一通訊連結多資料流傳輸的協議，但目前已被其維護者廢棄。客戶端團隊正計劃轉向如 yamux 這樣的新型資料流復用技術。 Lodestar 的Phil Ngo 宣布，他們已完成yamux的整合和測試工作，並傾向於直接過渡到新協議，而不是長期維護兩個協議，因為這將增加客戶端的營運成本。 Nimbus 的 Etan Kissling 也透露，他們團隊正在對 yamux 進行測試。開發者達成共識，將繼續關注其他 CL 用戶端團隊在協議過渡方面的進展，並計劃在未來幾個月內再次評估從 mplex 到新復用器的遷移策略。

Etan Kissling 在Pectra 議題上提出了關於EIP 7688的討論，該提案旨在引入一種向前兼容的數據結構，以便智能合約開發者能夠在以太坊執行層（EL）的數據序列化方法從RLP 過渡到SSZ 時繼續使用。儘管 Pectra 升級本身不會完全實現 SSZ，但 EIP 7688 的提出是為了確保 Pectra EIPs 在資料變更方面的前向相容性。

Alex Stokes 對於在 Pectra 升級中加入 EIP 7688 持謹慎態度，認為升級規模已經相當龐大。 Parithosh Jayanthi 在會議中提到，EIP 7688 最早可能在 Devnet 5 中進行測試。 Lodestar、Prysm、Teku 和 Lighthouse 等團隊的代表對此提案表示支持。 Stokes 和 Beiko 建議，在所有現有 Pectra EIPs 達到穩定狀態之前，應避免在 Pectra 中新增新的 EIPs。 Kissling 接受了這項建議，並詢問了何時重新討論此議題的最佳時機。儘管沒有具體答复，團隊普遍認為應在 Pectra Devnet 5 啟動前對 EIP 7688 進行再次評估。

PeerDAS 更新

Prysm 用戶端團隊的代表在會議上匯報了他們關於PeerDAS 實施的最新進展，並引發了對"blobsidecar" Engine API 請求必要性的討論。 Alex Stokes 建議在下一次 PeerDAS 小組會議中深入討論 PeerDAS 對 Engine API 所需進行的調整。他同時指出，一位EF 研究員已經草擬了正式規範，提議從PeerDAS 中移除抽樣機制，目的是降低升級過程的複雜度。然而，在最近一次的 PeerDAS 小組會議上，與會者擔心此舉可能會增加未來透過硬分叉重新引入抽樣的難度。此外，抽樣機制的移除對 Pectra 中 blob gas limit 安全性增加的影響尚不清楚。一項提議將執行層（EL）和共識層（CL）中的 blob gas limit 解耦的提案，EIP 7742，在本週的電話會議上再次被提出。 Stokes 表示他將更新該 EIP，並計劃在下一次的 CL 電話會議上討論其納入的可能性，以及與 Pectra 中 blob gas limit 調整相關的議題。

研究更新

在本週的電話會議中，開發者們集中討論了三項研究議題。首先，他們探討了 EIP 7251 下，驗證者在合併質押 ETH 餘額時可能遇到的邊緣情況。 Etan Kissling 提出，驗證者餘額在合併期間可能長時間未更新，這可能導致協議錯誤地分配同步委員會職責。對此，Alex Stokes 回應稱，這一問題與協議處理驗證者退出的情況相似，並建議在共識層（CL）規範中記錄這一邊緣情況，而不改變現有合併設計。

然後，開發者們討論了以太坊網路層的變更，特別是引入了「quic ENR entry」。 Quic 代表快速 UDP 互聯網連接，它幫助節點發送和接收資料。 Stokes 建議在 GitHub 上建立一個拉取請求（PR），以進一步詳細說明 quic ENR entry 的具體變更。

最後，ProbeLab 分享了他們對以太坊網路的節點運作情況的持續分析。報告顯示，目前有8335 個節點在以太坊網路上運行，其中42% 使用的是Lighthouse 客戶端。在美國營運的節點佔總數的 36%，且約一半的節點部署在資料中心。 Prysm 的開發者「Potuz」對於資料中心託管的 Lighthouse 節點數量超過自架節點的現象表示好奇。 Stokes 推測，這可能是因為 Lighthouse 用戶端的主要用戶群包括機構和專業的節點運營商。

在會議的尾聲，Potuz 敦促團隊審查他所提交的關於調整執行有效載荷結構的 PR。該提案在上一屆ACDC 電話會議首次被提出。 Potuz 強調了迅速決策的重要性，指出儘管這些變更在概念上簡單易懂，但要將它們整合進共識層（Consensus Layer, CL）規範卻頗具挑戰。他建議開發者們儘早著手這項工作。