Origin: Purse: Add ability to handle transactions that are dropped due to gas prices spikes

[mikeshultz]

As seen recently in prod, Purse doesn't handle gas prices spikes very well. We need to either:

• Allow a transaction to drop when the gas price rises (would need to re-work all pending transactions or inject some other tx in at that nonce)
• Continue to broadcast until the gas prices normalize to previous levels (this can lock up the accounts and cause tx rejections in relayer)
• Re-sign the transaction with a new gas price

I think re-signing is the only reasonable approach here.

[franckc]

That is a tough problem. What were the symptoms exactly ? I assume the transactions that were submitted with low gas price stayed pending for a long time and eventually got dropped out of the transaction pool by the Ethereum nodes ?

Resubmitting with a higher gas fee sounds like an interesting approach. It's going to be tricky to make sure we tightly control under which conditions a transaction gets resubmitted (like how long do we wait before resubmitting ? do we we also resubmit all the pending txn submitted afterwards, etc...) and what max gas price we are willing to pay (we should have a cap anyway).

[mikeshultz]

I'm not 100% sure this has actually been seen yet and am making some assumptions. The PR #2530 may shed some light. It may turn out that it was actually a symptom of the nonce issue I'm trying to fix with #2534.

But the hypothetical symptoms would be a completely clogged and unusable Relayer. Basically it would attempt to re-broadcast a tx until one day the network's gas price matches the transactions'.

Resubmitting with a higher gas fee sounds like an interesting approach. It's going to be tricky to make sure we tightly control under which conditions a transaction gets resubmitted (like how long do we wait before resubmitting ?

I think a reasonable approach would be when the tx gas price diverges by X wei and the tx has been re-broadcasted Y times already(which implies age). Those values might need a little work, but without auto-scaling or a higher amount of accounts to work with, they may need to be somewhat aggressive to keep things from getting clogged up.

do we we also resubmit all the pending txn submitted afterwards, etc...)

I think they can be dealt with individually, though the transactions submitted after may end up needing the same adjustment.

The cap though is kind of interesting, however. I was actually thinking that in this case we maybe want to ignore it or give it a little more room. If some transactions were submitted when the network price was low, and the price shoots up past the cap, what do we do then? Intentionally drop the tx and all pending transactions queued behind it for that account? I guess that's a valid option.

[mikeshultz]

CC @DanielVF

[DanielVF]

So we can turn this "bug" into a feature.

We can run our initial transaction at price that is "reasonable" without having to pay at the fastest rate. If we don't get mined in 2-4 blocks, we can then resign the transaction with a higher price but the same nonce. In this way, we can get most transactions in at a much cheaper rate than we currently do, while having great worse-case transaction time guarantees.

[mikeshultz]

I do especially like how this positive spin reframes an issue I've feared since the initial build. I still think there's some other questions, like how to deal with the gas price limit but I like where you're head's at, @DanielVF.