Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardhat forking network validation #1902

Open
fredlacs opened this issue Sep 23, 2021 · 5 comments
Open

Hardhat forking network validation #1902

fredlacs opened this issue Sep 23, 2021 · 5 comments
Labels
blocked-reason:needs-edr status:blocked Blocked by other issues or external reasons type:improvement

Comments

@fredlacs
Copy link
Contributor

A number of users attempt to fork different networks using hardhat.

Some networks are evm compatible with an RPC interface that works with hardhat forking, but the internals are sometimes different to that of the evm (for example gas metering is different).

By forking these networks with hardhat, users might get the impression that their tests are executing correctly but when contracts are deployed they can fail.

This can still be useful for integration testing, but users should get a warning about that when attempting to fork certain networks.

@alcuadrado
Copy link
Member

Thanks for opening this issue, @fredlacs. It's something that we also noticed and were worried about. Many users don't realize that Hardhat Network and Arbitrum are very different systems, with some compatibility.

How do you think we should communicate this? In particular, what did you mean by "This can still be useful for integration testing"? Integration tests for contracts that are meant to be run on Arbitrum?

@fredlacs
Copy link
Contributor Author

The feature is useful for integration testing in the sense that it can give a dev more confidence that their Arbitrum deployment will integrate with the correct addresses and using the intended interfaces.

The two main issues that I'd highlight in a warning are: possible different execution environment, precompiles and gas metering.

I think an opt-in mechanism with loud warnings for any chain ID that isn't whitelisted works well.

@github-actions
Copy link
Contributor

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.

@gzeoneth
Copy link

gzeoneth commented Jul 26, 2022

With #2995, the user would have to add a new flag to make networks like Arbitrum Nitro works with hardhat. That would serves as part of the opt-in mechanism but we probably should still have a warning based on chainId.

@mdcoon
Copy link

mdcoon commented Feb 2, 2023

To add to the discussion. The precompiles are essential for any smart contract attempting to get L1 gas fee information on-chain, or even offchain in unit tests through the harhat ethers providers. The precompile addresses/opcodes are not passing. If I call an RPC endpoint directly outside of Hardhat, it works fine. But obviously can't test my contracts through a forked Hardhat instance that does not support the precompiles. Perhaps some opcodes and precompile addresses could be mapped to fallback to the backing archive node RPC endpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked-reason:needs-edr status:blocked Blocked by other issues or external reasons type:improvement
Projects
Status: No status
Development

No branches or pull requests

5 participants