撰寫： Christine Kim

編譯：Luccy，BlockBeats

編按：以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第134 次電話會議，本次會議上，開發者們探討了多個關鍵EIP 的實現細節和技術挑戰，包括EIP 7549、EIP 7251、EIP 6110、EIP 7688 等。

此外，開發者們也深入討論了PeerDAS 的實施，這項數據可用性採樣技術預計將顯著提升以太坊網路支援Rollups 及其數據可用性需求的能力。會議中提出了將Pectra 分成兩個硬分叉進行升級的建議，並討論了不同EIP 的激活時間和相互依賴關係的問題。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

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）的證明，並且有些誤導性。對此改動沒有人提出反對意見。 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 電話會議。