以太坊研究人員報告指出，使用 EIP-8411 的分段廣播設計，模擬 1 MiB 執行載荷的中位傳播時間低於一秒，而將該載荷作為單一訊息發送時則約需五秒。
摘要
- 測試將 1 MiB 載荷的中位傳播時間從五秒縮短至一秒以下。
- EIP-8411 將執行載荷拆分為多個區塊，節點可在完整載荷完成前先行驗證並轉發。
- 執行出價中的 Merkle 根讓節點能獨立驗證每個收到的載荷分段。
- 原型測試使用了 500 個模擬節點、家庭建構者頻寬、地理延遲以及十個隨機化網路種子。
- 以太坊開發者將於 2026 年 9 月 17 日的 ACDC 會議上討論 EIP-8411 是否納入 Hegotá。
以太坊研究於 9 月 17 日發布了最新測試結果，詳細介紹了一個原型，該原型將執行載荷拆分為更小的片段，使節點能在收到完整載荷之前驗證並轉發每個分段。這些發現來自模擬與原型客戶端程式碼，而非以太坊主網測量數據。
該提案目前仍是以太坊 EIPs 儲存庫中的草稿網路 EIP。其當前設計以 execution_payload_chunks 主題取代 EIP-7732 引入的單一 execution_payload gossip 主題，並透過建構者執行出價中包含的 Merkle 根來提交這些片段。
以太坊 EIP-8411 消除等待完整載荷的需求
以太坊現有的 gossip 模型可能要求節點在將大型訊息轉發給對等節點之前先接收並驗證該訊息。EIP-8411 背後的研究人員將由此產生的延遲描述為儲存轉發問題，因為完整載荷必須跨越一個網路跳躍才能開始下一個跳躍。
透過分段傳播，建構者將載荷劃分為固定片段。每個分段都帶有與執行出價中提交的根相關聯的 Merkle 包含證明。接收節點可以檢查一個分段，並在其餘片段仍在到達時就開始將其轉發出去。
此外，Ethereum Magicians 上的 EIP 討論將此計畫變更描述為以可獨立驗證的區塊取代 EIP-7732 的單一載荷訊息。該草稿目前提出 64 個區塊以及一個將每個片段綁定到原始載荷承諾的 Merkle 證明結構。研究人員表示，Merkle 承諾代表了基本分段所需的主要共識層新增內容。最新的研究原型保留了現有的 gossipsub 線路格式、網路網狀結構建構、對等節點度數與評分系統，同時改變了載荷片段的發布與轉發方式。
以太坊的文件目前將執行載荷描述為由執行客戶端產生並透過共識過程傳遞的交易與狀態相關資料。驗證者透過共識 gossip 網路接收提案區塊，然後將執行資料發送給其執行客戶端進行驗證。
模擬將 1 MiB 中位時間從五秒縮短
9 月 17 日報告中最強勁的效能數據來自一項受控模擬。研究人員使用地理網路延遲、50 Mbps 上傳容量與 100 Mbps 下載容量對 500 個節點進行建模，其中 1 MiB 載荷源自一個家庭建構者，且沒有高頻寬資料中心節點。
在該設定下，將載荷作為一個完整的 gossipsub 訊息發送，大約需要五秒才能到達半數接收節點，尾部則接近六秒。經過調校的分段版本達到約 0.75 秒的中位時間，尾部則接近一秒。
研究人員強調，這些測量數據來自一個模擬測試框架，該框架在模擬網路與虛擬時鐘上運行真實的 Prysm 與 go-libp2p-pubsub 程式碼。每次測量都使用了十種隨機化網路配置。主網條件可能與所建模的拓撲、頻寬與流量假設有所不同。
其基本的 Tier 1 設計結合了分段與批次發布。報告指出，使用 16 KiB 分段時，1 MiB 載荷的中位傳播時間從五秒降至一秒以下，而尾部延遲則從約六秒降至略高於一秒。
批次發布改變了來源傳送片段的方式。建構者不再是在開始下一段之前先傳送某一段的所有副本，而是提早將不同的片段分發給不同的對等節點，讓酬載的多個區段能同時開始在網路中傳輸。研究人員表示，相較於當今的整則訊息做法，第一層級需要多出約三分之一的接收位元組。這項取捨來自於傳送許多獨立識別的片段，以及為了公告這些片段所需的額外控制訊息。
更進階的層級可減少重複的網路流量
第二個提出的層級處理重複資料的問題。節點不再將每個區段推送給所有符合資格的網狀對等節點，而是可以將片段推送給有限的群組，同時向其他節點公告其可用性。對等節點僅在需要時才請求缺少的區段。
該原型將此系統與其作者所稱的「有紀律的拉取」結合。節點最初向一個對等節點請求某個區段，等待一段定義好的逾時時間，若第一個對等節點未能交付，則轉向另一個來源。
在 1 MiB 的酬載大小下，研究指出，有紀律的拉取將每個節點的接收流量降低至約 1.5 份酬載副本，相較於控制較不嚴謹的變體中明顯更多的重複流量。研究人員發現，當可用的上傳頻寬有限時，減少重複資料變得越來越有用。
這種做法帶來了另一個取捨。惡意或超載的對等節點可能公告某個區段，然後拒絕提供它。研究人員測試了一種扣留情境，其中某些節點宣傳了區段但未能回應請求。在較高的扣留程度下，調校過的拉取式設計顯示出尾延遲上升。作者測試了較短的逾時時間與多個可能的請求來源，作為限制此類暴露的方法。
他們的第三個層級加入了 Reed-Solomon 抹除編碼。酬載會被壓縮、以額外的同位片段編碼，並分割成區段。節點在收集到足夠的片段後即可重建酬載，無需等待每一個原始區段。
研究人員表示，在他們的測試中，編碼模型具有最低的尾延遲，且在某些區段被扣留時仍能運作。代價是發布來源的頻寬較高，因為同位資料增加了傳送的數量。
EIP-8411 現在面臨 Hegotá 納入討論
EIP-8411 目前並非已啟用的以太坊功能。該 GitHub 提案於 9 月 4 日開啟，仍標示為等待審查的網路 EIP 草案。該提案需要 EIP-7732，也就是以太坊的內建提案者－建構者分離設計。
以太坊開發者已要求 EIP-8411 取得 PFI（即「提議納入」）狀態，以納入 Hegotá，也就是預期在 Glamsterdam 之後的網路升級。在 9 月 10 日的全核心開發者執行層討論中，開發者表示該提案應由共識層開發者電話會議審議，因為此變更主要影響共識網路。
此請求是在正常的 Hegotá PFI 截止日期之後提出的。其支持者提出 EIP-8411 作為 EIP-8142 的替代方案，後者曾探索將區塊放入 blob，但引發了對建構者端 KZG 證明以及資料可用性子網重複使用的擔憂。
ACDC #187 議程安排了 9 月 17 日 14:00 UTC 的 EIP-8411 PFI 討論。截至本報導時，該電話會議尚未舉行，因此尚未記錄任何將 EIP-8411 納入 Hegotá 的決定。
開發者一直在縮減 Hegotá 在帳戶抽象、擴容、抗審查性及其他協議工作方面的功能集。EIP-8411 比許多提案更晚進入該流程，且仍需要核心開發者的納入決定。
這項網路提案與以太坊提升第一層容量的工作相關。更大的 gas 上限可能導致更大的執行酬載，增加驗證者必須在固定共識截止時間內接收的資料量。以太坊的 gas 上限在 2025 年底達到 6,000 萬，此前驗證者已表示支持該調升。
Vitalik Buterin 曾將更高的第一層容量、PeerDAS 及未來的 ZK-EVM 工作描述為以太坊擴容計畫的一部分。更快的酬載交付正與這些變更一同被研究，因為更大的網路訊息會對節點頻寬與傳播截止時間造成更大壓力。
原型程式碼已可使用但仍屬實驗性
研究人員已發布 Prysm 與 go-libp2p-pubsub 的原型實作。建議使用的 variant-a Prysm 分支包含一系列置於 –enable-segmented-payload-gossip 旗標之後的變更，而隨附的 libp2p 分支則實作了該研究中使用的轉發與請求策略。
作者明確地將其研究分支描述為「一套測試框架，而非一項提案」。論文中測量的某些功能，包括進階的糾刪碼配置，仍是測試環境中的實驗性元件，未必屬於最低限度的 EIP-8411 規範的一部分。
研究人員指出的未解問題包括：控制訊息流量增加、處理大量較小訊息所帶來的 CPU 成本、替代的片段對應方式、佇列管理、計時器調校，以及較新的 QUIC 導向網路堆疊是否會產生不同結果。
作者計畫進一步比較 variant A 所使用的單一主題設計、部分訊息方法，以及將個別片段指派至各自 gossip 主題的模型。目前的原型在模擬顯示較小的 8 KiB 片段並未帶來進一步的延遲改善、反而增加控制流量之後，仍以 16 KiB 片段作為其建議基準。
