以太坊核心開發(fā)者最新會議摘要：激活PeerDAS、提高blob gas限制

發(fā)布時間 :

2025 年 2 月 19 日 03:05

編者按：以太坊所有核心開發(fā)者共識電話（ACDC）每兩周舉行一次，主要討論和協(xié)調(diào)對以太坊共識層（CL）的更改。本次為 ACDC 第 135 次電話會議，本次會議主要集中在準備 Pectra Devnet 1、PeerDAS Devnet 1 以及 Simple Serialize (SSZ) 以太坊改進提案（EIPs）的測試網(wǎng)絡(luò)上。

開發(fā)者們就軟件包維護、EIP 包括流程和命名新一輪以太坊共識層升級等議題展開了深入討論。此外，會議還涉及到了在 Electra 規(guī)范下的實現(xiàn)進展、PeerDAS 網(wǎng)絡(luò)變更對以太坊節(jié)點處理和驗證數(shù)據(jù)的影響、以及關(guān)于增加 blob gas 限制的復(fù)雜工程問題。

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

2024 年 6 月 13 日，以太坊開發(fā)人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC)Call #135 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員 Alex Stokes 主持，開發(fā)人員在會上討論和協(xié)調(diào)對以太坊共識層（CL，也稱為信標鏈）的更改。本周，開發(fā)者們討論了 Pectra Devnet 1、PeerDAS Devnet 1 以及一個用于 Simple Serialize（SSZ）以太坊改進提案（EIPs）的第三個專用測試網(wǎng)絡(luò)的準備工作。

公告

開發(fā)者們以兩個公告開始了會議。以太坊基金會開發(fā)運維（DevOps）工程師 Parithosh Jayanthi 表示，ethPandaOps 團隊，這是一組在以太坊基金會開發(fā)運維（EF DevOps）工作的工程師團隊，將接管 ethereum-package Kurtosis 模塊的維護和開發(fā)。這個軟件包過去被開發(fā)者用來啟動以太坊測試網(wǎng)絡(luò)和相關(guān)工具，例如用于監(jiān)控和測試各種客戶端實現(xiàn)的 Grafana 數(shù)據(jù)儀表板。該軟件包從 Kurtosis 技術(shù)團隊遷移到 ethPandaOps 團隊的過程中，可能會影響用戶，因為某些鏈接將重定向到由 ethPandaOps 團隊管理的 GitHub 存儲庫，而不再是 Kurtosis 團隊。Jayanthi 建議用戶更新他們的軟件鏈接，并關(guān)注 ethPandaOps 團隊發(fā)布的新版本。

第二個公告由以太坊基金會協(xié)議支持主管 Tim Beiko 發(fā)布。Beiko 表示，他正在努力引入新的流程，以分階段將 EIPs 納入以太坊的升級中。他已經(jīng)創(chuàng)建了一份草案 EIP，定義了「Proposed for Inclusion」（提議包含）、「Considered for Inclusion」（考慮包含）和「Scheduled for Inclusion」（計劃包含）這些標簽。他希望開發(fā)者們審閱該文件并提供反饋。他希望在下次 ACD 會議前完成這份文件。

Electra

下一個 Electra 主要版本 v1.5.0-alpha.3 的代碼規(guī)范即將完成。開發(fā)者們同意將共識規(guī)范 GitHub 倉庫中的拉取請求（PR）#3768 合并到下一個版本。這份拉取請求由 Nimbus 開發(fā)者 Etan Kissling 創(chuàng)建，他指出，「committee_bits」字段應(yīng)該附加到「Attestation」的末尾，而不是數(shù)據(jù)的中間，以避免數(shù)據(jù)序列化問題。除了 PR #3768，Stokes 問是否還有其他需要在下一個 Electra 規(guī)范主要版本發(fā)布前解決的未決問題。Jayanthi 在 Zoom 聊天中提到，通過執(zhí)行層（EL）觸發(fā)的驗證器整合存在一些未決問題。Stokes 記錄了在會議后跟進 EL 觸發(fā)的驗證器整合狀態(tài)的事項。

關(guān)于最新的 Electra 規(guī)范的實施進展，會議上的大多數(shù)共識層（CL）客戶端團隊表示，他們能夠在 v1.5.0-alpha.3 最終確定后一到兩周內(nèi)準備好新版本進行測試。開發(fā)者們同意在幾周后重新討論下一個 Pectra 開發(fā)網(wǎng)絡(luò) Pectra Devnet 1 的時間安排。

