以太坊的区块头里住着一些字段，同一个名字在执行层和共识层各自翻译成了不同的数学对象。withdrawals_root——提款根——就是其中最典型的一个：执行层的区块头里，它是一个 Merkle Patricia 树（MPT）的根；共识层的执行负载头里，它是 SSZ 序列化算出的默克尔根。两边描述的是同一串提款记录，哈希却按两套规则生长。EIP-6465 想把这道裂缝填上：2023 年 2 月 8 日由 Etan Kissling 与 Mikhail Kalinin 起草，状态草稿，动作是把提款列表的承诺统一迁到 SSZ。
一个名字，两棵树
先把历史摆正。提款字段是随信标链提款功能进入执行层区块头的，执行层习惯用自家万能的 MPT 给任何列表做承诺；而共识层的哲学是类型化编码，列表进 SSZ 默克尔树。两套编码对同一批提款单（每单四栏：全局提款序号、验证者编号、收款地址、金额）给出的根值完全不同。日常运转相安无事——两边各自验各自的，转换发生在负载翻译的那一步。但提案的动机页列了受害场景：名字携带歧义，实现里一个字段名两种语义，跨层测试、形式化验证、第三方解析工具都得多长一只眼睛。更根本的是方向的账单：以太坊整体在往 SSZ 走，每多一个字段赖在 MPT 上，‘支持两种承诺’的组合就多留一格。
迁移的手术刀法
提案的做法是标准迁移工法：提款容器升级为渐进容器（EIP-7495 的动态版本化编码，字段集用位图声明），列表装进渐进列表，执行层区块头的提款根字段语义改为’这棵 SSZ 树的哈希树根’。共识层的执行负载随之改类型，状态转换函数里两边算根的路径合并成一条。提案挂在一条依赖链上：类型化交易信封、信标提款本体、SSZ 交易、渐进容器、渐进列表——前两项是既成事实，后三项还在各自推进，这条链子本身解释了提案为什么多年停在草稿：它不孤单，是 SSZ 化大队列里的一个工位。
为什么值得动一个字段
改承诺算法听着像换轮胎不用停车——区块头字段谁在消费？至少四方：同步节点逐字段重算的验证路径、轻客户端的默克尔证明、依赖字段语义构建的跨链桥与索引器、以及所有做两层映射的一致性测试。提案把这些成本换的是三件东西：少支持一种树、名字与值一对一、共识层的类型定义成为唯一权威。这是协议整理期的典型交易——不为新功能，为把双轨基础设施并轨，让未来的每个字段只有一种读法。这类整理提案的历史价值往往在其示范：提款根之后，同一逻辑会轮到别的字段，一份迁移工法就是全套模板。
一条对照账
MPT 与 SSZ 默克尔树对同一列表的承诺差异，可以按地址树与字段树的关系来体会：MPT 把键值对塞进带路径压缩的十六叉分枝里，键的写法直接塑造树形；SSZ 规定每种类型有一棵形状固定的二叉完全树，长度只影响顶部几层。同一串提款单，前者像按门牌号分拣的信封堆，后者像流水号对齐的货架——盘点结论（根值）自然不同。统一货架之后，‘提款到底有没有被这个块承诺过’的回答只剩一种算账方式，这类’少一种算账方式’正是无状态化和跨层验证路线图反复索取的红利。
快速问答
问：今天两个根并存会造成用户可见问题吗？ 答：正常使用感知不到；受影响的是写解析器和验证器的工程师——他们要清楚自己在读哪一层的定义。
问：渐进容器在这里解决了什么新问题？ 答：给提款单这种小结构留出’以后加字段’的编码出口：靠位图声明哪些字段激活，新旧版本的哈希路径仍可对照。
风险提示：本文为协议机制科普，不构成任何投资建议；编码定义与依赖关系以 EIP 仓库及共识规范当期文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。