以太坊状态的账本结构叫 MPT——改良默克尔 Patricia 树，八个岔路口的树。2020 年 9 月 1 日，一份提案想把八岔路口拆成二岔路口：EIP-3102，Binary trie structure，现状态 Stagnant（停滞）。它没有随任何升级上线；它服务的”无状态化”大方向此后长期以 Verkle 树为官方路线讨论，而 EIP-3102 本身连同那份路线图注释都停留在提案层文本（路线概览见 Verkle 树是什么？状态树重构与无状态客户端的路线图，换树迁移的工程难题见 换树不放假：EIP-8347 想把状态迁移搬到链下去）。
动机：瓶颈从哈希挪到了磁盘
提案的推理链写得干净：十六进制树比二叉树浅，浅意味着哈希次数少——这是旧设计的前提优势。但五年运行后现实翻转：磁盘访问才是比哈希更大的瓶颈，客户端已转向 turbo-geth 首创的”扁平键值库”，中间节点用时再重算。更重要的是无状态化的路线需求：验证者要随身带证明，二叉树的证明尺寸比十六进制小约四倍，“为无状态以太坊”几乎是二叉树的定向设计。此外 MPT 塞满省字节的古怪优化——子节点 RLP 不足 32 字节就嵌进父节点、叶标记位、扩展节点——换来的磁盘节省以兆字节计，复杂度却按实现事故计，作者认为这笔买卖不划算。
新树长什么样
规范给出一棵纯二叉树：每个节点四元组，左右子节点哈希加可选前缀加值。没有子节点（两侧都是空哈希 hash("")）即为叶子，值只出现在叶子；前缀段取代了 Patricia 的扩展节点，把”连续单边下钻”压成一条前缀。RLP 编码整体弃用；无论序列化结果多短，每个节点一律哈希——取消”小于 32 字节就内嵌”的特例，把证明逻辑里最容易出 bug 的分支直接剪掉。账户树与存储树合并成一棵”状态树”，键长 32 到 64 字节。
键布局：把账户拍平进一棵树
合并后一个账户的四项数据钉在地址哈希的位段上：余额 A_b 在 hash(A_a)[0..253] 拼 0b00，nonce 在拼 0b01，代码 A_c 在拼 0b10，存储树根 A_s 在拼 0b11；存储槽则再挂一层 hash(A_a)[0..253] ++ 0b11 ++ hash(k)。理由一节点出两个好处：扁平数据库里同一账户的全部数据在磁盘上天然聚堆（键前缀相同），读一个账户只撞一次盘；一笔交易涉及多账户多槽位时，见证只需一棵树、一份证明——这正是给无状态客户端递的梯子。顺带一提，这份提案成文时正文只写抽象的 hash()，理由一节才点名候选：选 blake2b 是因为它比当时的 keccak 实现快，足以抵消树变深带来的哈希开销。
为什么扇出从八变二
十六进制的”八岔路口”来自 Patricia 树按 4 比特 nibble 分段寻址的旧约定：每下钻一层消耗一个十六进制位，树浅但每层最多八个孩子。二叉树每层只消耗 1 比特，同样的键要下钻四层才走完一个十六进制位，树深约莫翻四倍、节点数也约多四倍。这笔”深度换证明”的交易是否划算，完全取决于系统更常做哪件事：全节点自己算根（浅树省哈希）还是外部验证者背证明（窄树省字节）。提案押注后者，因为客户端的扁平化存储已经实质上放弃了”靠浅树省盘”的旧假设。
哈希选 blake2b 的账
节点数暴增四倍，哈希次数随之上去，用树深换磁盘的代价必须找回来。提案选 blake2b：性能优于当时的 keccak 实现；更新的 BLAKE3 更快，但成文时 Go 官方生态尚无成熟品，安全考量压过速度贪新。“树形”与”哈希函数”被拆成两个独立决策分别论证，这是提案文本结构上值得写作者学习的部分：形状为证明尺寸服务，哈希为树形回吐的成本服务。
停滞的意义
EIP-3102 未进任何分叉，路线竞赛里 Verkle 树方案长期占住官方叙事（向量承诺代替树本身，见 Verkle 树是什么？状态树重构与无状态客户端的路线图），此后讨论又转向更轻的替代结构——EIP-3102 连”当替补方案”的窗口都没等到。但它验证过的东西没有作废：扁平存储是方向、单树一份见证是方向、剪掉 RLP 特例是方向——后来的方案在不同载体上继续执行这些结论。读停滞提案的纪律照旧：文中 hash()、键布局与 blake2b 选择都是该提案语境内的设计，不是现网事实；现网状态树仍是 MPT，钱包和浏览器的余额、存储证明按现行结构生成。
风险提示：本文是以太坊数据结构提案科普，不构成投资建议；状态树结构与证明格式随升级演进，链上数据核验请以现网客户端与当期规范为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。