zkEVM Type 1-4 详细分类
Vitalik 2022 的 zkEVM Types 分类法、每个 Type 的取舍、各代表项目
日期: 2026-12-22 方向: ZK工程 / 电路开发 阶段: Phase 4 - ZK电路开发实战 (Day 223-243) 标签: #ZK #zkEVM #Vitalik #Type1 #Type4
今日目标
| 类型 | 内容 |
|---|---|
| 学习 | Vitalik 2022 的 zkEVM Types 分类法、每个 Type 的取舍、各代表项目 |
| 实操 | 写「zkEVM 选型指南」给团队/项目方做选择参考 |
| 产出 | zkevm_guide.md |
背景：Vitalik 2022 的分类
2022-08-04，Vitalik 在 《The different types of ZK-EVMs》 中提出 4 类分类，作为 zkEVM 设计取舍的标准坐标轴。
核心轴：EVM 兼容度 vs Prover 性能。越接近 EVM 越慢；越偏离 EVM（用 ZK-friendly 替代）越快。
EVM-equivalent ────────────────────────────► Performant
Type 1 → Type 2 → Type 2.5 → Type 3 → Type 4
(slowest) (fastest)
Type 1：Fully Ethereum-equivalent
定义：完全 ZK-prove Ethereum 协议本身，不改任何东西。
- 用 ZK 证明 keccak256（每 hash ~140k 约束）
- 用 ZK 证明 trie operations（state tree 用 keccak Merkle Patricia）
- 完整支持所有 precompile（包括奇怪的 modexp、ecrecover）
优势：
- 直接在 ZK 中跑 mainnet block，无任何修改
- L1 client 验证 ZK proof 即可，未来可作为 EF "Verkle + zkEVM" 主链方案
劣势：
- Prover 极慢：单 block prove 数小时
- 极贵：~$10/block prove cost (估算)
代表项目：
- Taiko (Type 1 ambitions) - 主网上线，目标 Type 1
- EF zkEVM team - 研究项目，未上线
- Kakarot - Cairo 实现，跑在 StarkNet 上
真实数据：
- Taiko Alpha-3：单 block prove 大约 ~30 min（GPU 集群）
- 估算 mainnet 单 block prove 成本：$1-5
Type 2：EVM-equivalent (但状态 trie 内部不同)
定义：从开发者视角看就是 EVM，但内部实现略有不同：
- state tree 可能用 Poseidon-MPT 替代 keccak-MPT（更 ZK-friendly）
- 但 EVM bytecode 完全相同，opcode 行为相同
优势：
- 现有合约 0 修改部署（合约地址、bytecode、log 都一致）
- Prover 比 Type 1 快 5-10×（state tree 用 ZK-friendly hash）
劣势：
- L1 客户端不能直接验证（state root 用了不同 hash）
- 需要额外 keccak 在 ZK 内（针对 EVM 内的 keccak opcode）
代表项目：
- Scroll - 目前最忠实 Type 2
- Linea - 偏 Type 2.5（部分 opcode 处理略变）
性能估算：
- Scroll：~5-10 min/batch（数百 tx）
- prove cost：~$0.1-0.5/tx
Type 2.5：EVM-equivalent except for gas costs
定义：Type 2 的优化版本——某些 opcode 提高 gas（让 prover 友好）。
- 例：keccak 提价让用户少调用，整体减少 prover 工作量
- 行为仍然「正确」（执行结果一样），但 gas 计费不同
优势：
- 比 Type 2 快 ~30%
- 仍兼容大部分合约（除非合约 hardcode 了 gas 数字）
劣势：
- 合约可能因 gas 变化失效（如固定 gas limit 的 internal call）
- 需要 educate 开发者「这个 opcode 在 zkEVM 上更贵」
代表项目：
- Linea - 部分 Type 2.5 倾向
Type 3：Almost EVM-equivalent
定义：少数 opcode/precompile 不同：
- 不支持
selfdestruct - 某些 precompile（modexp, ec curves）改写或不支持
- block.number 等 host 函数语义略调整
优势：
- 比 Type 2 快 ~2×
- 大部分合约（>95%）能直接跑
劣势：
- 5% 左右合约需要修改（删 selfdestruct、避开特殊 precompile）
- DEV 工具（Hardhat fork mainnet）可能行为不一致
代表项目：
- Polygon zkEVM - 当前是 Type 3，目标 Type 2
- Scroll 早期 - 部分 Type 3 特性（已逐步对齐 Type 2）
真实兼容性问题：
- Aave V2 在 Polygon zkEVM 部署时，因 modexp precompile 行为不同需要 patch
- WETH9 因 selfdestruct 缺失行为不同（不影响主流 use case）
Type 4：High-level-language equivalent
定义：从 Solidity / Vyper 源码编译到自定义 ZK-friendly bytecode：
- 不是 EVM bytecode，是项目自定义 VM
- LLVM-based 编译器（如 zksolc），从 Yul/Solidity → 中间 IR → 自定义指令集
优势：
- 最快 prover（5-10× faster than Type 2）
- 可以做 ZK-native 优化（如 ZK-friendly hash、自定义 storage layout）
- 通常 native AA / paymaster 等增强
劣势：
- 合约 bytecode 不同 → contract address 通过 CREATE2 计算结果不同
- 不是真正的「EVM 等价」：subtle 行为差异（gas、bytecode hash、CREATE 地址）
- 工具链（Etherscan、Tenderly）需要专门适配
代表项目：
- zkSync Era - 经典 Type 4，zksolc + EraVM
- StarkNet - Cairo（不是 EVM 兼容，但有 Solidity → Cairo 转换器 Warp）
- Aleo Leo - 完全不同的 ZK-native 语言
真实兼容性问题：
- 2023 年 Uniswap 在 zkSync Era 部署时发现：CREATE2 计算的 pool 地址与主网不同（因为 init code hash 不同），需要重新部署 quoter 合约
- 一些用 inline assembly 的合约（Yearn、Curve 部分版本）在 zkSync 编译失败
完整对比表
| 维度 | Type 1 | Type 2 | Type 2.5 | Type 3 | Type 4 |
|---|---|---|---|---|---|
| EVM 字节码兼容 | ✓ | ✓ | ✓ | ~ | ✗ |
| EVM 状态树兼容 | ✓ | ✗ (Poseidon MPT) | ✗ | ✗ | ✗ |
| Solidity 兼容 | ✓ | ✓ | ✓ | ~ | ✓ (源码层) |
| CREATE2 地址兼容 | ✓ | ✓ | ✓ | ✓ | ✗ |
| selfdestruct | ✓ | ✓ | ✓ | ✗ | ✗ |
| 所有 precompile | ✓ | ✓ | ✓ | 部分 | 部分 |
| gas costs equivalent | ✓ | ✓ | ✗ | ✗ | ✗ |
| L1 client 可验证 | ✓ | ✗ | ✗ | ✗ | ✗ |
| Prover 速度 | 1× | 5-10× | 7-12× | 10-20× | 30-50× |
| 代表 | Taiko, EF | Scroll | Linea | Polygon zkEVM | zkSync, StarkNet |
选型指南 / Selection Guide
你是 DApp 开发者，要部署到哪个？
合约简单（ERC20, Uniswap fork） → 任何 Type 都可以
合约复杂、有 inline asm 或 selfdestruct → Type 1/2/2.5
要直接 mainnet 0 修改部署 → Type 1/2 (Scroll, Linea)
要最便宜的 fees → Type 4 (zkSync Era)，但要重新审计
要最忠实 mainnet → Type 1 (Taiko)
你是 Rollup 项目方？
要赢市场（fast + cheap）→ Type 4
要赢开发者心智 → Type 2 (Scroll)
要做最未来 → Type 1（赌 EF 长期方向）
要做企业级私有 chain → Type 2.5（CDK fork）
演进趋势 / Evolution
2022-2023: 大家都从 Type 4 / 3 入场（Polygon, zkSync）
2024: Scroll 用 Type 2 后，行业开始向 Type 2 收敛
2025+: Type 1 chain 开始上线（Taiko），zkEVM 成 EF 主链方向
Vitalik 自己 2024 表态：长期看 Ethereum L1 自己会变成 Type 1 zkEVM（"zk EL"），目前 EF 在做 SP1/RISC0 zkVM 来 prove geth/reth 客户端。
工程实战经验
Type 4 项目「踩坑」清单
- CREATE2 init code hash 不同 — 跨链工具（Quoter, UniswapPositionsManager）地址不一致
- bytecode hash 不同 — 一些合约要校验 hash 的逻辑要 patch
- gas estimation 行为不同 — Hardhat / Foundry 模拟可能不准
- delegatecall 限制 — zkSync Era 早期不支持任意 delegatecall
- block.timestamp 精度 — 某些 chain 给 ms 精度
Type 2 项目踩坑清单
- state tree hash 不同 — Etherscan / The Graph 可能 indexing 慢
- 某些 precompile 缺失 — bn128 add/mul 通常 OK，但 modexp 大数运算可能慢
关键速查
Type 1: full Eth-equiv | slowest, future
Type 2: bytecode-equiv | Scroll, near-mainnet
Type 2.5: gas adjusted | Linea
Type 3: mostly-equiv | Polygon zkEVM
Type 4: source-equiv | zkSync Era, fastest
面试题
-
Q: zkEVM Type 1 和 Type 4 的核心 trade-off 是什么？ A: Type 1 完全 EVM 等价（包括 state tree 用 keccak），客户端可直接 verify、合约 100% 兼容；但 prover 极慢（数小时）。Type 4 从源码编译到自定义 bytecode，prover 快 30-50×、可以做 ZK 优化、UX 改善（native AA），代价是 bytecode/地址不一致、审计需要重做。
-
Q: 为什么 Vitalik 长期看好 Type 1？ A: 终局是 Ethereum L1 自己变 zkEVM，让任何 light client 都能用 ZK 验证整条链。这要求 Ethereum 协议 1:1 ZK 化（Type 1）。中短期 Type 2/3/4 是 L2 务实选择，但 L1 自己只能走 Type 1。
-
Q: 你做一个 DEX，要上 zk-Rollup，会选 Type 几？ A: 看几个因素：(a) 现有合约成熟度 — 有就选 Type 2 (Scroll)；(b) UX 要求 — gasless 重要选 Type 4 (zkSync, native AA)；(c) 团队带宽 — 不想重写就选 Type 2/2.5。多链部署可以两边都上。
-
Q: 如果选了 Type 4 (zkSync Era)，你会优先验证哪些兼容性问题？ A: (1) CREATE2 地址（影响 Uniswap pools 等）；(2) inline assembly 编译；(3) gas estimation 准确度；(4) selfdestruct 是否被使用；(5) 第三方协议（Permit2, Multicall3）是否已部署。
明日预告
Day 236 — Aztec 与隐私 L2。Privacy-first zk-Rollup 架构，Noir + UltraPlonk + 完整的 private state model。