fix: Add section about EXTCODEHASH in differences from L1 (#283)

<!--

Thank you for contributing to the ZKsync Docs!

Before submitting the PR, please make sure you do the following:

- Update your PR title to follow [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/)
- Read the [Contributing
Guide](https://github.com/matter-labs/zksync-docs/blob/main/CONTRIBUTING.md).
- Understand our [Code of
Conduct](https://github.com/matter-labs/zksync-docs/blob/main/CODE_OF_CONDUCT.md)
- Please delete any unused parts of the template when submitting your PR

-->

# Description

<!-- Please describe what are the changes and what they are solving for
in this PR. -->

Our `EXTCODEHASH` deviates from EVM specification.

## Linked Issues

CPR-1186

## Additional context

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`.