原文標題：《Ethereum All Core Developers Consensus Call #124 Writeup》
原文作者：Christine Kim
原文編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第124 次電話會議，會議主要涵蓋了Devnet #12 的更新、Cancun/Deneb 升級的進展結果以及與Slashable 資訊傳播相關議題。在會議中，開發者們積極討論了Libp2p 網路協定的微小更改，以減少大消息對節點的放大效應。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
2023 年12 月14 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Consensus (ACDC) call #124 會議。 ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員Danny Ryan 主持，開發人員在會議上討論和協調對以太坊共識層（CL）的更改。本週，開發者們聚焦討論Devnet #12 測試網路上對Cancun/Deneb 升級的測試進度。自從上週的全核心開發者執行（ACDE）會議以來，所有執行層（EL）和共識層（CL）用戶端組合都已接取Devnet #12，其中包含Prysm 用戶端。已啟用MEV-Boost 軟體，但不包含具有Prysm 的用戶端組合。開發者表示他們正按計劃進行，計劃在接下來的一到兩週內啟動Goerli 陰影分支，以測試Cancun/Deneb 升級，並包括所有客戶端。此外，開發者也討論了Slashable 訊息傳播的規則，以及接下來兩週的通話行程。
Devnet #12 更新
以太坊基金會的DevOps 工程師Barnabas Busa 表示，所有EL/CL 用戶端組合，包括那些使用Prysm 作為CL 用戶端的組合，都已成功接入Devnet #12。使用Prysm 的客戶端組合尚未進行MEV-Boost 軟體測試。然而，在Devnet #12 上，MEV 工作流程正在測試其他CL 用戶端。最近，Lighthouse 用戶端已進行補丁更新，以解決與MEV 相關的錯誤。此外，基金會的另一位DevOps 工程師Parithosh Jayanthi 表示，他們注意到在Devnet #12 上的Besu 節點存在問題，他們仍在努力確定其根本原因。作為下一步，開發者將故意透過網路發送惡意區塊，測試區塊生成器，並為新添加的Prysm 用戶端執行hive 測試，對Devnet 上的用戶端組合進行壓力測試。 Jayanthi 在通話期間在公開的Discord 訊息中表示，開發者們仍然計劃在年底前在Goerli 測試網路上啟動陰影分支。
Slashable 資訊更新
接著，開發者們簡要討論了與Cancun/Deneb 升級後在以太坊上Slashable 訊息的傳播和時機有關的幾個問題。作為背景，Slashable 資訊包括重複或無效區塊和blob 的傳播。 Lodestar 用戶端的匿名開發者Dapplion 透過GitHub 提出了一個拉取請求（PR），旨在向Beacon Chain API 添加新事件，使節點操作員能夠更快地了解Slashable 事件，尤其是在存在大量Slashable 資訊的情況下，這將特別有用。 Dapplion 在他的PR 中提到：「對於大型操作者而言，切割事件的總成本在很大程度上取決於他們的回應時間。如果有許多金鑰涉及操作錯誤，那麼這些Slashable 資訊可能需要一些時間才能包含在鏈上。」Dapplion 的PR 在通話之前已經被合併到Beacon Chain API 的規範中，並正由各個CL 用戶端團隊實施，例如Prysm 和Lighthouse。
Dapplion 也提出了一個與測量區塊傳播時間有關的PR。他指出，由於Cancun/Deneb 升級和blob 交易的引入，測量區塊傳播時間將變得更加困難。 Dapplion 在他的PR 中詳細說明了他提出的解決方案。正如在PR 主題線程中開發者所注意到的那樣，他們傾向於透過在現有相關的Beacon Chain API 事件中添加時間戳字段來解決這個問題。
開發者討論的第三個與Cancun/Deneb 升級後Slashable 訊息傳播有關的主題是blob 的傳播條件。 Lighthouse 開發者「sean」（或GitHub 上的「realbigsean」）指出，現有的blob 傳播規則導致了意外的後果。 Sean 在通話中表示：「如果您使用Beacon API 進行廣播驗證，那麼以gossip 的方式可能導致訊息的有效和無效是出乎意料的。原因在於，從技術上講，可以傳播兩個具有與其相關的Slashable 頭部的不同blob 索引的blob。您被允許傳播這些，但不被允許傳播那些具有相同blob 索引的。」
Sean 補充說，當涉及到blob 的Slashable 訊息傳播時的奇怪行為對網路的健康沒有實質性的影響，除了對節點操作員來說只是一個「奇怪」的結果需要理解和解析。因此，雖然對於Cancun/Deneb 的啟動來說並不緊急，但他建議開發者在未來的升級中考慮對處理Slashable 資訊傳播規則的規定進行修改。 Danny Ryan 同意這種看法，表示開發者應該花時間「全面」考慮解決這個問題的方法。 Ryan 建議在一月重新討論這個主題，讓開發者有時間設計一個全面的計畫來更新Slashable 的blob 和區塊傳播規則。
接下來，開發者們討論了對libp2p 網路協定的微小更改，以減少對節點發送大消息（例如具有大量blob 的區塊）的放大效應。 Sean 強調了新增的「IDONTWANT」控制訊息，可以用於通知libp2p 對等節點暫停發送大訊息。 Ryan 表示他將嘗試聯繫libp2p 團隊來合併這個PR，如果有進一步的延遲，將在下週的ACDE 電話會議中重新討論這個問題。
