zkEVM là gì? Running the EVM on Proofs Instead of Execution

Imagine a big construction project in Hanoi. Every wall, every beam, every pipe has to be checked. On normal Ethereum, every single node in the network re-checks every wall — a thousand engineers each walk the whole building to certify it is safe. Now imagine one engineer checks the building once, then signs a stamped certificate. The city accepts the stamp as proof the entire building is safe — no one re-walks the site.

That is what a zkEVM does. zkEVM là gì? It is a zero-knowledge virtual machine that runs Ethereum smart contracts and produces a cryptographic validity proof — a stamped certificate — proving the execution was correct. Instead of every node re-executing every transaction, only one machine runs the code, and everyone else verifies a tiny proof. Ethereum still approves the building, but it checks the stamp, not the walls.

In this guide you'll learn how zkEVMs work under the hood, why zk evm tương thích with existing Ethereum tools matters, what changes for zkevm solidity developers, and how the major projects — zkSync, Polygon zkEVM, Scroll, Linea, Starknet — sit on the compatibility spectrum.

---

zkEVM là gì — The Short Answer

A zkEVM (zero-knowledge Ethereum Virtual Machine) is an execution environment that runs EVM-compatible smart contracts while generating a zero-knowledge proof that the execution was done correctly. It is the programmability layer inside a ZK rollup — the part that lets a Layer-2 rollup run Solidity contracts, not just simple transfers.

Three words to unpack:

• EVM — the Ethereum Virtual Machine, the rulebook that defines how smart contracts

run. It is a state transition function: give it a state and a transaction, it returns a new state.

• Zero-knowledge proof — a way for a prover to convince a verifier a statement is true

without revealing the details of how.

• Validity proof — when applied to a rollup, the proof says "these transactions were

processed correctly and the new state is right." This is what makes it a *validity rollup* (zk-rollup) rather than an optimistic one.

The key inversion in our title — running the EVM on proofs instead of execution — is this: on L1, every node re-executes every transaction, using trust through redundancy. A zkEVM replaces that redundancy with trust through math. Execute once, prove once, verify everywhere.

---

Why EVM Compatibility Matters (The Inheritance Argument)

The EVM is not just a machine; it is an ecosystem. The single biggest asset Ethereum has is the network effect of its tooling and developer base. A zkEVM that can run existing contracts inherits that network effect:

• Solidity developers can deploy with the same language, the same mental model.
• Wallets, explorers, indexers understand the same bytecode and ABI formats.
• Existing contracts — DeFi protocols, token standards — work without rewriting.
• Auditors and security tooling can reason about the same semantics as on L1.

This is why the compatibility question dominates the industry. Every zkEVM team has to decide: how much of Ethereum do we drag into the circuit? That decision is the heart of Vitalik Buterin's famous framework.

---

How a zkEVM Proves Execution (Under the Hood)

Let's go one layer deeper than "it makes a proof."

The Execution Trace Is the Source of Truth

A transaction doesn't run as one giant step. It runs as a long ordered list of tiny machine instructions called opcodes — ADD, SLOAD, CALL, SHA3, and hundreds more. Each opcode has a precise rule defined in the Ethereum Yellow Paper (for example, ADD pops two values from the stack and pushes their sum).

The record of every opcode executed — along with the stack, memory, and storage effects — is called the execution trace. This trace is the raw material the zkEVM turns into a proof.

From Trace to Proof

1. Run the transaction, capturing the full execution trace.
2. Turn each opcode into a constraint — an algebraic statement like "top two stack

cells, when added, equal the new top cell." The whole trace becomes a big system of constraints (a circuit).

1. Prove all constraints hold using a zero-knowledge proof system (SNARK or STARK).
2. Verify on Ethereum: the L1 verifier contract checks the one compact proof, then

updates the state root. The proof guarantees the new state root is correct — it certifies f(S, T) = S' without anyone re-running T.

Because the proof attests to correctness — not secrecy — it also means the L1 verifier doesn't need to know the contents of every transaction. The city checks the stamp, not the walls.

---

Figure 1: How a zkEVM proves execution — from transaction to a certified state root

---

The Compatibility Spectrum: Vitalik's Four Types

In August 2022, Vitalik Buterin published "The different types of ZK-EVMs," framing the industry's core trade-off. The types are not a quality ranking — they are points on a sliding scale of what gets proven.

