Skip to main content

Difference between Morph and Ethereum

There are several technical differences between Ethereum’s EVM and Morph's optimistic zkEVM.

We’ve compiled a list to help you understand these distinctions better.


For most Solidity developers, these technical details won't significantly impact your development experience.

EVM Opcodes

OpcodeSolidity equivalentMorph Behavior
BLOCKHASHblock.blockhashReturns keccak(chain_id || block_number) for the last 256 blocks.
COINBASEblock.coinbaseReturns the pre-deployed fee vault contract address. See Contracts.
DIFFICULTY / PREVRANDAOblock.difficultyReturns 0.
BASEFEEblock.basefeeDisabled. If the opcode is encountered, the transaction will be reverted.
SELFDESTRUCTselfdestructDisabled. If the opcode is encountered, the transaction will be reverted.

EVM Precompiles

The SHA2-256 (address 0x2), RIPEMD-160 (address 0x3), and blake2f (address 0x9) precompiles are currently not supported. Calls to these contracts will be reverted. We plan to enable these three precompiles in a future hard fork.

The modexp precompile is supported, but only for inputs up to 32 bytes (i.e. u256).

The ecPairing precompile is supported but limits the number of points(sets, pairs) to 4, instead of 6.

Other EVM precompiles like ecRecover, identity, ecAdd, and ecMul are fully supported.

State Account

Additional Fields

We have introduced two additional fields in the StateAccount object: PoseidonCodehash and CodeSize.

type StateAccount struct {
Nonce uint64
Balance *big.Int
Root common.Hash // merkle root of the storage trie
KeccakCodeHash []byte // still the Keccak codehash
// added fields
PoseidonCodeHash []byte // the Poseidon codehash
CodeSize uint64


  • There are two types of codehash for each contract bytecode: KeccakCodeHashand PoseidonCodeHash.

  • KeccakCodeHash is kept to maintain compatibility for EXTCODEHASH.

  • PoseidonCodeHash is used for verifying the correctness of bytecodes loaded in the zkEVM, where Poseidon hashing is far more efficient.


When verifying EXTCODESIZE, loading the entire contract data into the zkEVM is costly. Instead, we store the contract size in storage at contract creation. This approach avoids the need to load the code, as storage proof is sufficient to verify this opcode.

Block Time

Block Time Subject to Change

Blocks are produced every second, with an empty block generated if there are no transactions for 5 seconds. However, this frequency may change in the future.

To compare, Ethereum has a block time of ~12 seconds.

Reasons for Faster Block Time in Morph User Experience:

  • A faster, consistent block time provides quicker feedback, enhancing the user experience.

  • Optimization: As we refine the zkEVM circuits in our testnets, we can achieve higher throughput than Ethereum, even with a smaller gas limit per block or batch.


  • TIMESTAMP will return the timestamp of the block. It will update every second.
  • BLOCKNUMBER will return an actual block number. It will update every second. The one-to-one mapping between blocks and transactions will no longer apply.

Future EIPs

Morph closely monitors emerging Ethereum Improvement Proposals (EIPs) and adopts them when suitable. For more specifics, join our community forum or Discord for discussions.

Transaction Fees