以太坊核心開發者最新會議摘要：Deneb升級進度及下一個升級Electra優先考慮的EIP

編者按：以太坊所有核心開發者共識電話（ACDC）每兩周舉行一次，主要討論和協調對以太坊共識層（CL）的更改。本次為 ACDC 第 126 次電話會議，會議還涵蓋了對以太坊權益獎勵曲線變更的討論，以及對硬分叉升級中可能引入的其他變更的展望。

在會上，開發者們討論了即將到來的以太坊 Electra 升級的相關議題，包括已確認納入 Electra 的 EIP 和一些備選 EIP 的討論。此外，會議還討論了有關 Deneb 升級的更新，包括 Deneb 在 Sepolia 和 Holesky 兩個測試網絡上的激活計劃。在會議的後半部分，開發者們還就 Electra 升級後的 Prague 升級進行了討論。

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

2024 年 1 月 23 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #126 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。本周，開發者們討論了在 Electra 升級中應該優先考慮哪些代碼更改。

以下是確認納入 Electra 升級的以太坊改進提案（EIP）：

EIP 6110，鏈上供應驗證者存款EIP 7002，執行層觸發退出EIP 7549，將委員會索引移出證明

由於時間有限，開發者們同意在下一次 ACDC 會議上繼續討論 EIP 7251（增加 MAX_EFFECTIVE_BALANCE）、EIP 7594（對等數據可用性采樣）以及與 SSZ 相關的 EIP。他們還同意不將 EIP 6914（重用驗證者索引）和 EIP 7547（包含列表）列為 Electra 升級的優先考慮，因為希望保持升級范圍狹窄，並且最好能在今年年底之前在主網上實施。

Danny Ryan 簡要介紹了 Deneb 升級的最新情況。在 2024 年 1 月 24 日星期三，以太坊基金會發佈了一篇博客，詳細列出了在 Sepolia 和 Holesky 上進行的 Deneb 升級的所有最新客戶端發佈。這兩個測試網絡將是 Deneb 升級在以太坊主網激活之前的最後兩個測試網。Sepolia 計劃於 1 月 30 日激活 Deneb，而 Holesky 則將於一周後的 2 月 7 日激活。

通話的剩餘時間用來討論 Deneb 之後被稱為 Prague/Electra 的下一個升級的候選 EIP。Prague 是以太坊執行層（EL）升級的名稱，而 Electra 是共識層（CL）升級的名稱。上周，開發人員審查了主要影響 EL 協議的 Prague 提案。而本周，開發人員則審查了主要影響 CL 協議的 Electra 提案。

Teku 開發者 Mikhail Kalinin 因介紹了EIP 6110，該提案將驗證者的存款追加到 EL 塊上。進行這項代碼更改的動機是為了減少客戶端軟件設計的復雜性，提升驗證者的用戶體驗。Danny Ryan 稱該 EIP 為以太坊的「一項主要安全改進」。以太坊基金會的協議支持主管、ACDC 會議主席 Tim Beiko 補充說，該 EIP 是在 Prague/Electra 升級中，EL 客戶端團隊已經表示支持的兩個 CL 關註的 EIP 之一。與為 Electra 提出的其他一些以 CL 為重點的 EIP 一樣，EIP 6110 需要對 EL 進行協議級別的更改。考慮到 CL 和 EL 客戶端團隊對 EIP 6110 的支持，開發人員同意在 Prague/Electra 中包含這項代碼更改。

EIP 6914 將使得完全退出的驗證者的索引號能夠重新分配給新進入的驗證者。這樣做的動機是為了防止驗證者索引隨時間不受限制地增長。Lighthouse 開發者「Dapplion」提出了這個 EIP，但指出盡管這項代碼更改對於以太坊的長期健康至關重要，但在 Electra 中無需對其進行優先處理。開發人員一致同意在 Electra 中不將 EIP 6914 列為優先考慮。

Danny Ryan 分享了 EIP 7002 的背景。「有兩個 [驗證者] 密鑰。有活躍密鑰和提取憑證。活躍密鑰管理質押。提取憑證最終擁有資金。自零階段以來，這種關系可能存在一個缺陷，即隻有活躍憑證能夠觸發退出。因此，如果活躍密鑰丟失，或者如果擁有活躍密鑰和擁有提取憑證的關系更為動態，就可能出現相當惡劣的情況和結果。」Ryan 詳細解釋說，這個 EIP 的主要好處之一是在以太坊上實現更多無需信任的質押池設計。作為 EL 客戶端團隊表示支持的另一個以 CL 為重點的 EIP，CL 客戶端團隊渴望在 Electra 中包含 EIP 7002。與 EIP 6110 一樣，7002 將需要對 EL 進行輕微的更改。Ryan 指出，該 EIP 的實施正在從有狀態的預編譯更改為 EVM 字節碼。他呼籲 EVM 字節碼專傢密切關註實施情況，並在由 Geth 開發者「Lightclient」起草後提供幫助進行審查。

接下來，以太坊基金會研究員邁克·Neuder 介紹了 EIP 7251，該提案將驗證者的最大有效質押從 32 ETH 增加到 2048 ETH。想了解為什麼需要進行這項代碼更改的背景，請閱讀有關驗證者集大小增長問題的 Galaxy Research Report。Neuder 指出，由於其復雜性以及對其他代碼更改（如 EIP 7002）的依賴性，這項代碼更改比其他提案「更有爭議」。Lighthouse 開發者「Sean」表示支持該提案，但鑒於其復雜性，建議考慮在多個硬分叉中實施這些更改，而不是一次性升級。Neuder 對這個想法表示支持。Lodestar 開發者 Gajinder Singh 不贊成將 EIP 7251 的實施分開到多個分叉中，擔心這會在長期內給開發人員帶來更多麻煩。

EIP 7002 中最大的復雜性之一是協議內的質押合並功能，該功能將使現有的驗證者節點運營商能夠在最小化收益損失的情況下合並來自多個驗證者的質押。根據 Neuder 及其同事提出的設計，驗證者節點運營商隻會在 256 個紀元（約 27 小時）的一段時間內失去獎勵。Neuder 表示，他和同事已經就 EIP 7002 的設計咨詢了 Lido、Coinbase 和 Figment 等主要質押服務提供商，並獲得了他們對這一代碼更改的支持。

代表 Prysm 團隊的開發者 Terence Tsao 表示，他們不贊成在 Electra 中包含 EIP 7002，因為 EL 客戶端團隊希望在年底之前執行 Prague/Electra 升級。Tsao 說：「我們認為這個 EIP 的復雜性太大，無法適應即將在十月或十一月到來的小型分叉。」關於 Prysm 團隊對應該包含在 Electra 中的 EIP 的全面觀點，可以在這篇博客文章中閱讀。Prysm 開發者「Potuz」補充說，在他看來，沒有能夠顯著減少 EIP 7002 復雜性的「迷你版本」，以便仍然將其納入 Electra。關於 EIP 7002，Potuz 表示：「我不明白這如何在 2024 年的任何形式下實施。」

然而，Potuz 也補充說，如果開發人員願意將 Electra 的實施范圍延遲到 2025 年，那麼 Prysm 團隊將提供升級的不同優先級，並推動包含許多其他代碼更改，包括 EIP 7002，以及與正式提案生成器分離和數據可用性抽樣相關的 EIP。他說：「我們非常保守，因為我們知道我們從未在一年內分叉過兩次，尤其是在 CL 中，如果我們的范圍是在今年，嘗試放入這麼多 EIP 是不現實的。」鑒於在 Electra 中包含此代碼更改遇到的阻力，Ryan 建議繼續討論 Electra 的其他提案 EIP，並在另一次電話會議上再次討論 EIP 7002。

EIP 7547 創建了一種機制，通過該機制驗證者可以強制在一個區塊中包含某些交易。其主要動機是提高以太坊的審查抗性。與其他幾位開發人員一起起草了該提案的 Neuder 解釋說，以太坊上已經有 67% 的區塊生成者在審查交易，超過 90% 的驗證者接收來自第三方生成者的區塊。在以太坊上有明顯需要增強審查抗性。然而，Neuder 指出，在強制交易包含列表的實施方面存在一些開放的設計問題，主要涉及到需要滿足的確切條件。

Tsao 插話稱，Prysm 團隊過去幾個月一直在實施 EIP 7547，並進行了正式提案生成器分離。然而，由於 EIP 7547 的復雜性，他不認為這個代碼更改是 Electra 的合適候選項。Sean 和 Potuz 都對 EIP 的復雜性表示擔憂。Singh 建議客戶團隊改為全面實施構建器覆蓋標志功能，這是一種機制，如果在 EL 上檢測到審查活動，將導致驗證者回歸到本地區塊生產。

由於開發人員對此代碼更改的反對，Ryan 建議不將其列為 Electra 升級的優先事項。Potuz 再次強調，如果開發人員能夠改變對分叉范圍和主網激活時間的期望，Prysm 團隊將支持在 Electra 中包含 EIP 7547。

接著，Dapplion 分享了 EIP 7549，這是一項僅影響 CL 的代碼更改。這一代碼更改將使共識投票的聚合更為高效，可通過多種方式實施，從低到高復雜度不等。以太坊基金會研究員 Dankrad Feist 支持選擇實施 EIP 7549 的最簡單方式，即在 CL 客戶端中簡單地將「AttestationData」中的「index」字段的數值設為零。Danny Ryan 也支持這一策略。開發人員同意以最簡單的形式將 EIP 7549 納入 Electra。

