2024 年 2 月 8 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #127 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。本周，開發者們安排了 Dencun 升級在 2024 年 3 月 13 日激活主網。他們還討論了主網上一個導致 9 個錯過驗證機會的事件的教訓。該事件發生在 2024 年 2 月 6 日星期二，重新引發了關於通過一項名為 enshrined 提案者構建分離（ePBS）的升級來消除驗證器對可信中繼的依賴的討論。此外，開發者們還同意重新考慮 Electra 升級中的 maxEB 和包含列表等代碼變更。

Dencun 測試

以太坊基金會開發者營運工程師 Parithosh Jayanthi 表示，2 月 7 日星期三在 Holesky 測試網上激活 Dencun 升級進展順利。Jayanthi 說：「至少在 Holesky 上我們沒有注意到任何問題。」他補充道：「我們已經通過了 Goerli 的 blob 事務的過期窗口，因此我們運行了一堆節點，正在進行創世同步以及檢查點的同步測試。」

Prysm 開發者 Terence Tsao 提到，在 Holesky 升級期間錯過了分叉過渡塊。雖然這「不是什麼大問題」，但 Tsao 表示，該事件導致了他的節點出現了 11 秒的區塊延遲。他建議客戶端團隊仔細檢查，看看他們的實現是否在升級期間某種方式導致了這種延遲。

Lighthouse 開發者「Sean」表示，Lighthouse 團隊已經在他們的客戶端中實現了與節點恢復相關的邏輯，即當鏈尚未完成 blob 事務時，節點可以通過依賴於一個未完成檢查點的檢查點同步來恢復。然而，Sean 表示，實現這一邏輯比他的團隊預期的要複雜，並鼓勵 CL 客戶端團隊在遇到類似困難時尋求幫助。

Nethermind 開發者 Marcin Sobczak 表示，他的團隊正在繼續調查上周四ACD 電話會議中提到的他們客戶端中的潛在 bug。Sobczak 表示，他的團隊已經開始向 Goerli 網路發送大量的事務，到目前為止，沒有發現任何問題。他說，在 Goerli 上的測試應該在幾個小時內完成。

Dencun 主網激活

以太坊基金會協議支持負責人 Tim Beiko 分享了以下 Dencun 升級的主網激活日期和時間：

Beiko 提到，他已經聯繫了 L2Beat.com 上排名前 10 的以太坊 Rollups 團隊，以評估他們對 Dencun 的準備情況。「所有團隊基本上都處於各種測試階段。我認為，L2 方面的團隊將在 3 月初到中旬左右準備好在主網上使用 4844，」Beiko 說道。「我認為我們不應該基於 L2 團隊的準備情況來阻止任何事情。」

Tsao 表示，從 Prysm 方面來看，他的團隊希望有兩周時間準備 Dencun 升級的最終主網發布版。代表 Lighthouse 客戶端團隊的 Sean 同意這個時間表。其他 CL 客戶端團隊，如 Teku 和 Lodestar，表示他們也可以在兩周內準備好最終的主網客戶端發布版。

基於這種情緒，Beiko 最初建議將主網升級日期定在 3 月 8 日星期四或 3 月 12 日星期二。然而，開發者們在 Zoom 會議聊天中反對了最終客戶端發布和提議的硬分叉日期之間緊張的周轉時間。開發者們同意在最終客戶端軟體版本發布和升級日期之間留出三周的時間。開發者們將在下一次 ACDC 電話會議之前準備好最終的客戶端發布版，即 2024 年 2 月 22 日星期四。然後，Beiko 將於次日，即 2024 年 2 月 23 日星期五，正式發布一篇部落格文章，宣布 Dencun 的主網激活。主網節點營運商將從那時起大約有三周的時間來升級他們的軟體，Dencun 硬分叉將在 2024 年 3 月 13 日發生。

主網錯過區塊事件

在 2024 年 2 月 6 日星期二，Bloxroute Max Profit 中繼向驗證者交付了 9 個未能添加到以太坊區塊鏈上的區塊。這是由於中繼中的一個錯誤導致的，該錯誤未能正確降級提交有問題區塊的區塊生成者。Bloxroute 隨後修補了他們的中繼，並對驗證者因丟失區塊獎勵而進行了補償。

