Slow consensus & hard confirmation

In the slow consensus cycle, the head and coil peers derive and hard-confirm the effects of whole block stacks at a time, so that the effects can be executed on the L1 blockchain. The head peers’ workload is lighter than the coil peers’ because they can reuse their cached results from fast consensus:

• Each head peer simply derives the effects for the block stack and broadcasts her hard acknowledgements to the other head and coil peers.
• Each coil peer verifies the stack’s block briefs (as followers do in fast consensus), derives the effects, and broadcasts his hard acknowledgments.

The result of this activity is a stream of multisigned effects, where the effects of each block stack are multisigned atomically.

Which blocks?

The head peers take turns defining the block stacks, according to the leadership schedule.

When a head peer is assigned as the slow-consensus leader for the current block stack, she waits for the previous block stack to be hard-confirmed, then broadcasts a new block stack referencing all the newly soft-confirmed block briefs.

Which effects are necessary?

Naively, the peers would derive and explicitly sign every effect of every block in the stack:

• The standalone evacuation commitment of every minor block.
• The settlement effect, fallback effect, rollout effects, and refund effects of every major block.
• The finalization effect and rollout effects of the final block (if any).

However, signing every standalone evacuation commitment is redundant, since many are superseded by just a few in the block stack. Therefore, peers can save significant effort by not deriving or signing the superseded standalone evacuation commitments.

For example, suppose that a block stack consists of 1,000 minor blocks. In that case, the last evacuation commitment supersedes the first 999, so the peers need only derive and sign that one.

As a more advanced example, suppose that a block stack consists of 500 minor blocks, followed by one major block, followed by 499 minor blocks. In this case:

• The 500th evacuation commitment supersedes the first 499.
• The 501st block’s settlement, fallback, and rollout effects must be signed.
• The 1000th block’s evacuation commitment supersedes those of the 502nd to 999th blocks.

Thus, the peers need only sign two of the 999 standalone evacuation commitments.

The general algorithm to select the necessary effects is as follows:

1. Partition the stack’s blocks by major block version.

2. For each partition:

   • Include all effects that are not standalone evacuation commitments.
   • Exclude all standalone evacuation commitments except the last one (if any).

Atomicity and signing order

If peers can arbitrarily cherry-pick which effects they sign in a block stack, it could lead to stranded funds on L1 or inconsistent confirmation of L2 state.

To illustrate this, suppose that a block stack consists of 100 minor blocks, then one major block, then 20 minor blocks, then two major blocks, then 50 minor blocks. As the previous section explains, the peers need only derive and sign these effects:

• The 100th block’s standalone evacuation commitment.
• The 101st block’s effects.
• The 121st block’s standalone evacuation commitment.
• The 122nd and 123rd blocks’ effects.
• The 173rd block’s standalone evacuation commitment.

A malicious coalition of peers could wreak havoc by withholding certain signatures:

• Withholding signatures for the 101st block’s fallback effect would strand the entire treasury if the 101st settlement is executed, but all subsequent settlement/finalization effects expire before execution.
• Withholding signatures for the 121st block’s standalone evacuation commitment would mean that, if the 101st block’s fallback effect is executed, then only the 101st block’s evacuation commitment could prevail during dispute resolution. Thus, the outcomes of the 102nd to 121st blocks’ requests would be ignored. It would be very disruptive and complicated to backtrack the consensus protocol to collect these missing signatures after the fact.
• Withholding signatures for the 122nd block’s rollout effects would strand the L1 funds that those rollouts were supposed to pay out.

How can the honest peers prevent these problems from occurring? The key observation is that withholding signatures for the 101st block’s settlement effect would prevent the execution of the rest of that block’s effects and all subsequent blocks’ effects. Therefore, the peers can wait to receive signatures for all those effects before broadcasting the signatures for that settlement effect.

What about the 100th block’s standalone evacuation commitment? If it’s the only effect to be signed in the whole block stack, then Gummiworm still benefits because the first 100 blocks’ request outcomes could be recognized in dispute resolution. This is equivalent to retroactively truncating the block stack past that evacuation commitment. The same logic extends to any of the first standalone evacuation commitments.

However, the peers should still wait to receive signatures for all the block stack’s necessary effects before moving on to the next block stack, as it would be needlessly complicated to accommodate such retroactive truncation.

Hard acknowledgments

Each peer broadcasts block-stack signatures as follows.

When the block stack contains a settlement or finalization effect, the peer:

1. Broadcasts the first acknowledgment of the block stack, containing signatures for all necessary effects except for the first settlement/finalization effect.
2. Waits to receive the first acknowledgments from all the head peers and a quorum of coil peers.
3. Broadcasts the second acknowledgment of the block stack, containing the signature for the first settlement/finalization effect.
4. Moves on to the next block stack.

Otherwise, the peer:

1. Broadcasts the sole acknowledgment of the block stack, containing the signature for the last evacuation commitment.
2. Waits to receive the sole acknowledgments from all the head peers and a quorum of coil peers.
3. Moves on to the next block stack.

Hard confirmation

Each head and coil peer considers a block stack to be hard-confirmed when he has collected all the hard acknowledgments for the block stack from all the head peers and a quorum of coil peers.