Deploying the P256Verifier contract on a new EVM chain

[yohanelly95]

Running the same script and deploying the same contract with the same salt (ie, 0) deploys to a new contract address and not the deterministic address 0xc2b78104907F722DABAc4C69f826a522B2754De4.

I also used the same optimizer runs as well. Do you know what is being missed here?

[yohanelly95]

Note: CREATE2 does exist on the chain. For eg, even using anvil where the Create2 Factory is deployed does not deploy the contract to the same deterministic address @nalinbhardwaj

[nalinbhardwaj]

Sorry, misunderstood your second comment:

Are you using the same version of Foundry / solc (0.8.21) as the repository?

It may also be simpler to replay our deployment transaction so you don't have to replicate the repo set up exactly.

[yohanelly95]

Sorry, misunderstood your second comment:

Are you using the same version of Foundry / solc (0.8.21) as the repository?

It may also be simpler to replay our deployment transaction so you don't have to replicate the repo set up exactly.

Yes using the same solc version, specified it in the foundry toml along with the optimizer runs as well.

I see, so this txn is a call to the Create2 factory contract. I would like to deploy this contract on anvil for now, so technically if the foundry toml matches and the contract matches (including the same salt) then it should deploy to the deterministic address? Not sure why that's not working currently for me

[yohanelly95]

@nalinbhardwaj actually not using the same foundry version, I am on forge 0.2.0 (62cdea8 2024-07-23T00:18:49.756549000Z). Would this matter though for the deployment? Since we are using the Create2 factory to deploy the contract.

[thomasknauth]

One thing I recently discovered is that if you just "forge build" you will not arrive at the same address because the bytecode differs. Apparently, the final portion of the bytecode encodes metadata (i.e., hashes) of the build configuration. Unless the build configuration matches exactly (compiler version is just one moving piece among many that can change the final hash; in my case, I suspect additional remappings which forge inserts automatically) with what was used originally (and it does not match out of the box, unfortunately) you will not arrive at the same address. I was actually going to create an issue and suggest the repo should at least mention somewhere that it is not sufficient to just run "forge build" to arrive at the same bytecode/deploy address.

[yohanelly95]

One thing I recently discovered is that if you just "forge build" you will not arrive at the same address because the bytecode differs. Apparently, the final portion of the bytecode encodes metadata (i.e., hashes) of the build configuration. Unless the build configuration matches exactly (compiler version is just one moving piece among many that can change the final hash; in my case, I suspect additional remappings which forge inserts automatically) with what was used originally (and it does not match out of the box, unfortunately) you will not arrive at the same address. I was actually going to create an issue and suggest the repo should at least mention somewhere that it is not sufficient to just run "forge build" to arrive at the same bytecode/deploy address.

I agree, the repo should add this as a side-note. For now I have forked the repo and updated the address on the forked repo.

[holic]

might make sense for them to check in the compiled bytecode + init code and an alternative deploy script that uses that for deployment rather than the local foundry's compiled output (which may differ due to above)