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

2023 年 11 月 16 日，以太坊開發(fā)人員齊聚一堂 Zoom 參與了 All Core Developers Consensus (ACDC) call #122 大會。ACDC 電話會議是以太坊基金會研究員每兩周舉行一次的系列會議 Danny Ryan 主持人，開發(fā)人員在會議上討論協(xié)調(diào)以太坊共識（CL）的更改。本周，開發(fā)人員聚焦討論 Cancun/Deneb 升級的 CL 改善進(jìn)展。

大部分 CL 客戶端團(tuán)隊表示，他們的目標(biāo)是實現(xiàn)本周或下周的目標(biāo) Deneb 實現(xiàn)標(biāo)準(zhǔn)化更新。開發(fā)者同意下周四所有核心開發(fā)者的執(zhí)行（ACDE）電話會議開始討論啟動 Devnet #12。隨后，開發(fā)人員進(jìn)行了詳細(xì)的討論 Geth 開發(fā)者 Péter Szilágyi 提出的處理執(zhí)行層（EL）提出相關(guān)客戶端多樣性問題的建議。

Blob Sidecar 網(wǎng)絡(luò)更新

如ACDC＃121所探討的，CL 客戶端團(tuán)隊是對的 blob 改善傳播條件，顯著降低和過去 11 開發(fā)網(wǎng)絡(luò)所看到的 blob 與溝通相關(guān)的復(fù)雜性和問題。以下是每一個問題。 CL 自上次以來，客戶端團(tuán)隊一直在進(jìn)行 ACDC 今天的進(jìn)展更新：

Lighthouse：開發(fā)基本完成。新代碼的審查和測試需要在下周末進(jìn)行。

Teku：新的溝通驗證已經(jīng)實施。正在進(jìn)行建設(shè)工作流的研發(fā)。

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

Prysm：該計劃將于下周末完成。之后需要另一周的時間來整理和構(gòu)建工作流。

基于 CL 更新客戶端，Ryan 下次建議 ACD 計劃在電話會議期間啟動 Devnet #12。以太坊基金會（EF）的 DevOps 工程師 Barnabas Busa 說，下一個 Cancun/Deneb 開發(fā)網(wǎng)絡(luò)的「合理」目標(biāo)啟動日期可能是 11 月 29 日或 30 日。EF 的另一位 DevOps 工程師 Parithosh Jayanthi 詢問了相關(guān) hive 測試的最新情況。EF 測試團(tuán)隊的 Mario Vega 確定，升級的基礎(chǔ) hive 測試已準(zhǔn)備就緒。在接下來的幾周內(nèi)，他的團(tuán)隊將是 hive 添加測試套件用于構(gòu)建和構(gòu)建「blobber」測試工作流的新功能。

接著，Teku 開發(fā)者 Enrico Del Fante 提出了一個問題，關(guān)于 CL 客戶端在 Cancun/Deneb 后再用「byRoot」RPC 請求檢索缺失的塊和 blob 適度條件是什么，Del Fante 詳細(xì)解釋了這些問題。其他開發(fā)者支持通話中的其他開發(fā)者 CL 規(guī)范中明確規(guī)定，即當(dāng)通過規(guī)范時， RPC 當(dāng)請求導(dǎo)入時，客戶端應(yīng)該何時接收塊和塊 blob，如果客戶端沒有通過八卦協(xié)議收到它們。開發(fā)人員還討論了其他客戶端需要滿足的條件，以回答相關(guān)塊和 blob 的 RPC 請求。Prysm 開發(fā)者 Terence Tsao 指出，基本上有「三個層次」解決這些條件。客戶端可能會通過以太坊的點對點網(wǎng)絡(luò)層收到一個 blob 或塊。第二個層次是客戶端通過八卦接收 blob 或塊，并通過狀態(tài)轉(zhuǎn)換功能驗證信息。第三個也是最后一個層次是客戶端接收相關(guān)塊及其相關(guān)塊 blob 所有必要的信息。開發(fā)者就在這里 Cancun 規(guī)范中關(guān)于 Del Fante 辯論需要滿足哪個層次的問題。

Ryan 建議 Del Fante 在 GitHub 創(chuàng)建一個獲取請求，以正式化這個問題的語言，并在下周最終確定。

處理 EL 客戶端多樣性問題

在 ACDC＃122 上述討論的最后一個話題是 Szilágyi 提出的「Making EL Diversity Moot」提案。Geth 開發(fā)者 Marius van der Wijden 在通話中，我分享了該提案的摘要，解釋了該提案試圖解決的問題「最壞狀況」是的，如果大多數(shù)客戶端都有錯誤，以太坊上的大多數(shù)驗證人都會被削減并被迫退出網(wǎng)絡(luò)。Szilágyi 建議的方法不是鼓勵大多數(shù)客戶轉(zhuǎn)換到少數(shù)客戶，而是鼓勵用戶通過與其他少數(shù)客戶的交叉驗證來解決問題。

「與其要求大家運行少數(shù)客戶端(可能不方便)，不如要求大家運行多個客戶端(可能很貴)；我們可以讓他們使用他們喜歡的任何客戶端，而只是讓他們與其他客戶端進(jìn)行無狀態(tài)的交叉驗證，」Szilágyi 建議道。為了使這一提案有效，Geth 和其它 EL 客戶端團(tuán)隊將不得不致力于構(gòu)建其客戶端的輕量級版本，以交叉驗證以太坊塊。用于交叉驗證塊的客戶端版本將無法與網(wǎng)絡(luò)同步、提出塊，或以其他方式執(zhí)行 EL 客戶端的所有功能。Van der Wijden 提及，構(gòu)建「無狀態(tài)」以太坊客戶端的工作將是以太坊未來的工作 Verkle Trie 升級是有幫助的。

Nethermind 開發(fā)者?ukasz Rozmej 他說，他對該提案持否定態(tài)度，因為 EL 為了與其他客戶端交叉驗證，客戶端需要額外的工作，這將延遲塊生成過程。此外，Rozmej 他說他更愿意等待 Verkle Trie 升級完成后，再進(jìn)行無狀態(tài)以太坊客戶端的建設(shè)。Rozmej 如果與其他客戶端的交叉驗證失敗，客戶端將如何處理塊生成。要解決這個問題，Ryan 建議采取「n of m」的方式。如果塊的交叉驗證正在進(jìn)行 6 至少有一個客戶端 3 如果成功，驗證人將繼續(xù)驗證塊，否則將停止驗證。

Ryan 還提出了一個擔(dān)憂，即這個提案可能會進(jìn)一步減少用戶從使用像 Geth 大多數(shù)這樣的客戶端轉(zhuǎn)換到少數(shù)客戶端的動機，特別是如果它們通過 Szilágyi 由于交叉驗證提案減少，交叉驗證提案減少 Geth 由錯誤引起的降低風(fēng)險?！肝艺J(rèn)為這對網(wǎng)絡(luò)健康是正確的，」對于 Ryan 的焦慮，Van Der Wijden 回應(yīng)道。「最重要的是，我們不會最終確定任何無效狀態(tài)。這比 Geth 是否占據(jù) 50% 或 60% 網(wǎng)絡(luò)更為重要。」Van Der Wijden 還指出，該提案不需要獲得所有提案 EL 只有客戶端團(tuán)隊的支持才能繼續(xù)推進(jìn)。至少，Van Der Wijden 表示 Geth 團(tuán)隊將調(diào)查該提案的原型設(shè)計，并提供相關(guān)塊驗證延遲的基準(zhǔn)數(shù)據(jù)。