此事件重新激發了關於如何最好減輕驗證者對於包含 MEV 的區塊的依賴性的討論。Prysm 開發者「Potuz」表示，解決問題的一個即時方案可能是向驗證者的斷路器功能添加一個新的啟發式，用於檢查無效區塊，並在中繼連續發送兩個或三個無效區塊時回退到本地區塊生成。以太坊基金會的研究人員 Danny Ryan 和 Dankrad Feist 擔心，這種啟發式的添加可能會被精明的 MEV 參與者輕易利用，他們可能會故意觸發斷路器，以暫時將所有區塊中的 MEV 收入歸自己所有。Lighthouse 的 Sean 指出，啟發式的精確實現可能會因客戶端而異，從而使惡意參與者更難利用，但對此，Ryan 建議這種啟發式仍然可能會有一個大多數客戶端實現遵循的標準。

隨後，Ryan 提出了一個「八卦頻道」（gossip channel）的想法，驗證者可以在其中收聽並提供關於區塊生成者的區塊簽名的資訊，以更快地向整個網路通知有問題的生成者，而無需依賴中繼。然而，Potuz 反對了這個想法，表示開發者應該將資源投入到交付 ePBS 上，這是一個代碼更改，將完全消除對受信任的中繼的需要，並支持區塊生成者和驗證者之間的直接交互。在深入討論是否應該將 ePBS 優先於短期解決方案（如專用八卦頻道用於區塊驗證）之前，Danny Ryan 建議先評估一下已經提出的 Electra 的幾個其他代碼更改。

Electra 提案

簡單提要，Ryan 詢問開發者是否支持將「Pectra」作為 Prague/Electra 的合併升級名稱。電話會議上的開發者似乎對這個合成詞沒有強烈的意見。Ryan 繼續討論了哪些代碼更改應該優先考慮用於 Electra 的問題。

Electra EIP 7549

在ACDC＃126期間，開發者們同意在 Electra 升級中包含 EIP 7549。EIP 7549 是一項僅影響以太坊 CL 的代碼更改，旨在使驗證者證明的聚合更加高效。開發者們已經同意採用 EIP 7549 的最簡設計以包含在 Electra 中。然而，根據 GitHub 上開發者之間對代碼更改的更多討論，有人希望增加代碼更改的複雜性，以便它對網路產生更廣泛的影響。Teku 開發者 Mikhail Kalinin 解釋說：「這是在 EIP 7549 最初提出的基礎上的進一步。正如 Danny 所說，它允許我們在鏈上緊密打包證明。它的好處在於，考慮到當前的驗證者集大小，我們可以將證明的區塊空間增加多達四倍。目前，如果它們理想地聚合，我們可以保留兩個插槽的證明。這個改變將允許我們在不增加字節塊大小的情況下將此數增加到八個插槽。」

Danny Ryan 同意這是對 EIP 的一個很好的改變，但建議仔細權衡它可能給協議帶來的影響。Ryan 表示：「你增加了容量，但你減少了該容量的潛在多樣性，這似乎是一個合理的權衡，但需要考慮風險。」Kalinin 表示同意，並表示他將進一步進行一些分析，並在相同的 EIP 編號下提供新的規範更改。

Electra SSZ

如在ACDC＃126上討論的，開發者們正在考慮包括與 SSZ 格式相關的五個 EIP。來自 Lighthouse 的 Sean 表示，他需要更詳細地評估代碼更改，但從他的角度來看，這些代碼更改「是一個好事」。據報導，另一位開發者在 Zoom 聊天中寫道，他們希望將 SSZ 格式更改作為一個大的更改捆綁到協議中，而不是分階段實施。Ryan 建議客戶端團隊對 Nimbus 開發者 Etan Kissling 提出的 SSZ 更改進行更多盡職調查，並在下一次 ACDC 電話上重新討論這個話題。

Electra ePBS

Prysm 開發者「Potuz」在下一個主要的以太坊升級中提出了 ePBS 的理由。「我認為我們在主網上遇到的問題並不是一個即時問題或一個次要問題。九個區塊消失或驗證者是否被退款並不是問題的關鍵，真正的問題是我們需要信任中繼。我們甚至不知道檢查是什麼。我們甚至不知道修復是什麼。這是封閉源軟體，這個開發是在一個黑盒子裡進行的，」Potuz 說，並補充說：「這些是五個中繼正在轉發我們所有的區塊或 90% 的區塊，以及最多 10 個玩家正在構建這些區塊。我認為我們需要做的是決定這是一個優先事項，我們在以太坊中不應該有一個受信任的玩家使用閉源軟體做出決策，負責支付或不支付，為驗證者退款，甚至決定哪些交易被審查或不被審查。一旦我們把這個當作優先事項，那麼我們就可以討論是否存在 ePBS 的可行設計。」

