zkEVM (Zero-Knowledge Ethereum Virtual Machine)
zkEVMs are EVM-compatible execution environments that leverage zero-knowledge proofs to verify the correctness of computations off-chain, enabling scalable and private Ethereum transactions.
A zkEVM (Zero-Knowledge Ethereum Virtual Machine) is a type of Layer 2 scaling solution for Ethereum that aims to execute Ethereum transactions and smart contracts in a way that can be efficiently verified using zero-knowledge proofs, while maintaining compatibility with the existing Ethereum ecosystem. The primary goal is to enable scalability by processing transactions off-chain and then submitting a concise proof of their validity to the Ethereum mainnet (Layer 1). The 'EVM' part signifies that the zkEVM is designed to be compatible with the Ethereum Virtual Machine, meaning that smart contracts written for Ethereum can be deployed and executed on the zkEVM with minimal or no modifications. This compatibility is crucial for adoption, as it allows existing dApps and tools to function seamlessly. There are different architectural approaches to building zkEVMs, broadly categorized into Type 1 (fully EVM-compatible), Type 2 (EVM-compatible with minor modifications), Type 3 (more generalized ZK-rollups), and Type 4 (fully abstract). The core challenge lies in translating the complex state transitions and computations of the EVM into a format suitable for zero-knowledge proof generation (e.g., arithmetic circuits or algebraic representations). This involves proving the correctness of EVM opcodes, state storage, and transaction execution off-chain. The resulting zero-knowledge proof is then verified on Layer 1, allowing the rollup to post its state updates securely and efficiently.
graph LR
Center["zkEVM (Zero-Knowledge Ethereum Virtual Machine)"]:::main
Pre_cryptography["cryptography"]:::pre --> Center
click Pre_cryptography "/terms/cryptography"
Rel_ethereum["ethereum"]:::related -.-> Center
click Rel_ethereum "/terms/ethereum"
Rel_evm_ethereum_virtual_machine["evm-ethereum-virtual-machine"]:::related -.-> Center
click Rel_evm_ethereum_virtual_machine "/terms/evm-ethereum-virtual-machine"
Rel_scalability["scalability"]:::related -.-> Center
click Rel_scalability "/terms/scalability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
Imagine [Ethereum](/en/terms/ethereum) is a busy city, and a zkEVM is like a super-fast train station built nearby. It processes lots of passenger requests (transactions) really quickly off to the side, and then sends a single, tiny report back to the main city saying everything was done correctly, without slowing down the main city.
🤓 Expert Deep Dive
zkEVMs represent a sophisticated application of zero-knowledge proof technology to enhance blockchain scalability, particularly for Ethereum. The fundamental challenge is bridging the gap between the EVM's execution model and the algebraic structures required by ZK-proof systems (like SNARKs or STARKs). Different zkEVM designs employ distinct strategies to achieve EVM compatibility while enabling ZK-proof generation. Type 1 zkEVMs aim for full EVM equivalence, meaning any valid EVM execution is also a valid zkEVM execution, often requiring complex circuit designs to represent EVM opcodes and state transitions. Type 2 and Type 3 zkEVMs relax strict EVM equivalence for greater ZK-friendliness, potentially sacrificing some compatibility for improved proof efficiency. Type 4 zkEVMs focus on abstracting the computation into a general arithmetic circuit, requiring a transpilation step from EVM bytecode. Key technical considerations include the efficient representation of EVM's Merkle Patricia Trie for state storage, handling of complex opcodes (e.g., hashing, precompiles), and managing the proof generation overhead. The security of a zkEVM relies on the soundness of the underlying ZK-proof system and the correctness of the EVM emulation within the ZK-friendly domain. Trade-offs involve the degree of EVM compatibility versus the efficiency and complexity of proof generation.