区块头里的状态根迟一拍：EIP-7862 的延迟状态根方案

一句话定位

EIP-7862 由 Paradigm 与以太坊基金会的研究者在 2024 年 12 月 23 日提出，截至本文撰写时状态为 Draft。它的处方只有一句话：区块头里的 state_root 字段不再指向本区块执行完的状态，而是指向上一个区块执行完的状态。不加新字段、不改哈希算法，只改一个字段的语义——用一拍延迟把以太坊最重的一笔计算从关键路径上摘下来。

状态根为什么卡在关键路径

每出一个块，构建者都要在状态树上重算一遍根哈希：所有被交易触碰的节点沿路径重新哈希，聚合出一个承诺整个账户世界最新快照的值。并行执行越彻底，这个归并哈希的尾巴越显眼——许多执行可并行，但默克尔聚合天然接近串行。更糟的是在 MEV 拍卖语境下，构建窗口被压得很短，构建者要在拍卖截止前同时完成执行和算根，两个环节都被哈希尾巴拖住。

迟一拍之后发生什么

按提案，第 n 块的 state_root 存的是第 n-1 块的执行后状态，等价于第 n 块的执行前状态。验证者收到区块时，要核对的状态根来自已经彻底结束的上一块，算好了、不用再等；他们投票不再押注于一个还在计算中的哈希。构建者侧的账也变了：每个槽位只需为一个区块算根（补交上一块的），而不是在拍卖窗口里为成百上千个候选区块各算一遍，提案原话是从每槽数千次降到一次。配合 EIP-7928 的区块级访问列表，算根还能借上一块预知的键集做并行分片。

为延迟付的账

天下没有免费的时延。第一笔账在轻客户端：想要第 n 块执行后状态的证明，得多等一个槽位——状态可用性整体右移一拍。第二笔账在语义教育：所有依赖”区块头状态根即本块结果”的索引器、资源管理器与协议注释都要改读法，字段名没变含义变了，是最容易滋生静默错误的一类改动。第三笔账与 ePBS 咬合：提案的动机段明确把自己和 7732 的更紧构建时限、7928 的并行化摆在同一条演进线上，三者谁先谁后、能不能分步上，都会改变各自的设计细节。

一条观察线

把执行结果变成可延迟承诺，是协议设计里少见的优雅一手：不消除工作，只是把工作挪出别人的等待时间。同类思路在分布式系统里反复出现——日志系统先接受写入再刷盘，数据库先返回预提交再确认。以太坊此前不敢动状态根，因为验证模型把”根必须即时”当成了信任地基。这份提案重新审视了那条地基其实需要多硬：如果投票核对的对象本来就该是确定的过去而非正在成形的现在，迟一拍损失的只是新鲜度，动不了的从来不是安全性，而是所有人的读表习惯。

快速问答

问：这是说状态根可以不诚实吗？ 答：不是。根仍然必须与执行结果一致，只是它承诺的对象从”本块之后”改成”上一块之后”，一致性检查平移一格。

问：轻客户端要多等多久？ 答：按提案的安全考量，状态证明多等一个槽位，约十二秒。

问：这个提案被排进升级了吗？ 答：截至本文撰写时仍是 Draft，未进入任何已命名升级的收录清单。

一个常见误会

常有人以为延迟状态根等于取消状态根，或者类似缓存那样的尽力而为。都不是——共识仍逐块验证状态转换，只是把聚合哈希的截止时间松开一拍。给一切实时系统松绑的钥匙往往不是删掉检查，而是想清楚每个检查究竟必须紧到哪个时刻。

风险提示：本文仅作技术科普，不构成任何投资建议。