Redeploy contracts from the same deployer

[fedgiac]

There have been instances of a user sending ETH to the ETH-flow address in the wrong network, which has a high chance of making the funds completely unrecoverable.

To reduce concerns of this kind, the ETH-flow contract has been redeployed to the same address on all supported chains. There is still a risk when sending a transaction for a network to another one, but in many cases the order should just expire and the refunder should eventually reimburse the user. Note that the deployed contract doesn't use CREATE2, meaning that there's no guarantee that the contract at the target address is indeed the ETH-flow contract code.

I also added the standard json representation of the solc input (and successfully tested it). If Etherscan verification through the verification script fails (unfortunately, a common occurrence) it should be possible to give verification another shot through the Etherscan web interface.

How to test

Confirm that the barn deployment (0x04501b9b1d52e67f6862d157e00d13419d2d6e95) and the prod one (0xba3cb449bd2b4adddbc894d8697f5170800eadec) exist on all networks, that their contract code is verified matches the ETH flow, and that the deployment parameters are the expected ones.

[bh2smith]

Looks legit.

[anxolin]

Nice job. Thanks a lot! In principle looks good.

I tried to validate. I was kind of expecting the same bytecode, but they differ by a few bytes.
I saw in Etherscan they both use the same compiler version and they both have optimizations enabled, the only difference is some flags (london EvmVersion, GNU GPLv3 license vs default evmVersion, so maybe there's a slight different).

Probably not a big deal, just let me know if I should test any further.

...
0667358221220dd6ac68dca08d6be1c4da0e828b663868839c2a8d206f54f6cae8f64c576247564736f6c63430008100033

vs

0667358221220ef8802913dc7f390c98427b120eee077bb04d92ea672807f56839d2e432db81764736f6c63430008100033

I checked the contract in the networks, and the settlement and wrapped native token look correct to me, so I give a soft approve, but let me know if we are aiming for the same bytecode or how should I easily test is the same thing.

[fedgiac]

I tried to validate. I was kind of expecting the same bytecode, but they differ by a few bytes.
I saw in Etherscan they both use the same compiler version and they both have optimizations enabled, the only difference is some flags (london EvmVersion, GNU GPLv3 license vs default evmVersion, so maybe there's a slight different).

I'd have generally expected the same bytecode. I compared the contract bytecode with the existing deployment and and they only differ in the Solidity metadata.

I debugged it a bit by checking the rawMetadata field of the compiled output with the metadata of the v1.0.0 artifacts and they only differ for one of the imported libraries:

Doing the same for that library, you can see that the only thing that changes is the hash of that file. What I think at this point is that the different metadata come from the comment change from commit dc93358.

This is confirmed by the fact that the comment change happened before the Base deployment, and indeed comparing the Base deployment bytecode (old, new) shows that the two are indeed the same.

I believe it's ok to keep the new deployment as they are without a perfect bytecode match.

[anxolin]

@fedgiac amazing explanation! thanks for this. It looks all good to me