This page outlines what opcodes differ in behavior between Abstract and Ethereum.

It is a fork of the ZKsync EVM Instructions page.

​

CREATE & CREATE2

Deploying smart contracts on Abstract is different than Ethereum (see contract deployment). To guarantee that create & create2 functions operate correctly, the compiler must be aware of the bytecode of the deployed contract in advance.

// Works as expected ✅
MyContract a = new MyContract();
MyContract a = new MyContract{salt: ...}();

// Works as expected ✅
bytes memory bytecode = type(MyContract).creationCode;
assembly {
    addr := create2(0, add(bytecode, 32), mload(bytecode), salt)
}

// Will not work because the compiler is not aware of the bytecode beforehand ❌
function myFactory(bytes memory bytecode) public {
   assembly {
      addr := create(0, add(bytecode, 0x20), mload(bytecode))
   }
}

For this reason:

• We strongly recommend including tests for any factory that deploys contracts using type(T).creationCode.
• Using type(T).runtimeCode will always produce a compile-time error.

​

Address Derivation

The addresses of smart contracts deployed using create and create2 will be different on Abstract than Ethereum as they use different bytecode. This means the same bytecode deployed on Ethereum will have a different contract address on Abstract.

​

CALL, STATICCALL, DELEGATECALL

For calls, you specify a memory slice to write the return data to, e.g. out and outsize arguments for call(g, a, v, in, insize, out, outsize). In EVM, if outsize != 0, the allocated memory will grow to out + outsize (rounded up to the words) regardless of the returndatasize. On Abstract, returndatacopy, similar to calldatacopy, is implemented as a cycle iterating over return data with a few additional checks and triggering a panic if out + outsize > returndatasize to simulate the same behavior as in EVM.

Thus, unlike EVM where memory growth occurs before the call itself, on Abstract, the necessary copying of return data happens only after the call has ended, leading to a difference in msize() and sometimes Abstract not panicking where EVM would panic due to the difference in memory growth.

success := call(gas(), target, 0, in, insize, out, outsize) // grows to 'min(returndatasize(), out + outsize)'

success := call(gas(), target, 0, in, insize, out, 0) // memory untouched
returndatacopy(out, 0, returndatasize()) // grows to 'out + returndatasize()'

Additionally, there is no native support for passing Ether on Abstract, so it is handled by a special system contract called MsgValueSimulator. The simulator receives the callee address and Ether amount, performs all necessary balance changes, and then calls the callee.

​

MSTORE, MLOAD

Unlike EVM, where the memory growth is in words, on zkEVM the memory growth is counted in bytes. For example, if you write mstore(100, 0) the msize on zkEVM will be 132, but on the EVM it will be 160. Note, that also unlike EVM which has quadratic growth for memory payments, on zkEVM the fees are charged linearly at a rate of 1 erg per byte.

The other thing is that our compiler can sometimes optimize unused memory reads/writes. This can lead to different msize compared to Ethereum since fewer bytes have been allocated, leading to cases where EVM panics, but zkEVM will not due to the difference in memory growth.

​

CALLDATALOAD, CALLDATACOPY

If the offset for calldataload(offset) is greater than 2^32-33 then execution will panic.

Internally on zkEVM, calldatacopy(to, offset, len) there is just a loop with the calldataload and mstore on each iteration. That means that the code will panic if 2^32-32 + offset % 32 < offset + len.

​

RETURN, STOP

Constructors return the array of immutable values. If you use RETURN or STOP in an assembly block in the constructor on Abstract, it will leave the immutable variables uninitialized.

contract Example {
    uint immutable x;

    constructor() {
        x = 45;

        assembly {
            // The statements below are overridden by the zkEVM compiler to return
            // the array of immutables.

            // The statement below leaves the variable x uninitialized.
            // return(0, 32)

            // The statement below leaves the variable x uninitialized.
            // stop()
        }
    }

    function getData() external pure returns (string memory) {
        assembly {
            return(0, 32) // works as expected
        }
    }
}

​

TIMESTAMP, NUMBER

For more information about blocks on Abstract, including the differences between block.timestamp and block.number, check out the blocks on ZKsync Documentation.

​

COINBASE

Returns the address of the Bootloader contract, which is 0x8001 on Abstract.

​

DIFFICULTY, PREVRANDAO

Returns a constant value of 2500000000000000 on Abstract.

​

BASEFEE

