The CLARITY Act Isn't a Bank vs. Crypto Fight. It's a Test of America's Ambition
The CLARITY Act isn't banks vs. crypto — it's about whether the U.S. builds digital financial infrastructure that works for everyone, including community banks.
ZKsync Blog > EVM Bytecode Compatibility Is ...
Published Apr 2, 2025
EVM Bytecode Compatibility Is Now Live on ZKsync Era
ZKsync has achieved EVM equivalence with EVM Interpreter:
- Developers can run unmodified EVM bytecode.
- This means tools like Foundry and Hardhat just work out of the box.
EVM bytecode interpreter features:
- Deploy Solidity & Vyper contracts without recompilation — just like on Ethereum.
- Works with Foundry, Hardhat, and Remix natively, no plugins needed.
- Same address derivation (create, create2) as Ethereum.
- Pre-deployed contracts (Create2 Proxy, Safe Factory, Multicall3…) for seamless onboarding.
- Some limitations remain (e.g., higher gas costs than native EraVM, no delegatecall between EVM and EraVM).
Enabling EVM Bytecode Compatibility on ZKsync Era
When Matter Labs started working on ZKsync Era, achieving full EVM compatibility in a general-purpose ZK rollup was widely viewed as a major technical challenge. There were no existing general-purpose ZK virtual machines or open-source circuits for proving Ethereum opcodes. The team had to build everything from scratch, making trade-offs to bring ZKsync to production.
One of those trade-offs was not implementing a Type 2 ZK-EVM (which fully matches EVM bytecode) but instead designing a ZK-optimized and stable virtual machine: EraVM. This allowed ZKsync to launch much sooner, but it introduced differences from the EVM that affected developer experience and tooling compatibility.
Over the past two years, the team has made significant improvements to developer experience, refining tooling and addressing key pain points. However, despite these efforts, some teams were still unable to deploy their projects due to incompatibilities with EraVM, while others simply required full EVM equivalence to maintain consistency with their existing codebase. The demand for a solution that allows unmodified EVM bytecode to run seamlessly on ZKsync was clear and today we’re addressing that.
The Path Forward
While EVM Equivalence is here today, we want to make it even better in the future:
- EVM Interpreter (Today): The first step is an EVM Interpreter that runs on top of EraVM and allows EVM bytecode execution. This enables EVM tools like Foundry and Hardhat to work out of the box on ZK chains like Era, without requiring plugins or extensions.
- Native EVM Execution (Coming Soon): The next step will come with Boojum 2.0, a new proving system and VM that will enable native EVM execution. We shared some technical details during ETH Denver with more to come in the following weeks. For an overview, refer to this post from Anthony Rose in the ZK Nation forum.
The EVM Interpreter, included in protocol upgrade v27, is a significant milestone, adding EVM equivalence to ZKsync Sepolia testnet, and soon to all ZK Chains.
What Developers Can Expect
With the introduction of the EVM Bytecode Interpreter, developers can now deploy and execute unmodified EVM bytecode, eliminating the need for custom compilers or modified tooling.
- The interpreter targets the Cancun EVM version, which was activated on Ethereum mainnet in March 2024.
- Developers can deploy EVM bytecode contracts without recompilation, using standard Solidity and Vyper compilers. Foundry, Hardhat, and Remix work out of the box without requiring special plugins or modifications.
- Address derivation follows Ethereum’s behavior, meaning contracts deployed using
createand create2generate the same addresses as they would on Ethereum. - EVM bytecode contracts and EraVM contracts can interact normally, except for
delegatecall, which is not supported across environments.
To further improve compatibility, the interpreter includes pre-deployed contracts for common use cases:
- Create2 proxy (Arachnid) –
0x4e59b44847b379578588920cA78FbF26c0B4956C - Create2 deployer (pcaversaccio) -
0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2 - ERC2470 singleton factory –
0xce0042B868300000d44A59004Da54A005ffdcf9f - Safe Singleton Factory –
0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7 - Multicall3 (mds1) –
0xcA11bde05977b3631167028862bE2a173976CA11 - Create2 proxy (Zoltu) -
0x7A0D94F55792C434d74a40883C6ed8545E406D12
How It Works
ZKsync’s EVM Interpreter allows developers to deploy and run unmodified EVM bytecode on top of EraVM. Instead of requiring contracts to be compiled into EraVM-specific bytecode, the interpreter interprets EVM opcodes at runtime, making it possible to use standard Ethereum tooling without modifications.
At a high level, here’s how it works:
- EraVM remains the core execution environment. The EVM Interpreter does not replace EraVM but runs as a translation layer inside it. This means both native EraVM contracts and EVM bytecode contracts can coexist.
- EVM contracts are flagged and routed through the interpreter. When an EVM contract is deployed, it is tagged with a special identifier. Instead of executing native bytecode, the EVM Interpreter is invoked to process its logic.
- Opcodes are interpreted in real-time. The interpreter translates EVM instructions into EraVM operations as they execute, ensuring compatibility with Ethereum’s behavior.
- EraVM gas (ergs) is used, not EVM gas. Gas fees are paid in ergs (EraVM gas units), and while the costs may differ from Ethereum’s pricing model, transactions remain significantly cheaper than on Layer 1.
For more details, read the EVM Emulator documentation.
EVM Emulation vs. Native EraVM Execution
While the EVM Interpreter makes it easy to bring existing Ethereum contracts to ZKsync, EraVM-native bytecode remains the best choice for most projects due to its better performance and lower gas costs.
We recommend:
- Use native EraVM bytecode whenever possible for optimal efficiency.
- Use the EVM Emulator only if you need features like exact
create2address derivation or other EVM-specific behaviors.
Limitations & Unsupported Features
While the EVM Interpreter significantly improves developer experience, there are still some limitations due to the underlying EraVM architecture:
- Gas Behavior: EVM bytecode is translated at execution time, making transaction fees higher than running native EraVM bytecode.
- Debugging Limitations: Some EVM debugging tools and RPC methods are unavailable due to differences between EVM and EraVM execution.
- Opcodes and precompiles:
CALLCODE, SELFDESTRUCT, BLOBHASH, BLOBBASEFEEand modexp, blake2f, pointEvaluationare not supported as they’re not implemented in EraVM yet. - No Access Lists (EIP-2930): The interpreter does not support access lists for optimizing gas costs.
- Different Warm/Cold Storage Mechanics: Only contracts accessed within the EVM environment are considered warm.
delegatecallBetween EVM and EraVM Contracts is Not Supported.
Learn more in the EVM Emulator documentation.
What’s Next & Getting Started
The EVM Interpreter is live on the ZKsync Era Sepolia testnet with mainnet activation planned in the weeks ahead, pending governance approval. The feature is available across the Elastic Network, meaning other ZK chains running v27 can enable the interpreter at any time.
The next version of the proof system, Boojum2.0, will allow native EVM execution, significantly reducing the costs of EVM equivalence.
We encourage developers to test the EVM Interpreter and share their feedback on our developer forum. Deploying an EVM contract on ZKsync Era is now as straightforward as deploying on Ethereum — no special compilers or modifications are required.
Resources
Share the article
More from ZKsyncView all
Why and How We're Sunsetting ZKsync Lite
ZKsync Lite sunsets on May 4, 2026. Block production stops, but your funds are safe — withdraw via L1 claim contract. First 100K withdrawals sponsored.
The Wire That Couldn't Be Recalled
April 18's $290M loss at Kelp DAO came with a remarkable statement: the protocol worked exactly as designed. That sentence is the entire argument banks need to understand before choosing tokenized infrastructure — because some systems sold as blockchains are, underneath, just wires. And wires fail open.