摘要：另一方面，會議提到Geth開發者Szilágyi提出了解決執行層（EL）上的客戶端多樣性問題的提案。接著，Teku開發者EnricoDelFante提出了一個問題，關于CL客戶端在Cancun/Deneb后使用「byRoot」RPC請求檢索缺失的塊和blob的適當條件是什么，DelFante關于這些問題做出詳細解釋。...

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 團隊將調查該提案的原型設計，并提供相關塊驗證延遲的基準數據。