feat(StdChains): add chain enum, block explorer URLs, and sync with alloy-chains

[sakulstra]

Hey first time I noticed StdChains https://twitter.com/msolomon44/status/1699116841753534877 and checked if we can replace with our internal tooling for this.

Two things that would be quite useful for us is:

• explicit constant getters for the chains defined (aka StdChains.Arbitrum)

This is quite handy for when you want to e.g. ensure a script is run on a specific network.

• in viem the chain struct also contains the blockexplorer

This is quite handy as you can easily log addresses as blockexplorer link, making them directly clickable.

perhaps could make sense to somehow sync https://github.com/foundry-rs/forge-std/blob/master/src/StdChains.sol#L180 automatically with viem? It's a bit sad that support of chains is so different between:

• StdChains: https://github.com/foundry-rs/forge-std/blob/master/src/StdChains.sol#L180
• viem chains: https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions
• ethers-rs: https://github.com/gakonst/ethers-rs/blob/master/ethers-core/src/types/chain.rs

[mds1]

perhaps could make sense to somehow sync https://github.com/foundry-rs/forge-std/blob/master/src/StdChains.sol#L180 automatically with viem? It's a bit sad that support of chains is so different between:

The best I can think of here is to have all tools start from something like the chainlist chains.json file and each run their own script to convert that data into the format needed for their supported chains.

explicit constant getters for the chains defined (aka StdChains.Arbitrum)

What do you mean by this? Perhaps an example would be helpful. Since we do have the getChain method currently

in viem the chain struct also contains the blockexplorer

Adding block explorer URL for the reason mentioned is a nice idea. If we only add it to the Chain struct it should be backwards compatible since that's a return type only. If we added it to ChainData so you can call setChain with it that would be a breaking change, so we'd probably want to create a ChainDataV2 struct with a new version of setChain

[sakulstra]

@mds1, sure an example from a current project is having sth like this.
We currently maintain a separate library which just exposes chainIds via a easy accessible namespace: https://github.com/bgd-labs/aave-helpers/blob/master/src/ChainIds.sol#L4

We use them e.g. to validate that a script is run on the correct network:
https://github.com/bgd-labs/aave-helpers/blob/master/src/ScriptUtils.sol#L31

Or to work around issues with deal on certain networks: https://github.com/bgd-labs/aave-helpers/blob/master/src/CommonTestBase.sol#L34

Generally for us it has proved to be useful having chainIds exposed via human readable name, opposed to hardcoding numbers everywhere. Was just thinking as StdChains exposes this data anyways via getChain() could be useful to also expose supported chainIds via a more straightforward getter.

[mds1]

Makes sense, so you can get the chain ID from a human readable name using the getChain(string) method, for example getChain("mainnet").chainId. Here's a forge-std that does this:

forge-std/test/StdCheats.t.sol

Line 404 in 1d9650e

assumeNotPrecompile(addr, getChain("optimism_goerli").chainId);

[sakulstra]

@mds1 i understand but usability wise it is not the same right?

With ChainIds.ARBITRUM_GOERLI(or similar) I have a constant that autocompletes in a common editor.
With assumeNotPrecompile(addr, getChain("optimism_goerli").chainId); on the other hand i need to know it's optimism_goerli, not Optimism_goerli etc.

[mds1]

Right, it's just a string so it won't autocomplete. Probably could add an enum that has all the same strings as the enum values, along with a getChain(enum ChainAliases) overload

[zerosnacks]

We now maintain https://github.com/alloy-rs/chains that has been getting more and more external contributions to make sure their chain info is up to date. One thing that is missing however is a default RPC URL as that can be considered opinionated and likely to go down.

[sakulstra]

@zerosnacks somehow missed that

Are they somewhere exposed within foundry/solidity? Would love if we could stop maintaining our own name/chain map 😅

[zerosnacks]

Hi @sakulstra,

I don't believe we currently expose this in a convenient way but this should be straightforward following the work on multichain configuration where we also resolve the name. Proposal is to add a new cheatcode vm.getChainId(name) where name is an alloy-chains compliant name.

Opened an issue in Foundry to track this foundry-rs/foundry#12187