Potuz 敦促開發者考慮將 Electra fork 推遲到 2025 年，而不是 2024 年，並利用「Interop event」，這很可能是 2024 年 5 月發生的以太坊核心開發者見面會，來完善 ePBS 的最終設計。Tsao 表示，ePBS 只是「解決問題的一種方案。」他強調說，構建器 API 是一項重要的軟體，它與以太坊協議不「保持激勵一致」，需要更新。來自 Lighthouse 的 Sean 鼓勵開發者考慮 ePBS 之外的解決方案，這些解決方案將中繼固定在以太坊協議中，以解決信任中繼的問題。以太坊基金會研究員 Dankrad Feist 表示，在他看來，ePBS 是一個非常重大的變化，不應該倉促進行。他對移除中繼的主要擔憂之一是打開了驗證者竊取構建器 MEV 的可能性。目前，中繼不僅受到驗證者的信任，還受到構建器的信任。構建器信任中繼不會提前運行他們的交易，他們對驗證者也可能沒有同樣程度的信任，沒有協議中的適當防護欄。

Potuz 對 ePBS 是一個大型代碼更改的看法提出了異議，他認為目前的 ePBS 設計與包含列表或 maxEB 的工程變化程度不大。Danny Ryan 插話說：「每當我看到這個話題被提出時，就會有很多關於我們到底在優化什麼的問題。這是一個正確的最終目標是什麼的問題？似乎有很多不同的意見。首先包含這個決定是為了弄清楚設計是什麼。」為此，Ryan 建議進行一次分組討論，討論 ePBS 的設計，並看看開發者是否能就其複雜性和對其他代碼更改的依賴達成一致意見。

ePBS 的分組討論將於美東時間 2 月 13 日上午 9:00（世界時 14:00）舉行。

Electra 包含列表（Inclusion Lists）

接着，開發者討論了EIP 7547，即包含列表。在ACDC＃126期間，開發者並不熱衷將該提案納入 Electra。然而，Ryan 表示自上一次 ACDC 電話會議以來，開發者希望再次討論該提案。以太坊基金會研究員 Mike Neuder 表示已經創建了包含列表的簡化設計。他還指出了一個新文件，詳細介紹了客戶端可能的包含列表規範。Ryan 表示已經審查了這些規範，並同意這並不像他最初想象的那麼複雜。Sean 同意包含列表可能是可以納入 Electra 的，但在他看來，maxEB 是一個更重要的代碼更改。「我認為現在我傾向於嘗試同時包括 maxEB 和包含列表，而不是完整的 ePBS，」Sean 說。他補充說，數據可用性採樣（DAS）可以與這些其他更改並行進行。

與 ePBS 類似，開發者同意在單獨的分組電話會議上更詳細地討論包含列表。包含列表的分組會議將於美東時間 2 月 16 日上午 9:00（協調世界時 14:00）舉行。

Electra peerDAS 和 maxEB

開發者討論的最後兩個可能納入 Electra 的提案是 peerDAS 和 maxEB。在 peerDAS 的話題上，Danny Ryan 表示，許多客戶端團隊表示他們打算在 Electra 升級的同時並行進行這個代碼更改。由於 peerDAS 並不嚴格要求硬分叉，因此可以獨立於 Pectra 升級進行部署。在沒有硬分叉升級的情況下，peerDAS 不會導致 blob 事務的最大數量增加，即每個塊的 blob 事務的最大數量。然而，Ryan 提到，一旦 peerDAS 準備就緒，就可以安排一個只更改 blob 事務最大數量的小型硬分叉。因此，Ryan 建議開發者同時進行 peerDAS 和 Electra 的工作。然而，Sean 表示，他認為 peerDAS 準備實施的速度可能比 Electra 升級更快，並希望最遲在 Electra 分叉時實施。對此，Ryan 隨後建議在 Electra 升級中暫時包含 peerDAS，並在該代碼更改最終成為 Electra 分叉中其他項目的阻礙時將其移除。開發者未能就此提案達成一致意見。Ryan 建議在 ePBS 和包含列表分組電話會議結束後重新討論這個問題。對於在 Electra 中包含 maxEB 的討論，Ryan 也建議同樣做法。開發者同意在兩周後的下一次 ACDC 電話會議上重新討論這些問題。

原文連結