feat(anvil): support for multi-block depth reorgs in Anvil

[ameya-deshmukh]

Component

Anvil

Describe the feature you would like

Add support for simulating reorgs of multiple block depths (n ≥ 1) in Anvil, enabling developers to thoroughly test smart contracts and infrastructure against reorg scenarios.

Example of a 3-block deep reorg:

Before reorg:
Block 100 <- Block 101 <- Block 102 <- Block 103 <- Block 104

After reorg:
                              ┌─ Block 102 <- Block 103 <- Block 104 (Uncles)
                              |
Block 100 <- Block 101 <- Block 102' <- Block 103' <- Block 104' (New canonical chain)

Additional discussion and insights are sought from @mattsse on how best to implement this feature, including:

• How to specify the depth of the reorg
• What transactions should be included in the new canonical chain
• How to handle transaction filters for each block in the reorg

Additional context

Reorgs can cause critical infrastructure to break if not handled correctly. Implementing a testing framework for multi-block depth reorgs in Anvil would help mitigate these risks and promote best practices in reorg testing. This issue is inspired from issue 1799.

[mattsse]

this would be nice to have indeed.

we need to come up with a solution that makes the behaviour derivable from the rpc request.

I think the most powerful method would be to give the user control over how to rearrange the blocks.

although I'm not sure what the best ergonomics would look like here

maybe a function that reorgs x number of blocks, returning those blocks, then the user can manually construct the new chain, but this is a bit cumbersome and could be combined into a single call, though the question here is what rules the reorg should follow:

• exclude txs from certain senders
• include a new transaction (provided by the request)

what else?

[ameya-deshmukh]

hmmm as to what "rules" the reorg should follow, i think the best possible method would be to

• have an inclusion/exclusion filter from the uncle blocks (i.e. filter transactions with certain properties from each uncle block)
• have a list of transaction objects prepared which can then be inserted into the new blocks, can be represented as the tuple (tx, n) where tx is the transaction and n is the block to include it in.
• So essentially the i ^th block would be a subset of transactions from the uncle block + a new set of transactions where in (tx,n), n == i

Does that make sense or would that be too cumbersome?

[mattsse]

i think that makes sense

[ameya-deshmukh]

Thanks!

[EdwardJES]

Hey @zerosnacks, I'd love to take this one please.

[ameya-deshmukh]

Hey @EdwardJES would you like to collaborate on this?

[EdwardJES]

Hey @ameya-deshmukh, I'm happy to take the development on this one. I could have a draft PR up in the next coming days that will build towards the interface you've suggested above. Your early feedback on it would be greatly appreciated🙏

[EdwardJES]

Hey @ameya-deshmukh, @zerosnacks, @mattsse this one is ready for review at your earliest convenience #8489. Tyvm 🙏

[kafeikui]

Hi guys, very pleased to see that Foundry will soon support the testing function of reorg! I wonder would the simulation of reorg include resending events being affected by reorg with the removed property set to true(in eth_subscribe and eth_getFilterChanges)? I am looking forward to this feature very much to test the reorg case of events subscription/polling.