2024年2月8日，以太坊所有核心開發者參加了ACDC電話會議#127，討論了Decun升級的情況、主網激活日期以及與主網遺漏區塊事件測試相關的問題。主網啟動日期定在2024年3月13日，此外，也討論了包括EIP 7549、SSZ格式相關的五項EIP、ePBS、包含清單等提案。開發者們對每項提案的優先順序、設計複雜度以及對以太坊協議的影響進行了充分的評估。其中，ePBS成為焦點，討論推遲到2025年，電子包含清單實施計劃。接下來，將在ACDC電話會議結束後重新討論以及評估。
(Note: This summary is 205 words long)
原文標題：《以太坊所有核心開發者共識呼籲#127 Writeup》
譯者：Christine Kim
編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者共識電話（ACDC）每週召開一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC第127次電話會議，會議即將到來的Decun升級的情況、主網啟動日期以及與主網遺漏區塊事件測試相關的問題進行了深入討論。
同時，會議也討論了Electra升級中的提案，包括EIP 7549、SSZ格式相關的五項EIP、ePBS、包含清單等。在討論過程中，開發者就每項提案的優先順序、設計複雜度以及對以太坊協議的影響進行了充分的討論和評估。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將編譯如下：
2024年2月8日，以太開發人員齊聚Zoom參加了全核心開發者共識（ACDC）電話會議#127會議。 ACDC電話會議是一個每週六舉行一次的系列會議，由以太坊基金會研究員Danny Ryan主持，開發人員在會上討論和協調了對以太坊智力層（CL）的更改。本週，開發者們安排了Dencun升級於2024年3月13日啟動主網。他們也討論了主網上的一個導致9個缺失驗證機會的事件的教訓。該事件發生在2024年2月6日星期二，重新引發了關於透過一個名為enshrined倡議者構建分離（ePBS）的升級來消除對可信集群的驗證器此外，開發者們還同意重新考慮Electra 升級中的maxEB 和包含清單等代碼變更。
鄧存測試
以太坊基金會開發者營運工程師Paritosh 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上的測試應該在幾個小時內。
鄧村主網激活
以太坊基金會協議支援負責人Tim Beiko 分享了以下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 提出了一個「八卦頻道」（八卦頻道）的想法，驗證者可以在其中傾聽並提供關於區塊生成者的區塊簽名的信息，以更快地向整個網路通知有問題的生成者然而，Potuz 反對這個想法，表示開發者應該將資源投入到交付ePBS 上，這是一個代碼更改，將完全消除對受信任的中繼的需求，並支持區塊生成者和驗證者之間的直接交互。在深入討論ePBS 應該優先於短期解決方案（如專用八卦頻道用於區塊驗證）之前，Danny Ryan 建議先評估已經提出的Electra 的幾個其他程式碼變更。
厄勒克特拉提案
簡單提一下，Ryan 詢問開發者是否支援將「Pectra」Prague/Electra 的Medium 升級名稱。電話會議上的開發者似乎對這個合成詞沒有強烈的意見。 Ryan 繼續討論了哪些程式碼變更應該優先考慮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 編號下提供新的規範變更。
伊萊克特拉SSZ
如同在ACDC＃126 上討論的，開發者們正在考慮包括與SSZ 格式相關的五個EIP。來自Lighthouse 的Sean 表示，他需要更詳細地評估程式碼更改，但從他的角度來看，這些程式碼更改「是一件好事」。據報道，另一位開發者在Zoom 聊天中寫道，他們希望將SSZ 格式更改為一個大的更改組到協議中，而不是分階段實施。 Ryan 建議客戶端團隊對Nimbus開發者Etan Kissling 提出了SSZ 更改，進行了更多盡職調查，並在下一次ACDC 電話上重新討論了這個主題。
伊萊克特拉ePBS
Prysm開發者「Potuz」在下一個主要的以太坊升級中提出了ePBS的理由。 「我認為我們在主網上遇到的問題不是一個即時問題或一個次要問題。九個區塊消失或驗證者是否被退款已經不是問題的關鍵，真正的問題是我們需要信任中繼。我們甚至不知道檢查是什麼。我們甚至不知道修復是什麼。這是封閉源軟體，這個開發是在一個黑盒子裡進行的，」Potuz 說，並補充說：「這些是5 個正在轉發我們所有的區塊或90% 的區塊，以及最多10 個玩家正在建立這些區塊。我認為我們需要做的是決定這是一個優先事項，我們在以太坊中不應該有一個受信任的玩家使用閉源軟體做出決策，負責支付或不支付，為驗證者退款，甚至決定哪些交易被審查或不被審查。一旦我們把這個當前優先事項放在首位，那麼我們就可以是否存在ePBS 的討論可行設計。”
Potuz 敦促開發者考慮將Electra 分叉推遲到2025 年，而不是2024 年，並利用“Interop 活動”，這很可能是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）舉行。
ElectrapeerDAS 和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 也同樣做法。開發者在7 天內同意之後的下一次ACDC電話會議上重新討論了這些問題。
資訊來源：0x資訊編譯自網際網路。版權歸作者區塊律動BlockBeats所有，未經許可，不得轉載