Type	Name	What It Proves	Compatibility	Proving Speed	Examples
1	Ethereum-equivalent	Everything, incl. block structure & state tree	Perfect	Slowest	PSE zkEVM, Taiko
2	EVM-equivalent	EVM bytecode (tweaked block/state for speed)	Excellent	Faster	Polygon zkEVM, Scroll
3	Almost EVM-equivalent	Bytecode minus hardest-to-prove features	Good (some rewrites)	Fast	Early Scroll/Polygon (transitional)
4	High-level-language equivalent	Solidity compiled to a ZK-friendly language	Limited (addresses change)	Fastest	zkSync Era, Starknet

The rule of thumb Vitalik gives: lower types are more compatible but slower to prove; higher types are faster but break more assumptions. Precompiles — specialized cryptographic contracts like Keccak or ecrecover — are usually "at the top of the list" of things removed by Type 3 because they are notoriously hard to ZK-prove.

Projects move between types as their prover technology matures. Early Scroll and early Polygon zkEVM shipped as Type 3; both are converging toward Type 2. zkSync's STARK-based plans include eventual support for Rust and C++ contracts too.

---

Figure 2: Vitalik's four types of zkEVM — the compatibility vs speed spectrum

---

The Two Big Families: Bytecode-Level vs Source-Level

Underneath the four types, there is a simpler divide that determines the developer experience.

Family 1: Prove Native EVM Bytecode (Types 1–3)

Polygon zkEVM, Scroll, and Linea prove EVM bytecode directly. The circuit interprets the same bytecode the EVM would run. This is the strongest security story: because the state-transition spec being proven is Ethereum's, behavior is inherited faithfully rather than silently reinterpreted.

• Polygon zkEVM builds toward Type 2. It proves bytecode via a custom zkASM

interpreter and PIL arithmetization, and batches multiple L2 blocks. Most of the standard toolchain — Hardhat, Foundry, Remix, Etherscan verification — works directly.

• Scroll proves native bytecode and uses Ethereum's native Merkle-Patricia Trie for

state commitments, and now runs its prover on a RISC-V zkVM (OpenVM).

• Linea (ConsenSys) markets itself as fully EVM-equivalent, with deep MetaMask

integration.

For these, zkevm solidity compatibility is near-total: recompile and deploy.

Family 2: Compile the Source Language (Type 4)

zkSync Era and Starknet take a different route: they prove a custom language designed to be ZK-friendly, not the EVM bytecode.

• zkSync Era compiles Solidity/Vyper with zksolc / zkvyper — an LLVM-based

toolchain that takes Solidity → Yul/IR → LLVM IR → EraVM bytecode, the instruction set of zkSync's custom register-based VM. You write the same Solidity, but a different compiler produces different bytecode.

• Starknet (StarkWare) uses Cairo, a provable-by-design language. Contracts are

written in Cairo or Rust, not Solidity — migration means a rewrite.

Type 4 proving is much faster (it proves a language built for ZK, not a virtual machine built in 2015), but it sacrifices compatibility at the edges: contract addresses can differ, handwritten EVM bytecode is hard to use, and some opcode behavior changes.

---

Figure 3: What a Solidity developer sees on each zkEVM family

---

zkevm solidity — What Actually Changes for Developers

The most practical question a Vietnamese Solidity developer asks: "Tôi có cần viết lại smart contract của mình không?" The honest answer depends on the family.

On Polygon zkEVM / Scroll / Linea (bytecode-level)

• Change: minimal. The same compiler, the same bytecode, the same deployment flow.
• Watch out for: state-tree differences (some use Poseidon-based trees), gas repricing

for expensive opcodes (Keccak, storage writes), and precompile behavior in Type 3 phases.

On zkSync Era (source-level)

• Change: recompile. Install zksolc and recompile your Solidity. Most contracts work,

but the edge cases are real: - extcodesize checks break. In EraVM every account is a smart account, so an EOA returns a non-zero extcodesize. Code that rejects contracts by this check will misbehave. - block.number returns the L2 batch number, not a per-transaction block number. - tx.origin is dangerous under native account abstraction (any smart account can be the origin). - CREATE / CREATE2 address derivation differs from Ethereum. - Gas has two dimensions: execution gas plus pubdata cost (bytes posted to L1). Always estimate with zks_estimateFee, not the standard eth_estimateGas. - Native account abstraction is always on — accounts are contracts, and paymasters can sponsor gas.

The Golden Rule

Test on testnet first, and re-check every assumption your contract makes about the EVM. Equivalent ≠ identical. This is the crux of zk evm tương thích: compatibility is a spectrum, and "works" is not the same as "works exactly like L1."

---

Gas, Precompiles, and the Hidden Compatibility Tax

