Add a noCompile option to etherscan verification

[smartcontracts]

We use hardhat-etherscan programmatically during our deployment process to automatically verify contracts as we go. We do this because we take various steps throughout the deployment where we need additional checks to help us confirm that certain contracts have not been tampered with during deployment. We use the task verify:verify which recompiles contracts:

https://github.com/NomicFoundation/hardhat/blob/48df7d37cccc8ce72233d73f2866c159c4212b74/packages/hardhat-etherscan/src/index.ts#L233-L234

This ends up being annoying during deployment because we've already compiled the contracts once when hardhat deploy is triggered. I'd like to see an option noCompile which will skip this re-compilation step if enabled. Would be super helpful!

Thank you!

[fvictorio]

Hey @smartcontracts, this seems reasonable but things are a bit more complex here.

We actually compile twice during verification:

1. The first time we compile just the file that has the contract that you are trying to verify (and its dependencies, of course). We do this to try to send as few files as possible to etherscan.
2. If for some reason that compilation doesn't produce the same bytecode that has been deployed, which can happen in some edge cases, or if the verification just fails, we compile the whole project and try again.

This is not a very good strategy: we could try just sending the minimum set of files without re-compiling first, and etherscan would let us know if it succeeded.

The reason I'm explaining this is because, if we just ignore that line when --no-compile is used like #2478 does, you'll get a compilation attempt anyway, which is probably not what you want.

We could skip both that line and the "verify with the minimal set of files" attempt when --no-compile is used, which would mean losing that "feature", but maybe that's fine. Then, in another iteration, we could improve the minimal verification thing so that it doesn't re-compile, and add that logic back even when --no-compile is being used.

So, tl;dr: would you be fine with --no-compile not attempting to do a minimal verification (that is, with --no-compile always sending all the files in your project even if that might not be necessary)?

[smartcontracts]

@fvictorio sorry just getting back to this thread now. What's the downside of sending the entire project to Etherscan? Is it just slower? IMO it's totally fine to send all of the files in the project to Etherscan even if not necessary (when --no-compile is enabled). We can work on a second PR to make minimal verification work again.

[fvictorio]

What's the downside of sending the entire project to Etherscan? Is it just slower?

I don't think it's (much) slower. It's just that some users have complained about having "unrelated" files showing up on etherscan.

@fvictorio sorry just getting back to this thread now. What's the downside of sending the entire project to Etherscan? Is it just slower? IMO it's totally fine to send all of the files in the project to Etherscan even if not necessary (when --no-compile is enabled). We can work on a second PR to make minimal verification work again.

Great, let's do that then. @tonykogias do you feel like updating your PR to do this? It's a bit more involved than what you did, but it shouldn't be too hard.

[tonykogias]

Great, let's do that then. @tonykogias do you feel like updating your PR to do this? It's a bit more involved than what you did, but it shouldn't be too hard.

Yea sure, I will give it a shot in the next couple of days.

[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.

[emretepedev]

Same issue here.

[0x8f701]

Same issue here, any news @fvictorio this currently causes the verification to be super slow. half of our contracts spent already 2hours to verify:)

[kevupton]

This would definitely speed things up for us. We run a compile anyway before doing the verification, and need to go through and verify many contracts.

[fvictorio]

This is high on our to-do list. I can't promise a date, but I hope we'll be able to work on this soon:tm:

[smartcontracts]

Heyo! Just wanted to check in here again. We're removing programmatic verification in our application for now, but would be great to add that back in soon once this issue is resolved.

[0x8f701]

I'd also like to ask @fvictorio is there any news regarding this issue?

[0x8f701]

Hi @alcuadrado @fvictorio our team has been blocked by this for nearly 4 months, hardhat verification is super inefficient and makes our debugging very hard. Could you help unblocking us?

[fvictorio]

@GopherJ I'll try to get this done next week.

[fvictorio]

I believe this was fixed by https://github.com/NomicFoundation/hardhat/pull/3372 :slightly_smiling_face: