2024 年 5 月 30 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #134 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員 Alex Stokes 主持，開發人員在會上討論和協調對以太坊共識層（CL，也稱為信標鏈）的變更。本周，開發者們討論了 Pectra Devnet 0 啟動後的經驗和未解決的問題。他們還辯論將 Pectra 升級的範圍擴大到包括 peerDAS 和 SSZ 容器代碼更改的可行性。

Devnet 0 回顧

根據 Pectra 在 Devnet 0 上的啟動情況，客戶端團隊已同意在硬分叉激活期間保持 EIP 7549 影響的驗證行為不變。在之前的一次 ACDC 會議上，開發者們曾考慮過多種方案，以確保在分叉期間 EIP 7549 的影響不會導致大量無效驗證。為了避免使升級變得更加複雜，客戶端團隊決定在與其他 Pectra EIP 相同的紀元激活 EIP 7549，且在分叉前後不改變驗證行為。

關於 EIP 7251，開發者們仍然不確定是否應該允許從執行層（EL）觸發質押 ETH 的合併。這對於像 Lido 這樣的質押池來說將是一個理想的功能，這樣質押的合併就不必依賴於節點操作員，而是可以通過智能合約來實現。Stokes 建議在幾周後檢查客戶端實現驗證者質押合併的進展，然後再確定它們應該是 EL 操作還是 CL 操作。

然後，開發者們討論了關於 EIP 6110 下驗證者存款最終確認的一些未解問題。Teku 開發者 Mikhail Kalinin 在會議前的一條GitHub 評論中總結了這些問題的解決方向。Lighthouse 開發者「sean」提出了一個關於 Engine API 中「GetPayloadBodies」請求的版本控制的問題。Stokes 建議開發者們在 GitHub 上針對這個問題創建的pull request中發表他們的意見。

EIP 7549 變化

Nimbus 開發者 Etan Kissling 建議對 EIP 7549 的實現進行一個小改動。「這是關於泛化索引的穩定性問題。當我們在容器中間添加一個新字段時，後續字段會被分配一個新的索引，這會打破基於 EIP 4788 在執行層（EL）的證明，並且有些誤導性。……因此，我建議將新字段行動到末尾，以避免這兩個問題。」Kissling 解釋道。對此改動沒有人提出反對意見。Stokes 建議開發者在 GitHub 上查看 Kissling 提出的pull request。

另一個對 EIP 7549 的改動是在會議上提出的，將請求和其他由 EL 觸發的請求設計為 EL 區塊的附加程序。關於這個改動，Kalinin 表示：「在我看來，這是一個非常不錯的設計方案，它簡化了 EL……而且這基本上是對執行層區塊中泛化請求的一種替代方案。」Stokes 建議在下次 CL 會議上再次討論這個話題，以便開發者有更多時間審查GitHub 上的這個提案。

Pectra 範圍討論

有一些聚焦於共識層（CL）的 EIP 尚未正式包含或排除在 Pectra 升級之外。本周會議上，開發者們討論了是否在 Pectra 中加入EIP 7688和 PeerDAS。EIP 7688 採用了「StableContainer」SSZ 數據結構的一部分，以確保 EIP 7549 對證明的更改具備向前兼容性。作為背景介紹，SSZ 是一種在 CL 中使用的數據結構，開發者希望在執行層（EL）中也使用它。有關 SSZ 轉變的更多資訊，請參閱之前的會議記錄。PeerDAS 是以太坊上數據可用性採樣的實現，預計將大大增強網路支持 rollups 及其數據可用性需求的能力。實際操作中，PeerDAS 預計將驗證者可以附加到區塊的 blob 交易數量從每個區塊 3 個增加到 64 個或更多。

以太坊基金會開發者營運工程師 Barnabas Busa 表示，開發者已經在一個開發網路上啟動了 PeerDAS 的早期迭代版本。「我認為很多客戶端已經發現了很多問題，當我們有了實質性的進展時，隨時都可以重新啟動一個新的開發網路，」Busa 說。Stokes 詢問開發者們是否願意在可能導致升級延遲的情況下將 PeerDAS 添加到 Pectra 中。

一位暱稱為「Nishant」的開發者重新提出了將 PeerDAS 激活與 Pectra 中其他 EIP 的激活分開的建議。雖然這是可行的，但另一位暱稱為「atd」的開發者強調，如果開發者計劃在短時間內依次激活這些升級，用戶還是需要同時升級他們的軟體。atd 說：「我認為，在另一次升級兩個月後進行分叉是有點瘋狂的。如果我們要協調所有人升級客戶端，我們不想在兩個月後再讓所有人升級客戶端。那樣的話，甚至連一個發布周期都不夠。」

atd 補充說，在他看來，PeerDAS 是 Pectra 中包含和討論的 EIP 中最「有趣」的代碼更改。Stokes 表示，即使這會導致升級延遲，他也希望將 PeerDAS 包含在 Pectra 中。Grandine 客戶端開發者 Saulius Grigaitis 提議從 Pectra 中移除 EIP 7549 和 EIP 7688，以便支持 PeerDAS。這引發了對 EIP 7688 實施細節的討論。開發者們未能就代碼更改達成一致，並將在下一次 ACDC 會議上重新討論這一提案。

關於 PeerDAS 的話題，開發者們繼續權衡將 Pectra 分成兩個硬分叉的想法。以太坊基金會開發者選項工程師 Parithosh Jayanthi 警告說，如果開發者將 Pectra 分成兩個升級，他們必須小心不要在未來的 Pectra 第二部分中增加更多的 EIP。Jayanthi 說：「我想提到的一件事是，如果我們考慮分成兩個分叉，我們必須非常小心，不要在接下來的分叉中加入更多的新 EIP。我不知道我們是否能夠做到這一點。如果我們能夠在一年或一年半之前承諾一些事情，因為我們總是在提出新的想法，優先級也在變化等等。」

繼續討論兩個升級的想法，Lighthouse 開發者「sean」說，他沒有預見到 PeerDAS 與當前 Pectra EIP 列表之間有很多相互依賴關係。因此，這兩者可以分別進行，之後在開發者對它們的實現更加自信時輕鬆合併。Atd 同意這一觀點，認為在分別開發和測試這些內容後，將 Pectra EIP、PeerDAS 和 EIP 7688 合併不會有太大風險。

Busa 建議繼續測試 Pectra EIP 和 PeerDAS，但將代碼更改設計成 PeerDAS 在開發網路和測試網路上比 Pectra EIP 晚一個 epoch 激活。他指出，這已經是在 Devnet 0 上進行 Pectra EIP 和 PeerDAS 測試的方式。Busa 說：「實際上沒有什麼需要改變」，他補充說，如果 PeerDAS 在其他 Pectra EIP 準備好時還未準備好，開發者可以將該代碼更改從升級中刪除。這引發了幾個關於 PeerDAS 不同激活 epoch 如何影響客戶端團隊工作的疑問。最終，開發者們同意繼續開發 PeerDAS 及 Pectra EIP，但前提是 PeerDAS 將在開發網路和測試網路上在不同的 epoch 激活。

如前文所述，開發者們同意將 EIP 7688 是否包含在 Pectra 中的討論留到下一次 ACDC 電話會議。

原文連結