You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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 leastConfirmationBlockDepth
blocks old.The following appear to be relevant places in the code where on-chain state is accessed:
Added by @ggwpez:
The current road map for this issue looks like this:
ConfirmTx
andWaitDeployed
)The text was updated successfully, but these errors were encountered: