以太坊的一个区块实际上由两套结构拼成：共识层的信标区块记录谁在何时提议、证明怎么聚合；执行层的执行载荷装着交易、收据和状态承诺。节点同步历史时，两层通常各要下载一遍完整内容。EIP-8237（2026 年 4 月创建，草案）提出一个字段级改动：让共识层凭一条哈希就能核对”该自己核对的东西”，而不必先下载每份区块正文。
一个字段与一条哈希链
提案的载体叫 partial_header_hash：一个 SHA-256 累加器，把执行载荷里需要共识层独立校验的那些字段按固定顺序逐个卷进哈希——每遇到一个新字段，就把当前链值与这个字段联合再哈希，走到头得到总结算。它出现在两个容器里：在执行层的 ExecutionPayload 中是新增字段；在 EIP-7732（ePBS，把提议与打包在协议里分离的提案）定义的 ExecutionPayloadBid 中，它顶替了原来的 execution_requests_root。含义随之分两层：执行层交付载荷时，累加器让共识层一次性确认所有受约束字段没被替换；信标区块体里带着这条链的终值，共识层校验一段历史时只需重放累加器，区块正文可以之后再取、甚至交给别的程序。
为什么系在 ePBS 上
今天的结构里，执行层要共识层过目的字段零散嵌在信标区块头各处（状态根、收据根等等），每多一个就要再长一块固定空间。ePBS 把”先认领打包好的区块承诺、后交付正文”做成协议动作后，本提案顺势把这些散点收拢成可枚举、可按序哈希的清单：日后想给共识层再加核对项，改的是累加器的字段列表而不是区块头的物理布局。这也是它被概括为”两层各追各的”的原因——共识层跑完信标侧校验，执行数据的完整性由累加器兜底，范围同步第一次在协议层与正文下载解了耦。
链式结构的甜与苦
累加器的优点是便宜且免密钥：两个字段值一样、顺序不一样，终值就不同，篡改任何一环后面的链全断。缺点是排错粒度粗：对不上时只知道”清单 somewhere 错了”，实现要按字段顺序二分定位。它与默克尔树是互补物：树擅长”只证明一片叶子”，链擅长”整体一次核完”，而共识层对执行载荷的需求恰好像后者。
一次历史同步的对照账
拿一个只关心共识侧的归档任务来算。今天的流程：按区块下载执行载荷（正文加收据根那一堆）、交执行层校验、再落库；一个区间下来，载荷占了带宽的大头，而多数载荷对「把信标链历史跑直」这件事只有校验价值。走通 8237 的流程后：拉一段信标区块头，对每个块从 Bid 里取 partial_header_hash，本地重放累加器，全绿即可确认执行侧字段未被篡改；正文要么之后补齐，要么对纯信标任务干脆不要。省下的正是那笔「为了核对而搬运」的流量。另一侧的账也公平：客户端要多养一个累加器实现，字段清单变更时要跨实现同步顺序表；哈希链的排错粒度粗，一次失配得按清单二分找错处。两本账摆在一起，这条路线值不值，取决于社区多常有「只要共识层对账」的任务——这也是它被归进 ePBS 家族而不是独立提案的原因。
快速问答
问：普通用户要改什么吗？ 答：不需要。这是客户端之间的同步协议改造，与钱包、交易格式无关。
问：字段为什么同时动两个容器？ 答：Bid 覆盖”只有承诺没有正文”的认领场景，Payload 覆盖”正文到手”的交付场景，两处取值必须一致。
问：和 EIP-7732 什么关系？ 答：它修改 7732 定义的数据结构，ePBS 不落地它就无从生效；两者都是草案。
风险提示：本文描述尚未激活的协议草案，不构成任何投资建议；字段与容器细节以当期提案文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。