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

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

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）上有關客戶端多樣性問題的提案。

如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 團隊將調查對這一提案進行原型設計，並提供有關區塊驗證延遲的基准數據。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。