哈希是单向的：从原文能算出指纹，从指纹推不回原文。以太坊的状态树整个建立在指纹上——键先哈希、节点靠哈希互指。平时这没问题，但一旦要对这棵做了几亿笔交易的树动结构手术（比如从十六叉的patricia树改成别的形态），问题来了：新树要求按原文重新组织键值，可节点手里只有满地哈希。那些在旧树时代被写进节点地址、再没被回访过的存储槽，它们的原文去哪找？EIP-6873在2023年4月给出的是一条预防性命令：所有执行层客户端，必须从”Verge前一个分叉”起，保存自己产生过的每一个地址哈希和槽哈希对应的原像。
原像是什么、为什么要留
术语里，原像（preimage）就是哈希前的那份原文：某个账户的地址、某个存储槽的完整键。节点日常执行交易时不断顺手算出这些哈希，但通常算完就把原文丢了——数据库里存键值对、树上存指纹，本来就是省地方的做法。可结构迁移本质上是一次全库重排：你必须能回答”这个指纹当初对应什么明文”。如果一个节点从没保存原像，它就无法独立把旧树换算成新树，只能去求别的节点帮忙——而”别人帮忙转换”恰恰违背了以太坊每节点独立验证的底线。所以提案把义务定得很干脆：在T_p到T_v两个分叉时间戳之间的所有区块，客户端生成过的每个地址/槽哈希，其原像必须落盘；这段时间之外存不存则自愿。
一份带保质期的义务
这份义务不是永久的：它只覆盖”上一个分叉到Verge本身”的窗口。窗口之前的历史原像，指望的是链上交易数据里本来就有的痕迹与归档方案；窗口之后，新结构自己接管一切。这种限时设计是为磁盘算的——原像库等于把键再明文存一份，是无状态路线上一笔公认的隐性负担。提案作者Guillaume Ballet把6873挂在自己牵头的历史过期与状态转换讨论下，后续Verkle路线被统一二叉树方案接替、整条时间线多次改道，6873因此长期停在Stagnant：机制仍然成立，落地时刻表却一直没敲定。
快速问答
问：节点现在默认保存原像吗？ 答：主流客户端近年为支持树证明确实引入了键值数据库（原像库），但那是各自的功能演进，不等于6873这条义务已被激活。 问：丢了原像的节点会怎样？ 答：无法独立参与依赖原像的结构迁移，只能重新同步或借助可信快照——这正是提案要避免的被动局面。 问：这跟EIP-4444历史过期矛盾吗？ 答：方向互补：一个清理不再需要的远古历史，一个保留恰恰需要的键原文，共同刻画”节点该存什么”的边界。
一把钥匙的比喻
把状态树想成一栋每间房都只挂指纹锁的大楼：门禁系统里存的全是哈希，住过谁、门牌号原文是什么，物业平时并不记录。某一天大楼要整体换锁芯——从十六进制的排房规矩改成二叉排房规矩，新锁芯要求按门牌号原文重新建档。这时没有保存过原文的物业只有一条路：挨家敲门问”您当初登记的号码是多少”。问题在于，这栋楼的设计哲学是每个物业管理员必须独自完成点验，不能外包给隔壁物业，否则整栋楼的独立性就没了。6873相当于在换锁公告发布前两年就下达的物业条例：从即日起，凡是你亲手打印的指纹，纸样必须留档。留档两年，换锁完成，义务解除——晚打印的房号由新系统直接记录原文，早年那些房间的原文则交给链上历史与归档系统兜底。
风险提示：本文讨论协议演进机制，不构成投资建议；节点存储行为请以各客户端当期文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。