The Evolution of zkEVMs: Balancing Compatibility and Performance in Ethereum Scaling
In 2022, Vitalik Buterin posed a simple question that would define the next four years of Ethereum scaling: how much Ethereum compatibility are you willing to sacrifice for faster zero-knowledge proofs? His answer came in the form of a five-type classification system for zkEVMs that has since become the industry standard for evaluating these critical scaling solutions.
Fast forward to 2026, and the answer isn't so simple anymore. Proving times have collapsed from 16 minutes to 16 seconds. Costs have dropped 45x. Multiple teams have demonstrated real-time proof generation faster than Ethereum's 12-second block times. Yet the fundamental trade-off Vitalik identified remains—and understanding it is essential for any developer or project choosing where to build.
The Vitalik Classification: Types 1 Through 4
Vitalik's framework categorizes zkEVMs along a spectrum from perfect Ethereum equivalence to maximum proving efficiency. Higher type numbers mean faster proofs but less compatibility with existing Ethereum infrastructure.
Type 1: Fully Ethereum-Equivalent
Type 1 zkEVMs don't change anything about Ethereum. They prove the exact same execution environment that Ethereum L1 uses—same opcodes, same data structures, same everything.
The upside: Perfect compatibility. Ethereum execution clients work as-is. Every tool, every contract, every piece of infrastructure transfers directly. This is ultimately what Ethereum needs to make L1 itself more scalable.
The downside: Ethereum wasn't designed for zero-knowledge proofs. The EVM's stack-based architecture is notoriously inefficient for ZK proof generation. Early Type 1 implementations required hours to generate a single proof.
Leading project: Taiko aims for Type 1 equivalence as a based rollup using Ethereum's validators for sequencing, enabling synchronous composability with other based rollups.
Type 2: Fully EVM-Equivalent
Type 2 zkEVMs maintain full EVM compatibility but change internal representations—how state is stored, how data structures are organized—to improve proof generation.
The upside: Contracts written for Ethereum run without modification. The developer experience remains identical. Migration friction approaches zero.
The downside: Block explorers and debugging tools may need modifications. State proofs work differently than on Ethereum L1.
Leading projects: Scroll and Linea target Type 2 compatibility, achieving near-perfect EVM equivalence at the VM level without transpilers or custom compilers.
Type 2.5: EVM-Equivalent with Gas Cost Changes
Type 2.5 is a pragmatic middle ground. The zkEVM remains EVM-compatible but increases gas costs for operations that are particularly expensive to prove in zero-knowledge.
The trade-off: Since Ethereum has a gas limit per block, increasing gas costs for specific opcodes means fewer of those opcodes can execute per block. Applications work, but certain computational patterns become prohibitively expensive.
Type 3: Almost EVM-Equivalent
Type 3 zkEVMs sacrifice specific EVM features—often related to precompiles, memory handling, or how contract code is treated—to dramatically improve proof generation.
The upside: Faster proofs, lower costs, better performance.
The downside: Some Ethereum applications won't work without modification. Developers may need to rewrite contracts that rely on unsupported features.
Reality check: No team actually wants to stay at Type 3. It's understood as a transitional stage while teams work on adding the complex precompile support needed to reach Type 2.5 or Type 2. Both Scroll and Polygon zkEVM operated as Type 3 before advancing up the compatibility ladder.
Type 4: High-Level Language Compatible
Type 4 systems abandon EVM compatibility entirely at the bytecode level. Instead, they compile Solidity or Vyper to a custom VM designed specifically for efficient ZK proofs.
The upside: Fastest proof generation. Lowest costs. Maximum performance.
The downside: Contracts may behave differently. Addresses might not match Ethereum deployments. Debugging tools need complete rewrites. Migration requires careful testing.
Leading projects: zkSync Era and StarkNet represent the Type 4 approach. zkSync transpiles Solidity to custom bytecode optimized for ZK. StarkNet uses Cairo, an entirely new language designed for provability.
Performance Benchmarks: Where We Stand in 2026
The numbers have transformed dramatically since Vitalik's original post. What was theoretical in 2022 is production reality in 2026.
Proving Times
Early zkEVMs required approximately 16 minutes to generate proofs. Current implementations complete the same process in roughly 16 seconds—a 60x improvement. Several teams have demonstrated proof generation in under 2 seconds, faster than Ethereum's 12-second block times.
The Ethereum Foundation has set an ambitious target: proving 99% of mainnet blocks in under 10 seconds using less than $100,000 in hardware and 10kW of power consumption. Multiple teams have already demonstrated capability close to this target.
Transaction Costs
The Dencun upgrade in March 2024 (EIP-4844 introducing "blobs") reduced L2 fees by 75-90%, making all rollups dramatically more cost-effective. Current benchmarks show:
| Platform | Transaction Cost | Notes |
|---|---|---|
| Polygon zkEVM | $0.00275 | Per transaction for full batches |
| zkSync Era | $0.00378 | Median transaction cost |
| Linea | $0.05-0.15 | Average transaction |
Throughput
Real-world performance varies significantly based on transaction complexity:
| Platform | TPS (Complex DeFi) | Notes |
|---|---|---|
| Polygon zkEVM | 5.4 tx/s | AMM swap benchmark |
| zkSync Era | 71 TPS | Complex DeFi swaps |
| Theoretical (Linea) | 100,000 TPS | With advanced sharding |
These numbers will continue improving as hardware acceleration, parallelization, and algorithmic optimizations mature.
Market Adoption: TVL and Developer Traction
The zkEVM landscape has consolidated around several clear leaders, each representing different points on the type spectrum:
Current TVL Rankings (2025)
- Scroll: $748 million TVL, largest pure zkEVM
- StarkNet: $826 million TVS
- zkSync Era: $569 million TVL, 270+ deployed dApps
- Linea: ~$963 million TVS, 400%+ growth in daily active addresses
The overall Layer 2 ecosystem has reached $70 billion in TVL, with ZK rollups capturing increasing market share as proving costs continue declining.
Developer Adoption Signals
- Over 65% of new smart contracts in 2025 deployed on Layer 2 networks
- zkSync Era attracted approximately $1.9 billion in tokenized real-world assets, capturing ~25% of on-chain RWA market share
- Layer 2 networks handled an estimated 1.9 million daily transactions in 2025
The Compatibility-Performance Trade-off in Practice
Understanding the theoretical types is useful, but the practical implications for developers are what matter.
Type 1-2: Zero Migration Friction
For Scroll and Linea (Type 2), migration means literally zero code changes for most applications. Deploy the same Solidity bytecode, use the same tools (MetaMask, Hardhat, Remix), expect the same behavior.
Best for: Existing Ethereum applications prioritizing seamless migration; projects where proven, audited code must remain unchanged; teams without resources for extensive testing and modification.
Type 3: Careful Testing Required
For Polygon zkEVM and similar Type 3 implementations, most applications work but edge cases exist. Certain precompiles may behave differently or be unsupported.
Best for: Teams with resources for thorough testnet validation; projects not relying on exotic EVM features; applications prioritizing cost efficiency over perfect compatibility.
Type 4: Different Mental Model
For zkSync Era and StarkNet, the development experience differs meaningfully from Ethereum:
zkSync Era supports Solidity but transpiles it to custom bytecode. Contracts compile and run, but behavior may differ in subtle ways. Addresses aren't guaranteed to match Ethereum deployments.
StarkNet uses Cairo, requiring developers to learn an entirely new language—though one specifically designed for provable computation.
Best for: Greenfield projects not constrained by existing code; applications prioritizing maximum performance; teams willing to invest in specialized tooling and testing.
Security: The Non-Negotiable Constraint
The Ethereum Foundation introduced clear cryptographic security requirements for zkEVM developers in 2025:
- 100-bit provable security by May 2026
- 128-bit security by end of 2026
These requirements reflect the reality that faster proofs mean nothing if the underlying cryptography isn't bulletproof. Teams are expected to meet these thresholds regardless of their type classification.
The security focus has slowed some performance improvements—the Ethereum Foundation explicitly chose security over speed through 2026—but ensures the foundation for mainstream adoption remains solid.
Choosing Your zkEVM: A Decision Framework
Choose Type 1-2 (Taiko, Scroll, Linea) if:
- You're migrating existing battle-tested contracts
- Audit costs are a concern (no reaudit needed)
- Your team is Ethereum-native without ZK expertise
- Composability with Ethereum L1 matters
- You need synchronous interoperability with other based rollups
Choose Type 3 (Polygon zkEVM) if:
- You want a balance of compatibility and performance
- You can invest in thorough testnet validation
- Cost efficiency is a priority
- You don't rely on exotic EVM precompiles
Choose Type 4 (zkSync Era, StarkNet) if:
- You're building from scratch without migration constraints
- Maximum performance justifies tooling investment
- Your use case benefits from ZK-native design patterns
- You have resources for specialized development
What Comes Next
The type classifications won't remain static. Vitalik noted that zkEVM projects can "easily start at higher-numbered types and jump to lower-numbered types over time." We're seeing this in practice—projects that launched as Type 3 are advancing toward Type 2 as they complete precompile implementations.
More intriguingly, if Ethereum L1 adopts modifications to become more ZK-friendly, Type 2 and Type 3 implementations could become Type 1 without changing their own code.
The endgame appears increasingly clear: proving times will continue compressing, costs will continue declining, and the distinction between types will blur as hardware acceleration and algorithmic improvements close the performance gap. The question isn't which type will win—it's how quickly the entire spectrum converges toward practical equivalence.
For now, the framework remains valuable. Understanding where a zkEVM sits on the compatibility-performance spectrum tells you what to expect during development, deployment, and operation. That knowledge is essential for any team building on Ethereum's ZK-powered future.
Building on zkEVM infrastructure? BlockEden.xyz provides high-performance RPC endpoints across multiple zkEVM chains including Polygon zkEVM, Scroll, and Linea. Explore our API marketplace to access the infrastructure layer your ZK applications need.