bug(`forge`): deterministic address changed after updating forge version

[Keref]

Component

Forge

Have you ensured that all of these are up to date?

• [X] Foundry
• [X] Foundryup

What version of Foundry are you on?

forge 0.2.0 (f2518c9 2024-08-06T00:20:17.084842600Z)

What command(s) is the bug in?

No response

Operating System

Windows

Describe the bug

I use forge to deploy deterministic contracts across several chains. Because of a bug that caused race conditions on low latency blocks like Arbitrum, I updated forge to the latest version. Now the contract addresses have changed, despite nothing else in the configuration having changed. In particular, I have a create2ownable contract that I use to deploy ownable contracts:

    address _c2o = getAddress(FORGE_DETERMINISTIC_DEPLOYER, type(Create2Ownable).creationCode, "Create2Ownable");

with

  function getAddress(address deployer, bytes memory bytecode, bytes32 _salt) public pure returns (address){
    bytes32 hash = keccak256(abi.encodePacked(bytes1(0xff), deployer, uint256(_salt), keccak256(bytecode)));
    return address(uint160(uint256(hash)));
  }

The contract has no parameter, and now is consistent across various chains, but with a different address from previously deployed contracts. Which makes it impossible to deploy with the same address now.

Code is using solc 0.8.19.

What has changed with forge or cast? Is there a chance to rollback forge version (and how do I know, forge doesnt keep logs after updating)

[zerosnacks]

Hi @Keref would you be able to share your foundry.toml?

Do you remember the commit of your previous install?

You can use foundryup --commit <COMMIT_HASH> to install a specific commit and build from source

[Keref]

Hi, foundry.toml hasnt changed:

[profile.default]
src = 'contracts'
out = 'out'
libs = ['lib']
fs_permissions = [{ access = "read-write", path = "./"}]
solc_version = '0.8.19'
evm_version = "shanghai"

I tried with various past versions, the April and March version give the correct previous address which differ from the computation with latest version, and indeed there's a indeed creationCode difference between some foundry versions. I think that should be a bug?

The code is available here: https://snowtrace.io/address/0x1Cc1655Ac0e9be0113004b8bE12cc750D8a6AF15/contract/43114/code

Still exploring various past foundry versions bc I cant remember last time I updated foundry and some contracts still dont compile identically.

[zerosnacks]

Would you be able to share the build artifacts created of the two versions (the working one and the latest one)? This will help narrow down the issue.

Do you have examples of this contract on other chains?

Settings you may want to look into for deterministic deployments are:

bytecode_hash = "none"
cbor_metadata = false

[Keref]

~~With bytecode_hash set to none will I still be able to verify contracts?~~ I can deploy and verify without issue. Tried with cbor_metadata = false and it works, I think it still is a bug that you need special configuration (that is not mentioned in the forge create2 doc) to get the expected behavior.

Here are both arifacts generated with 2 forge versions (cafac26... and 2cb87) without bytecode_hash and cbor_metadata params in foundry, same code Create2Ownable Create2Ownable-cafc2606a2187a42b236df4aa65f4e8cdfcea970.json

Create2Ownable-2cb875799419c907cc3709e586ece2559e6b340e.json

[klkvr]

@Keref do you mind checking if you are able to generate same bytecode on nightly-f625d0fa7c51e65b4bf1e8f7931cd1c6e2e285e9 version?

Given that you are working on Windows, the change might be caused by https://github.com/foundry-rs/compilers/pull/108. From files you've linked I can see that Create2Ownable's metadata hash has changed without any changes to bytecode which might happen when \r\n endings are replaced with \n

[Keref]

Yes indeed it looks like it's working now. The line ending hasn't been changed on my side though and I thought github would automatically convert those upon commit?

[jenpaff]

resolved by https://github.com/foundry-rs/compilers/pull/108