Telegram (AI) YouTube Facebook X
Ру

What is zkEVM?

What is zkEVM?
What is zkEVM?

What is zkEVM?

zkEVM is a smart-contract execution environment that supports zero-knowledge proofs (ZKPs) and is fully compatible with Ethereum’s infrastructure.

On top of it run layer-2 solutions (ZK rollups) that scale the network, raise throughput and cut fees.

How does a zkEVM work?

A zkEVM gives developers access to the Ethereum environment atop a ZK-rollup architecture. It combines familiar tooling with L2 security and speed, letting teams lift and shift existing smart contracts and dapps, or build new products, without changing code.

zkEVM execution environment

EVM executes smart contracts and computes Ethereum’s state after each new block. The virtual machine translates Solidity into a machine-readable format, governing the rules for changing data on-chain.

A zkEVM reproduces this environment and adds cryptographic verification. It takes the network’s initial state, processes transactions and updates the data while simultaneously generating a zero-knowledge proof.

Because Ethereum’s architecture is preserved, developers can readily port existing dapps and tokens to a zkEVM.

Proof scheme in a zkEVM

ZKPs let one cryptographically prove possession of certain information without revealing the underlying data (for example, proving sufficient funds without disclosing a wallet balance).

In a zkEVM, the proof system generates a ZK-proof to verify transactions. This guarantees computational accuracy and the correctness of state transitions.

The zkEVM verifier smart contract

In Ethereum, nodes must check every transaction, limiting throughput. ZK rollups address this by batching many operations and generating a single zero-knowledge proof for the lot, then posting it to the base chain.

This lightens the load on the blockchain, boosting throughput and lowering fees while keeping L1-grade security. A key role is played by the verifier smart contract deployed on Ethereum mainnet. It works as follows:

  1. Receives a validity proof (ZKP) from the rollup.
  2. Compares the batch’s resulting data with the system’s initial state.
  3. Confirms the correctness of the state update.
zkEVMs take an initial state
A zkEVM takes an initial state, processes transactions and produces an updated state with a ZKP. Source: Chainlink.

The chief advantage is that the contract need not re-execute every transaction—checking a single cryptographic proof suffices.

What are the advantages of a zkEVM?

A zkEVM offers several benefits over classic L1 blockchains and other rollup designs.

Secure scaling

ZK-based virtual machines are not constrained by the base layer’s relatively low throughput yet inherit its robustness.

L2 transactions are verified on L1 via validity proofs. This lets zkEVMs optimise speed and throughput without sacrificing security.

Lower fees

The main difference from Optimistic Rollups lies in data handling. “Optimistic” designs must publish full transaction data to L1.

A zkEVM writes only final state changes on-chain because correctness is already guaranteed cryptographically. Less data directly reduces users’ gas costs.

Fast finalisation

Optimistic rollups have a “challenge period” of 1–2 weeks. In ZK systems, transactions finalise as soon as the proof is published to Ethereum.

This matters for the DeFi sector: traders can move liquidity instantly, improving capital efficiency.

Network effects

Full EVM compatibility opens access to Ethereum’s vast ecosystem—mature tools, libraries and documentation. As other major networks also use the VM (Polygon, Avalanche), the technology has effectively become a Web3 standard.

What are the pitfalls of using a zkEVM?

ZKP and the EVM evolved independently for years, making their fusion into a single zkEVM a demanding engineering task. Early efforts such as zkSync Lite lacked smart-contract functionality—supporting only simple token transfers, atomic swaps and NFT issuance.

Progress continues, but the community still faces several fundamental architectural tensions.

Stack-based architecture

The EVM is stack-based (the LIFO principle), which suits a simple VM but is inefficient for zero-knowledge proofs.

A register-based architecture is preferable for zkEVMs—it better fits the heavy computation and cryptography on which ZK relies.

Opcode complexity

Unlike standard runtimes, the EVM uses a specialised set of instructions (opcodes) such as CALL, DELEGATECALL and REVERT. Adapting them to ZK circuits is hard, complicating the architecture and verification of the VM’s behaviour.

Storage costs

