以太坊所有核心開發(fā)者共識電話（ACDC）每兩周舉行一次，主要討論和協(xié)調(diào)對以太坊共識層（CL）的更改。本次為 ACDC 第 123 次電話會議，會議主要涵蓋了對 Cancun/Deneb 和 Devnet #12 測試更新的評估，以及對 Devnet #11 中出現(xiàn)的驗證者退出問題的解決。此外，開發(fā)者還就網(wǎng)絡(luò)規(guī)范澄清、升級計劃流程和 EIP 狀態(tài)進行了深入討論。

在對 Cancun/Deneb 的討論中，開發(fā)者強調(diào)了穩(wěn)定性，并討論了是否啟動 Goerli 影子分叉。然而，由于 Prysm 客戶端尚未準備好測試，決定等待其準備就緒。對于測試工具和鏈重組的討論強調(diào)了對更全面測試覆蓋的需求，并提出了使用 Hive 和 Kurtosis 測試套件的建議。在 EIP 狀態(tài)和 CFI 標簽的問題上，Beiko 提出了是否應(yīng)該保留這些標簽的疑慮，開發(fā)者們尚未就此問題達成明確的共識。

Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

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

· Devnet #12 的啟動：目前正在對 Devnet #12 上 Teku、Lodestar 和 Lighthouse 客戶端軟件以及所有執(zhí)行層（EL）客戶端軟件進行測試。Prysm 團隊預(yù)計將在最新的 Devnet 上兩到三周內(nèi)準備好他們的軟件進行測試。

· Devnet #11 上的驗證器退出問題：在 Devnet #11 上，開發(fā)者們發(fā)現(xiàn)了與驗證器退出有關(guān)的問題，目前由 Nimbus 客戶端團隊解決中。在問題解決之前，Devnet #11 將繼續(xù)正常運行。

· 網(wǎng)絡(luò)規(guī)范澄清：開發(fā)者們討論了對「BlockByRoot」和「BlobSidecarsByRoot」請求的規(guī)范進行澄清，明確共識層（CL）節(jié)點是否應(yīng)按特定順序響應(yīng)這些請求。

除了對 Cancun/Deneb 的更新之外，開發(fā)者們還討論了以太坊基金會協(xié)議支持負責(zé)人 Tim Beiko 提出的一些流程問題，以提升對以太坊升級的協(xié)調(diào)。

2023 年 11 月 30 日星期三，Cancun/Deneb 升級在 Devnet #12 上正式啟動。以太坊基金會測試團隊的 Mario Vega 表示，目前在測試網(wǎng)絡(luò)上運行的三個 CL 客戶端中「迄今為止沒有發(fā)現(xiàn)重大問題」。基金會的 DevOps 工程師 Barnabas Busa 提到，在 Lighthouse、Teku 和 Lodestar 之間，總共有 225 個驗證者分布在三個節(jié)點上。由于 Devnet #12 的穩(wěn)定性，基金會的 DevOps 工程師 Parithosh Jayanthi 詢問開發(fā)者是否應(yīng)該開始計劃進行 Goerli 影子分叉以進一步測試 Cancun/Deneb。然而，考慮到目前最流行的 CL 客戶端 Prysm 尚未加入 Devnet #12，開發(fā)者們決定在 Prysm 客戶端軟件準備好進行測試之前暫時擱置計劃進行 Goerli 影子分叉。Beiko 建議在年底之前的某個時候著手進行 Goerli 影子分叉。由于 Devnet #12 的穩(wěn)定性，暫時擱置計劃，直到 Prysm 客戶端軟件準備好進行測試。

網(wǎng)名「Dustin」的 Nimbus 開發(fā)者介紹了他的團隊正在解決的 Devnet #11 的問題細節(jié)。這些問題在開發(fā)者將 Devnet #11 的三分之一驗證者退出，以在 Devnet #12 上使用時首次發(fā)現(xiàn)。Ryan 詢問 Dustin 是否可以通過額外的測試來發(fā)現(xiàn)這些問題。Dustin 回應(yīng)稱，在他看來，這些錯誤的性質(zhì)是由共識規(guī)范范圍之外的實現(xiàn)細節(jié)引起的。然而，他也承認在為了測試覆蓋的好處而嚴格按照 CL 規(guī)范編寫客戶端軟件與為了獲得更好的節(jié)點性能而涉足規(guī)范的灰色區(qū)域之間存在「明顯的緊張關(guān)系」。

