Hardhat 3 timestamps are broken if intervalMining is set to less than 1000

[kanej]

This was reported by @SebastienGllmt in Telegram.

timestamps are broken if intervalMining is set to less than 1000 on 3.0.0-next.16
the block timestamp advances faster than real clock time

Next steps

• Reproduce in script
• Check whether the configuration around interval mining is flowing through to EDR correctly

[kanej]

@SebastienGllmt can I check, a valid reproduction would be:

1. Create a Hardhat script that connects to a Hardhat network with interval mining set to 500ms
2. the script polls every half second for the latest block and prints the block number and timestamp

We expect the bug to express itself as the timestamp getting out of sync (into the future) from wall clock time.

[SebastienGllmt]

Specifically, this is the hardhat config I used

evmMain: {
      type: "edr",
      chainType: "l1",
      chainId: 31337,
      automine: true,
      intervalMining: 250, // matches Arbitrum (250ms)
    },

You can get the block using

const client = ; // initialize viem public client

while(true) {
    const blockNumber = client.getBlockNumber({ cacheTime: 0 });
    const block = client.getBlock({ blockNumber }); 
    console.log(block.timestamp)
}

[fvictorio]

@SebastienGllmt can you try adding allowBlocksWithSameTimestamp: true to that config?

[SebastienGllmt]

@fvictorio that seems to have fixed it, so I guess the fix to this issue is either to make allowBlocksWithSameTimestamp: true implicit if intervalMining < 1000 or add an error message asking the user to set allowBlocksWithSameTimestamp: true in that case

[kanej]

I think a warning makes more sense here. I am not a fan of changes in the underlying configuration at unseen break points. We should be explicit.

[fvictorio]

Yes, I think the options are:

• A warning
• A config validation error (good idea for HH3, probably not for HH2)
• Making the default value of allowBlocksWithSameTimestamp depend on the value of intervalMining (I don't dislike this idea as much as @kanej, but don't love it either).

A warning is easy to add and non-controversial, so I'd say we go with that.