search

NomicFoundation / hardhat-ignition

Hardhat Ignition is a declarative deployment system that enables you to deploy your smart contracts without navigating the mechanics of the deployment process.
https://hardhat.org/ignition
MIT License
107 stars 24 forks source link

IGN403 should be aware of development networks #793

Open fvictorio opened 2 months ago

fvictorio commented 2 months ago

Assuming Ignition has some way to know that a network is a development network, then IGN403: You have sent transactions from 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 and they interfere with Hardhat Ignition. Please wait until they get 5 confirmations before running Hardhat Ignition again. shouldn't be thrown for those kinds of networks.

To be honest I don't fully understand the reason for this error (and as far as I can tell, Ignition doesn't have a reference with expanded explanations about errors like Hardhat does). But I can imagine someone starting a node, running a transaction with the default account, and then trying to deploy something with Ignition. I can imagine it because it just happened to me.

One easy way to detect if a network is a development network is to send a hardhat_metadata request. If it doesn't fail, then it's a development node. This works both on Hardhat and Anvil.

fvictorio commented 2 months ago

Something similar happens when you deploy on a Hardhat or Anvil node with automining disabled. When the deployment transactions are (manually) mined, Ignition hangs. You have to mine four or five blocks more for the deployment task to finish.

I guess the underlying reason here might be the same: there is a "safe" number of blocks used to consider a transaction finalized. If that's the case, I think that number should be 0 for development networks.

kanej commented 2 months ago

We detect whether a network has automining enabled. If automining is enabled we don't require confirmations. If automining is disabled we use the config value for required confirmations (there might be some weird rules for private besu chains, but leaving them out of it).

I think the feature your requesting is, "detect a development node with automing off and set a the number of required confirmations to 1"?

This in effect would add three categories:

  1. Normal network (use config for required confirmations)
  2. Development network with Automining on (use different strategy for confirmation)
  3. Development network with automining off (override config for required confirmations and set it to 1).
fvictorio commented 2 months ago

That makes sense to me, yes.