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 升級的優先考慮，因為希望保持升級範圍狹窄，並且最好能在今年年底之前在主網上實施。

Deneb 升級最新消息

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

Electra 討論

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

EIP 6110: 鏈上供應驗證者存款

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: 重用驗證者索引

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

EIP 7002: 執行層可觸發退出

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

EIP 7251: 增加最大有效質押

接下來，以太坊基金會研究員邁克·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: 包含列表

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。

EIP 7549: 將委員會索引移出證明

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

EIP 7594: 對等數據可用性抽樣 (PeerDAS)

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 會議。

SSZ 相關的 EIP

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

· EIP-6404: SSZ 交易 Root

· EIP-6465: SSZ 提款 Root

· EIP-6466: SSZ 收據 Root

· EIP-6493: SSZ 交易簽名方案

· EIP-7495: SSZ 穩定容器

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

變更權益獎勵

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

原文連結