{"id":92492,"date":"2025-12-22T10:13:15","date_gmt":"2025-12-22T07:13:15","guid":{"rendered":"https:\/\/forklog.com\/en\/?p=92492"},"modified":"2025-12-23T11:46:46","modified_gmt":"2025-12-23T08:46:46","slug":"what-is-zkevm","status":"publish","type":"post","link":"https:\/\/forklog.com\/en\/what-is-zkevm\/","title":{"rendered":"What is zkEVM?"},"content":{"rendered":"
\n

What is zkEVM?<\/h2>\n

zkEVM is a smart-contract execution environment that supports zero-knowledge proofs<\/a> (ZKPs) and is fully compatible with Ethereum\u2019s infrastructure. <\/p>\n

On top of it run layer-2 solutions<\/a> (ZK rollups<\/a>) that scale the network, raise throughput and cut fees.<\/p>\n<\/div>\n

\n

How does a zkEVM work?<\/h2>\n

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<\/a> and dapps<\/span>, or build new products, without changing code.<\/p>\n

zkEVM execution environment<\/h3>\n

EVM<\/a> executes smart contracts and computes Ethereum\u2019s state after each new block. The virtual machine translates Solidity into a machine-readable format<\/span>, governing the rules for changing data on-chain.<\/p>\n

A zkEVM reproduces this environment and adds cryptographic verification. It takes the network\u2019s initial state, processes transactions and updates the data while simultaneously generating a zero-knowledge proof.<\/p>\n

Because Ethereum\u2019s architecture is preserved, developers can readily port existing dapps and tokens to a zkEVM.<\/p>\n

Proof scheme in a zkEVM<\/h3>\n

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

In a zkEVM, the proof system generates a ZK-proof to verify transactions. This guarantees computational accuracy and the correctness of state transitions.<\/p>\n

The zkEVM verifier smart contract<\/h3>\n

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.<\/p>\n

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:<\/p>\n

    \n
  1. Receives a validity proof (ZKP) from the rollup.<\/li>\n
  2. Compares the batch\u2019s resulting data with the system\u2019s initial state.<\/li>\n
  3. Confirms the correctness of the state update.<\/li>\n<\/ol>\n
    \"zkEVMs
    A zkEVM takes an initial state, processes transactions and produces an updated state with a ZKP. Source: Chainlink<\/a>.<\/figcaption><\/figure>\n

    The chief advantage is that the contract need not re-execute every transaction\u2014checking a single cryptographic proof suffices.<\/p>\n<\/div>\n

    \n

    What are the advantages of a zkEVM?<\/h2>\n

    A zkEVM offers several benefits over classic L1 blockchains and other rollup designs.<\/p>\n

    Secure scaling<\/h3>\n

    ZK-based virtual machines are not constrained by the base layer\u2019s relatively low throughput yet inherit its robustness.<\/p>\n

    L2 transactions are verified on L1 via validity proofs. This lets zkEVMs optimise speed and throughput without sacrificing security.<\/p>\n

    Lower fees<\/h3>\n

    The main difference from Optimistic Rollups<\/a> lies in data handling. \u201cOptimistic\u201d designs must publish full transaction data to L1.<\/p>\n

    A zkEVM writes only final state changes on-chain because correctness is already guaranteed cryptographically. Less data directly reduces users\u2019 gas costs.<\/p>\n

    Fast finalisation<\/h3>\n

    Optimistic rollups have a \u201cchallenge period\u201d of 1\u20132 weeks. In ZK systems, transactions finalise as soon as the proof is published to Ethereum.<\/p>\n

    This matters for the DeFi<\/a> sector: traders can move liquidity instantly, improving capital efficiency.<\/p>\n

    Network effects<\/h3>\n

    Full EVM compatibility opens access to Ethereum\u2019s vast ecosystem\u2014mature tools, libraries and documentation. As other major networks also use the VM (Polygon<\/a>, Avalanche<\/a>), the technology has effectively become a Web3<\/a> standard.<\/p>\n<\/div>\n

    \n

    What are the pitfalls of using a zkEVM?<\/h2>\n

    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<\/a> lacked smart-contract functionality\u2014supporting only simple token transfers, atomic swaps<\/a> and NFT<\/a> issuance.<\/p>\n

    Progress continues, but the community still faces several fundamental architectural tensions.<\/p>\n

    Stack-based architecture<\/h3>\n

    The EVM is stack-based (the LIFO<\/span> principle), which suits a simple VM but is inefficient for zero-knowledge proofs.<\/p>\n

    A register-based architecture is preferable for zkEVMs\u2014it better fits the heavy computation and cryptography on which ZK relies.<\/p>\n

    Opcode complexity<\/h3>\n

    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\u2019s behaviour.<\/p>\n

    Storage costs<\/h3>\n

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

    Proofs are resource-intensive<\/h3>\n

    Generating zero-knowledge proofs demands substantial resources. For fast, stable operation, networks often require costly specialised hardware.<\/p>\n<\/div>\n

    \n

    What types of zkEVM exist?<\/h2>\n

    Vitalik Buterin proposed<\/a> 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\u2019s architecture, the slower ZK proofs are to produce.<\/p>\n

    \"\u0442\u0438\u043f\u044b_zkEVM\"
    The main zkEVM types according to Vitalik Buterin. Source: vitalik.eth.limo<\/a>.
    <\/figcaption><\/figure>\n

    Type 1: full Ethereum equivalence<\/h3>\n

    These systems aim for near-total identity with the original network, preserving hash functions, state trees and consensus logic unchanged.<\/p>\n

    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\u2019s base layer.<\/p>\n

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

    Type 2: full EVM equivalence<\/h3>\n

    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.<\/p>\n

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

    Type 2.5: EVM equivalence except for gas costs<\/h3>\n

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

    Type 3: near-full EVM compatibility<\/h3>\n

    These support most EVM opcodes but intentionally omit functions onerous for ZK, such as certain precompiles.<\/p>\n

    This compromise accelerates the network and proof generation, though some complex apps may need code adjustments.<\/p>\n

    Type 4: language-level compatibility<\/h3>\n

    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\u2019s architectural constraints.<\/p>\n

    The downside is incomplete compatibility: contract addresses differ from mainnet and familiar debugging tools may be unavailable. Examples: zkSync Era<\/a> and Starknet<\/a> (via the Warp transpiler<\/span>).<\/p>\n

    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.<\/p>\n<\/div>\n

    \n

    What is the outlook for zkEVMs?<\/h2>\n

    Ethereum\u2019s scaling is entering a new phase with the advance of zkEVMs.<\/p>\n

    In October 2025, Brevis unveiled<\/a> 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\u2011second Ethereum Foundation<\/a> standard.<\/p>\n

    Pico Prism\u2019s 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.<\/p>\n

    These advances align with the Ethereum Foundation\u2019s strategy for a \u201cfull transition\u201d to ZK<\/a>. The initiative will begin with an optional zkEVM client for mainnet.<\/p>\n

    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.<\/p>\n

    Bankless co-founder Ryan Sean Adams believes<\/a> 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.<\/p>\n

    \n

    \u201cNo other blockchain follows this strategy \u2014 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,\u201d he concluded.<\/p>\n<\/blockquote>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    A zkEVM is a smart-contract runtime that supports zero-knowledge proofs and is fully compatible with Ethereum.<\/p>\n","protected":false},"author":1,"featured_media":92493,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"select":"1","news_style_id":"1","cryptorium_level":"","_short_excerpt_text":"A zkEVM brings ZK proofs to the EVM for faster, cheaper, secure Ethereum scaling.","creation_source":"","_metatest_mainpost_news_update":false,"footnotes":""},"categories":[2113],"tags":[46,277,1338,2400,1317],"class_list":["post-92492","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cryptorium","tag-ethereum","tag-scaling","tag-zk-rollups","tag-zk-evm","tag-zkp"],"aioseo_notices":[],"amp_enabled":true,"views":"333","promo_type":"1","layout_type":"1","short_excerpt":"A zkEVM brings ZK proofs to the EVM for faster, cheaper, secure Ethereum scaling.","is_update":"","_links":{"self":[{"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/posts\/92492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/comments?post=92492"}],"version-history":[{"count":1,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/posts\/92492\/revisions"}],"predecessor-version":[{"id":92494,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/posts\/92492\/revisions\/92494"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/media\/92493"}],"wp:attachment":[{"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/media?parent=92492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/categories?post=92492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/forklog.com\/en\/wp-json\/wp\/v2\/tags?post=92492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}