原文標題：《Ethereum All Core Developers Consensus Call #120 Writeup》
原文作者：Christine Kim
原文編譯：Luccy，BlockBeats
上一次會議
在 10 月 19 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) Call #120 會議。ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。本週，開發者們主要關注以下議題的進展：
1. CL 規範的 1.4.0-beta.3 版本；
2. Devnet-10 的啓動條件；
3. Gajinder Singh 對 blob 延遲進行分析，他是一位維護 Lodestar 和 EthereumJS 客戶端的軟件開發者。
召喚（The Summoning）
Danny Ryan 宣佈發佈了 Cancun/Deneb（Dencun）升級的新 CL 代碼規範，被稱爲「召喚」。這個版本在 CL GitHub 倉庫中被正式標記爲 1.4.0-beta.3 版本，主要包含兩個變更：
1. 主網 KZG 配置：完成了以太坊可信設置儀式輸出所需的格式化工作，並將其包含在最新的 CL 規範發佈中。
2. 新的八卦規則：Teku 開發者 Enrico Del Fante 創建了一個新的八卦規則，以確保 CL 節點不會傳播超過每個區塊最大 blob 數量的 blob，目前規範中定義的每個區塊的 blob 數量爲六個。這將確保驗證者不能用超過每個區塊六個 blob 的無效消息垃圾郵件網絡。
Devnet-10
CL 規範 1.4.0-beta.3 版本的更改將在下一個開發網絡 Devnet-10 上進行測試。然而，Devnet-10 的啓動還有一些障礙。以太坊基金會的 DevOps 工程師 Barnabas Busa 表示，他仍在等待客戶端團隊發佈新的軟件版本。一旦這些準備就緒，Busa 希望在 10 月 20 日（週二）的某個時候啓動下一個開發網絡。
使用化名「Potuz」的 Prysm 客戶端的開發者指出，最新的 CL 規範中包含的主網 KZG 配置在對「go-kzg」進行更改之前無法合併到 Geth 和 Prysm 中。「go-kzg」是一個單獨的代碼倉庫，將 KZG 承諾方案實現到 Go 編程語言中。開發者們在電話會議上對 go-kzg、Geth 和 Prysm 倉庫之間的依賴關係表示了失望。這並非 Potuz 和其他開發者第一次提出關於使用 KZG 庫進行 EIP 4844 的挑戰。
以太坊基金會的 DevOps 工程師 Parithosh Jayanthi 表示，開發者可以在沒有主網 KZG 配置和新客戶端發佈的情況下啓動 Devnet-10，但這意味着開發者不會在 Devnet-10 上測試任何新代碼，而是在 Devnet-9 上重新測試發佈的代碼。
本週，在 Devnet-9 上，開發者們發現了 CL 客戶端實現中的一個問題。以太坊基金會測試團隊的 Mario Vega 解釋稱，驗證者未能正確處理無效的數據塊（blob）。Vega 介紹說，如果驗證者惡意地將有效的數據塊廣播給部分節點，而將無效的數據塊廣播給其他節點，那麼接收到無效數據塊的節點將無法追蹤鏈的頭部。爲了解決這個問題，已經創建了一個 hive 測試，以便輕鬆複製這些條件並針對新的客戶端發佈進行測試。這將使開發者能夠立即瞭解他們針對該問題的修復是否有效。
關於這個問題，Enrico Del Fante 提到，當某個區塊包含一個或多個與區塊中現有 blob 承諾不匹配的索引的 blob 時，在特定情況下，Teku 客戶端將不會導入這個區塊。以太坊基金會研究員 Dankrad Feist 指出，故意提議包含無效 blob 的區塊的驗證者除了可能增加以太坊點對點網絡的計算負擔並導致接收區塊的部分驗證者與網絡失去同步之外，並沒有其他好處。Feist 強調，這種行爲沒有經濟收益，即使驗證者這樣做，以太坊點對點層的額外計算負擔也將受到每個區塊最大 blob 數量的限制。
儘管如此，爲了阻止驗證者採取這種行爲，開發者們正在討論可能添加一個新的削減條件。新的削減條件將試圖監控區塊中無效 blob 的包含情況，以阻止驗證者故意給點對點層帶來壓力。然而，由於改變以太坊驗證者經濟學所需的研究和分析成本很高，Ryan 建議在 Dencun 之後的下一個升級 Prague/Electra 的背景下進一步討論這個提議。
Ryan 補充指出，開發者可以在 Dencun 的 CL 規範中爲這種情況設定適當的行爲，即使 blob 索引與區塊承諾不匹配，驗證者仍應導入區塊。他認爲，由於驗證者沒有經濟動力去以 Del Fante 描述的方式傳播含有無效 blob 的區塊，這種非理性行爲可能導致的網絡負擔最大程度地受到每個區塊最大 blob 數量的限制。因此，對 CL 規範進行微小修改應該足以在短期內解決問題，同時開發者可以考慮未來升級的更持久性解決方案，如新的削減條件。
Jayanthi 與 Ryan 再次確認，在開發者在客戶端設置主網 KZG 配置並解決 Mario Vega 提出的問題之前，Prysm 客戶端上至少不會啓動 Devnet-10。Ryan 強調，關於新的削減條件的討論僅在 Prague/Electra 升級的背景下進行，而不是 Dencun，並且關於導入包含無效 blob 的區塊的 CL 規範的更改不應成爲啓動 Devnet-10 的障礙。Prysm 和 Lighthouse 客戶端團隊的代表表示，他們將在 10 月 20 日（明天）爲他們的軟件發佈更新。
區塊延遲分析
在 10 月 14 日（星期六）的一次分享中，以太坊客戶端 Lodestar 和 EthereumJS 的維護者 Gajinder Singh 分享了關於基於八卦傳播的 blob 數量與區塊導入延遲之間關係的新分析。Singh 指出，在他對 Devnet-9 的實驗中，驗證者接收到的 blob 數量越多，區塊的延遲就越明顯地增加。
下表總結了 Singh 的發現。第一列列出了完整區塊到達的百分比，而表格中的數值表示導入區塊所需的秒數。
區塊導入延遲（以秒爲單位）與區塊中包含的 blob 數量之間的關係。圖源: Gajinder Singh, Twitter
Singh 在推特上表示，雖然每個區塊中只有一個 blob 產生的延遲可以忽略不計，但任何高於兩個的數字都會引入顯著的延遲。Dankrad Feist 表示，Singh 的分析數據與他在以太坊主網上傳播大區塊的實驗結果非常不同。Feist 斷言：「看起來這些數據不可能是正確的」，並補充說，由於 blob 是與區塊並行處理的，所以將 blob 處理的延遲加到區塊時間上是一種不準確的方式來預測主網上區塊傳播時間。Singh 關於帶有 blob 的區塊傳播的預測可以在
Singh 在 Twitter 上表示，儘管每個區塊中只有一個 blob 產生的延遲可以忽略不計，但任何高於兩個的數字都會引入顯著的延遲。然而，Dankrad Feist 指出，Singh 的分析數據與他在以太坊主網上傳播大區塊的實驗結果有很大差異。Feist 斷言：「這些數據看起來不可能是正確的」，並補充說，由於 blob 是與區塊並行處理的，因此將 blob 處理的延遲加到區塊時間上來預測主網上區塊傳播時間是一種不準確的方式。Singh 關於帶有 blob 的區塊傳播的預測可以在這裏找到。Feist 稱 Singh 的分析「過於悲觀」。
儘管存在分歧，Feist 和 Ryan 都認爲 Singh 的分析確實值得其他客戶端團隊借鑑。Ryan 鼓勵其他 CL 團隊嘗試在 Devnet-9 上重現 Singh 的實驗，看看他們是否能得到相似的數據和結果。如果有關於引入 blob 後區塊延遲的新數據，Ryan 建議在下週的 ACDE 電話會議上重新討論這個議題。
「原文鏈接」