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

原文連結