以太坊核心開發者最新會議摘要:將在年底前進行Goerli影子分叉,並測試Cancun/Deneb升級

原文標題:《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 電話會議中重新討論這個問題。

Total
0
Shares
Related Posts