先把坐标系画出来
zkEVM 这个词同时被很多项目使用，但同一块招牌下的工程路线差别很大。把这个问题讲得最系统的公开材料，是 Vitalik Buterin 在 2022 年 8 月发表的一篇分类文章。它不评优劣，而是画一张坐标图：编号越低，对以太坊越兼容、证明越慢；编号越高，证明越快、兼容代价越大。Type 1 力求对以太坊不做任何改动，Type 2 在应用看不见的层面换掉区块结构与状态树，Type 3 删改个别难证的特性，Type 4 干脆从 Solidity 这类高级语言直接编译到对零知识证明友好的语言。理解这张图，比记住某个项目当年的编号更有用，因为类型会移动。
Type 1：什么都不改，先求验得了
Type 1 的立场是让证明系统适配以太坊，而不是反过来。哈希、状态树、交易树、预编译，一项都不替换，目标是按原样验证以太坊的执行层区块。好处是复用面最大：执行客户端可以原样用来生成和处理 Rollup 区块，浏览器、调试器这类工具几乎不用改。代价写在同一篇文章里——以太坊当初不是围绕零知识证明设计的，逐块证明极其吃力，文章写作时证明一个以太坊区块要花上数小时，缓解办法只有把证明器大规模并行化，或者等专用芯片成熟。
Type 2 与 Type 2.5：换掉外壳，保住内核
Type 2 的路线是「从内部看与以太坊一模一样」：合约与账户逻辑完全等价，但区块结构、状态树这些应用无法直接访问的外壳被换成证明友好的替代品，比如用 Poseidon 一类的哈希替换 Keccak 与默克尔帕特里夏树的组合。绝大多数应用不受影响，受影响的是少数直接验证历史区块默克尔证明的应用——依赖这类证明的跨链桥要注意，这类依赖即使在以太坊本链也会被未来改动波及。证明提速主要来自换掉对证明不友好的密码学组件，但 EVM 本身的低效仍然保留。文中还给出 Type 2.5：不改变语义，只把个别特别难证的操作的 gas 价格抬高，用它控制最坏情况证明时间。
Type 3 与 Type 4：快，但要付迁移成本
Type 3 为速度删改个别特性，最常被动刀的是某些预编译，合约代码、内存或栈的处理也可能有细微差异。对开发者，预编译缺失会让依赖它们的合约直接执行失败。Type 4 则把 Solidity 或 Vyper 源代码直接编译成证明友好的语言，跳过逐条模拟 EVM 执行的开销，作者明确承认这能大幅降低成本、让更多人有能力当证明者。代价有三处：合约地址依赖精确字节码的机制（如 CREATE2 的撞地址算法）会对不上，影响依赖未部署合约的应用；手写 EVM 字节码的段落只获有限支持；按字节码工作的调试设施难以原样搬移。那篇文章写作时，各团队正沿不同方向移动，某个项目的归属应以其当前文档为准。
类型会变，核验要重做
项目并不钉死在某一型：文章列举了多条迁移路径——从 Type 3 逐步补齐预编译走向 Type 2，从 Type 2 提供双模式走向混合形态，也可能主动反向移动：加入一个对某门 ZK 友好语言做验证的预编译，等于让开发者在以太坊兼容与速度之间自选，这在坐标系里反而算 Type 3。作者本人表达的倾向是所有路线最终汇向 Type 1。落到普通用户，判断某条链的成色看三件事：官方文档如何描述其哈希与状态结构、预编译清单是否完整、依赖历史区块证明的应用能否原样运行。引用任何「某链是几型」的说法时，应核对官方文档当前状态并留意所引材料的发布时间——本文的类型描述与项目归属均出自那篇 2022 年的文章，不代表当下状态。本文只做技术梳理，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。