TL;DR: ZKsync is achieving full EVM equivalence in two steps:

1. EVM Emulator (Live today on Era testnet): Runs unmodified EVM bytecode on EraVM.

2. Native EVM Execution (Coming Soon): Full EVM equivalence with Boojum 2.0.

EVM bytecode emulator 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 to Full EVM Equivalence

Our long-term goal has always been full EVM equivalence, and we are achieving it in two steps:

1. EVM Emulator (Today): The first step is an EVM Emulator 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. This upgrade will remove the need for emulation, providing full EVM equivalence. 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 Emulator, included in protocol upgrade v27, is a significant milestone, bridging the gap until full EVM equivalence arrives with Boojum 2.0.

What Developers Can Expect

With the introduction of the EVM Bytecode Emulator, developers can now deploy and execute unmodified EVM bytecode on EraVM, eliminating the need for custom compilers or modified tooling.

• The emulator 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 emulator 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 Emulator 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 emulator 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 Emulator 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 emulator. When an EVM contract is deployed, it is tagged with a special identifier. Instead of executing native bytecode, the EVM Emulator is invoked to process its logic.

• Opcodes are interpreted in real-time. The emulator 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 Emulator 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.

Limitations & Unsupported Features

While the EVM Emulator 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 emulator 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.

What’s Next & Getting Started

The EVM Emulator 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 emulator at any time.

While the emulator brings EVM bytecode compatibility, the long-term goal is full EVM equivalence, which will be achieved with the next-generation proving system later this year. This upgrade will enable native EVM execution, further improving compatibility and efficiency.

We encourage developers to test the EVM Emulator 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

EVM Bytecode Emulator Docs

• [ZIP-9] V27 EVM Emulation Upgrade