Blocks

It would be inefficient to gather the peers’ consent for each user request’s effects individually. Thus, Gummiworm’s peers consent to the effects of whole blocks of requests at a time.

Each block consists of a block brief and the effects derived from it.

Block briefs

Each block brief consists of a block header and a block body.

The block body is a data record of the head peers’ decision on:

• requests — the total order and validity of newly received user requests. Each request is identified by its request ID and the Blake2b-256 hash of its request header.
• depositsAbsorbed — deposits that the head peers have decided to absorb.
• depositsRejected — deposits that the head peers have decided to reject (i.e. to never absorb).

type BlockBody = {
  requests: [RequestId, ValidityFlag, Hash32 /* of UserRequestHeader */][],
  depositsAbsorbed: RequestId[],
  depositsRejected: RequestId[],
}
 
type ValidityFlag = boolean

The block header is a fixed-size metadata record about the decision:

• Head ID — uniquely set by initialization of the Gummiworm system.

• Block type — one of the four block types: initial, minor, major, final.

• Block number — the sequential number of this block brief, starting from zero for the initial block.

• Block version — a pair of non-negative integers starting from (0,0) for the initial block:

  • Major version — incremented by every major and final block.
  • Minor version — incremented by every minor block, reset to zero by every major and final block.

• Creation start time — when did the head peers start creating this block brief?

• Creation end time — when did the head peers finish creating this block brief?

• Block body hash — a hash of the block body.

Thus, the block header concisely summarizes the head peers’ decision, as detailed in the block body.

Block types

There are four types of blocks:

1. The initial block is the block with which Gummiworm starts up. It contains an initialization effect and a fallback effect. Its block body is empty.

2. A minor block is a block with which Gummiworm merely updates its evacuation map. It contains an evacuation commitment and zero or more refund effects. Its block body is restricted:

   • No absorbed deposits.
   • No user requests with outcomes requiring immediate payouts on L1.

3. A major block is a block with which Gummiworm absorbs deposits, remits immediate payouts, and supersedes the previous block’s fallback effect. It contains a settlement effect, a new fallback effect, zero or more rollout effects, and zero or more refund effects. Its block body is restricted:

   • No more absorbed deposits than Gummiworm’s max-deposits-absorbed-per-block parameter.

4. The final block is the block with which Gummiworm gracefully terminates when manually triggered by one of the head peers. It contains a finalization effect and zero or more rollout effects. Its block body is restricted:

   • No absorbed deposits.
   • No valid deposit requests.

Block stacks

A block stack is a sequence of blocks with consecutive block numbers, with these salient features:

• Block stack number — the sequential number of this block stack, starting from zero for the initial block stack, which only contains the initial block.
• The first block number in the stack.
• The last block number in the stack.
• The first major block’s number in the stack (if any).

In the fast-consensus cycle, the head peers soft-confirm block briefs, one at a time. In the slow-consensus cycle, the head and coil peers hard-confirm block effects, one block stack at a time.