☂️ Reorg resistance of Ethereum backend

[matthiasgeihs]

The Ethereum backend is currently build on the assumption that a transaction cannot be reverted. While this may be true for local testnets, it is not true for public testnets and the Ethereum mainnet, where block reorgs can happen.

We should make the Ethereum backend work with Ethereum nets where reorgs appear. An idea how to implement this is as follows: We introduce a parameter ConfirmationBlockDepth. Whenever go-perun accesses on-chain state, we only provide on-chain state if it is at least ConfirmationBlockDepth blocks old.

The following appear to be relevant places in the code where on-chain state is accessed:

• Contract validation: ValidateAdjudicator, ValidateAssetHolder
• Event subscription: Watch, Filter
• Contract deployment: WaitDeployed
• Transaction confirmation: ConfirmTransaction

Added by @ggwpez:
The current road map for this issue looks like this:

• Reorg resistance in go-perun
  • Simulated reorgs in go-ethereum accounts/abi/bind/backends: add simulated reorgs ethereum/go-ethereum#22624
    • Tests
  • Resistant Event Subs Resistant Event Sub #40
    • Use in go-perun Use resistant EventSubs in eth/channel #85
    • Expose BoundContract Expose BoundContract in contract bindings #41 (done but not merged)
    • Generic Event Subs Generic Event Sub #39 (done but not merged)
      • Use in go-perun Use generic EventSubs in eth/channel #84
  • Resistant TX confirming
    • Generic TX confirming Resistant TX confirmation #97 (partially done with ConfirmTx and WaitDeployed)
    • Resistant contract deployment Resistant contract deployment #99
    • Fix finality depth Reasonable Finality Depth #98
  • Reorg Tests
    • Reverting
    • Reordering Events
    • Reordering TX
    • Header subscription

[ggwpez]

Biggest point missing: How to test this.
Currently we use the simulated block chain from go-ethereum. Im evaluating if it can do reorgs here.

[ggwpez]

After adding a Reorg(depth) function to go-ethereum, i was able to get a legit reorg on the simulated backend.
It removed the previous events with a removed: true event.
It does seem, however, that the TX do not end up in the mempool again, and therefore needs to be resent by the user.
Im not sure if this is normal behaviour in a geth node or an incapability of the simulated chain.

Looking at chainlink, they periodically pull the mempool status to check that the TX is still in and resend if not.
We therefore probably need something similar to their BPTM (bullet proof TX manager).