Ethereum & Scroll Differences

A number of technical details differ between Ethereum mainnet’s EVM and Scroll’s modified design for a zkEVM. Below you can see those differences as they exist on Scroll and Scroll Sepolia.

For open-source contributors and infrastructure builders, please contact our team for additional support.

EVM Opcodes

We support the cancun EVM target and the latest Solidity version 0.8.26.

EVM Precompiles

The RIPEMD-160 (address 0x3) blake2f (address 0x9), and point evaluation (address 0x0a) precompiles are currently not supported. Calls to unsupported precompiled contracts will revert. We plan to enable these precompiles in future hard forks.

The modexp precompile is supported but only supports inputs of size less than or equal to 32 bytes (i.e. u256).

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

The other EVM precompiles are all supported: ecRecover, identity, ecAdd, ecMul.

Precompile Limits

Because of a bounded size of the zkEVM circuits, there is an upper limit on the number of calls that can be made for some precompiles. These transactions will not revert, but simply be skipped by the sequencer if they cannot fit into the space of the circuit. Read more about the Circuit Capacity Checker.

State Account

Additional Fields

We added two fields in the current 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
}

CodeHash

Related to this, we maintain two types of codehash for each contract bytecode: Keccak hash and Poseidon hash.

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.

CodeSize

When verifying EXTCODESIZE, it is expensive to load the whole contract data into the zkEVM. Instead, we store the contract size in storage during contract creation. This way, we do not need to load the code — a storage proof is sufficient to verify this opcode.

Block Time

To improve the throughput of the Scroll chain, we introduced a dynamic block time in our Curie upgrade. During the congestion period, a block will be sealed once the transactions in the block reach the circuit limit instead of waiting for the 3-second interval. During normal hours, blocks will still be sealed at 3-second interval to ensure a consistent user experience.

Transaction Ordering

Similarly to Ethereum, the Scroll sequencer aims to prioritize executable transactions based on their “tip” (priority fee). In most cases, transactions will be included in the next block in decreasing order of their tips.

However, just like in Ethereum, this ordering is not guaranteed by the protocol, and some blocks might diverge from it. In particular, during periods of low mempool congestion, the sequencer will process transactions on a first-come-first-served basis, so some transactions might precede others with higher tip in the same block.

Reorgs and Finality

Starting from our DarwinV2 upgrade, the maximum reorg depth has been set to 17 blocks. Transaction ordering should be unchanged after this threshold, however the only absolute guarantee is for transactions to be finalized (proof submitted to L1).

Future EIPs

We keep a close eye on all emerging EIPs adopted by Ethereum and adopt them when suitable. If you’re interested in more specifics, reach out in our community forum or on the Scroll Discord.

Transaction Fees

The fee charged to Scroll transactions contains two parts:

• L2 gas fee: similar to L1, the amount of L2 execution fee equals to L2_gas_price * L2_gas_used, covering the following costs:
  • L2 sequencer execution & storage cost
  • Validity proof verification and finalization cost on L1
  • Prover cost
• L1 data fee: additional fee on top of L2 gas fee. The L1 data fee is only charged to L2-initiated transactions, not to L1-initiated transactions. The fee covers the cost of sending data to L1 for data availability. Because we roll up the tx data to L1, the L1 rollup fee is calculated based on the size of tx data.

For more information, see Transaction Fees on Scroll.