今天一个区块是怎么传的
2022 年合并之后，以太坊的出块结构分成两层：共识层的信标块负责证明与投票信息，执行层的执行载荷装着这一轮实际打包的交易列表。在现行规格里，执行载荷作为信标块体内部的一个字段整体嵌入——传播一个区块，等于传播一个装着全部交易的信封。验证者要判断这个区块，得把信封连同里面的交易一起处理。EIP-7898 的提议听起来像拆包裹：信标块体里不再塞完整的执行载荷，只放它的头部摘要，交易数据以独立的载体形式另行传输，规范里称之为带包含证明的执行载荷。
拆分想换来什么
提案文本给出的价值有两层。一层是共识层的解耦收益：信标节点的验证焦点回到信标块本身的签名与结构，执行数据可以走另一条传播路径，两条路径各自优化。另一层是可用的包含证明：独立传输的执行载荷自带证明，轻客户端不必下载整块交易数据，也能核验某笔交易确实被这个区块包含。提案作者特意强调，这个方案和 ePBS 一类拆 epoch 的方案不同：它不改变区块的导入机制，也不把提案者与构建者分离，只是把可用性定义扩展为同时等待独立载荷的到达——技术上比拆周期简单得多。同时提案留了口子：只有在 gossip 实时传播场景需要等载荷到达，走检查点同步或范围同步的节点仍可以像现在一样由执行层主动拉块，不必被迫等待。
为什么要标注它停滞了
读这份 EIP 必须直面的事实是状态栏：官方仓库中它被标记为 Stagnant，即停滞。EIP 仓库的惯例是，长期缺乏讨论、实现或推进动力的草案会被维护者移入这一状态，它不等于被正式拒绝，但意味着没有活跃的开发与审议在把它往前推。理解这一状态要放回语境：拆执行载荷的收益在合并后的架构里并非无可替代，相关的解耦诉求同时存在于 ePBS、单槽时间线等多条更宏大的路线里，社区对先做哪个存在优先级分歧。一份结构清晰的提案在更大的路线之争里暂缓，是 EIP 史上常见的命运。
对普通用户意味着什么
这份提案不改变任何用户能感知的东西：转账格式、Gas 规则、确认逻辑都与它无关。它属于节点通信与验证结构层面的工程选项。读者从这篇文章里值得带走的是方法而非结论：看到某个改进型 EIP 处于停滞，正确读法不是功能被否决，也不是团队失败，而是该需求暂时被其他路线吸收或延后。判断链的演进方向，盯已排期的升级与其包含的 EIP 列表，比盯单份草案的状态变化更可靠。
风险提示：本文为共识层协议机制的技术介绍，不构成投资建议，不构成对以太坊路线图任何时间表的预测。相关升级以官方公告为准。
头部里到底留了什么
被留在信标块里的执行载荷头部，保留的是承诺类字段：父区块哈希、状态根、收据根这类摘要信息，交易的逐条明细则被挪到独立载体里，随附一段可验证的包含证明，使轻客户端能核验某笔交易确在该块而无需下载全部交易。这个思路在以太坊的路线图里并不孤单：信标链与执行链各自成熟后，哪些字段必须同块传输、哪些可以晚到一步，是持续被讨论的工程题。同一方向上还有对单槽时间线、执行层与共识层解耦的更大胆提案，对照阅读能看清 EIP-7898 的定位——它是这条路上刻意选小的版本：不重排时间线、不拆 proposer 与 builder，甚至不要求等待载荷才承认区块可用，只在 gossip 传播路径上加一个可用性条件。小改动换来小风险，也难怪它的推进可以完全独立于路线之争。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。