The answer that most of the industry has converged on is rollups – moving execution off the main chain while keeping Ethereum as the final source of truth. But the specific flavor of rollup that has generated the most technical ambition, the most VC funding, and the most heated debate is the zkEVM: a system that takes Ethereum’s smart contract engine and wraps it in advanced cryptography so that a single mathematical proof can stand in for thousands of individually verified transactions.
Getting this to work has turned out to be one of the hardest problems in blockchain engineering. Here is why.
Two Ideas That Were Never Meant to Meet
To understand what makes zkEVMs difficult, you need to understand the two things being stitched together.
The EVM (Ethereum Virtual Machine) is the software that runs smart contracts. Think of it as Ethereum’s operating system. Every node on the network runs the same EVM, executing the same transactions, arriving at the same results. That redundancy is what makes Ethereum trustworthy – but it is also what makes it slow. When millions of nodes re-execute every transaction independently, throughput has a hard ceiling.
Zero-knowledge proofs are a branch of cryptography that lets you prove a statement is true without revealing the evidence. In practical terms: instead of asking every Ethereum node to re-run a batch of 10,000 transactions, you can run them once off-chain, generate a compact cryptographic proof that the results are correct, and post just that proof to Ethereum. The chain verifies the proof in milliseconds. Done.
The problem? These two systems were designed in completely different eras, for completely different purposes. The EVM is a stack machine with an instruction set full of edge cases, branching logic, and storage quirks. Zero-knowledge circuits are rigid mathematical structures that demand everything be expressed as polynomial equations over finite fields. Making one simulate the other faithfully is like writing a pixel-perfect Game Boy emulator – except the emulator has to output a formal mathematical proof that every frame was rendered correctly.
MLOAD instruction can read 32 bytes starting at any offset, not just neatly aligned boundaries. In a ZK circuit, this means reading two consecutive aligned chunks and performing bitwise operations to extract the right slice – turning a single opcode into a multi-step arithmetic dance. Multiply that kind of friction across every opcode, every precompile, and every storage operation, and you begin to see why building a zkEVM takes years, not months.What Developers Actually Care About
If you are a Solidity developer with a battle-tested DeFi protocol on Ethereum mainnet, the promise of a zkEVM is straightforward: deploy your existing code on a faster, cheaper network without rewriting anything. Your users get cheap transaction fees and near-instant finality. Your contracts keep their audited, proven logic. Ethereum mainnet still serves as your security backbone.
That is the pitch. The reality depends heavily on which zkEVM you choose, because they are not all offering the same thing.
Some zkEVMs can run your bytecode untouched – the compiled output of your Solidity contracts drops in and works. Others need you to recompile from source, which means your contract logic is preserved but the low-level execution path changes. A few strip out EVM compatibility almost entirely and ask you to target a new virtual machine, keeping only Solidity as a common starting point.
Each approach sits at a different point on a fundamental tradeoff curve: the more faithfully you replicate the EVM, the harder it is to generate proofs efficiently.
The Tradeoff Nobody Can Escape
The EVM is the virtual machine – the instruction set that smart contracts target. Ethereum is the full system: the EVM plus the block structure, the state tree format, the Keccak hash function, the RLP encoding, and everything else that makes the protocol work. You can perfectly replicate the EVM without replicating Ethereum itself. That distinction is exactly the line separating the first two types.
Full Ethereum clones (Type 1) replicate the entire system – not just the EVM, but the state storage format, the block structure, and the hash functions. The payoff is extraordinary: a Type 1 zkEVM can verify actual Ethereum L1 blocks. This means it could serve as a ZK-based Ethereum client, enabling multiple independent implementations to cross-check each other using cryptographic proofs rather than redundant execution. The tradeoff is brutal: Keccak-256 and Merkle Patricia Tries are notoriously expensive to prove, and generating a proof for a single block can take hours. The Ethereum Foundation’s zkEVM project sits here, betting that prover technology will catch up.
Bytecode-compatible systems (Type 2) keep the EVM instruction set identical but swap out the surrounding plumbing – replacing Keccak with ZK-friendly hash functions like Poseidon, restructuring the state tree, simplifying the block format. Your compiled smart contracts deploy and run without modification. The incompatibilities only surface at the edges: code that directly verifies Merkle proofs against Ethereum’s state trie, or applications that depend on specific block header fields, may need adjustment. Everything else works. Scroll is the flagship example – currently the largest zkEVM by total value locked – and it has staked its reputation on making migration from mainnet as painless as possible.
Compiler-level systems (Type 4) take the most radical departure. Instead of proving EVM bytecode, they compile Solidity and Vyper into an entirely different instruction set optimized for proof generation. This is the path zkSync Era chose, and it shows in the numbers: hundrerds of millions transactions, double digit percentages of cost reduction versus mainnet, and proving times that are orders of magnitude faster than Type 1 approaches.
The catch is not abstract. When you recompile Solidity to a different target, the bytecode changes – and that means CREATE2 addresses change too, since they are derived from the contract’s bytecode hash. Any system relying on counterfactual deployment (deploying a contract to a pre-computed address) breaks silently. This is not a niche concern: ERC-4337 smart contract wallets, one of Ethereum’s most important account abstraction standards, depend on exactly this pattern. Handwritten EVM assembly and bytecode introspection also fail. These are the kinds of compatibility fractures that do not show up in demos but surface painfully in production.
Between these extremes sit Type 2.5 (full EVM but with tweaked gas costs for ZK-expensive operations) and Type 3 (most of the EVM, with a few features removed – typically complex precompiles – to simplify the circuits).
One thing that Buterin’s taxonomy makes clear: these types are not permanent identities. Projects migrate between them as their proving systems mature. Polygon and Scroll both operated at Type 3 while working toward Type 2. zkSync has discussed adding EVM bytecode interpretation alongside its compiler path, which would move it toward Type 3. And Scroll has explored running in both Type 2 and Type 1 modes simultaneously. The type system describes where a project is today, not where it will stay.
The pattern across all of these is consistent: compatibility and proving speed pull in opposite directions, and every team picks a point on that curve and defends it – for now.
How It Differs From the Other Rollup Approach
zkEVMs are not the only rollup game in town. Optimistic rollups – used by Arbitrum and Optimism, currently the two largest layer-2 networks – take a fundamentally different bet. They post transaction data to Ethereum and assume everything is valid unless someone objects. A dispute window (typically seven days) gives watchers time to submit a fraud proof if they catch something wrong.
This is simpler to build. You do not need exotic cryptography or specialized proving hardware. But it comes with a cost: finality takes a week. If you deposit assets into an optimistic rollup bridge, withdrawing them to mainnet means waiting through that challenge period. Various workarounds exist (fast bridge services, liquidity networks), but they add complexity and trust assumptions.
zkEVMs eliminate this entirely. The proof is included with the batch. Verification happens on submission. Finality is bounded by Ethereum’s own block time, not by an arbitrary waiting period. For institutional DeFi, cross-chain asset movement, and any application where settlement speed matters, this is a material advantage.
Where Things Stand Today
The zkEVM space has shifted from “can this even work?” to “which approach wins?” Several projects are in production, handling real money:
The Convergence Thesis
Buterin has argued that, in the long run, everything converges toward Type 1. Not because Type 1 proving gets fast enough on its own, but because the pressure works from both directions simultaneously.
From below, ZK prover technology keeps improving: better algorithms, hardware acceleration, parallelization. Proving times that were measured in hours are now measured in seconds. From above, Ethereum itself can evolve to become more ZK-friendly – replacing Keccak with Poseidon at the protocol level, restructuring the state tree, simplifying precompiles. Every change Ethereum makes to accommodate ZK proofs narrows the gap that lower types exist to bridge.
If that convergence happens, the endgame is remarkable: multiple independent zkEVM implementations, each built by different teams, each capable of generating validity proofs for actual Ethereum L1 blocks. Ethereum would gain the same kind of client diversity it has today with execution clients like Geth and Nethermind – but backed by cryptographic proof rather than redundant execution. A bug in one implementation would not compromise the network because the others would catch it mathematically.
The Bigger Picture
Over 65% of new smart contracts in 2025 deployed on layer-2 networks rather than Ethereum mainnet. That migration is already happening, and zkEVMs are positioned to capture an increasing share of it.
But the significance reaches beyond Ethereum scaling. zkEVMs represent a broader architectural shift: the idea that you can replace redundant computation with cryptographic proof. Instead of thousands of nodes doing identical work to achieve consensus, one node does the work and proves it was done right. Everyone else just checks a short proof.
That model – compute once, verify everywhere – has implications well beyond blockchain. Any distributed system that currently relies on redundant execution for trust could potentially be restructured around validity proofs.
