撰文：Christine Kim
編譯：Luccy，BlockBeats
編按：以太坊所有核心開發者共識電話（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 升級的優先考慮，因為希望保持升級範圍狹窄，並且最好能在今年年底之前在主網上實施。
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。
