feat(`config`): add chain dependent `solc` config and support in multichain scripts

[sakulstra]

Component

Forge

Describe the feature you would like

At bgd we rely quite a lot on multichain scripts, which worked fine as long as Aave was only deployed on shanghai compatible blockchains.
With the recent expansion to linea(london) and zksync(zksolc) we're reaching a point where our workarounds no longer work.

Deploying for different chains, we try to solve with profiles.

[profile.bnb]
evm_version = 'shanghai'

[profile.linea]
evm_version = 'london'

One issue we face here is that whenever switching the evm version a complete recompile is needed. It would be great if the cache was per evm_version, so things only have to be recompiled once.

---

While the above issue is annoying, one more problematic thing is that multichain scripts (single script switching between networks) will always run with a single solc & evm_version. This leads to problematic situations:

• if you select london (with the goal to unite on the lowest accross chains), the script might fail with not activated when touching sth deployed on shanghai or cancun
• if you select cancun you will end up deploying non executable code on chains that are stuck on london
• another caveat is that when you rely on address prediction based on create2, addresses might be different then expected

Currently I don't see any solution for this problem, the workaround we currently use is to no longer use multichain scripts... which ofc is painful.
It would be great if one could configure solc per chainId and dynamically switch based on which network is currently forked. No idea how this could work, but I guess if using forge multichain this would be a must.

Additional context

No response

[grandizzy]

@sakulstra you have the option to pass the --evm-version arg to forge script
For tests that's supported inline like

    function setUp() public {
        myContract = new MyContract();
    }

    /// forge-config: default.evm_version = "berlin"
    function test_berlin() public {
        myContract.doSomething();
    }

    /// forge-config: default.evm_version = "cancun"
    function test_cancun() public {
        myContract.doSomething();
    }

does this work for your use case?

[sakulstra]

@grandizzy I think no.

This only really helps when I want to have a single evm_version for the full script, right?
But the point of multichain scripts is to do things on multiple chains in the same script.

E.g. in this example i'd like to switch the evm_version on every build<Network>Payload (as what we do under the hood is switch to that network and check if the payload was deployed and registered via create2). <- but e.g. this will will now no longer work with linea. If i deployed the payload with london, but execute the script via shanghai the addresses will be different. If I run the script with london, things on other networks might not work.

[grandizzy]

sorry, i misunderstood your use case. Switching evm version in same script / test is something we're looking to add (through a setEvmVersion cheatcode or by automatically figuring it out when a fork is selected). Automatically picking it up is a little bit more cumbersome as we'd have to maintain hardforks history (see #6440) but at min we could offer a similar config per fork / rpc_endpoint as in https://hardhat.org/hardhat-network/docs/guides/forking-other-networks#using-a-custom-hardfork-history )

[sakulstra]

Switching evm version in same script / test is something we're looking to add (through a setEvmVersion cheatcode or by automatically figuring it out when a fork is selected)

Having some per chain config would actually be great. Working with per chain profiles is quite painful, especially when working with external teams.

Would be so much more pleasant if on foundry toml we could just say: "use cancun & 0.8.27 on optimism, shanghai & 0.8.23 on mantle, london & 0.8.22 on linea" and then things work just automatically based on the selected fork.
Could be especially interesting once pectra is live and one might want to use eof and via-ir on some chain, but not on others.

[sakulstra]

Just to add on this, on sonic WETH was deployed with cancun, so for multichain scripts touching WETH (which sadly is quite common for us) we'd now need to bump to cancun breaking multiple of the other chains.