以太坊EIP-8411测试实现亚秒级载荷传播

以太坊研究人员通过 EIP-8411 分段广播设计实现亚秒级传播

以太坊研究人员报告称，在使用 EIP-8411 的分段广播设计模拟传输 1 MiB 执行负载时，中位传播时间低于一秒。相比之下，如果将整个负载作为一个消息发送，传播时间约为五秒。

测试与核心机制

测试结果显示，对于 1 MiB 的负载，中位传播时间从五秒缩短至不足一秒。EIP-8411 将执行负载拆分为多个块（chunks），节点可以在完整接收之前验证并转发这些片段。执行出价中包含的默克尔根（Merkle root）允许节点独立验证每个接收到的负载片段。

原型测试使用了 500 个模拟节点、家庭宽带带宽、地理延迟以及十个随机化的网络种子进行验证。以太坊开发者将于 2026 年 9 月 17 日的 ACDC 会议上讨论将 EIP-8411 纳入 Hegotá 升级的可能性。

解决“存储-转发”瓶颈

以太坊研究于 9 月 17 日发布了最新测试结果，详细阐述了一种原型方案，该方案将执行负载分解为更小的部分，使节点在接收到完整负载之前即可验证并转发每个片段。这些发现基于仿真和原型客户端代码，而非以太坊主网的实际测量数据。

该提案目前仍属于以太坊 EIP 存储库中的“草案网络层 EIP”。其当前设计用“execution_payload_chunks”主题取代了通过 EIP-7732 引入的单执行负载 gossip 主题，并通过构建者（builder）执行出价中包含的默克尔根来提交各个片段。

以太坊现有的 gossip 模型可能要求节点在转发给对等节点之前，必须接收并验证大型消息。EIP-8411 的研究人员将由此产生的延迟描述为“存储-转发”问题，因为完整的负载必须在开始下一跳之前跨越一个网络跳数。

在分段传播机制下，构建者将负载划分为固定大小的片段。每个片段都携带与执行出价中提交的根相关的默克尔包含证明。接收节点可以检查其中一个片段，并在剩余片段仍在到达时就开始将其发送出去。

Ethereum Magicians 上的 EIP 讨论指出，计划中的更改是用可独立验证的片段替换 EIP-7732 的单条负载消息。草案目前提议使用 64 个片段和一个默克尔证明结构，将所有片段绑定到原始负载承诺上。研究人员表示，默克尔承诺是实现基本分段所需的主要共识层添加内容。

最新的 research prototype 保持了现有的 gossipsub 线格式、网络网格构建、对等节点度数和评分系统不变，仅改变了负载片段的发布和转发方式。

仿真数据显示显著性能提升

9 月 17 日报告中最强劲的性能数据来自受控仿真。研究人员使用地理网络延迟、50 Mbps 上传容量和 100 Mbps 下载容量对 500 个节点进行了建模，负载源为家庭构建者，且没有高带宽的数据中心节点。

在该设置下，作为单个完整的 gossipsub 消息发送负载，到达半数接收节点大约需要五秒，尾部延迟接近六秒。而经过调优的分段版本中位传播时间接近 0.75 秒，尾部延迟接近一秒。

研究人员强调，这些测量结果来自运行真实 Prysm 和 go-libp2p-pubsub 代码的仿真环境，针对的是模拟网络和虚拟时钟。每次测量均使用了十个随机化的网络配置。主网条件可能与模型的拓扑结构、带宽和流量假设存在差异。

Tier 1：分段与批量发布

其基础 Tier 1 设计结合了分段与批量发布。报告显示，使用 16 KiB 的片段，1 MiB 负载的中位传播时间从五秒降至一秒以下，尾部延迟从约六秒降至略高于一秒。

批量发布改变了源端发送片段的方式。构建者不再在开始下一个片段之前发送完所有副本，而是早期将不同的片段分发给不同的对等节点，从而允许负载的多个部分同时开始在通过网络中移动。研究人员指出，Tier 1 比当前的整消息方法多接收了约三分之一的字节。这种权衡来自于发送许多独立标识的片段以及用于宣布它们的额外控制消息。

高级层级减少重复网络流量

第二个提议的层级旨在解决重复数据问题。节点不再将每个片段推送给所有合格的对等节点，而是将片段推送给有限的一组节点，同时向其他节点宣布可用性。对等节点仅在需要时才请求缺失的片段。

该原型将此系统与作者所称的“纪律性拉取”（disciplined pulls）相结合。节点最初从一个对等节点请求一个片段，等待定义的超时时间，如果第一个对等节点未能交付，则转向另一个源。

在 1 MiB 负载大小下，研究表明，“纪律性拉取”将每个节点接收到的流量减少到约 1.5 个负载副本，而在控制较少的变体中，重复流量要多得多。研究人员发现，当可用上传带宽受限时，减少重复数据变得愈发重要。

这种方法带来了另一种权衡。恶意或过载的对等节点可能会宣布某个片段，然后拒绝提供它。研究人员测试了一种扣留场景，其中一些节点广告了片段但未能响应请求。在较高的扣留水平下，调优后的基于拉取的设计显示出尾部延迟上升。作者测试了更短的超时时间和多个可能的请求来源，以限制这种风险。

Tier 3：里德-所罗门纠错编码

第三个层级增加了里德-所罗门（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 议程安排在 UTC 时间 9 月 17 日 14:00 进行 EIP-8411 PFI 讨论。截至本报告撰写时，会议尚未举行，因此尚未记录将 EIP-8411 纳入 Hegotá 的决定。

开发者们正在精简 Hegotá 的功能集，涵盖账户抽象、可扩展性、抗审查性及其他协议工作。EIP-8411 进入该流程的时间晚于许多提案，仍需获得核心开发者的纳入决定。

与 Layer 1 容量提升紧密相关

该网络提案与以太坊提高 Layer 1 容量的工作密切相关。更高的 Gas 限制可能导致更大的执行负载，从而增加验证者在固定的共识截止时间内需接收的数据量。

2025 年底，在验证者表示支持增加后，以太坊的 Gas 限制达到了 6,000 万。Vitalik Buterin 曾将更高的 Layer 1 容量、PeerDAS 和未来的 ZK-EVM 工作描述为以太坊扩展计划的一部分。随着网络消息变大，对节点带宽和传播截止时间的压力增加，因此正在研究与这些变化并行执行的更快负载交付方案。

原型代码可用但仍属实验性质

研究人员已发布了针对 Prysm 和 go-libp2p-pubsub 的原型实现。推荐的变体 A 是一个 Prysm 分支，包含一系列位于 `--enable-segmented-payload-gossip` 标志背后的更改，而配套的 libp2p 分支实现了研究中使用的转发和请求策略。

作者明确将其研究分支描述为“一种工具，而非提案”。论文中测量的某些功能，包括高级纠错编码配置，仍然是测试环境的实验性组件，不一定属于最小 EIP-8411 规范的一部分。

研究人员确定的未决问题包括：控制消息流量的增加、处理许多较小消息带来的 CPU 成本、替代的片段映射、队列管理、定时器调优，以及更专注于 QUIC 的新网络栈是否会产生不同结果。

作者计划进一步比较变体 A 使用的单主题设计、部分消息方法以及为单个片段分配单独 gossip 主题的模型。目前的原型将 16 KiB 片段作为推荐基线，因为仿真显示更小的 8 KiB 片段并未带来进一步的延迟增益，反而增加了控制流量。