Timing rules

Gummiworm timing rules are designed to eliminate or mitigate the following issues and ambiguities:

A user submits a request intending it to only be valid during some specified validity period. How should Gummiworm, a distributed system, respect the user’s wishes?
A settlement effect might be unexecutable because the preceding initialization/settlement effect’s paired fallback (“competing fallback”) has been executed. The two are mutually exclusive because they target the same L1 state for modification.
A settlement effect might be unexecutable if it tries to absorb a deposit that doesn’t exist. This might happen if the deposit doesn’t yet exist, will never exist, or did exist but has already been refunded.

User requests

Gummiworm’s current fast consensus leader validates the user requests streaming in, relative to the start time of the block brief he is currently producing. The leader fixes this time when he starts producing the block brief, so the leader (and followers replicating his work) can use it as a stable reference point.

Only requests with time-validity periods that include the block brief’s creation time can be valid:

\begin{equation*} \begin{split} \mathrm{request.validity\_start} &\leq \mathrm{block\_brief.creation\_start} \\ &< \mathrm{request.validity\_end} \end{split} \end{equation*}

If a request doesn’t satisfy the above inequalities, then it is marked invalid in the block brief without feeding it into the black-box L2 ledger.

Timeline showing user-request validity interval with three block-creation-start positions: inside interval valid, before-start invalid, after-end invalid.

Fallback

Gummiworm reduces the chance that a settlement effect might become unexecutable by giving it ample time to be executed before the competing fallback can be executed. It occasionally replenishes this time cushion, whenever it gets too short for comfort, by forcing a new settlement effect to be generated. When this new settlement is executed, it invalidates the old fallback effect and replaces it with a new one.

Furthermore, Gummiworm reduces ambiguity by introducing a short silence period between each settlement’s validity end time and its competing fallback’s validity start time. This ensures that, at any given time, exactly one of the two competing effects can be executed.

Altogether, the above behaviour is controlled with three parameters:

Min settlement duration
Inactivity margin duration
Silence duration

Initialization and fallback

Given the initial block brief’s creation end time:

The initialization effect’s validity end time is offset by the min settlement duration and inactivity margin durations.
The initial fallback effect’s validity start time is further offset by the silence duration.

Timeline from block 0 creation end to initialization validity end (offset by min settlement and inactivity margin), then silence duration to fallback 0 validity start.

Settlement and fallback

Each new settlement effect’s validity end time is offset backward from its competing fallback’s validity start time by the silence duration.

The new fallback effect’s validity start time is offset from its block brief’s creation end time by the min settlement, inactivity margin, and silence durations.

Two-block timeline: each settlement validity end sits silence-duration before competing fallback; new fallback start offset from block end by min settlement, inactivity margin, silence.

Forced settlement

A minor block brief must be upgraded to a major block brief (which causes a new settlement effect) if too little time remains before the competing fallback’s validity start time:

\begin{equation*} \begin{split} \mathrm{min\_settlement\_duration} \geq\; &\mathrm{competing\_fallback.validity\_start} \\ &- \mathrm{silence\_duration} \\ &- \mathrm{block\_brief.creation\_end} \end{split} \end{equation*}

Normally, if no one is submitting any user requests to Gummiworm, the fast-consensus leader waits for the previous block brief’s soft-confirmation and waits to receive at least one new request before finishing the current block brief. However, if the above inequality holds, the leader immediately finishes the current block brief upon soft-confirmation of the previous block brief, without waiting for requests.

Three timeline cases comparing remaining inactivity margin against min settlement plus silence: stay minor, must upgrade (equality), must upgrade (deficit).

Finalization

The finalization effect’s validity end time is offset backward from its competing fallback’s validity start time by the silence duration — i.e., same as for settlement.

Deposits

Gummiworm reduces the chance that a settlement effect might become unexecutable by preventing it from absorbing still-volatile deposits or deposits that might become refundable before their validity end time.

This behaviour is controlled with four parameters:

Submission duration
Maturity duration
Absorption duration
Silence duration (the same parameter used in the fallback timing rules)

Deposit request

Relative to a deposit request’s validity end time:

The deposit’s submission start time is equal to the deposit request’s validity end time.
The deposit’s submission end time is offset by the submission duration.
The deposit’s absorption start time is further offset by the maturity duration.
The deposit’s absorption end time is further offset by the absorption duration.
The refund effect’s validity start time is further offset by the silence duration.

Cardano as L1. If Cardano is the L1 blockchain, the transaction that creates the deposit utxo must set its validity end time no later than the deposit’s submission end time.

Timeline of deposit lifecycle: request validity end to submission deadline, then maturity to absorption start, absorption end, and refund tx validity start after silence.

Deposit absorption and rejection

A deposit is eligible for absorption if all these conditions hold:

Maturity. The deposit is mature if its absorption start time is no later than the block brief’s creation end time.
Non-expiry. The deposit is non-expired if its absorption end time is no earlier than the competing fallback’s validity start time.
Existence. The fast-consensus leader sees the deposit on the L1 blockchain when he ends his leadership term. If a follower is reproducing the block brief, replace this condition with: the follower sees the deposit on the L1 blockchain when he finishes verifying the block brief’s requests.

A deposit is immature (not yet eligible for absorption) if condition 1 fails to hold.

A deposit is ineligible and must be rejected if the deposit is expired, or if it’s mature and non-expired but doesn’t exist on L1.

Block N's absorption period overlaid against seven hypothetical deposits, each classified as absorb-if-exists, not-yet-mature, or never-absorb.

Suggested parameter values

The suggested min settlement duration is 12 hours, which should normally be enough for initialization, settlement, and finalization effects to become final on L1 with stubborn resubmission by Gummiworm nodes.

The suggested inactivity margin duration is 24 hours, which means that Gummiworm can go for 24 hours without having to create a new settlement effect for L1 submission.

The suggested silence duration is five minutes, which should be enough to separate settlement and finalization effects from their competing fallback effects.

The suggested deposit submission duration is three minutes, which should normally be enough for an L1 deposit transaction to be submittable on L1 after the deposit request’s soft-confirmation.

The suggested deposit maturity duration is one hour, which should normally be enough for a deposit to become quite final on L1.

The suggested deposit absorption duration is 48 hours, which should provide Gummiworm plenty of opportunities to absorb mature deposits before they expire.

Six suggested parameter values: min settlement 12h, inactivity margin 24h, silence 5min, submission 3min, deposit maturity 1h, absorption 48h.