以太坊ACDC會議#132紀要：Electra Devnet 0準備與其他技術議題

原文標題：《Ethereum All Core Developers Consensus Call #132 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編者按：

以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論和協調對以太坊共識層（CL）的更改。本次爲 ACDC 第 132 次電話會議，會議上，開發人員分享了關於第一個 Pectra 開發人員測試網絡（Pectra Devnet 0）的最新信息，討論了有關規範的開放性問題，並強調了與網絡發佈和數據可用性採樣相關的研究項目。其中涉及到的問題包括 Electra 開放性問題、與 Electra 相關的懸而未決的問題、以及研究開放性問題。

在 Electra 開放性問題方面，開發人員關注於 EIP 7251 和 EIP 7549 的影響，以及添加一個新的 EIP，該 EIP 將創建通用 EL 請求的建議。對於與 Electra 相關的懸而未決的問題，討論包括驗證者委員會索引類型的變化、驗證者存款數據處理的改變等。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2024 年 3 月 21 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #132 會議。ACDC 電話會議是一個每兩週舉行一次的系列會議，周的電話會議由以太坊基金會研究員 Alex Stokes 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。本週，開發人員分享了他們爲第一個 Pectra 開發人員測試網絡（也稱爲 Pectra Devnet 0）做準備的最新信息。他們討論了有關 Pectra Devnet 0 規範的開放性問題，並簡要強調了與網絡發佈和數據可用性採樣相關的兩個未完成的研究項目。

Electra 開放性問題

以太坊基金會 開發人員已經發布了 Pectra Devnet 0 的初始 CL 規範和測試向量。但是，關於這些規範有幾個懸而未決的問題，這些問題可能會在第一次 devnet 啓動時及時解決，也可能不會及時解決。Stokes 強調，其中一個問題與 EIP 7251（增加 MAX_EFFECTIVE_BALANCE）有關。開發人員似乎傾向於將驗證者質押的 ETH 合併作爲執行層（EL）可觸發操作。但是，就目前而言，合併在初始 Electra 規範中被定義爲 CL 操作。「這很好，因爲無論來源如何，信標鏈所需的大多數處理邏輯都是相同的，」Stokes 說。

開發人員在電話會議上討論的另一個懸而未決的問題與 EIP 7549（在證明之外移動委員會索引）有關。EIP 改變了驗證者證明的聚合方式和塊格式化的方式。當 Pectra 被激活時，將彙總升級前的證明不再與鏈上提交的新證明兼容。Stokes 在電話會議前的GitHub 問題中強調了兩種可能的解決方案。他寫道：

· 客戶端在上一個 Deneb 時代廣播這兩種格式，注意不要產生可斜切的消息。

· 爲前 Electra 證明擴展具有額外字段的塊，並在 Electra 的第一個紀元期間只允許 Deneb 風格。

Deneb 是在以太坊上激活的最新硬分叉的組合升級名稱。Electra 是以太坊上下一個立即硬分叉的 CL 升級名稱。

開發人員在電話會議上討論了這兩個選項。最終，他們決定暫時不更改 Electra 規範，而是看看這些丟失的證明如何影響 devnet 上的網絡安全。

開發人員在與 Electra 相關的電話會議上討論的第三個懸而未決的問題是，在升級中添加一個新的 EIP，該 EIP 將創建通用 EL 請求。Geth 開發者「Lightclient」提出的 EIP 將簡化更新消息從 EL 發送到 CL 的過程。由於基於智能合約的質押解決方案的興起，在以太坊上激活的 EIP 大量湧入，併爲 Pectra 提議直接從 EL 而不是 CL 觸發各種驗證器操作。Lightclient 的提議創建了一個通用框架，用於將「合約觸發的請求」從 EL 傳播到 CL。鑑於此 EIP 將改變 Pectra 的設計方式，特別是 EIP 6110 和 EIP 7002 的實施，Lightclient 強調，他希望客戶團隊儘快就他的提案提供反饋。開發人員同意在本週末之前嘗試並最終確定 Lightclient 的 EIP，以便在 4 月 22 日星期一之前構建和共享其規範。

然後，開發人員討論了 Teku 開發人員 Mikhail Kalinin 提出的與 EIP 7549 和 EIP 7251 相關的另外兩個懸而未決的問題。第一個是關於驗證者委員會索引類型的變化，而後者則提出了對驗證者存款數據處理的改變。Stokes 鼓勵開發人員更詳細地審查這兩個提案，以便在未來幾周內進一步討論。

最後，開發人員討論的與 Electra 規範相關的最後一個懸而未決的問題是blob 計數的增加。以太坊基金會 開發人員運營工程師 Parithosh Jayanthi 表示，他希望對 Dencun 升級後的 blob 活動進行分析，並根據此分析建議一次性增加 blob 計數，以包含在 Electra 升級中。以太坊基金會 研究員 Ansgar Dietrichs 強調，他還提出了一項建議，即激活逐步增加 blob 計數，這應該與 Jayanthi 提出的納入 Electra 的提議同時考慮。

研究開放性問題

在本週的 ACD 電話會議上，開發人員簡要討論了兩個研究項目。第一個是以太坊基金會研究員 Anders Elowsson 的一篇新研究文章，它提出了一種思考和實施以太坊發行政策變化的新模型。完整的帖子可以在這裏閱讀。Stokes 在電話會議上鼓勵開發人員查看該帖子。

Lighthouse 開發人員 Adrian Manning 提出的第二個研究項目與證明子網有關。正如 Manning 在GitHub上所說，「這個 PR 引入了’網絡分片’的概念，它只是一個抽象的概念，將節點 ID 標記爲一個數字（網絡分片）。然後，我們可以使用這個網絡分片（數字）來分配節點必須長期訂閱的主題。Manning 正在尋求對他的提案的最終意見，以便他的團隊可以開始研究以太坊的數據可用性採樣解決方案 PeerDAS。有關數據可用性採樣的信息，請閱讀此Galaxy Research 報告。

Nethermind 開發人員 Lukasz Rozmej 詢問 EIP 7547（包含列表）是否已獲准包含在 Electra 升級中。開發人員重申，EIP 7547 尚未被批准納入。

Saulius Grigaitis 是一位構建名爲「Grandine」的以太坊 CL 客戶端的開發人員，考慮到正在進行的 PeerDAS 研究，他對以太坊的分叉選擇規則提出了疑問。Grigaitis 要求開發人員在 PeerDAS 工作組中加入想法。