PeerDAS

接下來，開發(fā)者們討論了 PeerDAS 的實施進展。PeerDAS 是以太坊的一個網(wǎng)絡(luò)改進，將增強節(jié)點處理和驗證用戶通過 blob 交易提交的大量任意數(shù)據(jù)的能力。Stokes 回顧了上次 ACDC 會議上的決定，即開發(fā)者們將在其他 Pectra EIPs 的同時，平行開發(fā) PeerDAS，通過在開發(fā)網(wǎng)絡(luò)上激活 PeerDAS 的單獨激活周期來實現(xiàn)。

Lodestar 開發(fā)者 Gajinder Singh 表示，根據(jù)最近一次關(guān)于 PeerDAS 的分組會議的討論，開發(fā)者將在 Deneb 升級的基礎(chǔ)上，并在與其他 Pectra EIPs 分開的開發(fā)網(wǎng)絡(luò)上激活 PeerDAS。Teku 開發(fā)者 Enrico Del Fante 表示，開發(fā)者更容易在已經(jīng)在先前以太坊升級 Deneb 中確定的穩(wěn)定代碼規(guī)范上構(gòu)建 PeerDAS，而不是在不斷變化的 Pectra 代碼規(guī)范上。Jayanthi 同意現(xiàn)在將 PeerDAS 實施與其他 Pectra EIP 實施合并可能會在測試過程中引起復(fù)雜問題，尤其是在嘗試找出錯誤來源時。他建議將這兩個工作流程分開，然后在兩者的實現(xiàn)更穩(wěn)定后再進行合并。Stokes 表示同意，并說開發(fā)者們可以在大約一個月后重新討論合并 PeerDAS 和其他 Pectra EIP 實施的事宜。

關(guān)于啟動 PeerDAS Devnet 1 的話題，客戶端團隊對于何時準備好測試網(wǎng)啟動沒有明確估計。會議上的個人估計大致在 2 周到 1 個月之間。Stokes 建議在幾周后，客戶端團隊有更多時間進行 PeerDAS 實施時，重新討論開發(fā)網(wǎng)絡(luò)的時間安排。

然后，Beiko 指出，雖然 PeerDAS 是一個網(wǎng)絡(luò)改進，而不是以太坊核心協(xié)議的變化，但他仍然希望將代碼變化包含在 Pectra 升級的元 EIP 中。元 EIP 文檔是列出以太坊升級中包含的所有核心協(xié)議變化的公共文件。Beiko 指出，PeerDAS 是 Pectra 中「最大的特性」，盡管不需要硬分叉激活，但仍應(yīng)包含在文檔中，以表明開發(fā)者們認真準備在 Pectra 主網(wǎng)激活時及時準備好它。對此沒有異議。

提高 blob gas 限制

PeerDAS 改變了節(jié)點通過以太坊對等網(wǎng)絡(luò)層處理和傳播數(shù)據(jù)的方式。為了讓用戶，特別是 Layer-2 rollups，受益于這些變化，開發(fā)者必須將當前每塊六個 blobs 的限制提高到更高的閾值，這將允許更高的 blob（任意數(shù)據(jù)）吞吐量。更改 blob 限制需要對以太坊核心協(xié)議進行更改，如開發(fā)者在本周會議上討論的那樣，這可能涉及比簡單調(diào)整協(xié)議技術(shù)棧中的一個常量值更復(fù)雜的工程工作。

Stokes 提議，在更改 blob gas 限制時，解耦執(zhí)行層（EL）和共識層（CL）之間的依賴關(guān)系。目前，任何對 blob gas 限制的更改都需要更改 EL 和 CL 協(xié)議。Stokes 提出了一些方法，可以打破這些依賴關(guān)系，使開發(fā)者能夠安全地從 EL 中刪除硬編碼的 blob gas 限制，并完全由 CL 決定。以太坊基金會（EF）研究員 Dankrad Feist 指出，除了 EL 和 CL 之間的依賴關(guān)系問題外，更改 blob gas 限制對區(qū)塊的 gas 計算的連鎖反應(yīng)也很重要。Feist 說：「最好的方法是改變計算方式。gas 價格計算發(fā)生在 EL 中可能是個錯誤。那應(yīng)該在 CL 中，但現(xiàn)在改變起來更難。……這并不容易。」

