[Compilers]<zksolc Bug Report>

[JhChoy]

Which compiler are you using?

• zksolc
• zkvyper

Which version of Solidity or Vyper?

0.8.25

zksolc/zkvyper version?

v1.4.1

Explain the issue

While developing Solidity contracts in zkSync, I noticed that they compile differently.

In Solidity, even if leftover data remains in memory, when returned as uint40 within a function, the 27 bytes of data disappear. Therefore, in the code below, even if a value larger than uint40 is input into getNumber, it is truncated in the _convertToUint40 function, and the function executes.

contract Foo {
    uint256[] internal numbers;

    function addNumber(uint256 number) public {
        numbers.push(number);
    }

    function getNumber(uint256 index) public view returns (uint256) {
        return numbers[_convertToUint40(index)];
    }

    function _convertToUint40(uint256 n) internal pure returns (uint40 result) {
        assembly {
            result := n
        }
    }
}

This means the results of getNumber(0) and getNumber(2**40) are the same.

However, contracts compiled with zksolc do not truncate, so the actual index queried in the numbers array is the input value itself. Therefore, executing getNumber(2**40) results in no return value and triggers an 'Array index out of bound' panic error (since the length of numbers is currently less than 2**40).
You can see deployed contracts here:
Sepolia
zkSyncSepoliaTestnet
Try calling getNumber(2**40).

This could create a serious bug when deploying Solidity contracts that assume truncation onto zkSync.

Link to your repo?

No response

[bxpana]

Thanks for the post. Will check this out and see what info I can find for you.

[hedgar2017]

@JhChoy zksolc uses the Yul codegen by default, and it is known for being more buggy.
Could you check if --force-evmla flag fixes the issue?

[JhChoy]

@hedgar2017
Yeap, the problem was resolved. Thanks!
Is it still unsafe to compile and deploy without that option?
Also, I noticed that the bytecode significantly increased for some contracts with that option.

[hedgar2017]

@hedgar2017

Yeap, the problem was resolved. Thanks!

Is it still unsafe to compile and deploy without that option?

Also, I noticed that the bytecode significantly increased for some contracts with that option.

We are using Yul produced by solc under the hood.
Unfortunately we do not control it, so perhaps solc developers can help and answer why their output is non-deterministic.

[JhChoy]

Hmm... Okay, I understand. It's getting a bit complicated.
Thank you for checking.

[hedgar2017]

@JhChoy we're going to synchronize our codegen settings with those generally expected.
However, it will only work with the ZKsync fork of solc (you can use it by specifying the era_version option in HH config), as it includes critical fixes for the old codegen.
We're currently discussing how to make this transition smooth.

[hedgar2017]

Forwarded to solc developers: ethereum/solidity#15142