Finality

A blockchain transaction attains finality when it is deemed irreversibly applied to the blockchain’s ledger state, meaning its outcome cannot be altered, reversed, or cancelled.

On Cardano, for example, the probability of a transaction being reversed decreases exponentially as its “block depth” increases, culminating in finality at block depth 2160.

On Gummiworm, in a sense, we could treat user request outcomes as final as soon as they are soft-confirmed by the head peers, because the consensus protocol prevents subsequent user requests from contradicting those outcomes.

However, Gummiworm’s L2 ledger does not exist in a vacuum — it is grounded in Gummiworm’s state on the L1 blockchain. This means that the L2 state changes are irrelevant unless they eventually cause corresponding changes to the L1 state. Therefore, the real measure of finality for Gummiworm’s user request outcomes is the probability that they will eventually irreversibly affect Gummiworm’s L1 state.

The diagram below sketches the finality progression. Each consensus checkpoint either ends the request’s progression (failed at soft-confirm) or unlocks a presumption of finality with increasing certainty, until the request’s effects are settled on L1:

Failed user requests

A failed user request’s outcome is final as soon as Gummiworm’s fast consensus soft-confirms that the request is invalid or has a failed outcome. Gummiworm’s slow consensus cannot retroactively declare that the request is valid --- the most it can do is withhold hard confirmation of the fast consensus decision if the coil peers cannot replicate it.

Withholding hard confirmation would transition Gummiworm to the rules-based regime, where only evacuation maps preceding the request in question can be selected.

This is a good thing: it means that users can receive quick, definite feedback on their failed user request outcomes. This allows them to fix the errors and resubmit the corrected user request.

Successful user requests

A successful user request’s outcome is final when all its associated effects are hard-confirmed by Gummiworm and executed with finality on the L1 blockchain.

When a successful user request has only just been hard-confirmed by Gummiworm, it can be presumed final by assuming all of these:

• All immediate effects associated with the request will be executed on L1 before they expire, and they will become final on L1.
• If consensus fails and Gummiworm transitions to the rules-based regime, an evacuation map descended from the user request’s outcome will be selected by the dispute resolution mechanism.

When a successful user request outcome has only just been soft-confirmed by Gummiworm, it can be presumed final by assuming that it will be hard-confirmed and that all the hard-confirmed request’s finality assumptions will hold.

In practice, it is prudent to presume finality upon hard confirmation for these reasons:

• The immediate effects generated by Gummiworm have ample time before they expire.
• The dispute resolution mechanism provides ample opportunity for an evacuation map descended from the user request’s outcome to be selected.

Presuming finality upon soft confirmation is riskier, but it may be reasonable for low-stakes user requests.