以太坊研究人员报告称，使用 EIP-8411 的分段广播设计，模拟的 1 MiB 执行负载的中位传播时间低于一秒，而将负载作为单条消息发送时大约需要五秒。
摘要
- 测试将 1 MiB 负载的中位传播时间从五秒缩短到一秒以下。
- EIP-8411 将执行负载拆分为多个块，节点可以在完全接收之前验证并转发这些块。
- 执行出价中的 Merkle 根让节点能够独立验证每个接收到的负载段。
- 原型测试使用了 500 个模拟节点、家庭构建者带宽、地理延迟和十个随机网络种子。
- 以太坊开发者将于 2026 年 9 月 17 日在 ACDC 上讨论 EIP-8411 是否纳入 Hegotá。
以太坊研究于 9 月 17 日发布了最新测试结果，详细介绍了一个原型，该原型将执行负载分解为更小的片段，以便节点在接收完整负载之前验证并转发每个段。这些发现来自模拟和原型客户端代码，而非以太坊主网测量。
该提案目前仍是以太坊 EIPs 仓库中的草案网络 EIP。其当前设计将 EIP-7732 引入的单一 execution_payload gossip 主题替换为 execution_payload_chunks 主题，并通过构建者执行出价中包含的 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 个有效载荷副本，而在控制较少的变体中重复流量要多得多。研究人员发现，当可用上传带宽有限时，减少重复变得越来越有用。
这种方法带来了另一个权衡。一个恶意或过载的对等节点可以通告一个片段，然后拒绝提供它。研究人员测试了一种扣留场景，其中一些节点通告了片段但未能响应请求。在较高的扣留水平下，经过调优的基于拉取的设计显示出尾部延迟上升。作者测试了更短的超时和多个可能的请求来源，作为限制这种风险的方法。
他们的第三个层级增加了里德-所罗门纠删码。有效载荷被压缩，用额外的奇偶校验片段进行编码，并分成多个片段。节点在收集到足够的片段后即可重建有效载荷，而无需等待每一个原始片段。
研究人员表示，编码模型在他们的测试中具有最低的尾部延迟，并且在一些片段被扣留时仍能保持功能。代价是发布源处的带宽更高，因为奇偶校验数据增加了发送量。
EIP-8411 现在面临 Hegotá 纳入讨论
EIP-8411 目前并不是一个已激活的以太坊功能。该 GitHub 提案于 9 月 4 日开启，目前仍标记为等待审查的 Draft 网络 EIP。该提案需要 EIP-7732，即以太坊的铭刻式提议者-构建者分离设计。
以太坊开发者已请求 EIP-8411 获得 PFI，即“提议纳入”状态，以纳入 Hegotá，这是预计在 Glamsterdam 之后进行的网络升级。在 9 月 10 日全核心开发者执行讨论中，开发者表示该提案应由共识层开发者电话会议审议，因为该变更主要影响共识网络。
该请求是在正常的 Hegotá PFI 截止日期之后提出的。其支持者提议 EIP-8411 作为 EIP-8142 的替代方案，后者曾探索将区块放入 blob，但引发了对构建者侧 KZG 证明和数据可用性子网复用的担忧。
ACDC #187 议程将 EIP-8411 PFI 讨论安排在 9 月 17 日 14:00 UTC。截至本报告发布时，该电话会议尚未举行，因此尚未记录将 EIP-8411 纳入 Hegotá 的任何决定。
开发者一直在收窄 Hegotá 在账户抽象、扩容、抗审查和其他协议工作方面的功能集。EIP-8411 进入该流程的时间晚于许多提案，仍需要核心开发者的纳入决定。
该网络提案与以太坊提高第一层容量的工作相关。更大的 gas 上限可能导致更大的执行有效载荷，增加验证者在固定共识截止时间内必须接收的数据量。以太坊的 gas 上限在 2025 年底达到 6000 万，此前验证者表示支持这一增长。
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 分片保留为其推荐基线。
