无状态验证是怎么回事？见证、Verkle 与以太坊的状态包袱

以太坊节点硬盘越装越满是老话题：验证一个区块，前提是本地存着整个状态库。无状态客户端想换一种方式——区块自己带着一份“证据包”过来，节点只执行这份证据就能验证。这个证据包就是见证，而无状态路线图走到哪一步、Verkle 树还是不是那道门，值得按官方口径重新捋一遍。

验证区块到底需要什么

验证一个区块，节点要重放区块里的交易、更新本地状态树，再比对算出的状态根和出块者声称的状态根是否一致。今天的客户端靠本地整棵 Patricia 梅克尔树干活，Geth 默认还要保留头部之后若干区块的历史状态。无状态验证把“本地状态库”换成随区块广播的见证：执行这些交易所需的状态片段，加上一份密码学证明，说明这些片段确实属于全局状态。官方路线图文档对这条路的定位很明确——验证所需的一切随区块传递，节点不再依赖硬盘上的状态数据库。

瓶颈是见证的大小

问题在于尺寸。梅克尔树给每个叶子到根作证，要沿路给出全部中间哈希和兄弟节点，状态越大见证越大。以太坊官方路线图页面专门算了这笔账：一个槽十二秒，见证必须在该时间内传遍网络并被处理，否则只有带宽充裕的机器才能参与验证，这本身就是中心化压力。另一个常被忽略的约束在硬盘之外：Geth 默认保留头部之后一百二十八个区块的状态数据，节点为了验证和重组回退被迫背着历史包袱，状态越涨、同步越慢、家用机器越少——无状态化要同时卸掉硬盘和带宽这两座山。Verkle 树是 Vector commitment 与 Merkle Tree 合成的数据结构的缩写，叶子到根更浅、分支更宽，配合多项式承诺还能让见证大小基本不随状态规模膨胀，从而把见证压到可行范围。

树长什么样：为什么宽反而小

Verkle 树的“宽”是关键。EIP-6800 把节点宽度定为 256——每个内部节点直接挂二百五十六个子节点，四十位十六进制的键从根走到叶子只要浅得多的几层。旧梅克尔树要靠一层层兄弟哈希自证结构，见证必须把沿途兄弟节点全带上；Verkle 节点改用向量承诺（这也是名字里 Ver 的来历），每个节点先对子节点算一个多项式承诺，开一个子节点只需要一个常数大小的证明，与兄弟数量无关。树宽了、层浅了、每层证明又与宽度解耦，见证尺寸才真正压进秒级传输的窗口。

Verkle 走到哪一步了

要看状态就看官方文档和 EIP。EIP-6800 提出在现有 Patricia 树旁边引入 Verkle 状态树，EIP-7612 设计“覆层树”过渡、EIP-7748 设计逐块迁移程序，均为草案状态。截至笔者 2026 年 9 月查阅，ethereum.org 路线图页面仍把 Verkle 描述为“测试网已经运行、但客户端仍有大量必需更新未完成”的方向，主网从未启用过这棵状态树；同期研究里也出现了二叉树等其他替代结构（见本栏目 EIP-7864 一文）。换言之，“以太坊将换 Verkle”不是已定事实，而是仍在改道中的一条路线。

对普通用户为什么重要

无状态化瞄准的是验证门槛：见证够小，家用设备也能独立验证区块，节点数量和被带宽筛选的集中度都会改变。它对终端用户的短期影响有限——钱包地址、交易格式都不变；中期影响体现在节点生态、状态膨胀治理，以及“谁还能独立查账”这件事上。跟踪这类路线议题，最可靠的做法是盯 EIP 状态字段和升级名单，而不是转述消息。本文为机制科普，不构成投资建议。