以太坊历史里有一段时间格外沉重：从2015年创世到2022年9月合并，七年多间的工作量证明区块靠一条规则串着——每个区块头引用前一块的哈希。这条链式结构意味着想验证某天的余额，理论上要从创世起逐块执行。历史过期类提案允许节点不再保存全部历史，那么新的问题冒出来：放弃存储的人，怎么向别人证明历史没有被动过手脚？停滞提案EIP-7643把合并前的那段历史装进一个SSZ累加器，用一个承诺根代替逐块执行。
累加器的形状
提案把合并前的历史切成固定大小的纪元：每个纪元装八千一百九十二个区块的记录，每条记录只有一个区块哈希和一个总难度值，两个字段。单个纪元的记录表是一个列表，再把这些列表按顺序卷成树状结构，最终承诺出一个根。提案正文直接给出了期望的累加器根值，作为全网共同的校验基准。
结构里有两个决定值得玩味。第一，记录对象是区块哈希而不是完整区块。区块哈希本身压缩了该区块全部内容的承诺，验证者只要对可疑区块本地计算哈希、与记录比对，就确认了它被记录在案；这比封存原始区块省了数个数量级的空间，却把完整性证明保留了下来。第二，每条记录带总难度。合并前的链身份靠累计难度判断哪条链更重，丢掉总难度就等于丢掉了那条时代的一条共识语义，累加器把它一并存档，历史查询工具因此还能按旧规则回答最长有效链类问题。
两种用法，一根封条
提案列出这个根的两类用途。第一类面向下载验证：想核对合并前数据的人可以下载原始数据，本地重算每条区块哈希并累加，比对本地算出的根与协议规定的根。一次哈希运算加一次比对，替代了逐块重放执行——前者是纯算术，后者要求完整执行环境。第二类面向证明尺寸：当累加器以默克尔树形态存在，对某个纪元内某区块是否在案的证明按对数增长，而不用把整段历史搬上链或塞进证明。
这正是历史过期蓝图的配套件：共识层的信标链持续为合并后的历史提供历史根承诺，合并前那段若无此类结构，就成了过期方案无法覆盖的尾巴。EIP-7643把尾巴也缝进承诺体系，验证链条从此完整。
不过提案本身停在停滞状态，截至本次核查没有推进迹象。这也在提醒我们：历史数据的长期守护者从来不只是协议，社区档案库、归档节点运营方、学术项目共同构成了这条数据的实际存续线。
快速问答
问：普通节点运营者需要做什么？ 答：不需要立即做什么。历史数据被放弃的前提是承诺体系就绪，提案停滞期间过期方案不会默认覆盖这段历史。
问：怎么验证合并前某个区块没被伪造？ 答：下载方需要区块头，本地计算区块哈希并核对它是否落在累加器某个纪元记录里，再比对累加器根。
问：这个根存在哪里？ 答：提案给出的做法是写入创世与协议常量层面，作为共识可访问的基准值；具体落地位置以推进后的规格为准。
一笔直觉账
把七年历史逐块重放比作重读整套银行流水，累加器像流水装订线上一枚带编号的钢印：平时不看，核对时一验便知整本是否原装。
风险提示：本文内容为协议机制科普，不构成任何投资建议；历史数据方案仍在讨论，以官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。