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