EIP-7864 统一二叉树是什么？以太坊状态树替换的草案讲什么

先给状态定调

以太坊有一批”状态树”主题的提案，Verkle 树之后，EIP-7864 是另一条路线：把现在的六叉状态树换成一棵统一的二叉树，把账户头、合约代码和存储槽全部装进同一棵逻辑树里。讨论它之前必须先钉住状态：EIP 页面自注的状态是 Draft（草案），也就是说它是一份在设计讨论阶段的技术提案，不等于已确定会进入某次升级。EIP 状态、客户端实现与网络激活是三回事，这条区分在任何协议讨论里都适用。本文讲三件事：为什么现有结构被认为不好证明、二叉方案怎么设计、以及”草案”意味着哪些东西还没定。

为什么现有状态树被点名

以太坊的状态装在十六叉的 Merkle Patricia 树里，地址、余额、代码哈希、存储值都可以用默克尔证明快速验证。但 EIP-7864 的动机部分指出，MPT 对”有效性证明”不友好：节点编码用了 RLP，哈希用的是 Keccak，账户树和存储树是”树套树”，而且合约代码本身不在状态树内。EIP 给过量级的例子：在一棵规模约 2 的 32 次方的树里，单条分支的常规证明期望尺寸约 3840 字节；极端情形下，一个用满约 3000 万 gas、只为触碰不同合约代码各一个字节的区块，要出示的证明可能达到数百 MB 级别——因为代码没有被切成可单独证明的小块。证明系统要为状态证明付出这么大的开销，正是它被点名的原因。

统一二叉树怎么设计

六叉状态树与统一二叉树的对照示意

草案的核心改动可以拆成四条。第一，树从六叉改为二叉：分叉数少，每条证明路径上的兄弟节点数少，常规证明尺寸明显下降。第二，账户头、代码和存储不再是分开的树，而是按存储类型分组进同一棵逻辑树，好处是同步和后续处理可以按类型区别对待。第三，合约代码被切块直接进入状态树，从根上消掉”代码不在树里、证明要整段带”的最坏情况。第四，键与值统一为 32 字节，账户数据按 256 个叶子一组来保留访问局部性。这些设计都服务同一个目标：让”用一个有效性证明代替重放执行”在工程上更便宜。

哈希函数为什么故意先不定

这份 EIP 里最容易被转述错的一点：树用了什么哈希函数尚未定稿。页面明确写着，当前参考实现用 BLAKE3 只是为了降低各执行层客户端试验的摩擦，最终选择仍是 TBD，候选名单里还有 Keccak 和针对证明电路更友好的 Poseidon2，后者另有基金会密码学评估在进行。设计上特意把哈希函数做成可替换件，官方表述是换哈希对实现的影响很小。看到”以太坊状态树改用 BLAKE3”这类确定句式的文章，应该回去对照这份原文的措辞。

从草案到现实：迁移还没开始

即使将来被接受，也不会一夜换树。草案描述的做法是分两步：先激活一棵从空开始的新二叉树，只把新的状态变化写进去，旧 MPT 冻结但继续存在；真正的存量数据迁移留给后续的独立硬分叉，EIP 文本里指向了配套的迁移提案。草案同时列了两处会伤害兼容性的地方：代码按块计费的 gas 结构可能改变部分合约的经济性，而”在 EVM 里证明历史状态”的老办法在新树上不再工作，且没有提出缓解方案。对普通用户来说，短期内感知不到任何变化；对开发者来说，现在值得做的是关注设计与试验反馈，而不是假设时间表。

与 Verkle 之类专业术语怎么摆位置

EIP-7864 不是第一次尝试改状态树，之前的 Verkle 树方案在路线图中长期占位。可以把两条路线理解成同一个目标下的不同工程取舍，谁进哪次升级以最终被客户端团队收编、进入升级清单的 EIP 为准。判断任何状态树提案的成熟度，都可以按同一套问题过一遍：状态标签是什么、有没有多客户端试验、迁移路径是否定义、激活进的是哪次升级。四个问题都答不上来，就还停留在纸面。