原文標題：《Ethereum All Core Developers Consensus Call #120 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats< /blockquote>

上次會議

在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 電話會議上重新討論這個議題。

「原文連結」

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia