API Reference
Alchemy Login

What is the difference between Polygon zkEVM and Ethereum?

Learn about the differences between Polygon zkEVM and Ethereum

This document provides a comprehensive list of differences between the Ethereum and Polygon zkEVM. The list includes supported EIPs, opcodes, JSON-RPC differences and additional changes made to build the zkEVM.

JSON RPC Method Differences

The following JSON RPC methods have differences in zkEVM as compared to EVM. The methods and their differences in zkEVM are as follows:

  • eth_call → doesn't support state override at the moment and pending block, this will be implemented in the issue 1990 and doesn't support from values that are smart contract addresses, this will be implemented in the issue 2017
  • eth_estimateGas → if the block number is set to pending it is assumed to be latest
  • eth_getBalance → if the block number is set to pending it is assumed to be latest
  • eth_getCode → if the block number is set to pending it is assumed to be latest
  • eth_getStorageAt → if the block number is set to pending it is assumed to be latest
  • eth_getTransactionByBlockNumberAndIndex → if the block number is set to pending it is assumed to be latest
  • eth_sendRawTransaction → can relay TXs to another node

Additional zkEVM_* methods

The zkEVM includes additional JSON-RPC methods which are listed below:

Opcodes

This section lists out the changes with Opcodes in zKEVM as compared to the EVM.

  • SELFDESTRUCT → removed and replaced by SENDALL.
  • EXTCODEHASH → returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
  • DIFFICULTY → returns "0" instead of a random number as in the EVM.
  • BLOCKCHASH → returns all previous block hashes instead of just the last 256 blocks.

BLOCKCHASH is the state root at the end of a processable transaction and is stored on the system smart contract.

  • NUMBER → returns the number of processable transactions.

Precompiled Contracts

The following precompiled contracts are supported in the zkEVM:

Other precompiled contracts have no effect on the zkEVM state tree and are treated as a revert, returning all gas to the previous context and setting the success flag to "0".

Additions

zk-counters → batch resources are available, linked to state-machine components, as a supplementary addition to gas computation.

Other Minor Differences

  • zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
  • JUMPDEST opcode is allowed in push bytes to avoid runtime bytecode analysis.
  • The zkEVM implements EIP-3541 from the London hardfork.
  • EIP-2718 which defines Typed Transaction Envelope, is not supported.
  • EIP-2930, which defines the Optional Access Lists transaction type, is not supported.

To start deploying on the zkEVM, check out the Polygon zkEVM Quickstart Guide.

ReadMe