Mining a block

[vpahari]

Hi there,

I am trying to reexecute transactions in a block using hardhat. The way I am currently doing this is that I am taking the block (for e.g. https://etherscan.io/txs?block=21322632), and reexecuting this using hardhat. Currently, here is the steps that I am taking:

1. I fork the block to blockNumber - 1 (so in this case it would be 21322631)
2. I set the automining to False, and set the mining to FIFO
3. I set the timestamp forward to the actual timestamp of the block
4. I gather the raw transactions and send transactions in order using eth_sendRawTransaction
5. After sending all the transactions in the block, I mine the block using evm_mine.

I am encountering a problem when sending the final transaction of the block, specifically this one (https://etherscan.io/tx/0x76603f4bdb6f70a211fa5ea2c1a7ea37f36b040a7c2077e2d161cd4240b26b5c). The problem is that this is a fee reception transaction sent from the builder to the proposer, and the amount of ETH transferred by this transaction is higher than what it currently has. So, when I call eth_sendRawTransaction, it returns an error. However, in the context of the block, the transaction is valid since it will receive some ETH from previous transactions.

Since I am only interested in reexecuting a block in a certain order, is there a way I can just mine a block on hardhat without using the eth_sendRawTransaction, or disabling the check for whether an address has enough ETH.

[fvictorio]

Hey @vpahari, thanks for opening this, this is really interesting. My understanding of what's going on here is:

When a node (e.g., geth) receives a transaction, some checks are performed to see if the transaction is valid. For example, if the nonce is too low, the transaction will be immediately rejected. If the nonce is too high, the transaction is not rejected, because it could be included later after the intermediate nonces are used.

Balance works a bit differently. Here the check is usually just "is the balance enough", even if a previous tx might increase the balance. The reason for this, AFAIK, is that checking the counterfactual "will this tx be actually valid if all these other txs are executed first" is costly, and therefore a potential DOS vector.

Now, nothing of this is standardized. Each node can do whatever it wants with the mempool. We usually just copy what geth does, like in this case. But I think your use case is super valid, and we should find a way around it.

Perhaps the simplest option is to just disable this check when automining is off, and just drop the transaction if, at the time of mining it, it's not valid. Hardhat is a development node, so DOS vectors are not relevant at all. This is a change in behavior though so we should be careful, but my guess is that it would be fine; I doubt anyone is relying on this particular behavior, and in any case I wouldn't consider this a breaking change since this is not exactly a public API.

@alcuadrado what do you think?