以太坊核心開發者最新會議摘要：Blob Sidecar網路更新、解決EL客戶端多樣性問題

閱讀本文需 10 分鐘

11月16日，以太坊所有核心開發人員參加了第122次All Core Developers Consensus (ACDC) 電話會議。

原文標題：《Ethereum All Core Developers Consensus Call #122 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

< br>

編按：

以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論和協調對以太坊共識層（CL）的變更。本次為 ACDC 第 122 次電話會議，會中指出多數 CL 用戶端團隊計劃在近期完成對 Deneb 規範的更新實現，並討論了新的開發網絡的啟動計劃。此外，開發者們專注於改進 blob 傳播條件，以簡化相關複雜性，並在 RPC 請求中檢索缺失區塊和 blob 的條件上進行討論。

另一方面，會議提到 Geth 開發者 Szilágyi 提出了解決執行層（EL）上的客戶端多樣性問題的提案。該提案旨在透過交叉驗證解決客戶端錯誤，產生了有關構建無狀態以太坊客戶端和區塊生成過程的深入討論。討論中涉及了 EL 用戶端團隊的不同立場，以及提案可能對網路健康和使用者動機的影響。問題的複雜性要求進一步研究和原型設計，而此提案將由 Geth 和其他 EL 用戶端團隊深入研究。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2023 年11 月16 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Consensus (ACDC) call #122 會議。 ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會議上討論和協調對以太坊共識層（CL）的更改。本週，開發者們聚焦在 Cancun/Deneb 升級的 CL 改進進度。

大多數 CL 用戶端團隊表示，它們的目標是在本週或下週完成對 Deneb 規範的更新實現。開發者同意在下週四的所有核心開發者執行（ACDE）電話會議上開始討論啟動 Devnet #12。然後，開發者們詳細討論了 Geth 開發者 Péter Szilágyi 提出的解決執行層（EL）上有關客戶端多樣性問題的提案。

Blob Sidecar 網路更新

如ACDC＃121所討論的，CL 用戶端團隊正在對blob 傳播條件進行改進，以顯著減少與過去11 個開發網路觀察到的blob 傳播相關的複雜性和問題。以下是各個 CL 用戶端團隊自上一次 ACDC 以來的進度更新：

Lighthouse：開發基本完成。需要到下週末進行新程式碼的審查和測試。

Teku：實施了新的傳播驗證。正在進行建置工作流程的開發。

Lodestar：計劃在本週末完成實施。

Prysm：計劃在下週末完成實施。之後需要另一個星期來整理建置工作流程。

基於 CL 用戶端的更新，Ryan 建議在下次 ACD 電話會議期間規劃啟動 Devnet #12。以太坊基金會（EF）的 DevOps 工程師 Barnabas Busa 表示，下一個 Cancun/Deneb 開發網絡的「合理」目標啟動日期可能是 11 月 29 日或 30 日。 EF 的另一位 DevOps 工程師 Parithosh Jayanthi 詢問了有關 hive 測試的最新情況。 EF 測試團隊的 Mario Vega 確認，升級的基本 hive 測試已經準備就緒。他的團隊將在接下來的幾週內為 hive 測試套件添加用於建置和「blobber」工作流程的新測試案例。

接著，Teku 開發者Enrico Del Fante 提出了一個問題，關於CL 用戶端在Cancun/Deneb 後使用「byRoot」RPC 請求檢索缺少的區塊和blob 的適當條件是什麼，Del Fante 關於這些問題做出詳細解釋。通話中的其他開發者支援在 CL 規範中明確說明，即當透過 RPC 請求匯入時，客戶端應何時接收區塊和 blob，如果客戶端沒有透過八卦協定接收它們。開發者也討論了其他客戶端需要滿足的條件，以回答有關區塊和 blob 的 RPC 請求。 Prysm 開發者 Terence Tsao 指出，基本上有「三個層次」來解決這些條件。客戶端可能透過以太坊的點對點網路層收到一個 blob 或區塊。第二個層次是客戶端透過八卦接收這個 blob 或區塊，並透過狀態轉換功能驗證訊息。第三個也是最終的層次是客戶端接收有關區塊及其相關 blob 的所有必要資訊。開發者們就在 Cancun 規範中關於 Del Fante 的問題需要滿足哪個層次進行了辯論。

Ryan 建議 Del Fante 在 GitHub 上建立一個拉取請求，以正式化此問題的語言，並在下週最終確定。

解決EL 用戶端多樣性問題

在ACDC＃122 上討論的最後一個主題是Szilágyi 提出的「Making EL Diversity Moot」提案。 Geth 開發者Marius van der Wijden 在通話中分享了該提案的摘要，解釋說這個提案試圖解決的“最壞情況”是，如果大多數客戶端存在錯誤，導致以太坊上的大多數驗證者被削減並被強制退出網路。 Szilágyi 的提案建議的方法是，不是鼓勵運行大多數客戶端的用戶切換到少數客戶端，而是鼓勵用戶透過與其他少數客戶端進行交叉驗證來解決問題。

「與其要求人們運行少數客戶端（可能不方便），或要求他們運行多個客戶端（可能很貴）；我們可以讓他們使用他們喜歡的任何客戶端，而只是要求他們與其他客戶進行無狀態的交叉驗證，」Szilágyi 建議。為了使這項提案奏效，Geth 和其他 EL 用戶端團隊將不得不致力於建立其客戶端的輕量級版本，以用於交叉驗證以太坊區塊。用於交叉驗證區塊的用戶端版本將無法與網路同步、提出區塊，或以其他方式執行 EL 用戶端的全部功能。 Van der Wijden 提到，建構「無狀態」以太坊客戶端的工作將對未來以太坊的 Verkle Trie 升級有所幫助。

Nethermind 開發者Łukasz Rozmej 表示，他對該提案持否定態度，因為EL 客戶端為了與其他客戶端進行交叉驗證，需要額外的工作，這將給區塊生成過程引入延遲。此外，Rozmej 表示，他更願意等待在 Verkle Trie 升級完成之後再進行建置可投產的無狀態以太坊客戶端的工作。 Rozmej 也提問，如果與其他客戶端的交叉驗證失敗，客戶端將如何處理區塊生成。為解決這個問題，Ryan 建議採取「n of m」的方式。如果對區塊的交叉驗證在 6 個客戶端中至少有 3 個成功，驗證者將繼續對區塊進行驗證，否則將停止驗證。

Ryan 也提出了一個擔憂，即這項提案可能進一步降低使用者從使用像Geth 這樣的大多數客戶端切換到少數客戶端的動機，特別是如果透過Szilágyi 的交叉驗證提案減少了由於Geth 中的錯誤而導致的削減風險。「我認為這對網路的健康是正確的事情，」對於 Ryan 的擔憂，Van Der Wijden 回應道。「最重要的是我們不會最終確定任何無效狀態。這比Geth 是否佔據50% 或60% 的網路更為重要。」Van Der Wijden 也指出，該提案不需要得到所有EL 用戶端團隊的支持才能繼續推進。至少，Van Der Wijden 表示 Geth 團隊將調查對這項提案進行原型設計，並提供有關區塊驗證延遲的基準數據。