This is not a constant on Abstract and is instead defined by the fee model. Most of the time it is 0.25 gwei, but under very high L1 gas prices it may rise.

​

SELFDESTRUCT

Considered harmful and deprecated in EIP-6049.

Always produces a compile-time error with the zkEVM compiler.

​

CALLCODE

Deprecated in EIP-2488 in favor of DELEGATECALL.

Always produces a compile-time error with the zkEVM compiler.

​

PC

Inaccessible in Yul and Solidity >=0.7.0, but accessible in Solidity 0.6.

Always produces a compile-time error with the zkEVM compiler.

​

CODESIZE

Yul uses a special instruction datasize to distinguish the contract code and constructor arguments, so we substitute datasize with 0 and codesize with calldatasize in Abstract deployment code. This way when Yul calculates the calldata size as sub(codesize, datasize), the result is the size of the constructor arguments.

contract Example {
    uint256 public deployTimeCodeSize;
    uint256 public runTimeCodeSize;

    constructor() {
        assembly {
            deployTimeCodeSize := codesize() // return the size of the constructor arguments
        }
    }

    function getRunTimeCodeSize() external {
        assembly {
            runTimeCodeSize := codesize() // works as expected
        }
    }
}

​

CODECOPY

contract Example {
    constructor() {
        assembly {
            codecopy(0, 0, 32) // behaves as CALLDATACOPY
        }
    }

    function getRunTimeCodeSegment() external {
        assembly {
            // Behaves as 'memzero' if the compiler is run with the old (EVM assembly) codegen,
            // since it is how solc performs this operation there. On the new (Yul) codegen
            // `CALLDATACOPY(dest, calldatasize(), 32)` would be generated by solc instead, and
            // `CODECOPY` is safe to prohibit in runtime code.
            // Produces a compile-time error on the new codegen, as it is not required anywhere else,
            // so it is safe to assume that the user wants to read the contract bytecode which is not
            // available on zkEVM.
            codecopy(0, 0, 32)
        }
    }
}

​

EXTCODECOPY

Contract bytecode cannot be accessed on zkEVM architecture. Only its size is accessible with both CODESIZE and EXTCODESIZE.

EXTCODECOPY always produces a compile-time error with the zkEVM compiler.

​

DATASIZE, DATAOFFSET, DATACOPY

Contract deployment is handled by two parts of the zkEVM protocol: the compiler front end and the system contract called ContractDeployer.

On the compiler front-end the code of the deployed contract is substituted with its hash. The hash is returned by the dataoffset Yul instruction or the PUSH [$] EVM legacy assembly instruction. The hash is then passed to the datacopy Yul instruction or the CODECOPY EVM legacy instruction, which writes the hash to the correct position of the calldata of the call to ContractDeployer.

The deployer calldata consists of several elements:

The data can be logically split into header (first 132 bytes) and constructor calldata (the rest).

The header replaces the contract code in the EVM pipeline, whereas the constructor calldata remains unchanged. For this reason, datasize and PUSH [$] return the header size (132), and the space for constructor arguments is allocated by solc on top of it.

Finally, the CREATE or CREATE2 instructions pass 132+N bytes to the ContractDeployer contract, which makes all the necessary changes to the state and returns the contract address or zero if there has been an error.

If some Ether is passed, the call to the ContractDeployer also goes through the MsgValueSimulator just like ordinary calls.

We do not recommend using CREATE for anything other than creating contracts with the new operator. However, a lot of contracts create contracts in assembly blocks instead, so authors must ensure that the behavior is compatible with the logic described above.

​

SETIMMUTABLE, LOADIMMUTABLE

zkEVM does not provide any access to the contract bytecode, so the behavior of immutable values is simulated with the system contracts.

1. The deploy code, also known as the constructor, assembles the array of immutables in the auxiliary heap. Each array element consists of an index and a value. Indexes are allocated sequentially by zksolc for each string literal identifier allocated by solc.
2. The constructor returns the array as the return data to the contract deployer.
3. The array is passed to a special system contract called ImmutableSimulator, where it is stored in a mapping with the contract address as the key.
4. In order to access immutables from the runtime code, contracts call the ImmutableSimulator to fetch a value using the address and value index. In the deploy code, immutable values are read from the auxiliary heap, where they are still available.

The element of the array of immutable values:

struct Immutable {
    uint256 index;
  uint256 value;
}