Fast consensus & soft confirmation

In the fast consensus cycle, the head peers are laser-focused on deciding the total order and outcomes of newly received user requests. The result of this activity is a stream of block briefs unanimously multisigned by the head peers.

Users submit requests to head peers

Users submit requests directly to head peers. When a head peer receives a request from a user, she assigns it a request ID, which is a pair of non-negative integers:

1. The head peer’s number.
2. The request number at this head peer, which the peer increments every time that she assigns a request ID.

type HeadPeerNumber = NonNegativeInteger
type RequestNumber = NonNegativeInteger
 
type RequestId = [HeadPeerNumber, RequestNumber]

Upon assigning a request ID, the head peer broadcasts the request (with this ID) to the other head and coil peers.

Gummiworm’s communication protocol between head peers ensures that each head peer receives user requests from each of his counterparts in the order that the counterpart assigns request IDs. For example, if Bob has head peer number 1, Alice can receive a batch containing the consecutive requests [(1, 32), (1, 33), (1, 34)] from him only if she has already received all the requests from (1, 0) to (1, 31).

On the other hand, Alice cannot receive the request (1, 33) from Bob before receiving (1, 32).

Leader produces a block brief

The head peers take turns producing the block briefs, according to the leadership schedule.

If a head peer is assigned as the fast-consensus leader for the current block number, she begins her term upon verifying the previous leader’s block brief. She sets her block brief’s creation start time at this time.

During her term, the leader processes all previously received user requests that have not yet been mentioned by any block brief, in the order of arrival. She then continuously processes any newly received user requests, as they arrive.

She processes them by issuing corresponding commands to her local black-box L2 ledger in this order to determine their outcomes.

Normally, the leader ends her term when she learns that the previous block brief is soft-confirmed. However, if she hasn’t yet processed any user requests when this happens, she instead ends her term when the earliest of these occurs:

• The leader receives a new user request.
• The forced settlement timing rule triggers.

Block body

Upon ending her term, the leader fixes the block brief’s creation end time and constructs the block body:

• List the processed user requests in the order she processed them, indicating their successful/failing outcomes.
• Absorb all eligible deposits in priority order, up to Gummiworm’s max-deposits-absorbed-per-block parameter. Deposits are prioritized by the start time of their absorption periods, with ties broken by the total order of the deposit requests.
• Reject all ineligible deposits.
• Defer all other deposits for later block briefs.

Block header

The leader completes the block brief by constructing the block header:

• Include the Gummiworm head’s ID.

• Set the block type:

  • Final if one of the head peers requested it in the previous block brief’s soft-confirmation.
  • Major if the forced settlement timing rule triggered, a valid user request with immediate payouts was processed, or a deposit was absorbed.
  • Minor, otherwise.

• Increment the block number.

• Increment the block version according to the block type.

• Include the block brief creation start and end times that the leader fixed.

• Calculate and include the block body hash.

Prepare to follow

Upon completing the block brief, the leader performs these actions:

1. Issue an ApplyDepositDecisions command to the black-box L2 ledger with the absorbed and rejected deposits to determine their outcomes.

2. Cache the newly determined outcomes for later use in the slow-consensus cycle.

3. Broadcast the completed block brief and a soft acknowledgment to the other head and coil peers.

4. Become a follower.

Followers reproduce the block brief

Each follower begins by awaiting the leader’s block brief, passively caching any newly received user requests in a local mempool.

Upon receiving the leader’s block brief, he processes the user requests in the total order declared by the block brief, issuing corresponding commands to his black-box L2 ledger. He waits as necessary to receive the user requests declared by the block brief.

Upon processing all the user requests declared by the block brief, the follower verifies the block body:

• For each head peer, the requests listed must form a consecutive sequence beginning from the immediate successor of the last request from that peer mentioned in any previous block brief (or from request number 0 if no previous block brief has mentioned any request from that peer). No requests from any given peer may be skipped.
• All requests’ validity flags must match the validation results returned by the local black-box L2 ledger.
• All eligible deposits must be absorbed in priority order, up to Gummiworm’s max-deposits-absorbed-per-block parameter.
• All ineligible deposits must be rejected.

The follower verifies the block header by reconstructing it from the block body. If this succeeds, he performs these actions:

1. Issue an ApplyDepositDecisions command to the black-box L2 ledger with the absorbed and rejected deposits to determine their outcomes.

2. Cache the newly determined outcomes for later use in the slow-consensus cycle.

3. Broadcasts his soft acknowledgment of the block to the other head and coil peers.

4. Stay a follower or become the leader for the next block brief, based on the leadership schedule.

Soft acknowledgment

A head peer’s soft acknowledgement of a block brief is simply the head peer’s signature of the serialized block header.

Soft confirmation

Each head and coil peer considers a block brief to be soft-confirmed when he has collected soft acknowledgements of the block brief from all head peers.