From 03ec55a494ca329914b39f9fc1dc94fc90bf4a97 Mon Sep 17 00:00:00 2001 From: Vladislav Volosnikov Date: Mon, 9 Dec 2024 08:44:19 +0100 Subject: [PATCH] fix: Add section about EXTCODEHASH in differences from L1 (#283) # Description Our `EXTCODEHASH` deviates from EVM specification. ## Linked Issues CPR-1186 ## Additional context --- .../70.differences/10.evm-instructions.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content/20.zksync-protocol/70.differences/10.evm-instructions.md b/content/20.zksync-protocol/70.differences/10.evm-instructions.md index cd49a639..5ccd7195 100644 --- a/content/20.zksync-protocol/70.differences/10.evm-instructions.md +++ b/content/20.zksync-protocol/70.differences/10.evm-instructions.md @@ -263,6 +263,18 @@ Contract bytecode cannot be accessed on zkEVM architecture. Only its size is acc `EXTCODECOPY` always produces a compile-time error with the zkEVM compiler. +## `EXTCODEHASH` + +Retrieving the code hash of a smart contract in the zkEVM protocol differs slightly from EVM. In EVM hash of non-existing account +is always `0`, and hash of existing account without code is `keccak("")`. Nonexisting contracts have no code, and their nonce and +balance are both zero. + +In zkEVM `EXTCODEHASH` operation has the following differences: + +- It doesn't check the balance of account. +- All contracts in precompiles space (plus `0x00`) are treated as existing empty accounts. +- For zkEVM contracts with bytecode it returns a versioned code hash based on sha3, rather than the keccak256 of the bytecode specified in EIP-1052. + ## `DATASIZE`, `DATAOFFSET`, `DATACOPY` Contract deployment is handled by two parts of the zkEVM protocol: the compiler front end and the system contract called `ContractDeployer`.