撰文：Christine Kim
編譯：Luccy，BlockBeats
編按：以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第135 次電話會議，本次會議主要集中在準備Pectra Devnet 1、PeerDAS Devnet 1 以及Simple Serialize (SSZ) 以太坊改進提案（EIPs）的測試網絡上。
開發者們就軟體包維護、EIP 包括流程和命名新一輪以太坊共識層升級等議題展開了深入討論。此外，會議還涉及了在Electra 規範下的實現進展、PeerDAS 網路變更對以太坊節點處理和驗證資料的影響、以及關於增加blob gas 限制的複雜工程問題。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
2024 年6 月13 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Consensus (ACDC)Call #135 會議。 ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員Alex Stokes 主持，開發人員在會上討論和協調對以太坊共識層（CL，也稱為信標鏈）的更改。本週，開發者們討論了Pectra Devnet 1、PeerDAS Devnet 1 以及一個用於Simple Serialize（SSZ）以太坊改進提案（EIPs）的第三個專用測試網絡的準備工作。
公告
開發者們以兩個公告開始了會議。以太坊基金會開發運維（DevOps）工程師Parithosh Jayanthi 表示，ethPandaOps 團隊，這是一群在以太坊基金會開發運維（EF DevOps）工作的工程師團隊，將接管ethereum-package Kurtosis 模組的維護和開發。這個軟體套件過去被開發者用來啟動以太坊測試網路和相關工具，例如用於監控和測試各種客戶端實現的Grafana 資料儀表板。軟體包從Kurtosis 技術團隊遷移到ethPandaOps 團隊的過程中，可能會影響用戶，因為某些連結將重定向到由ethPandaOps 團隊管理的GitHub 儲存庫，而不再是Kurtosis 團隊。 Jayanthi 建議用戶更新他們的軟體鏈接，並關注ethPandaOps 團隊發布的新版本。
第二個公告由以太坊基金會協議支持主管Tim Beiko 發布。 Beiko 表示，他正在努力引入新的流程，以分階段將EIPs 納入以太坊的升級中。他已經創建了一份草案EIP，定義了「Proposed for Inclusion」（提議包含）、「Considered for Inclusion」（考慮包含）和「Scheduled for Inclusion」（計畫包含）這些標籤。他希望開發者們審閱該文件並提供回饋。他希望在下次ACD 會議前完成這份文件。
Electra
下一個Electra 主要版本v1.5.0-alpha.3 的程式碼規格即將完成。開發者同意將共識規範GitHub 倉庫中的拉取請求（PR）#3768 合併到下一個版本。這個拉取請求由Nimbus 開發者Etan Kissling 創建，他指出，「committee_bits」欄位應該附加到「Attestation」的末尾，而不是資料的中間，以避免資料序列化問題。除了PR #3768，Stokes 問是否還有其他需要在下一個Electra 規範主要版本發布前解決的未決問題。 Jayanthi 在Zoom 聊天中提到，透過執行層（EL）觸發的驗證器整合存在一些未決問題。 Stokes 記錄了在會議後跟進EL 觸發的驗證器整合狀態的事項。
關於最新的Electra 規範的實施進展，會議上的大多數共識層（CL）客戶端團隊表示，他們能夠在v1.5.0-alpha.3 最終確定後一到兩週內準備好新版本進行測試。開發者們同意在幾週後重新討論下一個Pectra 開發網路Pectra Devnet 1 的時間表。
PeerDAS
接下來，開發者們討論了PeerDAS 的實施進度。 PeerDAS 是以太坊的網路改進，將增強節點處理和驗證用戶透過blob 交易提交的大量任意資料的能力。 Stokes 回顧了上次ACDC 會議上的決定，即開發者們將在其他Pectra EIPs 的同時，平行開發PeerDAS，透過在開發網路上啟動PeerDAS 的單獨啟動週期來實現。
Lodestar 開發者Gajinder Singh 表示，根據最近一次關於PeerDAS 的分組會議的討論，開發者將在Deneb 升級的基礎上，並在與其他Pectra EIPs 分開的開發網絡上啟動PeerDAS。 Teku 開發者Enrico Del Fante 表示，開發者更容易在先前以太坊升級Deneb 中確定的穩定程式碼規格上建置PeerDAS，而不是在不斷變化的Pectra 程式碼規格上。 Jayanthi 同意現在將PeerDAS 實施與其他Pectra EIP 實施合併可能會在測試過程中引起複雜問題，尤其是在嘗試找出錯誤來源時。他建議將這兩個工作流程分開，然後在兩者的實現更穩定後再進行合併。 Stokes 表示同意，並說開發者可以在大約一個月後重新討論合併PeerDAS 和其他Pectra EIP 實施的事宜。
關於啟動PeerDAS Devnet 1 的話題，客戶端團隊對於何時準備好測試網啟動沒有明確估計。會議上的個人估計大致在2 週到1 個月之間。 Stokes 建議在幾週後，當客戶端團隊有更多時間進行PeerDAS 實作時，重新討論開發網路的時間表。
然後，Beiko 指出，雖然PeerDAS 是網路改進，而不是以太坊核心協議的變化，但他仍然希望將程式碼變更納入Pectra 升級的元EIP 中。元EIP 文件是列出以太坊升級中包含的所有核心協議變化的公共文件。 Beiko 指出，PeerDAS 是Pectra 中「最大的特性」，儘管不需要硬分叉激活，但仍應包含在文件中，以表明開發者們認真準備在Pectra 主網激活時及時準備好它。對此沒有異議。
提高blob gas 限制
PeerDAS 改變了節點透過以太坊對等網路層處理和傳播資料的方式。為了讓用戶，特別是Layer-2 rollups，受益於這些變化，開發者必須將當前每塊六個blobs 的限制提高到更高的閾值，這將允許更高的blob（任意數據）吞吐量。更改blob 限制需要對以太坊核心協議進行更改，如開發者在本週會議上討論的那樣，這可能涉及比簡單調整協議技術堆疊中的一個常量值更複雜的工程工作。
Stokes 提議，在更改blob gas 限制時，解耦執行層（EL）和共識層（CL）之間的依賴關係。目前，任何對blob gas 限制的變更都需要更改EL 和CL 協定。 Stokes 提出了一些方法，可以打破這些依賴關係，使開發者能夠安全地從EL 中刪除硬編碼的blob gas 限制，並完全由CL 決定。以太坊基金會（EF）研究員Dankrad Feist 指出，除了EL 和CL 之間的依賴關係問題外，更改blob gas 限制對區塊的gas 計算的連鎖反應也很重要。 Feist 說：「最好的方法是改變計算方式。gas 價格計算發生在EL 中可能是個錯誤。那應該在CL 中，但現在改變起來更難。…這並不容易。」
開發者同意繼續調查對blob gas 限制和區塊中gas 計算進行更改的最佳途徑。開發者們也同意繼續討論在Pectra 中啟動PeerDAS 時是否會伴隨著blob gas 限制的增加。開發者對這些更改是應該結合在一起還是分多個硬分叉進行分階段實施存在分歧。
Jayanthi 表示，結合這些變更是一個「有風險」的決定，因為開發者在PeerDAS 在主網上啟動之前不會知道它的具體功能表現。以太坊基金會（EF）DevOps 工程師Barnabas Busa 補充說，Pectra 硬分叉的範圍已經非常大了，不需要再增加額外的程式碼變更。 Busa 說：「關鍵是我們已經有很多EIP 了，我覺得我們不斷地添加更多內容，這樣永遠不會結束。所以，我們必須在某個地方畫一條線，這就是我們的終點。我認為在在未來一年半的測試時間裡，發布PeerDAS 並增加blob 數量是不可能的。
一位螢幕名為「Francesco」的開發者建議，如果網路變更不會伴隨blob 數量的增加，可以移除PeerDAS 來「降低Pectra 的風險」。 Francesco 問：「如果沒有增加blob 數量，Pectra 的PeerDAS 到底有什麼好處？」
為了進一步說明測試PeerDAS 的困難，Jayanthi 指出，測試引入blobs 到以太坊的EIP 4844 並沒有完全模擬blobs 在以太坊主網上的實際表現和影響。 Jayanthi 說：「問題在於測試網路非常困難。我們確實進行了很多與4844 相關的出色測試，但blobs 在主網上的表現與在測試中的表現並不是完全一致。我們確實看到較弱的節點出現問題。意義，這也是我認為我們應該一步一步來而不是一次性完成的主要原因。
EF 研究員Ansgar Dietrichs 評論說，把增加blob 數量和PeerDAS 關聯起來是錯誤的，因為僅僅是PeerDAS 就已經要求開發者選擇一個blob 數量值。雖然開發者可以選擇與以太坊主網上相同的數字，但關於PeerDAS 應該使用什麼數字的決定必須做出。唯一選擇相同數字的理由是開發者增加了PeerDAS 的複雜性，使其在出現錯誤時能夠回退到目前Deneb 規範中的blob 傳播機制。 Dietrichs 補充說，關於測試複雜性的擔憂進一步加強了他認為Pectra 應該通過兩個硬分叉激活的觀點，而不是一個，但這並不意味著他認為PeerDAS 應該與blob 數量的更改分離。
SSZ 更新
Kissling 分享了三個與SSZ 相關的EIP 的進度更新。他指出，這些EIP 的實作工作已經在多個客戶端上展開，包括Teku、Grandine 和Lighthouse。他說，開發者可以開始討論這些SSZ EIP 的開發網路時間表，並可能在下一個ACDC 會議上將它們納入Pectra 升級的範圍。
F-Star 命名
有一篇在Ethereum Magicians 上的帖子，討論了Electra 之後的下一個以太坊共識層（CL）升級名稱。開發者已經為Prague 之後的執行層（EL）升級確定了名稱：大阪（Osaka）。候選的CL 升級名稱有：Fulu、Felis、Formosa 和Funi。這些名稱都遵循以“F”開頭的主要恆星命名慣例，適用於Beacon Chain 的第六次全網升級。 Stokes 請在通話中的開發者在Magicians 帖子上發表對此主題的看法。
