除了對 Cancun/Deneb 的更新之外，開發者們還討論了以太坊基金會協議支援負責人 Tim Beiko 提出的一些流程問題，以提升對以太坊升級的協調。本文源自 Christine Kim 所著文章《Ethereum All Core Developers Consensus Call #123 Writeup》，由 BlockBeats 編譯、整理。
（前情提要：以太坊坎昆升級跳票！原定2023年底，因測試網共識問題再延2024年 ）
（背景補充：以太坊坎昆升級「或延至明年」，測試網Devnet-9參與率達93% ）
以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論和協調對以太坊共識層（CL）的更改。會議主要涵蓋了對 Cancun/Deneb 和 Devnet #12 測試更新的評估，以及對 Devnet #11 中出現的驗證者退出問題的解決。
此外，開發者還就網路規範澄清、升級計劃流程和 EIP 狀態進行了深入討論。
延伸閱讀：以太坊坎昆升級核心：EIP4844的Blob為何能降低費用100倍？
在對 Cancun/Deneb 的討論中，開發者強調了穩定性，並討論了是否啟動 Goerli 影子分叉。然而，由於 Prysm 客戶端尚未準備好測試，決定等待其準備就緒。對於測試工具和鏈重組的討論強調了對更全面測試覆蓋的需求，並提出了使用 Hive 和 Kurtosis 測試套件的建議。
在 EIP 狀態和 CFI 標籤的問題上，Beiko 提出了是否應該保留這些標籤的疑慮，開發者們尚未就此問題達成明確的共識。
Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
2023 年 11 月 30 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #122 會議。ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。
本週，開發者們聚焦討論 Cancun/Deneb 測試的最新進展，具體包括：
- Devnet #12 的啟動：目前正在對 Devnet #12 上 Teku、Lodestar 和 Lighthouse 客戶端軟體以及所有執行層（EL）客戶端軟體進行測試。Prysm 團隊預計將在最新的 Devnet 上兩到三週內準備好他們的軟體進行測試。
- Devnet #11 上的驗證器退出問題：在 Devnet #11 上，開發者們發現了與驗證器退出有關的問題，目前由 Nimbus 客戶端團隊解決中。在問題解決之前，Devnet #11 將繼續正常執行。
- 網路規範澄清：開發者們討論了對「BlockByRoot」和「BlobSidecarsByRoot」請求的規範進行澄清，明確共識層（CL）節點是否應按特定順序響應這些請求。
除了對 Cancun/Deneb 的更新之外，開發者們還討論了以太坊基金會協議支援負責人 Tim Beiko 提出的一些流程問題，以提升對以太坊升級的協調。
Devnet #12
2023 年 11 月 30 日星期三，Cancun/Deneb 升級在 Devnet #12 上正式啟動。以太坊基金會測試團隊的 Mario Vega 表示，目前在測試網路上執行的三個 CL 客戶端中「迄今為止沒有發現重大問題」。基金會的 DevOps 工程師 Barnabas Busa 提到，在 Lighthouse、Teku 和 Lodestar 之間，總共有 225 個驗證者分佈在三個節點上。
由於 Devnet #12 的穩定性，基金會的 DevOps 工程師 Parithosh Jayanthi 詢問開發者是否應該開始計劃進行 Goerli 影子分叉以進一步測試 Cancun/Deneb。
然而，考慮到目前最流行的 CL 客戶端 Prysm 尚未加入 Devnet #12，開發者們決定在 Prysm 客戶端軟體準備好進行測試之前暫時擱置計劃進行 Goerli 影子分叉。Beiko 建議在年底之前的某個時候著手進行 Goerli 影子分叉。由於 Devnet #12 的穩定性，暫時擱置計劃，直到 Prysm 客戶端軟體準備好進行測試。
Devnet #11
網名「Dustin」的 Nimbus 開發者介紹了他的團隊正在解決的 Devnet #11 的問題細節。這些問題在開發者將 Devnet #11 的三分之一驗證者退出，以在 Devnet #12 上使用時首次發現。
Ryan 詢問 Dustin 是否可以通過額外的測試來發現這些問題。Dustin 回應稱，在他看來，這些錯誤的性質是由共識規範範圍之外的實現細節引起的。然而，他也承認在為了測試覆蓋的好處而嚴格按照 CL 規範編寫客戶端軟體與為了獲得更好的節點效能而涉足規範的灰色區域之間存在「明顯的緊張關係」。
「我是說更多的測試總是好的，但更系統地找出如何將更多的客戶端功能納入執行的測試中，也許是更多的自動化方式，無論是使用 Hive 還是 Kurtosis 或其他什麼方式。如果這些問題能夠解決或者事情能夠很好地被分解，以便能夠納入更多這些任務，我認為那肯定是有用的，」Dustin 還補充道
CL 開發者應該考慮解決的另一個挑戰是弄清楚 CL 規範應該規定和標準化節點行為的詳細級別。
「這裡的另一個挑戰是，標準化的程度，這實際上不僅僅是一個軟體工程問題，行為應該有多標準化嗎？」Dustin 問道。
所有的 CL 客戶端都通過了檢查基本行為的測試，但是這些測試範圍之外的行為是模糊的。
「這些是有意留下的模糊的東西嗎？什麼應該由規範真正明確規定，而什麼應該故意保持模糊？」Dustin 問道。
至少，開發者們同意在未來的 Devnets 和測試網路上為 Cancun/Deneb 的大量驗證者退出增加更多的測試。Ryan 還承認，在涉及 CL 客戶端和 CL 規範實施時，還有更嚴格和全面的測試覆蓋的空間。Vega 建議 Dustin 建立一個 HackMD 帖子詳細說明他的關切，並在下一次 Cancun/Deneb 測試電話會議上討論這個話題。Jayanthi 補充道，基於在 Cancun/Deneb Devnets 上最近發現的一些問題，開發者明顯需要能夠系統執行一定數量的鏈上整合相關行為的工具，比如質押 ETH 提取、驗證者退出等。為此，Jayanthi 建議使用 Hive 和 Kurtosis 測試套件的混合來構建這樣的工具。
談到 Cancun/Deneb 升級的新測試工具，Jayanthi 指出，開發者們正在研發一種可靠地在 Devnets 和測試網路上啟用鏈重組的工具。為了確保這個工具正常工作，Jayanthi 要求開發者分享在以太坊上觸發鏈重組的已知 bug 的詳細資訊。Jayanthi 解釋說，他將使用這些 bug 來測試該工具，並確保它能夠可靠地識別重組何時發生以及何時解決。
網路規範澄清
開發者們簡要討論了以太坊基金會研究員 Justin Traglia 提出的一個關於 CL 客戶端在收到「BlockbyRoot」或「BlobSidecarsByRoot」請求時應該返回的響應順序的開放拉取請求。Ryan 詢問不同 CL 客戶端團隊已經如何實現這個功能。電話會議上沒有任何開發者回答這個問題。
Ryan 建議在以太坊研究與開發 Discord 頻道上重新引起這個討論，讓更廣泛的客戶端開發者參與。Ryan 承認這兩個請求的規範存在歧義，
「可能是問題和奇怪邊緣情況的原因」「值得澄清和整理，」Ryan 肯定道。
Ryan 還提到他將在接下來的幾天釋出新版本的 CL 規範。最新版本顯著增加了關於 CL 客戶端何時可以通過「byRoot」RPC 請求提供塊和塊的規範。
有關關於通過「byRoot」RPC 請求檢索缺失的塊和塊的討論的更多背景，請參考此前的 通話記錄 。Ryan 強調，最新版本中包含的 CL 規範的新新增不會對已在 Devnet #11 或 #12 上執行的驗證者產生任何影響程式碼的破壞性更改。
升級規劃流程
接著，開發者們討論了 Beiko 提出的各種流程事項。Beiko 表示，警告 Goerli 測試網使用者在 Cancun/Deneb 升級在 Goerli 上啟用後的 3 個月內，或者在以太坊主網上啟用升級後的 1 個月內（以後者為準）即將棄用的部落格文章將於 11 月 30 日在以太坊基金會部落格上釋出。自電話會議結束以來，上述部落格文章已經發布，可以在 這裡 閱讀。
Beiko 建議在以太坊「pm」儲存庫下建立升級專用資料夾，將與特定升級相關的各種檔案整理到一個資料夾中以備後用。電話會議上的開發者們同意了 Beiko 的建議。
Beiko 提出的第二個流程事項是關於建立一個「Meta EIP」文件，以追蹤以太坊上已經完成的網路升級的全部範圍。
「目前沒有一個好的地方可以在部署和在部落格文章中宣佈之前追蹤網路升級的全部範圍，」Beiko 在一篇關於他關於 Meta EIP 提案的帖子中寫道。
「對於 Dencun，我們在一個難以找到的 markdown 檔案 7 中有 EL EIPs，而 CL EIPs 是 Beacon Chain 規範 3 的一部分。這並不是很好，因為這兩者都有點難以找到，它們各自使用不同的『格式』，而且會導致重複。由於 ERC 和 EIP 現在是分開的，我建議（回到）使用 Meta EIPs 來追蹤包含在網路升級中的 EIPs。」開發者們贊成建立這些文件。
Beiko 表示，他將在本週起草一個供 Cancun/Deneb 升級審查的文件。
最後，Beiko 提出了一個關於將擬議的程式碼更改，以太坊改進提案（EIPs）標記為「考慮包含」（CFI）的實用性的問題。據 Beiko 稱，CFI 是開發者們歷史上用作「軟訊號」的狀態，表示 EIP 的作者應該繼續為可能包含在未來硬分叉中的提案而努力工作。它僅用於 EL-focused 的程式碼更改和升級。
「[CFI] 高於來自隨機人的隨機想法，但在分叉中被接受之前，」Beiko 說。
過去，標籤 CFI 在指示 EL 上的哪些 EIP 將在升級中實施或何時實施方面幾乎沒有起到任何效果。它已被應用於具有不同程度的程式碼準備度和客戶端團隊支援的各種 EIPs。在 EVM Object Format（EOF）提案的情況下，開發者們使用這個標籤表明他們致力於在下一個即將到來的升級 Cancun/Deneb 中實施 EOF。
然而，EOF 以及其他幾個也被標記為 CFI 的提案都被從 Cancun/Deneb 中拒絕，目前尚不清楚這些被標記為 CFI 的 EIP 在下一個升級 Prague/Electra 中的狀態。
Beiko 表示，如果這個狀態沒有幫助，開發者們應該將其移除，但如果他們打算保留這個狀態，CL 開發者們也應該在考慮在 CL 升級中實施的程式碼更改上採用相同的標籤。目前尚不清楚 CL EIP 審查過程在多大程度上反應了 EL EIP 審查過程，以及它們在未來是否應該以相同的方式發展。通常，對 CL 規範的擬議程式碼更改在 ACDC 電話會議上進行討論，而對 EL 規範的擬議 EIP 則在 ACDE 電話會議上進行討論。
Swirlds Labs 的 Danno Ferrin 還提出了一個想法，即為所有 EIPs，無論是 CL 還是 EL 相關，建立一個佔位符欄位，用於標識它們在審查過程中的狀態，包括 CFI 狀態。在這個電話會議上，關於 EIP 狀態和 CFI 標籤的話題沒有明確的決定。
相關報導