[ZIP-9] V27 EVM Emulation Upgrade

Protocol Development Draft ZIPs
1
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. The key features of V27 are:

  • The EVM emulation, enabling the direct deployment and execution of EVM contracts on ZKsync without recompilation;
  • Fflonk verifier, optimizations and security improvements.

Motivation

The pursuit of full EVM equivalence at the bytecode level is a cornerstone of ZKsync’s technical vision, as outlined in the 2025 roadmap. This initiative is fundamental to ensuring that ZKsync can seamlessly support all tools and frameworks designed for Ethereum Layer 1, thus significantly enhancing the developer experience.

The primary motivation for the V27 upgrade is to integrate Ethereum-compatible smart contract development into ZKsync EraVM. By implementing an EVM emulator, ZKsync can offer developers the ability to use standard Solidity and Vyper compilers, as well as popular tooling such as Foundry, Hardhat, and Remix without modifications. This initiative supports the broader goal of making ZKsync a fully interoperable and user-friendly platform that maintains high performance and security standards of the underlying EraVM.

Another key aspect of the upgrade is support for verifying Fflonk proofs, which will significantly reduce the cost of on-chain proof verification on Ethereum. This is an important part of the overall initiative to minimize transaction costs on ZKsync.

Specification

The V27 upgrade contracts can be found in the Era Contracts Github repo. Details of the V27 upgrade are listed below:

EVM emulation

This release adds an optional EVM emulation mode, allowing chains to deploy and execute EVM contracts without recompiling for EraVM. This is an important step towards full EVM equivalence, which will open up new possibilities for developers and various Web3 protocols. EVM emulation provides following features:

  • Standard Compiler Support: Allows the use of unmodified EVM compilers for Solidity, Vyper and other languages.
  • Tooling Compatibility: Supports existing Ethereum development environments and build tools without the need for plugins or adaptations.
  • Consistent Address Derivation: Opens the way to deploy contracts using create and create2 consistently with Ethereum address derivation scheme.
  • Emulated EVM equivalence: For EVM contracts, the environment is compatible with EVM. This includes support for most opcodes and precompiles, as well as emulated EVM-equivalent gas cost of operations. More details on equivalence are provided in documentation page.
  • Pre-Deployed EVM Contracts: Includes essential contracts such as create2 factories, multicall3, and singletonFactory (ERC2470) to facilitate common contract interactions.

For developer resources on the EVM emulator, please visit documentation: EVM emulator overview (WIP).

New system contracts:

  • EvmEmulator: EraVM invokes this contract every time a call to the computer contract happens. EvmEmulator loads the EVM contract’s bytecode and executes it in the runtime.
  • EvmGasManager: Technical system contract used to emulate EVM storage gas behavior including warm/cold accesses mechanics.
  • EvmHashesStorage: Separate system contract that stores EVM code hashes (keccak256 hash of EVM bytecode).
  • EvmPredeploysManager: Contract used to deploy important ecosystem EVM contracts like Create2 factories.

New precompiles to enhance EVM compatibility:

  • Identity (0x04): Just returns the input data.

The EVM emulation feature also requires the following changes:

  • VM and circuits:
    • Remove additional EVM emulation gas stipend. This stipend was implemented in the past as part of preparations for the EVM emulation, but in the final implementation it is not needed: the caller pays for the emulation in full.
    • Increase memory stipend for EVM emulation frames. EVM emulator uses memory to store stack and bytecode. The initial free heap size has been adjusted to account for this.
  • L1 ecosystem contracts
    • EVM emulator hash is added to batch meta params (similar to DefaultAccount bytecode hash).
    • Admin facet: added function allowEvmEmulation() to enable EVM emulator on the chain.
    • Mailbox facet: added special service L1→L2 transaction functionality, which is necessary for the mechanism of enabling EVM emulator on the chain.
  • System contracts
    • Bootloader and DefaultAccount: support deployment of EVM contracts by EOAs (with tx without field to).
    • ContractDeployer: Add functionality to deploy EVM contracts using create, create2 and forced deployments. This functionality is available if the chain has the EVM emulation feature enabled.
    • KnownCodesStorage: Add functionality to publish EVM bytecodes.
    • AccountCodeStorage: Add EVM-specific functionality.