「我是說更多的測試總是好的，但更系統(tǒng)地找出如何將更多的客戶端功能納入運行的測試中，也許是更多的自動化方式，無論是使用 Hive 還是 Kurtosis 或其他什么方式。如果這些問題能夠解決或者事情能夠很好地被分解，以便能夠納入更多這些任務(wù)，我認為那肯定是有用的，」Dustin 還補充道，CL 開發(fā)者應(yīng)該考慮解決的另一個挑戰(zhàn)是弄清楚 CL 規(guī)范應(yīng)該規(guī)定和標準化節(jié)點行為的詳細級別?！高@里的另一個挑戰(zhàn)是，標準化的程度，這實際上不僅僅是一個軟件工程問題，行為應(yīng)該有多標準化嗎？」Dustin 問道。所有的 CL 客戶端都通過了檢查基本行為的測試，但是這些測試范圍之外的行為是模糊的?！高@些是有意留下的模糊的東西嗎？什么應(yīng)該由規(guī)范真正明確規(guī)定，而什么應(yīng)該故意保持模糊？」Dustin 問道。

至少，開發(fā)者們同意在未來的 Devnets 和測試網(wǎng)絡(luò)上為 Cancun/Deneb 的大量驗證者退出增加更多的測試。Ryan 還承認，在涉及 CL 客戶端和 CL 規(guī)范實施時，還有更嚴格和全面的測試覆蓋的空間。Vega 建議 Dustin 創(chuàng)建一個 HackMD 帖子詳細說明他的關(guān)切，并在下一次 Cancun/Deneb 測試電話會議上討論這個話題。Jayanthi 補充道，基于在 Cancun/Deneb Devnets 上最近發(fā)現(xiàn)的一些問題，開發(fā)者明顯需要能夠系統(tǒng)執(zhí)行一定數(shù)量的鏈上集成相關(guān)行為的工具，比如質(zhì)押 ETH 提取、驗證者退出等。為此，Jayanthi 建議使用 Hive 和 Kurtosis 測試套件的混合來構(gòu)建這樣的工具。

談到 Cancun/Deneb 升級的新測試工具，Jayanthi 指出，開發(fā)者們正在研發(fā)一種可靠地在 Devnets 和測試網(wǎng)絡(luò)上激活鏈重組的工具。為了確保這個工具正常工作，Jayanthi 要求開發(fā)者分享在以太坊上觸發(fā)鏈重組的已知 bug 的詳細信息。Jayanthi 解釋說，他將使用這些 bug 來測試該工具，并確保它能夠可靠地識別重組何時發(fā)生以及何時解決。

開發(fā)者們簡要討論了以太坊基金會研究員 Justin Traglia 提出的一個關(guān)于 CL 客戶端在收到「BlockbyRoot」或「BlobSidecarsByRoot」請求時應(yīng)該返回的響應(yīng)順序的開放拉取請求。Ryan 詢問不同 CL 客戶端團隊已經(jīng)如何實現(xiàn)這個功能。電話會議上沒有任何開發(fā)者回答這個問題。Ryan 建議在以太坊研究與開發(fā) Discord 頻道上重新引起這個討論，讓更廣泛的客戶端開發(fā)者參與。Ryan 承認這兩個請求的規(guī)范存在歧義，「可能是問題和奇怪邊緣情況的原因」「值得澄清和整理，」Ryan 肯定道。

Ryan 還提到他將在接下來的幾天發(fā)布新版本的 CL 規(guī)范。最新版本顯著增加了關(guān)于 CL 客戶端何時可以通過「byRoot」RPC 請求提供塊和塊的規(guī)范。有關(guān)關(guān)于通過「byRoot」RPC 請求檢索缺失的塊和塊的討論的更多背景，請參考此前的通話記錄。Ryan 強調(diào)，最新版本中包含的 CL 規(guī)范的新添加不會對已在 Devnet #11 或 #12 上運行的驗證者產(chǎn)生任何影響代碼的破壞性更改。

