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

大多數(shù) CL 客戶端團隊表示,它們的目標是在本周或下周完成對 Deneb 規(guī)范的更新實現(xiàn)。開發(fā)者們同意在下周四的所有核心開發(fā)者執(zhí)行(ACDE)電話會議上開始討論啟動 Devnet #12。然后,開發(fā)者們詳細討論了 Geth 開發(fā)者 Péter Szilágyi 提出的解決執(zhí)行層(EL)上有關(guān)客戶端多樣性問題的提案。

Blob Sidecar 網(wǎng)絡更新

如ACDC#121所討論的,CL 客戶端團隊正在對 blob 傳播條件進行改進,以顯著減少與過去 11 個開發(fā)網(wǎng)絡觀察到的 blob 傳播相關(guān)的復雜性和問題。以下是各個 CL 客戶端團隊自上一次 ACDC 以來的進展更新:

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

Teku:實施了新的傳播驗證。正在進行構(gòu)建工作流的開發(fā)。

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

Prysm:計劃在下周末完成實施。之后需要另一個星期來整理構(gòu)建工作流。

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

接著,Teku 開發(fā)者 Enrico Del Fante 提出了一個問題,關(guān)于 CL 客戶端在 Cancun/Deneb 后使用「byRoot」RPC 請求檢索缺失的塊和 blob 的適當條件是什么,Del Fante 關(guān)于這些問題做出詳細解釋。通話中的其他開發(fā)者支持在 CL 規(guī)范中明確說明,即當通過 RPC 請求導入時,客戶端應何時接收塊和 blob,如果客戶端沒有通過八卦協(xié)議接收到它們。開發(fā)者還討論了其他客戶端需要滿足的條件,以回答有關(guān)塊和 blob 的 RPC 請求。Prysm 開發(fā)者 Terence Tsao 指出,基本上有「三個層次」來解決這些條件?？蛻舳丝赡芡ㄟ^以太坊的點對點網(wǎng)絡層收到一個 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)絡。Szilágyi 的提案建議的方法是,不是鼓勵運行大多數(shù)客戶端的用戶切換到少數(shù)客戶端,而是鼓勵用戶通過與其他少數(shù)客戶端進行交叉驗證來解決問題。

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

Nethermind 開發(fā)者?ukasz Rozmej 表示,他對該提案持否定態(tài)度,因為 EL 客戶端為了與其他客戶端進行交叉驗證,需要額外的工作,這將給區(qū)塊生成過程引入延遲。此外,Rozmej 表示,他更愿意等待在 Verkle Trie 升級完成之后再進行構(gòu)建可投產(chǎn)的無狀態(tài)以太坊客戶端的工作。Rozmej 還提問,如果與其他客戶端的交叉驗證失敗,客戶端將如何處理區(qū)塊生成。為解決這個問題,Ryan 建議采取「n of m」的方式。如果對區(qū)塊的交叉驗證在 6 個客戶端中至少有 3 個成功,驗證者將繼續(xù)對區(qū)塊進行驗證,否則將停止驗證。

Ryan 還提出了一個擔憂,即這一提案可能進一步降低用戶從使用像 Geth 這樣的大多數(shù)客戶端切換到少數(shù)客戶端的動機,特別是如果通過 Szilágyi 的交叉驗證提案減少了由于 Geth 中的錯誤而導致的削減風險?！肝艺J為這對于網(wǎng)絡的健康是正確的事情,」對于 Ryan 的擔憂,Van Der Wijden 回應道?！缸钪匾氖俏覀儾粫罱K確定任何無效狀態(tài)。這比 Geth 是否占據(jù) 50% 或 60% 的網(wǎng)絡更為重要。」Van Der Wijden 還指出,該提案不需要得到所有 EL 客戶端團隊的支持才能繼續(xù)推進。至少,Van Der Wijden 表示 Geth 團隊將調(diào)查對這一提案進行原型設計,并提供有關(guān)區(qū)塊驗證延遲的基準數(shù)據(jù)。