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