ETH Place核心開發者最新會議總結：Devnet 12上線，升級規劃流程正在升級中

原標題：乙太坊所有核心開發人員共識呼籲#123寫

克裡斯汀·金的原創文章

原創合輯：Luccy， BlockBeats

編者按：

ETH研討會 所有核心開發人員共識電話會議 （ACDC） 每兩周舉行一次，以討論和協調ETH研討會共識層 （CL） 的更改。 這是ACDC的第123次電話會議，重點是評估坎昆/Deneb和Devnet #12測試更新，以及解決Devnet #11中出現的驗證人退出問題。 此外，開發人員還就網路規格說明、升級規劃流程和 EIP 狀態進行了深入討論。

在坎昆/Deneb的討論中，開發人員強調了穩定性，並討論了是否啟動Goerli影子分叉。 但是，由於 Prysm 用戶端尚未準備好進行測試，因此決定等待它準備就緒。 關於測試工具和鏈重組的討論強調了更全面測試覆蓋的必要性，並就使用Hive和Kurtosis測試套件提出了建議。 在EIP狀態和CFI標籤問題上，北光對是否應該保留這些標籤提出了擔憂，開發者對此問題尚未達成明確共識。

Galaxy Digital研究VP Christine Kim詳細介紹了會議的亮點，BlockBeasts彙編如下：

2023 年 11 月 30 日，ETH 開發人員聚集在 Zoom 上，參加全核心開發人員共識 （ACDC） 電話會議 #122 會議。 ACDC電話會議是由ETH研討會基金會研究員Danny Ryan領導的每兩週一次的系列會議，開發人員討論和協調ETH研討會共識層（CL）的更改。 本周，開發人員重點關注坎昆/Deneb測試的最新進展，包括：

· Devnet #12 的發佈：在 Devnet #12 上測試 Teku、Lodestar 和 Lighthouse 用戶端軟體以及所有執行層 （EL） 用戶端軟體正在進行中。 Prysm團隊希望在兩到三周內在最新的Devnet上準備好他們的軟體進行測試。

· Devnet #11 上的驗證器退出問題：在 Devnet #11 上，開發人員發現了一個與驗證器退出相關的問題，Nimbus 用戶端團隊目前正在解決這個問題。 Devnet #11 將繼續正常運行，直到問題得到解決。

· 網路規範說明：開發人員討論了澄清“BlockByRoot”和“BlobSidecarsByRoot”請求的規範，澄清了共識層（CL）節點是否應該以特定順序回應這些請求。

除了坎昆/Deneb更新之外，開發人員還討論了ETH基金會協議支援負責人Tim Beiko提出的一些流程問題，以改善ETH研討會升級的協調。

開發網 #12

2023 年 11 月 30 日星期三，坎昆/Deneb 升級在 Devnet #12 上正式啟動。 ETH基金會測試團隊的Mario Vega表示，目前在測試網上運行的三個CL用戶端“迄今為止尚未發現重大問題”。 基金會的DevOps工程師Barnabas Busa提到，共有225個驗證器分佈在Lighthouse，Teku和Lodestar之間的三個節點上。 由於Devnet #12的穩定性，基金會的DevOps工程師Parithosh Jayanthi詢問開發人員是否應該開始計劃Goerli影子分叉來進一步測試Cancun/Deneb。 然而，考慮到目前最受歡迎的CL用戶端Prysm尚未加入Devnet #12，開發人員決定擱置Goerli影子分叉的計劃，直到Prysm用戶端軟體準備好進行測試。 Beiko建議在今年年底前的某個時候在Goerli影子分叉上移動。 由於 Devnet #12 的穩定性，計劃被擱置，直到 Prysm 用戶端軟體準備好進行測試。

開發網 #11

網名“Dustin”的Nimbus開發人員分享了他的團隊正在處理的Devnet #11問題的細節。 當開發人員退出 Devnet #11 的三分之一驗證器以在 Devnet #12 上使用時，這些問題首次被發現。 里安問達斯汀是否可以通過額外的測試來發現這些問題。 達斯汀回應說，在他看來，這些錯誤的性質是由共識規範範圍之外的實現細節引起的。 然而，他也承認，在嚴格按照CL規範編寫用戶端軟體以測試覆蓋率的好處與涉足規範的灰色地帶以實現更好的節點性能之間存在“明顯的緊張關係”。

“我是說更多的測試總是好的，但更系統地弄清楚如何將更多的用戶端功能整合到運行測試中，也許更多的自動化，無論是使用Hive還是Kurtosis或其他什麼。 如果這些問題可以解決，或者事情可以很好地分解，以便能夠合併更多這些任務，我認為這肯定會很有用，“達斯汀補充道，並補充說，CL開發人員應該考慮解決的另一個挑戰是弄清楚CL規範應該規定和標準化節點行為的詳細程度。 “這裡的另一個挑戰是標準化程度，這真的不僅僅是一個軟體工程問題，行為應該有多標準化？” 達斯汀問道。 測試所有CL用戶端以檢查基本行為，但這些測試範圍之外的行為是不明確的。 “這些是故意模糊的東西嗎？ 規範中真正應該明確定義什麼，什麼應該故意模糊？” 達斯汀問道。

