Calculate bytecodehash in solidity on a ZK Stack based chain

[vmaark]

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.80.1

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

When I import {Utils} from "lib/era-contracts/system-contracts/contracts/libraries/Utils.sol"; and use hashL2Bytecode, the code doesn't compile.

Expected Behavior

Should compile without errors.

Current Behavior

Error (6933)
ParserError: Expected primary expression.
  --> lib/era-contracts/system-contracts/contracts/Constants.sol:20:44:
   |
20 | uint160 constant SYSTEM_CONTRACTS_OFFSET = {{SYSTEM_CONTRACTS_OFFSET}}; // 2^15```

### Repository Link (if applicable)

_No response_

### Additional Details

It's clear that ` {{SYSTEM_CONTRACTS_OFFSET}}; ` is not going to compile, the git commit adding it mentions preprocessing  . 

My question is if there is another way of doing the calculation (maybe with an already deployed system contract?), or something else. I also found there's another implementation for `hashL2Bytecode`, but under `l1-contracts`, the `L2ContractHelper.sol`, I assume that is not for this usecase.

### Prior Research

- [X] Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

It seems like you are encountering a preprocessing issue with the SYSTEM_CONTRACTS_OFFSET in the Constants.sol file. This preprocessing step is likely intended to replace placeholders with actual values during the build process, but it's not functioning as expected in your environment.

Regarding the calculation of the bytecode hash on ZKsync, the process typically involves specific system contracts designed to handle such operations. As you mentioned, there is an implementation under l1-contracts named L2ContractHelper.sol, but it's not suitable for your use case since it's designed for L1 operations.

For calculating the bytecode hash directly on ZKsync, you might want to consider the following approaches:

1. Direct System Contract Interaction: If there's a system contract deployed that handles bytecode hashing, you could interact with it directly. This would involve calling the contract's method that accepts bytecode as input and returns its hash. You would need to check the deployed system contracts on ZKsync for such functionality.

2. Manual Calculation: If a suitable system contract is not available, you might need to implement the hashing logic manually in your contract. This would involve replicating the hashing algorithm used by ZKsync in your Solidity code. Ensure that the hashing algorithm (like SHA256 or Keccak256) matches the one used by ZKsync for bytecode hashing.

3. Fixing the Preprocessing Issue: To resolve the preprocessing issue, you might need to ensure that your build environment correctly replaces the {{SYSTEM_CONTRACTS_OFFSET}} placeholder. This could involve adjusting your build scripts or environment settings to include the necessary preprocessing steps.

If these options do not resolve your issue, or if you need more specific guidance on interacting with system contracts for bytecode hashing, I recommend checking the ZKsync documentation or reaching out to the ZKsync development team for more detailed support.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[sarahschwartz]

Hi @vmaark, there is an implementation you may be able to use from the @matterlabs/zksync-contracts package.

You should also just be able to change your own chain contract manually.

If that doesn't work for your needs, can you explain in more depth where & how you are trying to use this?

[vmaark]

hey @sarahschwartz, thanks for the reply! I've looked at the package, but realized there's another obstacle for using it - the function is expecting bytes calldata, but the accessing the bytecode via type(UniswapV2Pair).creationCode is using memory. Specifically I'm trying to convert this function, which is used in uniswap v2:

    /// @dev calculates the CREATE2 address for a pair without making any external calls
    function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
        (address token0, address token1) = sortTokens(tokenA, tokenB);
        pair = address(
            uint160(
                uint256(
                    keccak256(
                        abi.encodePacked(
                            hex"ff",
                            factory,
                            keccak256(abi.encodePacked(token0, token1)),
                            hex"5ef2d07853620860a5e77bae863f7dc2bd883e28f5e9c837541f791fb45076c7" // init code hash, keccak256(type(UniswapV2Pair).creationCode)
                        )
                    )
                )
            )
        );
    }

I've looked at some zksync forks of uniswap v2, one solution I saw was storing them in a mapping and do a look-up instead of calculating it. Based on the notice in the EfficientCall library, this might be a better approach?

[dutterbutter]

@vmaark I would suggest the approach taken here: https://github.com/uniswap-zksync/era-universal-router/blob/v1.2.2-zksync-era/contracts/modules/uniswap/v2/UniswapV2Library.sol or you use the lib itself.

[vmaark]

thanks @dutterbutter, I'll look into integrating this

[vmaark]

Unfortunately still having issues with this one. Here are all the steps I'm taking:

1. compile with zksolc
2. run a simple script to get the bytecode hash:

import { utils } from "zksync-ethers";
import { hexlify } from "ethers";
import { HardhatRuntimeEnvironment } from "hardhat/types";

export const getUniswapV2BytecodeHash = async (hre: HardhatRuntimeEnvironment) => {
    const artifact = await hre.artifacts.readArtifact("UniswapV2Pair");
    const bytecodeHash = utils.hashBytecode(artifact.bytecode);
    const hexString = hexlify(bytecodeHash);
    
    return hexString;
}

3. use that hash in the address calculation

    function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
        (address token0, address token1) = sortTokens(tokenA, tokenB);
        pair = address(uint160(
            uint256(
                keccak256(
                    abi.encodePacked(
                        bytes32(0x2020dba91b30cc0006188af794c2fb30dd8520db7e2c088b7fc7c103c00ca494), // keccak256("zksyncCreate2")
                        bytes32(uint256(uint160(factory))), // sender
                        keccak256(abi.encodePacked(token0, token1)), // salt
                        hex'010004df694643e2d7e17535f16c21e9d1698b06c2ef330166830639b23b7f43', // init code hash
                        bytes32(0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470) // constructor input hash: keccak256("")
                    )
                )
            )
        ));
    }

Here's the relevant part of the sourcecode for creating the contracts:

    function createPair(address tokenA, address tokenB) external returns (address pair) {
        require(tokenA != tokenB, "MagicswapV2: IDENTICAL_ADDRESSES");
        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
        require(token0 != address(0), "MagicswapV2: ZERO_ADDRESS");
        require(getPair[token0][token1] == address(0), "MagicswapV2: PAIR_EXISTS"); // single check is sufficient
        bytes memory bytecode = type(UniswapV2Pair).creationCode;
        bytes32 salt = keccak256(abi.encodePacked(token0, token1));
        assembly {
            pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
        }
        IUniswapV2Pair(pair).initialize(token0, token1);
        getPair[token0][token1] = pair;
        getPair[token1][token0] = pair; // populate mapping in the reverse direction
        _allPairs.add(pair);
        emit PairCreated(token0, token1, pair, _allPairs.length());
    }

Interestingly, if I used

pair = address(new UniswapV2Pair{salt: salt}());

instead of the assembly section, I also got a different address. It's also kind of unclear from the documentation (and other resources, like https://foundry-book.zksync.io/tutorials/create2-tutorial, which actual method should be used for deterministic deployments, so I'm unsure in which direction should I continue investigating.

Also @dutterbutter the repository/branch you linked has address(0) for the bytecode hash for UniswapV2Pair in the deployment params.

[vmaark]

I figured what's causing the issue: the project is using hardhat for deployment, but foundry for unit tests, where we check that the create2 address is correct. Unfortunately foundry and hardhat generated bytecode will very likely differ in every case, according to foundry-rs/foundry#5559, which will make both the hash and the address different too.