原文標題：《Ethereum All Core Developers Consensus Call #127 Writeup》
原文作者：Christine Kim
原文編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第127 次電話會議，會議就即將到來的Dencun 升級的測試情況、主網激活日期以及與主網遺漏區塊事件相關的問題進行了深入討論。
同時，會議也探討了Electra 升級中的多項提案，包括EIP 7549、SSZ 格式相關的五項EIP、ePBS、包含清單等。在討論過程中，開發者就每項提案的優先順序、設計複雜度以及對以太坊協議的影響進行了充分的討論和評估。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
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 升級的主網啟動日期和時間：
Dencun 主網分叉時間的截圖：
標題：Dencun 硬分叉時間
來源：YouTube，@EthereumProtocol
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 電話會議上重新討論這些問題。
