把以太坊的世界状态从十六进 Patricia trie（MPT）搬到分区二叉树（PBT，EIP-8297 定义的新树形）——几何问题不难，难的是搬法：几十 GB 的状态、几万台节点、每 12 秒还在继续写。如果切换块当天每个节点各自“现切”，没人能保证各家的树长得一样，升级本身就成了全网最大的一次事故源。EIP-8347 的答案是别让状态迁移上链：全部在链下完成，链上只保留一个“双方对答案”的时刻。这份 2026 年 7 月中的 Draft 描述的是一套迁移剧本，而不是一组新的共识规则。
剧本的三幕
第一幕，选锚。挑一个已最终化的区块作为 ANCHOR_BLOCK（以区块哈希标识，具体主网取值留给演练后窗口确定），在这个块上把完整状态离线转换成 PBT，产出一个字节规范化、可自验证的 PBT 快照文件。因为锚定块已最终化，转换没有“追着写”的问题，做错了重跑即可。
第二幕，追平。快照天然落后链尖。节点拿到快照后，用链上公开的区块级访问列表（BAL，EIP-7928 定义——每块碰过哪些账户与存储槽、写后值是多少）从锚定块开始逐块重放增量，把状态树推到当前高度。BAL 是“只重放被改动部分”的账本，比重新执行整段历史便宜得多。迟加入的节点按大约每 50400 块（约一周）的节奏重新锚定，避免无限追溯。
第三幕，对答案。快照分发与追平阶段都跑在一个“影子承诺期”里：PBT 根在每个块旁路计算、与 MPT 根并存但不承担共识。两套实现长期给出一致结果后，指定某个硬分叉为 PBT_ACTIVATION_FORK——从那一块起 PBT 成为规范承诺，MPT 退休。旧节点可以在升级窗口内继续靠 BAL 重放追平对端，不必恰好持有同一份快照。
为什么值得单独写一份提案
换数据结构最大的一致风险在“过程”，不在“结果”：最终哈希相同但字节编码不同，轻客户端证明、快照同步、跨客户端对比全会出问题。EIP-8347 的关键词因此都是围绕可复现性设计的——字节规范化（byte-canonical，同一状态只有一种字节表示）、可验证快照（每个接收方能独立重算承诺）、影子承诺（对答案期足够长、代价足够低）。这些词的读者不是矿工或用户，而是各家客户端的同步模块维护者。
谁最该现在就读它
这份剧本里最具体的读者其实是节点操作员与客户端维护者：快照怎么签名与分发、BAL 重放追平多快、影子承诺期跑几轮，全部是升级前演练要逐项打勾的条目。普通持币者的正确姿势是反过来问一句：我用的钱包与节点服务商，有没有把这次换树当成一次需要预案的升级？搬家细节写得越清楚，链上生活被打断的概率越低。
快速问答
问：这次换树会动到我的账户吗？ 答：数据结构换了，地址、余额、合约存储的内容都不变——变的是“状态怎么组织与证明”，不是“状态里有什么”。
问：切换失败怎么办？ 答：影子承诺期就是为此设计的——两棵树并行期间发现分叉，推迟激活即可；激活块选定后，旧路径靠 BAL 重放仍可追赶，给落后节点留了台阶。
问：跟 EIP-7864（Verkle/统一二叉树早期提案）什么关系？ 答：8297/8347 是当前主线：8297 定义树形，8347 定义搬家流程。历史上以 verkle 为名的路线已被这套分区二叉树方案取代。
一个类比
这像给行驶中的火车换轨道：不能停车，于是新轨道在旁边的路基上铺好（离线快照），用道岔逐段并进（BAL 重放追平），确认两轨速度一致后扳一次道岔（激活块），旧轨随后拆除。整个工程里最贵的永远不是钢轨，是“不许停”。
风险提示：本文是对公开提案文本的解读，不构成投资建议；提案内容可能随社区讨论修改或作废，请以提案仓库页面为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。