Tx Replay: handle forks that occur during transaction replay

[hstove]

If a fork occurs, which causes signers to enforce transaction replay, it's possible for another fork to occur in the middle of a replay. When this occurs, signers must enforce transaction replay on the entire "in-progress" replay as if it was starting from scratch.

[fdefelici]

@hstove, I could use some clarification on what exactly is meant by being in the "middle of a replay."

In the "Transaction Replay" document, the example under "Handling a double fork" seems fairly open-ended (in terms of conditions under which the partial tx replay can be produced):

- Handling a "double fork"
    - Fork A results in transactions Ta
    - Some portion of Ta is mined
    - Fork B happens
    - We now need to replay all of Ta

However, in #5972, it seems like this situation would only arise if the tenure cost budget is exhausted mid-replay.

Could you clarify:

• What exactly constitutes being "in the middle of a replay"?
• Would it be only tied to tenure budget exhaustion, or are there other scenarios that could lead to this?

[fdefelici]

@hstove one more question about the txs to be replayed in this scenario, considering both: the "Transaction Replay" document piece preported above and what reported in this issue:

When this occurs, signers must enforce transaction replay on the entire "in-progress" replay as if it was starting from scratch.

Do you mean replay from scratch the whole replay txs set (obtained at first fork), or the tx replay "delta" not yet accomplished (that are hit by the second fork) ?

for instance:

• New burn block 1
• Fork A on 1, results in Tx Replay [tx1, tx2, tx3]
• Tx1 is then mined (replayed)
• New burn block 2
• Fork B on 2 ....

Now the Tx Replay set should be [tx2, tx3], and then "restarting from scratch" the Tx Replay process from there, right?

[hstove]

Hey @fdefelici - yeah, this would mainly only happen because of tenure budget exhaustion. It could also happen from no transactions from the replay set being mined yet.

I think you bring up good points about there being more scenarios than we might have originally envisioned. Consider:

• Burn block 1a with tx1
• Burn block 2a with tx2
• Burn block 3a with tx3

If 2a is forked (with burn block 2b), then the replay set would be [tx2, tx3]. Then, let's say 1a is forked, before our first replay set is finished. The new replay set should be [tx1, tx2, tx3].