Ryan 介紹了 EIP 7594，這是一個旨在將 EIP 4844 的目標 blob 數量擴展到每個區塊的 3 個 blob 之外的提案。開發人員擴展以太坊數據可用性的方式是通過啟用節點對 blob 數據進行抽樣，而不是下載完整的 blob。盡管 EIP 7594 的設計並不復雜，但其在網絡層的實施將需要客戶團隊投入大量的努力和測試。Tsao 詢問 EIP 是否將與目標 blob 數量的增加相結合，如果不是，EIP 是否需要共識級別的更改來實施。Ryan 確認，在其當前形式下，EIP 7594 不需要任何共識更改，可以獨立於硬分叉升級之外實施。然而，他表示，EIP 7594 是否應與 blob 數量的增加相配對是一個尚未確定的問題，後者將需要共識更改進行更新。

Feist 插話評論了在激活 Deneb 後來自 Layer 2 協議的 blob 需求。Feist 說：「[需求] 目前大約是每個區塊一個 blob，但在過去一年裡增長了 10 倍。」他補充說：「這很快就會變得緊迫，因為我們將很快進入 rollups 也會質疑為什麼我們根本不使用 4844，如果它比調用數據還要便宜的領域。我認為 [對 blob 的需求] 是我對此最小的擔憂。我認為在 4844 之後，這將變得非常明顯。」有關 EIP 4844 和 Deneb 升級的背景，請閱讀這份 Galaxy Research 報告。

Dapplion 贊成在 Electra 中優先考慮 EIP 7594，表示：「我認為每個 EIP 都有其優點，但從時間和產出的角度來看，擴展仍然是最好的投資。回報率非常明顯。因此，將其列為首要任務似乎是非常不明智的。」Lighthouse 開發人員 Pawan Dhananjay 要求了解 PeerDAS 在驗證大量 blob 數據方面的效率以及實施所需的密碼庫的狀態。Feist 表示他將回頭提供有關這些主題的更多信息。Potuz 再次表達了對 Electra 升級范圍的擔憂，以及如果包括 EIP 7594，則升級可能會變得過大，無法在年底之前在主網上激活目標。Potuz 說：「我們的印象是…我們打算通過在 2024 年范圍內對 [Electra] 進行優先處理，來優先考慮在 2025 年優先考慮 Verkle。我不明白我們如何能夠並行進行這個和 Verkle，並在今年發佈類似這樣的東西。這就是為什麼如果我們將其范圍定在今年，我們就不支持這個小型分叉的原因。」

以太坊基金會 DevOps 工程師 Parithosh Jayanthi 回應了關於與 Verkle 並行測試 PeerDAS 的擔憂。Jayanthi 表示，他的團隊正在研究一種通過隔離的影子分叉可靠測試 Verkle 的方法，EL 客戶端可以在沒有 DevOps 團隊支持的情況下獨立啟動。如果這個功能能夠實現，那麼在 EL 團隊致力於 Verkle 升級的同時，DevOps 團隊將有更多帶寬來幫助優先考慮在此期間測試 PeerDAS。Ryan 建議將 PeerDAS 作為 Electra 中的有條件的 EIP，並由 CL 客戶端團隊與其他 Electra EIP 一起進行工作，有權在延遲測試的情況下將其排除在升級之外。開發人員同意為了節省時間，推遲對 PeerDAS 的討論，將其留待下一次 ACDC 會議。

最後，Nimbus 開發者 Etan Kissling 正領導努力將以太坊的序列化方案從 RLP 更新為 SSZ，並介紹了與 SSZ 格式相關的五個 EIP。這些與 SSZ 相關的 EIP 將有助於減小交易包含證明的大小，減少由於 EL 和 CL 之間序列化格式差異而產生的協議復雜性，並在 EL 塊頭中使用的數據字段中引入更大的準確性。Kissling 提出的 EIP 包括：

EIP-6404: SSZ 交易 RootEIP-6465: SSZ 提款 RootEIP-6466: SSZ 收據 RootEIP-6493: SSZ 交易簽名方案EIP-7495: SSZ 穩定容器

這些 EIP 中的每一個都需要對 EL 進行後續更改。因此，Ryan 建議征求 EL 客戶端團隊關於是否願意在 Prague/Electra 升級中包含這些更改的反饋。由於通話時間有限，Ryan 還建議在下一次 ACDC 通話中更詳細地討論這些 EIP。

以太坊基金會研究員 Ansgar Dietrichs 提出了他在以太坊基金會同事 Anders Elowsson 關於更改權益獎勵曲線的研究帖子。根據 Elowsson 的研究，減少獎勵可能是可行的，以減少以太坊的通貨膨脹並降低驗證器集大小增長的速度。Ryan 鼓勵開發人員審查 Elowsson 的研究，並在此基礎上考慮在 Electra 或之後的不同硬分叉升級中包含的任何潛在行動項目或 EIP。