以太坊的世界状态存在一棵十六叉 Patricia 树里：账户树套存储树，键定长、分支宽。这棵用了多年的树正接近它的设计极限——证明越来越长、代码游离在树外、账户之间没有空间局部性。EIP-8297 提议整体换形：改成一棵分区二叉树（Partitioned Binary Tree），账户与存储合并成一棵、键变长且前缀无关、合约代码入树，每个键的首字节用来说明它属于哪类状态分区。
现行树的三个痛点
第一是证明宽度。十六叉树每一层最多带十六个兄弟哈希进证明，路径虽短但常数大，无状态验证与跨链桥要的见证因此偏肥。第二是代码与状态分离：合约字节码不进 Merkle 树，导致代码完整性只能靠执行客户端口头保证，无状态节点无法用证明方式验代码。第三是局部性缺失：同一个合约的 nonce、余额、存储散落在不同树里，一次冷访问要付多份独立证明与多份状态费。2023 年版的以太坊路线图曾把 verkle 树当作换树的既定方向；在 2026 年以来的路线图梳理中，该路线已被二叉树方案（先是统一二叉树，再到 PBT）取代。
新树的四个设计决定
提案的核心决定可以列成四条。其一，合并加zones：账户树与存储树并成一棵，键的首字节是分区标识，账户头、合约代码、存储各占固定区段，剩余区段留给未来类别。其二，变长前缀无关键：键不再补齐到固定宽度，但任何键不得是另一个键的前缀，计算根时会拒绝违规键；配合二叉结构，键直接当路径走，二叉分支让每层证明只需带一个兄弟哈希。其三，代码入树：合约字节码作为树中的叶子存储，代码完整性从此获得与状态同级的 Merkle 承诺，也为有效性证明友好性服务——现行 MPT 的 RLP 编码与 Keccak 组合对证明系统并不友好。其四，账户字段拆叶：nonce、余额、代码哈希等各自成叶、共享一个键前缀，访问同一账户的不同字段时证明可复用前缀路径，这就是分区带来局部性的含义。值得注意，草稿使用的哈希函数尚未定稿，参考实现暂用 BLAKE3 以降低实验摩擦。
收益与代价
收益侧，二叉结构把每层证明压到一个兄弟哈希，代码入树补上无状态与有效性证明拼图（内容寻址的代码叶子还让多个部署相同字节码的合约共享同一份代码存储），拆分叶子让访问同一账户的字段时证明可复用前缀。代价侧，换树是全库搬迁：所有节点要一次性重建状态树，任何直接读旧树格式的工具与归档数据都要适配；变长键也带来新的共识级约束，比如键长上限（草稿取 8192 字节，源于分支前缀编码的可表示范围），防止有人用畸形长键撑爆证明。树形改革在以太坊历史上属于最重的一类改动，推进节奏历来以年计。
当前状态
截至本文写作时，EIP-8297 处于草稿状态（Draft），创建于 2026 年 6 月 11 日，处于结构定义与参数标定阶段；分区大小、键长上限等关键参数尚未冻结，也未关联任何升级。
快速问答
问：PBT 和 verkle 树是什么关系？ 答：是同一条换树思路下的不同设计——verkle 用椭圆曲线向量承诺压缩证明，PBT 用纯哈希的二叉结构加分区追求短证明与局部性；按近期的路线图梳理，verkle 路线已被二叉树方向取代。 问：换了树我的钱会受影响吗？ 答：状态内容不变，变的只是组织与证明方式；这类改动理论上对账户余额与合约逻辑透明。 问：为什么要合并账户树和存储树？ 答：为了键前缀下的局部性与统一证明：同一合约的字段可以共享路径前缀，证明生成与状态费都更精确。
风险提示：本文为协议结构科普，不构成投资建议；提案处于早期阶段，细节以 EIP 仓库当期文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。