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 在主網上的表現與在測試中的表現並不是完全一致。我們確實看到較弱的節點出現問題。我們確實看到時間上的挑戰等類似情況，這就是為什麼即使我們能在開發網路中模擬出 PeerDAS 和增加 blob 數量都能正常運作的完美情況，但這對主網來說並沒有任何實際意義，這也是我認為我們應該一步一步來而不是一次性完成的主要原因。」

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 帖子上發表對此話題的看法。

原文連結