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).

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.

While EVM Equivalence is here today, we want to make it even better in the future:

1. 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.

2. 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.

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 create and create2 generate 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

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.

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 create2 address derivation or other EVM-specific behaviors.

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, BLOBBASEFEE and modexp, blake2f, pointEvaluation are 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.

• delegatecall Between EVM and EraVM Contracts is Not Supported.

Learn more in the EVM Emulator documentation.

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.

EVM Bytecode Interpreter Docs

https://docs.zksync.io/zksync-protocol/evm-emulator/overview

• [ZIP-9] V27 EVM Emulation Upgrade

[ZIP-9] V27 EVM Emulation Upgrade

Proposal Type ZIP One Sentence Summary ZIP-9 proposes the V27 upgrade for ZKsync with two key features: (1) EVM emulation, and (2) Fflonk verifier. Proposal Author Matter Labs Proposal Sponsor Cyfrin Date Created TBC Version v1 Summary of Action Upgrade ZKsync to V27 Link to Contracts GitHub - matter-labs/era-contracts at release-v27 Abstract ZIP-9 proposes the V27 upgrade for ZKsync.

https://forum.zknation.io