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

原文標題：《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 devnet s 等議題。

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

正如在 ACDE #193 上討論的，有一個新的 Engine API 規範，它允許 CL 客戶端從 EL blob 交易內存池中獲取 blob s。該方法稱為「 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 EIP s 在數據變更方面的前向兼容性。

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

PeerDAS 更新

Prysm 客戶端團隊的代表在會議上匯報了他們關於 PeerDAS 實施的最新進展，並引發了對「 blob sidecar 」 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 ）規範卻頗具挑戰。他建議開發者們儘早著手這一工作。