接著，開發(fā)者們討論了 Beiko 提出的各種流程事項。Beiko 表示，警告 Goerli 測試網(wǎng)用戶在 Cancun/Deneb 升級在 Goerli 上激活后的 3 個月內(nèi)，或者在以太坊主網(wǎng)上激活升級后的 1 個月內(nèi)（以后者為準）即將棄用的博客文章將于 11 月 30 日在以太坊基金會博客上發(fā)布。自電話會議結(jié)束以來，上述博客文章已經(jīng)發(fā)布，可以在這里閱讀。

Beiko 建議在以太坊「pm」存儲庫下創(chuàng)建升級專用文件夾，將與特定升級相關(guān)的各種文件整理到一個文件夾中以備后用。電話會議上的開發(fā)者們同意了 Beiko 的建議。

Beiko 提出的第二個流程事項是關(guān)于創(chuàng)建一個「Meta EIP」文檔，以跟蹤以太坊上已經(jīng)完成的網(wǎng)絡(luò)升級的全部范圍?！改壳皼]有一個好的地方可以在部署和在博客文章中宣布之前跟蹤網(wǎng)絡(luò)升級的全部范圍，」Beiko 在一篇關(guān)于他關(guān)于 Meta EIP 提案的帖子中寫道?！笇τ?Dencun，我們在一個難以找到的 markdown 文件 7 中有 EL EIPs，而 CL EIPs 是 Beacon Chain 規(guī)范 3 的一部分。這并不是很好，因為這兩者都有點難以找到，它們各自使用不同的『格式』，而且會導(dǎo)致重復(fù)。由于 ERC 和 EIP 現(xiàn)在是分開的，我建議（回到）使用 Meta EIPs 來跟蹤包含在網(wǎng)絡(luò)升級中的 EIPs?！归_發(fā)者們贊成創(chuàng)建這些文檔。Beiko 表示，他將在本周起草一個供 Cancun/Deneb 升級審查的文檔。

最后，Beiko 提出了一個關(guān)于將擬議的代碼更改，以太坊改進提案（EIPs）標記為「考慮包含」（CFI）的實用性的問題。據(jù) Beiko 稱，CFI 是開發(fā)者們歷史上用作「軟信號」的狀態(tài)，表示 EIP 的作者應(yīng)該繼續(xù)為可能包含在未來硬分叉中的提案而努力工作。它僅用于 EL-focused 的代碼更改和升級?！竅CFI] 高于來自隨機人的隨機想法，但在分叉中被接受之前，」Beiko 說。

過去，標簽 CFI 在指示 EL 上的哪些 EIP 將在升級中實施或何時實施方面幾乎沒有起到任何效果。它已被應(yīng)用于具有不同程度的代碼準備度和客戶端團隊支持的各種 EIPs。在 EVM Object Format（EOF）提案的情況下，開發(fā)者們使用這個標簽表明他們致力于在下一個即將到來的升級 Cancun/Deneb 中實施 EOF。然而，EOF 以及其他幾個也被標記為 CFI 的提案都被從 Cancun/Deneb 中拒絕，目前尚不清楚這些被標記為 CFI 的 EIP 在下一個升級 Prague/Electra 中的狀態(tài)。

Beiko 表示，如果這個狀態(tài)沒有幫助，開發(fā)者們應(yīng)該將其移除，但如果他們打算保留這個狀態(tài)，CL 開發(fā)者們也應(yīng)該在考慮在 CL 升級中實施的代碼更改上采用相同的標簽。目前尚不清楚 CL EIP 審查過程在多大程度上反映了 EL EIP 審查過程，以及它們在未來是否應(yīng)該以相同的方式發(fā)展。通常，對 CL 規(guī)范的擬議代碼更改在 ACDC 電話會議上進行討論，而對 EL 規(guī)范的擬議 EIP 則在 ACDE 電話會議上進行討論。

Swirlds Labs 的 Danno Ferrin 還提出了一個想法，即為所有 EIPs，無論是 CL 還是 EL 相關(guān)，創(chuàng)建一個占位符字段，用于標識它們在審查過程中的狀態(tài)，包括 CFI 狀態(tài)。在這個電話會議上，關(guān)于 EIP 狀態(tài)和 CFI 標簽的話題沒有明確的決定。