開發(fā)者們同意繼續(xù)調(diào)查對 blob gas 限制和區(qū)塊中 gas 計算進行更改的最佳途徑。開發(fā)者們還同意繼續(xù)討論在 Pectra 中激活 PeerDAS 時是否會伴隨著 blob gas 限制的增加。開發(fā)者們對這些更改是應(yīng)該結(jié)合在一起還是分多個硬分叉進行分階段實施存在分歧。

Jayanthi 表示，結(jié)合這些更改是一個「有風險」的決定，因為開發(fā)者在 PeerDAS 在主網(wǎng)上激活之前不會知道它的具體功能表現(xiàn)。以太坊基金會（EF）DevOps 工程師 Barnabas Busa 補充說，Pectra 硬分叉的范圍已經(jīng)非常大了，不需要再增加額外的代碼更改。Busa 說：「關(guān)鍵是我們已經(jīng)有很多 EIP 了，我覺得我們不斷地添加更多內(nèi)容，這樣永遠不會結(jié)束。所以，我們必須在某個地方畫一條線，這就是我們的終點。我認為在未來一年半的測試時間里，發(fā)布 PeerDAS 并增加 blob 數(shù)量是不可能的。」

一位屏幕名為「Francesco」的開發(fā)者建議，如果網(wǎng)絡(luò)變化不會伴隨 blob 數(shù)量的增加，可以移除 PeerDAS 來「降低 Pectra 的風險」。Francesco 問：「如果沒有增加 blob 數(shù)量，Pectra 的 PeerDAS 到底有什么好處？」

為了進一步說明測試 PeerDAS 的困難，Jayanthi 指出，測試引入 blobs 到以太坊的 EIP 4844 并沒有完全模擬 blobs 在以太坊主網(wǎng)上的實際表現(xiàn)和影響。Jayanthi 說：「問題在于測試網(wǎng)絡(luò)非常困難。我們確實進行了很多與 4844 相關(guān)的出色測試，但 blobs 在主網(wǎng)上的表現(xiàn)與在測試中的表現(xiàn)并不是完全一致。我們確實看到較弱的節(jié)點出現(xiàn)問題。我們確實看到時間上的挑戰(zhàn)等類似情況，這就是為什么即使我們能在開發(fā)網(wǎng)絡(luò)中模擬出 PeerDAS 和增加 blob 數(shù)量都能正常運作的完美情況，但這對主網(wǎng)來說并沒有任何實際意義，這也是我認為我們應(yīng)該一步一步來而不是一次性完成的主要原因。」

EF 研究員 Ansgar Dietrichs 評論說，把增加 blob 數(shù)量和 PeerDAS 關(guān)聯(lián)起來是錯誤的，因為僅僅是 PeerDAS 就已經(jīng)要求開發(fā)者選擇一個 blob 數(shù)量值。雖然開發(fā)者可以選擇與以太坊主網(wǎng)上相同的數(shù)字，但關(guān)于 PeerDAS 應(yīng)該使用什么數(shù)字的決定必須做出。唯一選擇相同數(shù)字的理由是開發(fā)者增加了 PeerDAS 的復(fù)雜性，使其在出現(xiàn)錯誤時能夠回退到當前 Deneb 規(guī)范中的 blob 傳播機制。Dietrichs 補充說，關(guān)于測試復(fù)雜性的擔憂進一步加強了他認為 Pectra 應(yīng)該通過兩個硬分叉激活的觀點，而不是一個，但這并不意味著他認為 PeerDAS 應(yīng)該與 blob 數(shù)量的更改分離。

SSZ 更新

Kissling 分享了三個與 SSZ 相關(guān)的 EIP 的進展更新。他指出，這些 EIP 的實現(xiàn)工作已經(jīng)在多個客戶端上展開，包括 Teku、Grandine 和 Lighthouse。他說，開發(fā)者可以開始討論這些 SSZ EIP 的開發(fā)網(wǎng)絡(luò)時間表，并可能在下一個 ACDC 會議上將它們納入 Pectra 升級的范圍。

F-Star 命名

有一篇在 Ethereum Magicians 上的帖子，討論了 Electra 之后的下一個以太坊共識層（CL）升級名稱。開發(fā)者已經(jīng)為 Prague 之后的執(zhí)行層（EL）升級確定了名稱：大阪（Osaka）。候選的 CL 升級名稱有：Fulu、Felis、Formosa 和 Funi。這些名稱都遵循以「F」開頭的主要恒星命名慣例，適用于 Beacon Chain 的第六次全網(wǎng)升級。Stokes 請在通話中的開發(fā)者在 Magicians 帖子上發(fā)表對此話題的看法。