Differences Between the EVM Emulator and Ethereum

While the EVM Emulator is designed to execute EVM bytecode as closely as possible to Ethereum, there are several differences due to the underlying EraVM execution model. These differences affect gas accounting, opcodes support, system behavior, and contract deployment.

This page outlines the key differences between the EVM Emulator on ZKsync and Ethereum (Cancun).

Gas behavior differences

• EVM emulation is executed on top of EraVM and all transactions start in EraVM environment. So gas and gaslimit values signed in the transaction correspond to the native EraVM gas, not EVM gas. For that reason presigned/keyless transactions created for Ethereum may be not compatible with ZK Chains. For detailed info: Gas emulation.
• “Intrinsic gas costs” are different from EVM.
• EVM emulation does not implement the gas refunds logic from EVM. Because users pay for EraVM gas and EVM gas is virtual, EraVM gas refunds logic is used instead of EVM one. It does not affect contracts behavior (refunds happen in the end of transaction).
• EVM gas isn't charged for tx calldata.
• Access lists are not supported (EIP-2930).

Limitations

• DELEGATECALL between EVM and native EraVM contracts will be reverted.
• Calls to empty addresses in kernel space (address < 2^16) will fail.
• GASLIMIT opcode returns the same fixed constant as EraVM and should not be used.

The following opcodes remain unsupported due to underlying limitations of EraVM:

• CALLCODE
• SELFDESTRUCT
• BLOBHASH
• BLOBBASEFEE

Precompiles

Some precompiles like RIPEMD-160 and blake2f are not supported in the EVM emulator as they're not supported in EraVM.

Check the list of available precompiles

Technical differences

• JUMPDEST analysis is simplified. It is not checked that JUMPDEST is not a part of PUSH instruction.
• No force of call stack depth limit. It is implicitly implemented by 63/64 gas rule.
• Account storage is not destroyed during contract deployment.
• If the deployer's nonce is overflowed during contract deployment, all passed gas will be consumed. EVM refunds all passed gas to the caller frame.
• Nonces are limited by size of u128, not u64.
• During creation of EVM contract by EOA or EraVM contract, emulator does not charge additional 2 gas for every 32-byte chunk of initcode as specified in EIP-3860 (since perform JUMPDEST analysis is simplified). This cost is charged if contract is created by another EVM contract (to keep gas equivalence).
• Code deposit cost is charged from constructor frame, not caller frame. It will be changed in the future.
• Only those accounts that are accessed from an EVM environment become warm (including origin, sender, coinbase, precompiles). Anything that happens outside the EVM does not affect the warm/cold status of accounts for EVM.

Next Steps

• Explore the technical architecture of the EVM Emulator for a deeper understanding of its implementation.
• Read about EraVM ↔ EVM contract interactions.
• Check how EVM gas emulation works.
• See the list of Pre-Deployed contracts.