Along with the EVM emulator, we provide a set of contracts that can be deployed to pre-defined addresses. This list includes important frequently used contracts that are typically deployed using keyless transactions:

Detailed overview of EVM emulation can be read in the contracts repo: era-contracts/docs/evm_emulation at release-v27 · matter-labs/era-contracts · GitHub

EVM gas model emulation explainer: EVM gas emulation overview

Fflonk verifier

The other feature of the V27 release is optional proof verification with Fflonk (previously, only the Plonk protocol was used). The new verifier contract implementation can accept both Plonk and Fflonk proofs, providing flexibility during the transition period. An important reason for this change is that on-chain verification of Fflonk proofs is approximately 30% cheaper than verification of Plonk proofs, while consuming roughly the same (or even fewer) resources to generate the proof.

New flexible dual verifier implementation: DualVerifier.sol
New Fflonk verifier implementation: L1VerifierFflonk.sol

Additional changes

The V27 update includes several optimizations, improvements, and fixes for EraVM and circuits that enhance the security and performance of the protocol. Improvements also affect Boojum’s gadgets and internal functions. For detailed info please read corresponding audit reports:

  • EraVM changes and fixes audit: [TBC]
  • EraVM changes and fixes audit #2: [TBC]

Several minor changes and fixes in the contracts are listed in the changelog: V27 changelog

Rationale

EVM emulation

The EVM emulator is designed as a translation layer that does not replace but enhances the EraVM execution environment. This approach allows ZKsync to leverage the robust security and performance of EraVM while extending compatibility with the broader Ethereum ecosystem. More specifically, the emulation of the EVM environment on top of EraVM minimizes the number of changes required in critical and battle-tested parts of the system, such as circuits, thereby significantly enhancing the security of new functionality for the ecosystem. As a result, the implementation of the emulator in the Yul language simplifies its development, testing and auditing, which in turn will make further updates and improvements a lot easier.

An important drawback of this approach is the increased cost of EVM contract execution compared to native EraVM contracts, due to the need to emulate the EVM environment. It is also important to note that the emulation cannot provide 100% equivalence with EVM; detailed information can be found in the list of differences: differences from EVM (Cancun). Despite the described shortcomings, emulation will open the way for a large number of use cases. A fully EVM-equivalent native execution environment is a key part of the 2025 roadmap.

Implementation & Backwards Compatibility

EVM emulation

The EVM emulator will be integrated into the ZKsync Era protocol as a system contract that intercepts and translates EVM bytecode to EraVM instructions dynamically. This system ensures that all Ethereum-compatible contracts can be executed without altering their original code.

This feature does not affect already deployed EraVM contracts. EVM emulation is an optional feature which can be enabled separately for each ZK Chain by the corresponding chain admin.

To test compatibility with EVM, a widely used canonical set of state tests was used: ethereum/tests. Corresponding test runner infrastructure for the emulator: era-evm-tester.

Fflonk verifier

To simplify upgrades and improve fault tolerance, the new Fflonk verifier will be added as an optional, second option for proving. This approach improves backward compatibility, but still requires changing the input data layout for zk-SNARK verification to distinguish between the two types of proofs. This should be taken into account when submitting proofs to the verifier. More detailed info: DualVerifier contract.

Security Considerations

The introduction of an EVM emulator involves complex interactions between different virtual machine instructions sets and system contracts. The verifier is an absolutely critical part of the protocol, on which the correctness and verifiability of the ecosystem depends.

Rigorous security audits and testing have been completed to ensure that proposed changes do not introduce vulnerabilities. Audit reports:

4 Likes
2

Small update about timelines: deployment to testnet expected on Tuesday (April 1).