Effects
Gummiworm’s effects on the L1 blockchain are deterministically derived from Gummiworm’s initial L1 state and the block briefs produced by the head peers. The effects can always be identically rederived by applying the following procedure to each consecutive block brief:
- Send commands, in total order, to the black-box L2 ledger and track the outcomes.
- Construct the effects from the request outcomes.
Initialization
Initialization is an immediate effect to which the head and coil peers consent before starting the Gummiworm consensus protocol. It can do anything the peers want, but Gummiworm needs it to do this:
- Set up Gummiworm’s initial state on the L1 blockchain in the main and equity compartments.
- (By hash) specify Gummiworm’s initial L2 state, which must reside in the main compartment.
- (By hash) specify the protocol parameter values with which the head and coil peers will run the Gummiworm consensus protocol.
- (By hash) specify the head peers’ respective contributions to Gummiworm’s initial equity.
A Gummiworm head’s ID is based on a unique aspect of its initialization effect.
If Cardano is the L1, see: initialization transaction (with diagram).
Finalization
Finalization is an immediate effect by which Gummiworm winds down its L1 state to terminate the consensus protocol gracefully:
- Pay for this effect out of the fallback contingency compartment.
- Distribute the funds from the equity and fallback contingency compartments to the head peers.
- Remit all L1 funds from the main compartment per the latest evacuation map.
- Clean up any remaining state on L1 that Gummiworm created for internal operations.
Finalization via Gummiworm’s consensus protocol is always preferable to evacuation via the rules-based regime because finalization pays out the L1 funds more cheaply, quickly, and efficiently than the equivalent rules-based evacuation.
If Cardano is the L1, see: finalization transaction (with diagram).
Settlement
Settlement is an immediate effect by which Gummiworm absorbs deposits, remits payouts, and supersedes the previous fallback effect.
Gummiworm’s max-deposits-absorbed-per-block parameter limits the number of deposits that the head peers can decide to absorb in a single block brief. This parameter’s value should be calibrated to ensure that the L1 blockchain’s transaction size limits do not prevent any settlement effects from being executed.
Gummiworm pays for settlement effects out of the equity compartment.
If Cardano is the L1, see: settlement transaction (with diagram).
Rollout
Rollout is an immediate effect that remits payouts by spending an aggregate payout. Rollout effects can support settlement and finalization by expanding the number of payouts the latter can remit beyond the limits imposed by the L1 blockchain on transactions.
In this way, a settlement/finalization effect can directly remit as many payouts as possible, and set up an aggregate payout in the exit compartment for subsequent remittance. A sequence of one or more rollouts can progressively remit more direct payouts from the aggregate payout.
Gummiworm pays for rollout effects out of the equity compartment.
If Cardano is the L1, see: rollout transaction (with diagram).
Evacuation commitment
An evacuation commitment is a contingent effect that binds Gummiworm to a particular evacuation map when it evacuates L1 funds in the rules-based regime. Evacuation commitments lay dormant; they remain unexecuted while none of the fallback effects have been executed.
The initialization effect contains an evacuation commitment binding Gummiworm to the evacuation map with which it was initialized. Similarly, every settlement effect includes an evacuation commitment, and every minor block contains a standalone evacuation commitment; these bind Gummiworm to their respective evacuation maps.
Each successive evacuation commitment supersedes its predecessor because it has a more up-to-date evacuation map. Furthermore, whenever a settlement effect is executed on L1, it invalidates all prior evacuation commitments, as their evacuation maps become inconsistent with Gummiworm’s L1 state and funds. Conversely, any subsequent evacuation commitments are valid only if the settlement effect is executed.
In other words, when a settlement effect absorbs deposits and remits payouts, it changes Gummiworm’s total balance of L1 funds, which invalidates the previous evacuation commitments because their evacuation maps are based on a different total balance of L1 funds. If the total L1 balance decreases, previous evacuation maps become insolvent. If the total L1 balance increases, previous evacuation maps become inadequate because they do not specify how to evacuate the excess L1 funds.
Gummiworm blocks’ version numbers help navigate these relationships between evacuation commitments:
- Evacuation commitments are compatible with Gummiworm’s L1 state if they share the same major version as the initialization or settlement effect that produced it.
- Among compatible evacuation commitments, each evacuation commitment supersedes those with a lower minor version.
Standalone evacuation commitment
For the initial and major blocks, the evacuation commitments are implicit in their initialization and settlement effects. However, for each minor block, the evacuation commitment is a standalone, fixed-size record with these fields:
- Head ID — uniquely set by initialization of the Gummiworm system.
- Block version.
- KZG commitment — a cryptographic KZG commitment to the minor block’s evacuation map.
When paired with the head and coil peers’ signatures from the minor block’s hard confirmation, this record can be presented to Gummiworm’s L1 dispute resolution scripts in the rules-based regime.
Fallback
Fallback is a deferred effect paired with initialization and every settlement effect. A fallback effect is executed if its paired effect is executed and no subsequent settlement or finalization effects are executed by a set deadline. In other words, Gummiworm’s consensus protocol sets a dead man’s trigger for fallback that is set on initialization, reset on settlement, and canceled on finalization.
When a fallback effect is executed, it transitions Gummiworm to the rules-based regime based on the L1 state produced by its paired effect. The transition sets up Gummiworm’s dispute resolution mechanism:
- Pay for this effect out of the fallback contingency compartment.
- Distribute the remaining equity to the head peers.
- Lock the main compartment’s L1 funds until the dispute is resolved.
- Set the major version to that of the fallback’s paired initialization or settlement effect.
- Set the voting deadline.
- Submit a default vote for the evacuation commitment contained in the paired effect.
- Set up exclusive ballot boxes for each head peer to submit one vote for a compatible evacuation commitment.
- Set up zero or more non-exclusive ballot boxes for the public to submit votes for compatible evacuation commitments. Equip each ballot box with a ratchet mechanism that requires each successive vote to be for an overriding compatible evacuation commitment.
Upon the voting deadline, discard the empty ballot boxes and select the evacuation commitment that supersedes all other voted-on commitments. Evacuate the main compartment’s L1 funds accordingly.
If Cardano is the L1, see: fallback transaction (with diagram).
If a Gummiworm system is started by head peers who intend to manage only their own funds without a supervising coil, then public ballot boxes are not needed for dispute resolution. In that case, the head peers can resolve the dispute before the voting deadline if they each submit a vote.
Once CIP-112 is available on mainnet, the fallback effect can be replaced by a Plutus guard script, eliminating the need for a pre-signed post-dated transaction. See CIP-112.
Refund
A refund is a deferred effect derived from a corresponding deposit request’s refund instructions. It can be executed if the deposit request’s registration is hard-confirmed and Gummiworm fails to absorb the deposit by the deadline specified in its refund instructions.
When a refund is executed, it returns the funds to the depositor at the address and datum specified in the deposit’s refund instructions.
If Cardano is the L1, see: refund transaction (with diagram).
Once CIP-112 is available on mainnet, refund effects can be replaced by a Plutus guard script, eliminating the need for pre-signed post-dated transactions and enabling faster recovery in some cases. See CIP-112.