EVM bytecode deployment and execution

General details about deploying and executing EVM contracts on ZKsync

The EVM Bytecode Interpreter allows developers to deploy and execute unmodified EVM contracts on ZKsync without requiring custom compilers. This section covers the deployment process, execution model, and key differences from standard EVM execution.

For a deeper technical breakdown of how the interpreter works, including memory layout, gas management, and returndata handling, see Technical Architecture of the EVM Interpreter.

Contract Deployment

EVM contracts can be deployed with a transaction without field to (as in Ethereum). In this case data field will be interpreted as init code for the constructor.

Additionally EVM contracts can be deployed from EraVM environment using system call to the following functions in ContractDeployer system contract:

FunctionEquivalent to
createEVMCREATE
create2EVMCREATE2

These methods use the same address derivation schemes as corresponding EVM opcodes.

Address Derivation

  • By Externally Owned Accounts (EOAs): The contract address is derived using the account nonce.
  • By Smart Contract: The contract address is derived using the deployment nonce.

See the NonceHolder system contract documentation for more details about two types of nonces in EraVM.

Deployment from an EVM Contract

EVM contracts cannot call createEVM or create2EVM directly, as they rely on system calls, which are restricted in the EVM environment. EVM opcodes CREATE and CREATE2 should be used instead.

For a breakdown of how the interpreter handles EVM contract deployment internally, refer to Technical Architecture of the EVM Interpreter.

Execution Flow

  1. Versioned Hash Check:
    • The system reads the contract’s versioned hash from AccountCodeStorage.
    • If the contract is an EVM contract (0x02), the EVM Interpreter is invoked.
  2. Bytecode Interpretation:
    • The interpreter loads the contract’s bytecode and executes it using EVM rules.
  3. Gas Handling:
    • A conversion ratio (5:1) is used to translate EraVM ergs limit to EVM gas limit.
    • EVM gas model is interpreted for compatibility. Actual transaction execution is paid in native EraVM gas (ergs). See EVM gas interpretation for details.
    • Since EVM execution requires multiple EraVM instructions per opcode, the effective cost is higher than for native EraVM contracts.

For a detailed explanation of gas conversion, memory layout, and EVM interpretation internals, see Technical Architecture of the EVM Interpreter.

Special Considerations

  • Transactions with a null to address are supported. This allows EOAs to deploy EVM contracts.
  • Failed deployment by a contract increases deployment nonce. This aligns with Ethereum but differs from EraVM, where failed deployments do not affect the nonce.

Next Steps


Made with ❤️ by the ZKsync Community