本文總結了以太坊所有核心開發者共識電話（ACDC）第134次電話會議的內容。會議討論了多個關鍵EIP的實施細節和技術挑戰，並深入研究了PeerDAS的實施、任務清單和提升以太坊支援率的能力。開發者們也討論了Pectra硬分叉升級建議，以及EIP的相互依賴問題。在會議上提出了關於EIP 7251、EIP 6110、EIP 7688等的討論。最終，開發者同意繼續開發PeerDAS以及Pectra EIP，但前提是PeerDAS將在開發網路和測試網路上在不同epoch啟動。下一次ACDC電話會議將繼續討論EIP 7688是否應包含在Pectra中。
作者：Christine Kim
編輯：Luccy，BlockBeats
編按：以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第134 次電話會議，本次高峰會上，開發者們探討了多個關鍵EIP 的實現細節和技術挑戰，包括EIP 7549、EIP 7251、EIP 6110、EIP 7688 等。
此外，開發人員也深入研究了PeerDAS 的實施，任務清單和提升以太坊支援率的能力。會議中提出了Pectra 硬分叉升級建議，並討論了EIP 的相互依賴問題。
Galaxy Digital 研究副總裁Christine Kim 對本次會議做了詳細記錄，BlockBeasts 將原文編譯如下：
2024 年5 月30 日，以太坊基金會開發者齊聚Zoom 參加了All Core 開發工程師s 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 是以太坊上資料可用性採樣的實現，預計將大大增強網路支援匯總及其資料可用性需求的能力。在實際操作中，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 清單之間有很多相互依賴關係。因此，這兩者可以分別進行，之後在開發者對它們的實現更加自信時輕鬆合併。在同意這一觀點，認為在分別開發和測試這些內容後，將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 電話會議。
資訊來源：0x資訊編譯自網際網路。版權歸作者區塊律動BlockBeats所有，未經許可，不得轉載