以太坊 EIP-8411 测试 sub-1s 有效负载传播
核心要点
- 以太坊研究人员报告称,使用 EIP-8411 的分段广播设计,模拟 1 MiB 执行有效负载的传播中值不到一秒,而将有效负载作为一条消息发送时大约需要 5 秒。
- 以太坊研究中心于 9 月 17 日发布了最新的测试结果,详细介绍了一个原型,该原型将执行有效负载分解为更小的部分,以便节点可以在接收完整有效

以太坊研究人员报告称,使用 EIP-8411 的分段广播设计,模拟 1 MiB 执行有效负载的传播中值不到一秒,而将有效负载作为一条消息发送时大约需要 5 秒。
摘要 测试将 1 MiB 有效负载的中值传播时间从 5 秒减少到 1 秒。
EIP-8411 将执行有效负载分割成节点可以在完全完成之前验证和转发的块。
执行投标中的 Merkle 根允许节点独立验证每个接收到的有效负载段。
原型测试使用了 500 个模拟节点、住宅建筑商带宽、地理延迟和 10 个随机网络种子。
以太坊开发者将于今天 2026 年 9 月 17 日在 ACDC 讨论 EIP-8411 以将 Hegotá 纳入其中。
以太坊研究中心于 9 月 17 日发布了最新的测试结果,详细介绍了一个原型,该原型将执行有效负载分解为更小的部分,以便节点可以在接收完整有效负载之前验证和转发每个片段。研究结果来自模拟和原型客户端代码,而不是以太坊主网测量。
该提案仍然是以太坊 EIP 存储库中的网络 EIP 草案。其当前的设计将通过 EIP-7732 引入的单个execution_payload 八卦主题替换为execution_payload_chunks 主题,并通过构建器执行投标中包含的 Merkle 根提交片段。
您可能还喜欢:以太坊价格复苏取决于 2,526 美元的突破
以太坊 EIP-8411 消除了整个有效负载的等待
以太坊现有的八卦模型可能要求节点在将大消息转发给对等点之前接收并验证大消息。 EIP-8411 背后的研究人员将由此产生的延迟描述为存储转发问题,因为完整的有效负载必须穿过一个网络跃点才能开始下一个网络跃点。
通过分段传播,构建者将有效负载划分为固定的部分。每个段都带有一个 Merkle 包含证明,该证明与执行投标中提交的根相关联。接收节点可以检查一个数据段并开始向前发送,而其余数据块仍在到达。
此外,以太坊魔术师上的 EIP 讨论将计划的更改描述为用独立可验证的块替换 EIP-7732 的单个有效负载消息。该草案目前提出了 64 个块和一个 Merkle 证明结构,将每个块与原始有效负载承诺绑定在一起。研究人员表示,Merkle 承诺代表了基本分割所需的主要共识级别的补充。最新的研究原型保持了现有的 gossipsub 线路格式、网络网状结构、同行程度和评分系统完好无损,同时改变了有效负载片段的发布和转发方式。
以太坊的文档目前将执行有效负载描述为由执行客户端生成并通过共识流程进行的交易和状态相关数据。验证者在将执行数据发送到执行客户端进行验证之前,通过共识八卦网络接收提议的区块。
模拟将 5 秒的中位数缩短了 1 MiB
9 月 17 日报告中最强劲的性能数据来自受控模拟。研究人员使用地理网络延迟、50 Mbps 上传能力和 100 Mbps 下载能力对 500 个节点进行建模,其中 1 MiB 有效负载来自住宅建筑商,并且没有高带宽数据中心节点。
在这种设置下,将有效负载作为一条完整的 gossipsub 消息发送大约需要 5 秒才能到达一半的接收节点,并且在尾部需要接近 6 秒的时间。经过调整的分段版本的中位数接近 0.75 秒,尾部接近 1 秒。
研究人员强调,测量结果来自针对模拟网络和虚拟时钟运行真实 Prysm 和 go-libp2p-pubsub 代码的模拟工具。每次测量都使用十个随机网络配置。主网条件可能与建模的拓扑、带宽和流量假设不同。
他们的基本第一层设计将分段与批量发布结合起来。该报告称,使用 16 KiB 段,1 MiB 有效负载的中值传播从 5 秒降至不到 1 秒,而尾部延迟从大约 6 秒降至略多于 1 秒。
批量发布改变了源发送片段的方式。构建器不是在开始下一个分段之前发送一个分段的每个副本,而是尽早将不同的分段分发给不同的对等点,从而允许有效负载的多个部分立即开始在网络中移动。研究人员表示,第一层所需的接收字节数比当今的整个消息方法多大约三分之一。权衡来自于发送许多独立识别的片段以及宣布它们所需的额外控制消息。
更高级的层减少了重复的网络流量
建议的第二层处理重复数据。节点可以将片段推送到有限的组,同时向其他人宣布可用性,而不是将每个片段推送到所有符合条件的网格对等体。对等方仅在需要时才请求丢失的段。
该原型将该系统与其作者所说的纪律拉动结合起来。节点最初从一个对等点请求一个段,等待定义的超时,如果第一个对等点无法交付,则移动到另一个源。
研究表明,在 1 MiB 有效负载大小下,严格的拉动将每个节点接收到的流量减少到大约 1.5 个有效负载副本,而在受控程度较低的变体中,重复流量要多得多。研究人员发现,当可用上传带宽有限时,减少重复项变得越来越有用。
这种方法造成了另一个权衡。恶意或过载的对等方可能会宣布一个分段,然后拒绝提供它。研究人员测试了一种扣留场景,其中一些节点通告了分段,但未能响应请求。在较高的预扣水平下,基于调整的拉式设计显示出尾部延迟增加。作者测试了更短的超时和多个可能的请求源作为限制这种暴露的方法。
他们的第三层添加了里德-所罗门擦除编码。有效负载被压缩,用额外的奇偶校验块进行编码并分成段。节点可以在收集足够的片段后重建有效负载,而无需等待每个原始片段。
研究人员表示,编码模型在测试中具有最低的尾部延迟,并且在某些片段被保留时仍能正常工作。代价是发布源的带宽更高,因为奇偶校验数据增加了发送量。
EIP-8411 现在面临 Hegotá 纳入讨论
EIP-8411 目前不是激活的以太坊功能。 GitHub 提案于 9 月 4 日开放,并仍被标记为等待审核的网络 EIP 草案。该提案需要 EIP-7732,这是以太坊所奉行的提案者-构建者分离设计。
以太坊开发人员已要求 EIP-8411 获得 Hegotá 的 PFI(或提议纳入)状态,这是 Glamsterdam 后预计的网络升级。在 9 月 10 日的所有核心开发人员执行讨论中,开发人员表示该提案应由共识层开发人员电话会议考虑,因为这一更改主要影响共识网络。
该请求是在 Hegotá PFI 正常截止日期之后提出的。其支持者提议 EIP-8411 作为 EIP-8142 的替代品,EIP-8142 探索了将块放入 blob 中,但引起了对构建器端 KZG 证明和数据可用性子网重用的担忧。
ACDC #187 议程安排于 9 月 17 日 14:00 UTC 进行 EIP-8411 PFI 讨论。在撰写本报告时,电话会议尚未进行,因此尚未记录将 EIP-8411 纳入 Hegotá 的决定。
开发人员一直在缩小 Hegotá 的功能集,包括账户抽象、扩展、审查阻力和其他协议工作。 EIP-8411 比许多提案更晚进入该流程,并且仍然需要核心开发人员纳入决策。
该网络提案与以太坊提高第一层容量的工作相关。较大的 Gas 限制可能会导致更大的执行负载,从而增加验证者在固定共识期限内必须接收的数据量。在验证者表示支持增加后,以太坊的 Gas 限额在 2025 年底达到了 6000 万。
Vitalik Buterin 描述了更高的 Layer 1 容量、PeerDAS 和未来的 ZK-EVM 工作作为以太坊扩展计划的一部分。随着这些变化,我们正在研究更快的有效负载传输,因为更大的网络消息对节点带宽和传播期限带来更大的压力。
原型代码可用,但仍处于实验阶段
研究人员已经发布了 Prysm 和 go-libp2p-pubsub 的原型实现。推荐的变体 -a Prysm 分支包含 –enable-segmented-payload-gossip 标志后面的一系列更改,而随附的 libp2p 分支实现了研究中使用的转发和请求策略。
作者明确地将他们的研究分支描述为“一个工具,而不是一个提案”。本文中测量的一些功能(包括高级纠删码配置)仍然是测试环境的实验组件,不一定是最低 EIP-8411 规范的一部分。
研究人员发现的悬而未决的问题包括控制消息流量的增加、处理许多较小消息的 CPU 成本、替代段映射、队列管理、计时器调整以及以 QUIC 为中心的新型网络堆栈是否会产生不同的结果。
作者计划进一步比较变体 A 使用的单主题设计、部分消息方法和将单独的八卦主题分配给各个片段的模型。在模拟显示较小的 8 KiB 片段在增加控制流量的同时不会产生进一步的延迟增益之后,当前原型将 16 KiB 片段保留为建议的基线。