Even the "most compatible" zkEVMs change the economics:

• Precompiles are the pain point. Keccak, ecrecover, modexp — all are expensive to

express as constraints inside a circuit. Type 3 zkEVMs remove or replace them; Type 2 designs have to prove them, which raises proving cost.

• Gas repricing. Some zkEVMs (the "Type 2.5" idea) deliberately lower gas for

expensive-to-prove opcodes like Keccak and storage writes, so users pay closer to the real cost of proving.

• Pubdata is real money. On zkSync, every byte you post to L1 costs gas. Efficient

calldata (short revert strings, packed arguments) directly lowers fees.

• Storage hashes. Some zkEVMs store state in ZK-friendly trees, so storage slot

addresses and proofs differ from Ethereum's Merkle-Patricia Trie — invisible to most contracts, but visible to protocols that read proofs or state roots directly.

---

Limitations and the Road Ahead

zkEVMs are production software, but they are not done:

• The prover is the bottleneck. Proving a batch takes far longer than executing it.

Provers today often run on specialized hardware owned by the founding team or a small set of operators — prover decentralization is an open problem.

• Liquidity fragmentation. A dozen ZK chains each build their own ecosystem; bridging

is friction and risk.

• Precompile proving cost keeps Type 2 slower than Type 4, which is why the "which

type" question keeps moving.

• The endgame is L1 itself. The Ethereum Foundation is actively researching zkEVMs to

verify Ethereum L1 blocks. Vitalik's hope: "everything becomes Type 1 over time" — Ethereum itself proven, and no one ever re-executes again.

For a Vietnamese developer, the practical roadmap: zk evm tương thích is already good enough for most dApps. Choose a bytecode-equivalent chain (Polygon zkEVM, Scroll, Linea) for drop-in deployments, or zkSync if you need the fastest proving and can handle the recompile checklist.

---

Figure 4: The zkEVM ecosystem at a glance

---

FAQ

Q: zkEVM là gì?

A: A zero-knowledge Ethereum Virtual Machine — an execution environment that runs EVM-compatible smart contracts and generates a validity proof that execution was correct. It lets ZK rollups run Solidity contracts without every node re-executing every transaction.

Q: zk evm tương thích với Ethereum như thế nào?

A: On a spectrum. Bytecode-equivalent zkEVMs (Polygon zkEVM, Scroll, Linea) are near-total: recompile and deploy. Source-level zkEVMs (zkSync Era) require zksolc and have edge-case differences (extcodesize, block.number, CREATE2, two-part gas). Starknet requires a rewrite in Cairo.

Q: zkevm solidity — tôi có cần viết lại contract không?

A: Usually not on bytecode-equivalent chains. On zkSync Era you recompile with zksolc, fix the edge cases above, and test on testnet. Only Starknet genuinely requires rewriting in a new language.

Q: zkEVM và zk-rollup khác nhau thế nào?

A: A zk-rollup is the full Layer-2 system (sequencer, bridge, data availability, settlement). The zkEVM is the execution engine inside it — the part that runs contracts and produces the proof. One is the building, the other is the engineer who certifies it.

Q: zkSync Era và Polygon zkEVM khác nhau ra sao?

A: zkSync proves its own EraVM bytecode compiled from Solidity (Type 4, faster, more edge cases). Polygon zkEVM proves native EVM bytecode (Type 2 target, more compatible, slower to prove). One favors speed, the other favors drop-in compatibility.

---

Summary: The Building, the Stamp, and the Inspector

• The EVM is a state transition function — the rulebook for how contracts run.
• A zkEVM proves the rulebook was followed — it turns the execution trace into

constraints, proves them, and lets Ethereum verify a tiny proof instead of re-running everything.

• Compatibility is a spectrum — Vitalik's four types trade compatibility for proving

speed; bytecode-level families (Polygon zkEVM, Scroll, Linea) favor compatibility, source-level families (zkSync, Starknet) favor speed.

• For developers, "works" ≠ "identical" — test everything, watch the opcode and gas

edge cases, and treat zk evm tương thích as a spectrum you verify, not a checkbox you trust.

The construction site in Hanoi is still being built. But the direction is clear: Ethereum is moving from a thousand engineers re-checking every wall to one engineer, one stamp, verified everywhere. Understanding zkEVM today means understanding where the whole industry is headed — proof instead of execution, math instead of redundancy.

---

Word count: ~2,100 | Primary keyword: "zk evm là gì" | Secondary: "zkevm solidity", "zk evm tương thích"