Simulate txs on the latest block instead of pending

[MartinquaXD]

Description

Currently the reference driver struggles to get transactions mined reliably. I think the reason is that we simulate the tx on the pending block instead of latest.
For context latest means simulate my tx on top of the last mined block while pending means simulating on the latest block AND all txs in the mempool that have a higher gas price than my tx.

I think this together with our logic that re-checks the tx on every new block (to detect reverts early and mine a cheaper cancellation tx instead of a more expensive revert) leads to seeing false reverts.
If we submit our tx on block n and it's not included in block n+1 it would still be in the mempool for block n+2. So if we re-simulate on pending at block n+1 our previously submitted tx would already be in the set of pending txs that get applied before our simulation happens and since both txs touch the same state the second one will revert.

Technically the optimal approach would be:

1. lock in gas price we want to use for the whole duration of the submission
2. before submitting anything simulate tx on pending with the locked in gas price
3. on subsequent blocks simulate on latest to avoid txs interfering with each other.

But for the sake of simplicity I think it makes sense to first go with always using latest instead to see if this even has the desired impact in the first place.

Changes

Always simulate txs on the latest block.

How to test

Temporarily deploy this to prod to see how this effects inclusion times / rates.

[gemini-code-assist]

Code Review

This pull request updates the estimate_gas function in crates/driver/src/infra/blockchain/mod.rs to target the latest block instead of the pending block. This change is intended to avoid false positive reverts when re-checking transactions after they have been submitted to the mempool. No critical issues found.

[fleupold]

So if we re-simulate on pending at block n+1 our previously submitted tx would already be in the set of pending txs that get applied before our simulation happens and since both txs touch the same state the second one will revert.

This is a pretty interesting hypothesis. Do you have concrete evidence that this is causing reverts (e.g. example solutions where we can now see that they should still simulate successfully at n+1). I'd expect nodes to deduplicate pending transactions from the same sender/nonce.

The other issue with latest is that it still has the block timestamp of the last block. In the past we had issues with solutions that would require the next block's timestamp (because of time dependent AMMs for instance).