Contract deployments with `blockTime` set take ~4 seconds

TLDR: Minimal working example (MWE) Using the the current ganache@alpha npm package together with the latest version of ethersjs exhibits an unexpected behavior when deploying contracts. The deployment of a single contract takes ~4 seconds unless a seemingly random but once found consistent amount of blocks is force mined with the evm_mine call.

For some production code I needed to setup a blockchain environment which has some contracts predeployed for later uses. We were using ethereum-waffle@3.4.0, which under the hood seems to use ganache-core@2.13.2. Some tests are time dependent which required me to allow the use of the blockTime option for the underlying provider. Once this blockTime was set, the setup for the tests took a long time, always around ~4+ seconds per deployed contract. I tried speeding them up by triggering the mining of blocks with the previously mentioned evm_mine call, but this did not help. Playing around even further showed that in that instance mining 7 blocks immediately triggered the contract deployment.

So I created a MWE with ganache@alpha and an ethersjs@5.5.1 which shows this behavior and logs the provider output to corresponding files. It already contains logs for my run and the console output of the timings is the following:

Time taken without blockTime set: 4285.957789000124
Time taken with 1 skipped: 4176.430750001222
Time taken with 12 skipped: 4139.068713000044
Time taken with 13 skipped: 4129.8051149994135
Time taken with 18 skipped: 149.827926998958
Time taken with 19 skipped: 90.71113900095224

Interestingly using ganache@alpha with no blockTime now also takes 4+ seconds, but this might just be a misconfiguration on my end?

Notes: I am fully aware that ethersjs sets a default polling rate of 4 seconds but I cannot believe that this is connected, since in my tests setting the pollingRate did not change my time measurements and deploying a contract is not event based. Unless there is peculiar stuff going on behind the curtains which I am not aware of. But then this brings up another question: Why does skipping n amount of blocks suddenly trigger the deployment if this is related to ethersjs polling rate?

I hope I can get some help and that the MWE is enough. To run simply issue yarn && yarn start and the logs will be put under the <project>/logs/ directory. And the MWE can be adapted as seen fit by whoever this might concern.

Thanks for the help in advance 🙏

[ndzik]

Sorry for the late reply, I got sick shortly after opening this issue and did not come around to it again until today.

Thanks again for all the replies and I can confirm that using WebSocketProvider behaves as expected 💪

[ricmoo]

@ndzik As best as I would guess, yes, a WebSocketProvider should work. 😃