Support for multi-chain

[lucas-janon]

Hi, I'm part of a team that's working on a multichain protocol and we usually need to deploy the same contracts to multiple chains.

As far as I know, the only way to support our use case is by running the same command multiple times using a different network each time. I'd like to have a way to run a single command and let Hardhat take care of running the command on different networks.

I don't have enough knowledge on Hardhat's codebase to come up with a potential solution, but here are some ideas:

• Exposing the createProvider internal function so hre.network.provider can be changed in runtime. (A bit hacky but could be an easy workaround.)
• Built-in support for an array of networks and sequentially running the script on each of them. (Great DX, but probably not so easy to do.)
• Changing hardhat-ethers to allow updating the provider in runtime.

My team can help building this functionality if you can provide some guidance.

Thank you.

[github-actions[bot]]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: fa776d17-8dbd-4a42-b225-5bd55172e59c

[github-actions[bot]]

This issue was marked as stale because it didn't have any activity in the last 30 days. If you think it's still relevant, please leave a comment indicating so. Otherwise, it will be closed in 7 days.

[SfyMantissa]

Hi!

If this is still relevant to the topic starter and to Hardhat maintainers, I would like to research this issue.

[tuler]

This is also relevant when you want to perform operations cross chains. Suppose you want to work with a ERC20 bridge. You may need to query information on one side of the bridge and send a transaction to the other side.

[abarmat]

I support having this feature too. It's becoming more common to need to interact with multiple chain as part of a setup that relies on cross-chain messaging. An example related to Arbitrum: start a transaction on L1 and then check for the retryable ticket on L2 and redeem if necessary.

What we did is to use hardhat tasks and in some cases our own CLI tool that apart from reading the provider from hardhat config through --network it also accepts an extra provider as argument.

Multi-chain setups increase the complexity and are prone to error, in some cases, not only providers but even keys are different across chains.

[SfyMantissa]

@feuGeneA Hi! If this is relevant for the Hardhat team, then I can do the research and post findings here. I think that it could be implemented in several ways and further discussion may be needed.

If it's OK, could this issue be assigned to me?

[fvictorio]

Hi folks. We know this is very important for a lot of teams. The main thing we need to get done to enable this is to separate the Hardhat Network logic into a separate package, which has a high priority on our roadmap. I don't know when that will be done, but I opened #3042 so that people interested in this can subscribe to that issue.