To organise data, the EVM uses the Merkle-Patricia tree and the hashing algorithm Keccak, neither optimised for ZK technologies. Proving the correctness of such hashes is compute-intensive, reducing system performance.

Proofs are resource-intensive

Generating zero-knowledge proofs demands substantial resources. For fast, stable operation, networks often require costly specialised hardware.

What types of zkEVM exist?

Vitalik Buterin proposed a zkEVM classification that highlights a key trade-off in design: choosing between Ethereum compatibility and proof-generation speed. The closer a system mirrors the base network’s architecture, the slower ZK proofs are to produce.

типы_zkEVM
The main zkEVM types according to Vitalik Buterin. Source: vitalik.eth.limo.

Type 1: full Ethereum equivalence

These systems aim for near-total identity with the original network, preserving hash functions, state trees and consensus logic unchanged.

The approach ensures complete compatibility with native applications, allows block explorers and standard execution clients to work without modification, and could ultimately bring ZK directly to Ethereum’s base layer.

The cost is resources: since the blockchain was not designed for this cryptography, proof generation in projects such as Taiko can take several hours.

Type 2: full EVM equivalence

These retain full application-level compatibility while optimising internals. For example, they may replace the resource-hungry Keccak with hash functions friendlier to ZK computation. This lets teams run existing dapps and use familiar developer tools unchanged.

Proofs are faster to generate than in Type 1, but still relatively slow. Examples: Scroll, Polygon zkEVM (in June 2025, a team of seven developers moved to the independent project ZisK).

Type 2.5: EVM equivalence except for gas costs

Raising gas costs for specific operations speeds up proof generation in complex scenarios, but may break some applications and require code changes.

Type 3: near-full EVM compatibility

These support most EVM opcodes but intentionally omit functions onerous for ZK, such as certain precompiles.

This compromise accelerates the network and proof generation, though some complex apps may need code adjustments.

Type 4: language-level compatibility

This abandons direct EVM mimicry. Instead, Solidity or Vyper is compiled into a format natively optimised for ZK proofs. That sidesteps the stack-versus-register conflict, maximising performance and minimising fees because the system is not burdened by Ethereum’s architectural constraints.

The downside is incomplete compatibility: contract addresses differ from mainnet and familiar debugging tools may be unavailable. Examples: zkSync Era and Starknet (via the Warp transpiler).

The industry is converging. Type 4 projects (for example, zkSync) are broadening standards support, edging towards Types 2 and 3, while Type 2 teams (Polygon, Scroll) focus on prover optimisations to speed things up.

What is the outlook for zkEVMs?

Ethereum’s scaling is entering a new phase with the advance of zkEVMs.

In October 2025, Brevis unveiled Pico Prism, a technology that enables near-instant proof generation using ordinary gaming GPUs. Tests showed strong efficiency: average block processing time was 6.9 seconds, and 96.8% of operations met the 10‑second Ethereum Foundation standard.

Pico Prism’s architecture has a single node create the ZK proof. Other network participants can verify it in fractions of a second, without wasting resources on re-computation.

These advances align with the Ethereum Foundation’s strategy for a “full transition” to ZK. The initiative will begin with an optional zkEVM client for mainnet.

In future, validators will be able to attest blocks by checking three independent proofs instead of re-executing transactions. The changes are intended to reinforce decentralisation and censorship resistance, enabling solo stakers to help secure the ecosystem.

Bankless co-founder Ryan Sean Adams believes that Ethereum is becoming a full-fledged ZK blockchain. In his view, the base layer will become the global layer for DeFi, with nodes runnable even on smartphones, while most user activity moves to L2.

“No other blockchain follows this strategy — using ZK technology to achieve maximum scalability and decentralisation. Bitcoin remains conservative with first-generation cryptography. Ethereum is actively moving to second-generation cryptography. Others scale with nodes that require data centres,” he concluded.

Follow ForkLog on social media

Telegram Instagram
Found a mistake in the text? Highlight it and press CTRL+ENTER.

Рассылки ForkLog: держите руку на пульсе биткоин-индустрии!

We use cookies to improve the quality of our service.

By using this website, you agree to the Privacy policy.

OK