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）規範卻頗具挑戰。他建議開發者們儘早着手這一工作。

原文連結