Linh has shipped Solidity on Ethereum for three years. Every Friday she does the same ritual: hardhat run deploy.ts, wait for confirmation, update the frontend's contract address. Then a client asks her to deploy the same protocol on a zkEVM. As a zk evm developer new to this world, she expects "add an RPC, change the chain id." Instead she discovers a menu: zkSync, Scroll, Linea, Taiko, and a recently sunset Polygon zkEVM — each with a different compiler, different deploy script, and different gas model. This article is the map she needed: what actually changes in the toolchain when your Solidity runs behind a zero-knowledge proof, chain by chain, with the tradeoffs spelled out.
The good news first: your Solidity knowledge carries over almost 100%. You do not need to learn a new language, a new state model, or how to build a circuit. The bad news: "zkEVM" is not one thing, and the toolchain difference is decided by one question — which bytecode actually runs. Answer that and every other change follows.
Figure 1: The zkEVM compatibility spectrum — the bytecode your compiler emits decides everything else in the toolchain
The zkEVM compatibility spectrum: which "EVM" are you deploying to?
In 2022 Vitalik Buterin published a typology that the industry still uses: Type 1 through Type 4, ordered by how faithfully each system reproduces the Ethereum Virtual Machine. Every tier accepts Solidity source code. The difference is what the compiler emits and what the chain executes.
Type 1 — Ethereum-equivalent. The same EVM bytecode, the same opcodes, the same state transition, verified with a proof. Taiko is the production example. You deploy exactly what you deploy on L1. The cost: proving the EVM directly is the most expensive kind of proving, which pushes fees up.
Type 2 — EVM-equivalent. Your bytecode runs unchanged, but the chain re-weights gas for a handful of opcodes that would otherwise blow up the prover, and stubs a few precompiles. Scroll and Linea are the production examples. Scroll's docs list the differences honestly: SELFDESTRUCT is disabled, DIFFICULTY/PREVRANDAO returns 0, COINBASE returns a fee vault, and the EIP-4844 blob opcodes are not exposed on L2. Most contracts never touch these.
Type 3 — mostly equivalent. Some opcodes are replaced with ZK-friendly counterparts, gas semantics are modified, and precompiles are only partially implemented. Your source compiles, but the behavior can diverge in gas-sensitive code. Polygon zkEVM was the marquee Type 3 — and it is the cautionary tale of this article.
Type 4 — Solidity-equivalent. The chain abandons EVM bytecode entirely and runs a custom VM. zkSync Era's EraVM executes its own instruction set. Your Solidity is source-compatible: it compiles, but to a different bytecode, through a different compiler, with different storage and gas semantics. This is the maximum toolchain delta.
The consequence is sharper than most tutorials admit. On Type 1 and Type 2, solc is still your compiler — the bytecode that runs is the bytecode you already audit. On Type 4, zksolc is your compiler — a second toolchain you must adopt, with its own versioning that tracks the EraVM protocol rather than Solidity. A solidity zk rollup dev who understands this single fork understands 80% of the migration work.
What changes in the compiler pipeline
Start with the chain that changes nothing. On Scroll, Linea, and Taiko, deployment is "add the RPC, deploy." Your Hardhat config gains a network entry, your Foundry foundry.toml gains an RPC URL, and solc produces the same bytecode it always has. Same addresses under the same CREATE2 salt, same storage layout, same tests. The audit your contract received on Ethereum mainnet applies to the L2 deployment directly — auditors call this transferability, and it is worth $20,000–50,000 per deployment in avoided re-audit work. For small Vietnamese teams that number is not abstract; it is often a quarter of a project's budget.
zkSync Era is the other end. Its toolchain is an LLVM pipeline. solc runs first as a child process and emits an AST; then zksolc lowers that IR to LLVM IR, runs the LLVM optimizer, and emits EraVM bytecode. Several practical consequences follow:
- Two compilers to version. zksolc's version tracks the EraVM protocol, so "update the compiler" means something different from solc's releases. Read the changelog.
- A different optimizer vocabulary. zksolc uses LLVM levels 0/1/2/3 plus
z(deployment-size optimization) and asizeFallbackre-run. Your oldruns: 200setting is meaningless. - Surprise divergences. Inline assembly that leans on EVM stack semantics can break.
tx.originandsend/transferare suppressed warnings.ripemd160is suppressed.ecrecoverworks.CREATE2addresses are derived from the bytecode hash, not raw init code, so they differ from L1. - A gas model that inverts your instincts. Storage is comparatively cheap, computation comparatively expensive. Contracts that hardcode gas amounts will behave differently, and your estimate of "what's expensive" needs re-learning.
In April 2025 zkSync shipped the EVM Bytecode Interpreter, which runs unmodified EVM bytecode on EraVM. Suddenly standard Foundry, Hardhat, and Remix work with no plugins, and create/create2 match the EVM exactly. The catch: interpreted execution costs more gas than native EraVM bytecode. So zkSync now offers a genuine choice — plain tooling at a fee premium, or custom tooling at the lower fee. The cost moved from developer time to user fees.
Figure 2: Solidity toolchain before vs after zkEVM — EVM-equivalent chains add an RPC; Solidity-equivalent chains add a new compiler
The zkevm tools that change in deployment and testing
For a Type 4 chain the deploy script itself changes. On zkSync you do not call ethers.getContractFactory and deploy; you use the Deployer class from @matterlabs/hardhat-zksync-deploy, or run forge create --zksync if you prefer the Foundry fork. The plugin suite is now bundled as @matterlabs/hardhat-zksync and includes compile, deploy, verify, Vyper support, upgradeable contracts, and a local node plugin that runs anvil-zksync for a local dev environment. foundry-zksync (installed via foundryup-zksync) adds --zksync flags to forge build, forge test, and forge create.
Everything downstream follows: contract verification goes through the zkSync verifier (which had its own bytecode-representation quirks fixed in 2026), the zksync-ethers SDK wraps ethers with EraVM-aware transaction fields, and gas estimation needs the zkSync gas model rather than an L1 heuristic. Testing, too, is a fork: era-test-node / anvil-zksync replicate EraVM locally, and stack traces come from zkSync-aware tooling.
Here is the honest summary a solidity zk rollup dev should keep in mind:
- Scroll / Linea / Taiko: zero toolchain delta. This is the "it just works" tier. Your CI, your fuzzing, your Tenderly traces — all carry over.
- zkSync (native EraVM): adopt hardhat-zksync or foundry-zksync, re-run the test suite, re-validate edge cases (assembly, precompiles, gas branches, address derivation), and budget for a re-audit.
- zkSync (interpreter): standard tools work, gas is higher, and — as the 2026 verifier fixes show — EVM-emulated verification is still maturing.
For Vietnamese teams the split is practical. Teams shipping DeFi or lending logic should treat Scroll's audit transferability as a line item; teams shipping GameFi or consumer apps should look hard at zkSync's account abstraction (next section), because that is where the user-facing value lives.
Gas, fees, and the prover you never see
Two things happen after your transaction executes: a sequencer orders it into a batch, and a prover constructs a zero-knowledge proof that the whole batch executed correctly. That proof is verified by a contract on Ethereum L1, which is what makes a zkEVM "validity-based" — withdrawals finalize in hours, not the 7-day fraud window optimistic rollups need.
Figure 3: zkEVM architecture — the developer never runs the prover, but its cost and schedule set the fees and finality
You, the developer, never run the prover. But its cost is in your fees and its schedule is your finality. A single proof can cost $50–500 in compute; the prover operator earns the difference between what users pay in gas and what proving costs. That is why the industry obsesses over proof cost. zkSync's Boojum upgrade cut proving costs roughly tenfold, and 2026 research shows proof generation has improved about 60x since early designs, with leading teams demonstrating sub-2-second proofs — faster than Ethereum's 12-second block time.
Fee arithmetic differs by chain. zkSync charges ~$0.01–0.06 per swap; Scroll ~$0.05–0.18. Scroll's fee is two parts — an L2 execution fee plus an L1 data fee for posting the transaction data to Ethereum, which is usually the dominant and most volatile component. zkSync's ZK-native gas pricing makes storage cheap and computation expensive. And finality ranges from about 20–45 minutes on zkSync to 30–60 minutes on Scroll, with "fast finality" features shrinking perceived latency on both.
Two operational realities matter more than the numbers. First, as of 2026 every major zkEVM runs a centralized prover; permissionless proving is a roadmap item (zkSync late 2026, Linea "by year-end 2026"), and Scroll's prover is open-source. Your chain's proof pipeline is a trust assumption, not a solved problem. Second, Dencun's blobs (EIP-4844) cut data costs but compatibility is patchwork — Scroll documents that blob opcodes are not exposed on L2 despite blob-based data availability, which will break naive monitoring code.
Account abstraction: zkSync's differentiator
The one feature that changes what you can build rather than how you deploy is account abstraction. zkSync Era ships it natively at the protocol level: every account is a smart contract, paymasters can sponsor gas, users can pay fees in any ERC-20, and passkey login and session keys work without ERC-4337 bundlers. On Scroll, Linea, and Taiko you build the same UX with ERC-4337 and bundler infrastructure (Pimlico, Stackup, Biconomy) — standard Ethereum AA tooling, unchanged.
For a developer the difference is architectural. ERC-4337 code written for L1 does not port to zkSync's native AA and vice versa; signature validation, msg.sender semantics, and the concept of "an account" differ. This is the single strongest reason consumer apps choose zkSync — and the single biggest trap for teams porting AA code the other direction.
Polygon zkEVM is gone: the chain-lifecycle risk
In June 2025 Polygon Labs gave twelve months' notice: Polygon zkEVM Mainnet Beta would be sunset. In July 2026 the sequencer stopped producing blocks. The chain no longer exists as an active network. EOA-held funds are recoverable through a Claims interface until December 2027, but assets locked in DeFi contracts are not recoverable through it, and infrastructure providers ended endpoint support. There is no migration path; Polygon redirected effort to Polygon PoS, the Agglayer, and the CDK framework.
This is the most important lesson in the article, and it is not about compilers. A zkEVM is a multi-year bet on a team's roadmap. The zkevm tools you adopt today (zksolc on zkSync, plain solc on Scroll) are a smaller risk than the chain-lifecycle risk — a rollup can be deprioritized under you. When you choose a chain, check the funding, the roadmap, and the history. Today's safe defaults are zkSync Era for consumer/AA apps, Scroll for audit-heavy DeFi, and anything CDK-based or optimistic for "build anywhere, settle anywhere" ambitions. Do not start a new build on a deprioritized rollup.
A practical checklist for the solidity zk rollup dev
- Recompile first, port never. On Scroll/Linea/Taiko nothing changes. On zkSync, run your existing suite through zksolc or the interpreter before touching a single line of Solidity.
- Audit the audit. Scroll transfers your L1 audit; zkSync requires re-validation for EraVM behavior. The $20–50K difference is real budget.
- Re-learn gas. Storage cheap / compute expensive on zkSync; L1 data fee dominant on Scroll. Do not reuse gas heuristics.
- Test on a local node.
anvil-zksync(zkSync) or plain Foundry (Scroll) — cheap before you touch testnet. - Check finality expectations. Hours, not seconds, for L1 finality; communicate that to your product team.
- Verify the chain is alive. Roadmap, TVL trend, prover decentralization status — the Polygon zkEVM sunset is the proof that this matters.
Frequently asked questions
As a zk evm developer, do I need to learn how to write circuits?
No. Circuit construction is handled by the rollup's prover team, not by application developers. Your job is unchanged: write Solidity, compile it, test it. On Type 4 chains the compiler changes, but you never write a constraint or a witness yourself.Does my contract need changes on every zkEVM?
Only on Type 3 and Type 4 chains, and even there usually only edge cases: inline assembly, unusual precompiles, gas-sensitive branching, andCREATE2 address assumptions. Type 1 and Type 2 chains run your bytecode as-is. The rule of thumb: if it deploys on L1 and the chain is Type 2, it deploys unchanged; if the chain is Type 4, budget for re-testing and possibly re-auditing.
What is the cheapest and most compatible zkevm tool to start with?
For the least-change path, Scroll: standard solc, standard Hardhat/Foundry, unchanged addresses and audits. For the lowest fees and native account abstraction, zkSync Era with@matterlabs/hardhat-zksync or foundry-zksync — or its EVM Bytecode Interpreter if you want standard tools first and are willing to pay higher gas. Start on a local node (anvil-zksync), then testnet, then mainnet.
Should I still avoid Polygon zkEVM?
The Mainnet Beta sequencer was sunset in July 2026; the chain is not producing blocks and there is no migration path. Do not start new builds on it. The underlying zkEVM technology continues in Polygon's CDK framework, so "ZK on Polygon" survives — but as a rollup you choose yourself, not as the old mainnet.How does finality on a zkEVM compare with optimistic rollups?
A zkEVM posts validity proofs to L1, so withdrawals finalize in hours (20–60 minutes for the proof + data to settle, depending on chain and congestion). Optimistic rollups need the 7-day fraud-proof window. The practical difference: zkEVM bridges feel near-instant, and you can rely on the proof as a guarantee rather than a game-theoretic threat.Conclusion
Linh's Friday deploy script survived mostly intact — but only because she first answered the question every zk evm developer must answer: which bytecode will actually run? On Type 1 and Type 2 chains (Taiko, Scroll, Linea) solc is still your compiler, your audits transfer, and the migration is an RPC. On Type 4 (zkSync Era) zksolc takes over, the zkevm tools multiply, and gas, addresses, and account abstraction all follow the new bytecode — unless you choose the EVM Bytecode Interpreter and pay the fee premium instead. The honest tradeoff, the one the marketing pages hide: bytecode equivalence costs fees and prover efficiency; custom VMs cost developer time and re-audits. And above both sits the risk the Polygon zkEVM sunset made concrete — the chain itself can disappear. Choose your compiler for today, choose your chain for three years, and test everything on a local node before you spend a single testnet dollar.
Quick Reference
| Property | EVM-equivalent (Scroll / Linea / Taiko) | Solidity-equivalent (zkSync Era) |
|---|---|---|
| Compiler | Standard solc | zksolc (LLVM pipeline) + era-solidity fork |
| Bytecode | Same EVM bytecode as L1 | Custom EraVM bytecode |
| Deploy tooling | Hardhat / Foundry unchanged | hardhat-zksync plugins or foundry-zksync |
| Addresses (CREATE2) | Same as L1 | Bytecode-hash derived, differs from L1 |
| Gas model | L2 execution + L1 data fee | Storage cheap, computation expensive |
| Precompiles | Mostly full; a few stubbed | ecrecover OK; ripemd160/send-transfer suppressed |
| Audit transfer | Direct from L1 ($20–50K saved) | Re-validation required |
| Account abstraction | ERC-4337 + bundlers | Native at protocol level |
| EVM bytecode path | Native (no interpreter needed) | EVM Bytecode Interpreter (higher gas) |
| Proof system | Halo2/OpenVM (Scroll), gnark (Linea) | Boojum STARK / Airbender |
| L1 finality | ~30–60 min (Scroll) | ~20–45 min |
| Typical swap fee | $0.05–0.18 (Scroll) | $0.01–0.06 |
| Best fit | DeFi, audit-heavy protocols | Consumer apps, GameFi, AA UX |
| Lifecycle risk | Scroll (2023–), Taiko (Type 1) | zkSync (2023–); Polygon zkEVM sunset 2026 |