探索 Verkle Trees:为 Ethereum 带来的轻量级可验证查询革命

·

关键词:Verkle TreesEthereum 扩容零知识证明可验证查询轻节点状态树优化

背景:The Verge 与轻节点未来

Vitalik 在最新的路线图中,将 The Verge 描述为“让节点验证区块链状态变得更快、更轻、更简单”。要让 1 TB 的状态数据在几秒钟之内可验证,传统 Merkle Patricia Tree(MPT)已显得笨重。答案正是 Verkle Trees:在保持去中心化安全假设的同时,把节点负担降了两个数量级。

1 背景知识:从可验证查询说起

场景问题解决思路
云数据库怀疑返回结果是否真实可验证数据结构(ADS)
客户端 RPC不信任节点返回的状态Merkle Tree 证明
无状态客户端不想下载整个状态Verkle Trees

可验证查询技术的核心,就是“我信不过你,但我可以 快速验证 你”。
从传统的 Merkle Tree,到 Verkle Tree(向量承诺 + Merkle 结构),是一次从“线性许可证”到“压缩授权”的飞跃。

2 Merkle Tree:老而弥坚的结构

2.1 原子组成

2.2 轻节点如何验证

轻节点只存储 block header,内含状态根。向全节点请求一笔账户数据时,会同时拿到

  1. 该数据块本身
  2. 一个 Merkle Path(约 log₂N 个兄弟节点,常见深度 ≈ 7)
  3. 计算根哈希并与本地 header 对比。一致即通过。

2.3 结构拓展

因此,扩容瓶颈 = 大量兄弟节点带来的网络 + 计算负载

👉 深入了解如何在链下巧妙压缩这些证明细节,让钱包一秒完成状态验证

3 Verkle Trees:向量承诺的降维打击

3.1 定义

作者给出了简明口诀:

Verkle Trees = Vector Commitments + Merkle Trees

3.2 证明大小对比

说明Merkle Tree(理想)Verkle Tree(主网设计)
10 亿条目路径1 KB< 150 B
压缩比例~10×
验证时间(轻节点)~3 s< 100 ms
引自 Vitalik blog 的结论:“Size ≤ 150 bytes 让 无状态客户端 在移动设备也能诞生。”

3.3 工作流程拆解

  1. Committer:为每层节点生成 48 B 多项式承诺
  2. Prover:一键算出针对某路径的 multiproof(单次 96 B)
  3. Verifier:运行椭圆曲线双线性配对,两步即可通过

3.4 进阶优化:合并证明

👉 实时追踪 Verkle 代码进度与主网测试网交互入口

4 性能、更新与未来兼容性

视角运算成本未来方案
Proof 生产log₂56 × 椭圆曲线乘法预计算缓存可换时间
Proof 验证1×FFT + 2×配对所有网络均在 100 ms 内可通过 ZK-SNARK 再次精简
状态更新触发整条路径重算,可以用备份承诺缓解未来转向量子安全 STARK 化哈希

社区预期:


5 常见问题 FAQ

Q1:Verkle Trees 与 EIP-4844 的 KZG Commitment 区别?
A:EIP-4844 是交易 数据可用性层 的多项式承诺;Verkle Trees 面向 全局状态存储。两者使用同一套 KZG 数学器件,目的与位置不同。

Q2:为何要采用如此宽的 256 分支而非传统 2 分支?
A:宽度越大,树深越浅,路径证明越少。向量承诺让兄弟节点不再必要,反而带宽瓶颈前端。

Q3:主网一旦升级,我的合约需要迁移吗?
A:不,EVM 语义层无感知升级。底层 MPT→Verkle 共享同一条 RPC 接口。

Q4:KZG 突破 128 位安全了吗?
A:当前采用 BN254,满足 NIST P-256 安全级别;若未来标准升级,可用高阶曲线(BLS12-381)无缝替换。

Q5:若量子计算到来,Verkle Trees 是不是废了?
A:Vitalik 已在方案中写明:届时可退回 STARKed Merkle Tree;中途不需任何社会分叉,可通过策略层脚本即可完成。

Q6:如何本地体验 Devnet?
A:下载最新 geth-verkle 分支即可用 --verkle 标志启动;同步时间 < 30 min(本地 SSD)。


尾声

当所有树深、网络往返与计算瓶颈被压缩到 150 字节以内,手机也能跑全以太坊客户端的那天——这就是 Verkle Trees 带来的未来。
对开发者而言,理解这一核心技术不仅是跟上扩容的第一步,更是提前布局 状态层可组合性 的关键拼图。