导语：以太坊研究论坛 Ethereum Research 9月17日发布的模拟结果显示，EIP-8411 的分段广播设计可将 1 MiB 执行负载的中位传播时间从约 5 秒降至 1 秒以下。不过，这些结果来自模拟和原型客户端代码，而非以太坊主网实测；EIP-8411 目前仍是 Draft 网络提案，并依赖 EIP-7732，即网络内置的提议者-构建者分离设计。
测试结果
在原型测试中，1 MiB 负载的中位传播时间由 5 秒降至不到 1 秒。调优后的分段版本在受控模拟中中位接近 0.75 秒，尾部延迟接近 1 秒。相比之下，整消息方案达到一半接收节点约需 5 秒，尾部接近 6 秒。研究人员使用 500 个模拟节点、地理位置延迟、50 Mbps 上传和 100 Mbps 下载能力、家庭构建者作为源，以及 10 组随机网络配置。
EIP-8411 如何工作
以太坊现有 gossip 模型可能要求节点先接收并验证大消息，再转发给对等节点，形成存储转发的延迟问题。EIP-8411 将执行负载拆分为可验证并转发的分块，节点无需先收到完整负载。当前设计以 execution_payload_chunks 话题替代 EIP-7732 引入的单一 execution_payload gossip 话题。构建者执行出价中的 Merkle 根承诺各分块，每个接收到的负载段附带与该根关联的 Merkle 包含证明。草案提出 64 个分块，以及将每个分块绑定至原始负载承诺的 Merkle 证明结构。研究人员称，Merkle 承诺是基础分段所需的主要共识层新增内容。原型保留现有 gossipsub 线格式、网络 mesh 构建、对等节点度和评分系统，仅改变负载分块的发布与转发方式。
模拟与分层设计
9月17日报告描述了使用真实 Prysm 和 go-libp2p-pubsub 代码、针对模拟网络和虚拟时钟运行的测试框架。研究人员提醒，主网条件可能与建模的拓扑、带宽和流量假设不同。
基础 Tier 1 设计结合分段与批量发布。使用 16 KiB 分段时，1 MiB 负载中位传播从 5 秒降至不到 1 秒，尾部延迟从约 6 秒降至略高于 1 秒。批量发布让源节点尽早向不同对等节点分发不同分块，而不是先发送某个分块的所有副本。研究人员称，Tier 1 接收字节量比当前整消息方案多约三分之一。
Tier 2 针对重复流量。节点将分块推送给有限群体，同时向其他节点宣告可用性，对等节点仅在需要时请求缺失分块。原型将其与“有纪律的拉取”结合：节点最初向一个对等节点请求分块，超时后若失败则转向另一来源。研究称，在 1 MiB 负载下，有纪律的拉取将每节点接收流量降至约 1.5 个负载副本。代价是恶意或过载对等节点可能宣告分块后拒绝提供；测试中更高的扣留水平会增加尾部延迟。
Tier 3 增加 Reed-Solomon 纠删码。负载被压缩、加入额外奇偶校验分块并分割成段。节点在收集足够分块后可重建负载，无需等待每个原始分块。研究人员称，编码模型在测试中尾部延迟最低，并能在一部分分块被扣留时保持功能，但由于奇偶校验数据增加发送量，发布源带宽也会上升。
Hegotá 纳入讨论
EIP-8411 目前并非已激活的以太坊功能。该 GitHub 提案于 9月4日开启，仍标记为等待审查的 Draft 网络 EIP。开发者已为 Glamsterdam 之后预期推出的网络升级 Hegotá 请求 PFI（Proposed for Inclusion，拟纳入）状态。在 9月10日 All Core Developers Execution 讨论中，开发者表示该提案应由共识层开发者电话会议考虑，因为该变更主要影响共识网络。该请求在正常 Hegotá PFI 截止日期之后提出。支持者提出 EIP-8411 作为 EIP-8142 的替代方案；后者曾探索将区块放入 blobs，但引发构建者侧 KZG 证明和数据可用性子网复用方面的担忧。ACDC #187 议程安排 9月17日 14:00 UTC 讨论 EIP-8411 PFI。截至该报道，电话会议尚未举行，因此未记录纳入决定。开发者一直在收窄 Hegotá 在账户抽象、扩展、抗审查及其他协议工作方面的功能集。EIP-8411 进入流程晚于许多提案，仍需核心开发者纳入决定。该网络提案与以太坊提高 Layer 1 容量相关：更高 gas 限制可能带来更大执行负载，并增加验证者在固定共识截止时间内必须接收的数据。以太坊 gas 限制在 2025 年末达到 6000 万，此前验证者信号支持提高。Vitalik Buterin 将更高 Layer 1 容量、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 分块作为推荐基线。