至少，開發人員同意為未來的Devnets和測試網添加更多測試，以便在坎昆/Deneb的大量驗證器退出。 Ryan還承認，在CL用戶端和CL規範實施方面，還有更嚴格和更全面的測試覆蓋空間。 Vega建議Dustin創建一個HackMD帖子，詳細說明他的擔憂，並在下一次坎昆/Deneb測試電話會議上討論這個話題。 Jayanthi補充說，基於最近在坎昆/Deneb Devnets上發現的一些問題，開發人員顯然需要擁有能夠系統地執行一定數量的鏈上集成相關行為的工具，例如質押ETH提款，驗證者提款等。 為此，Jayanthi建議混合使用Hive和Kurtosis測試套件來構建這樣的工具。

在談到坎昆/Deneb升級的新測試工具時，Jayanthi指出，開發人員正在開發一種工具，以可靠地啟動Devnets和測試網上的鏈重聚。 為了確保該工具正常工作，Jayanthi要求開發人員分享觸發ETH鏈重組的已知錯誤的詳細資訊。 Jayanthi解釋說，他將使用這些錯誤來測試該工具，並確保它能夠可靠地識別何時發生重組以及何時解決重組。

網络規範說明

開發人員簡要討論了ETH基金會研究員賈斯汀·特拉格利亞（Justin Traglia）提出的一個開放拉取請求，該請求涉及CL用戶端在收到“BlockbyRoot”或“BlobSidecarsByRoot”請求時應返回的回應順序。 Ryan 詢問不同的 CL 客戶團隊已經如何實現此功能。 電話會議中沒有一個開發人員回答這個問題。 Ryan建議恢復ETH研發Discord頻道的討論，讓更廣泛的客戶開發人員參與進來。 Ryan承認，這兩個請求的規範存在歧義，“可能是問題和奇怪邊緣情況的原因”，並且“值得澄清和整理”，Ryan肯定地說。

Ryan還提到，他將在未來幾天內發佈新版本的CL規範。 最新版本顯著增加了CL用戶端何時可以通過“byRoot”RPC請求提供塊和塊的規範。 有關通過“byRoot”RPC 請求檢索丟失的塊和塊的討論的更多背景資訊，請參閱前面的調用日誌。 Ryan 強調，最新版本中包含的 CL 規範的新添加不會對代碼進行任何重大更改，這些更改會影響已經在 Devnet #11 或 #12 上運行的驗證器的代碼。

升級規劃過程

接下來，開發人員討論了貝科提出的各種工藝專案。 根據Beiko的說法，一篇博客文章警告Goerli測試網使用者即將在Goerli上啟動坎昆/Deneb升級后的3個月內，或在ETH主網上激活升級后的1個月內（以較晚者為準），將於11月30日在ETH基金會博客上發佈。 自電話會議結束以來，上述博客文章已經發佈，可以在這裡閱讀。

Beiko 建議在 ETH 「pm」儲存庫下創建一個特定於升級的資料夾，以將與特定升級相關的各種文件組織到單個資料夾中供以後使用。 電話會議中的開發人員同意了Beiko的建議。

Beiko提出的第二個流程專案是創建一個「Meta EIP」文檔，以跟蹤ETH上已完成的網路升級的全部範圍。 “在部署並在博客文章中宣佈網络升級之前，沒有好地方可以跟蹤網络升級的全部範圍，”Beiko在一篇關於他的Meta EIP提案的文章中寫道。 “對於 Dencun，我們在難以找到的降價檔 7 中有 EL EIP，而 CL EIP 是信標鏈規範 3 的一部分。 這不是很好，因為兩者都有點難找到，它們各自使用不同的“格式”，並且會導致重複。 由於 ERC 和 EIP 現在是分開的，我建議（回到）使用 Meta EIP 來跟蹤網路升級中包含的 EIP。 開發人員贊成創建這些文件。 Beiko表示，他將在本周起草一份檔，以審查坎昆/德內布升級。

最後，Beiko提出了一個問題，即將擬議的代碼更改ETH改進提案（EIP）標記為“被認為包括”（CFI）的有用性。 根據Beiko的說法，CFI是開發人員歷來用作“軟信號”的狀態，這表明EIP的作者應該繼續努力研究可能包含在未來硬分叉中的提案。 它僅用於以 EL 為中心的代碼更改和升級。 「[CFI] 高於隨機人的隨機想法，但在他們被分叉接受之前，“Beiko說。

過去，標籤CFI在指示 EL 上的哪些 EIP 將在升級中實施或何時實施方面幾乎沒有作用。 它已被應用於廣泛的 EIP，具有不同程度的代碼準備和客戶團隊的支援。 在 EVM 物件格式 （EOF） 提案中，開發人員使用此標記來表明他們承諾在下一個即將到來的升級坎昆/德內布中實施 EOF。 然而，EOF以及其他幾個也被標記為CFI的提案被坎昆/德內布拒絕了，目前尚不清楚這些被標記為CFI的EIP在下一次升級布拉格/伊萊克特拉中的地位。

Beiko表示，如果這種狀態沒有幫助，開發人員應該刪除它，但如果他們打算保留它，CL開發人員也應該在他們考慮在CL升級中實施的代碼更改上使用相同的標籤。 目前尚不清楚CL EIP審查過程在多大程度上反映了EL EIP審查過程，以及它們將來是否應該以同樣的方式發展。 通常，對 CL 規範的建議代碼更改在 ACDC 電話會議上討論，而對 EL 規範的建議 EIP 在 ACDE 電話會議上討論。

Swirlds Labs的Danno Ferrin還提出了為所有EIP創建一個佔位元字段的想法，無論是CL還是EL相關，以標識它們在審查過程中的狀態，包括CFI狀態。 關於本次電話會議的 EIP 狀態和CFI標籤主題，沒有明確的決定。