I will attempt to summarize my understanding of 3SF and list some references. This is in direct relation to our next step in the cohort which is to run, prove and verify a state transition function in lean consensus that implements 3SF. During October myself, Utsav and Unnawut will try to prove a state transition from slot 0 to slot 1 in Ream’s lean concensus. Then, we will try to gossip the proof and have it verified by another validator. Such early slots include few computations that will facilitate proof generation.

Introduction

Currently Ethereum’s Consensus finalizes blocks in 64 to 95 slots. 3SF offers faster finality at 3 slots in good network conditions and includes a vote per slot. In contrast, Single Slot Finality protocol requires 3 votes per slot. 3SF consists of two subprotocols: a finality protocol and a Dynamic Availability (DA) one. The reason is CAP theorem which states that’s impossible for a protocol to satisfy liveness under dynamic participation and safety under network partitions. To overcome this ebb-and-flow protocols were introduced, they consist of two subprotocols each one outputting its own chain. 3SF is an instance of ebb-and-flow protocol, it employs a finality gadget called FFG-component that is nearly the same as Casper and two options for the DA protocols:

  1. modified version of TOB-SVD
  2. RLMD-GHOST

Preliminary notions

This is a collection of definitions found in the papers of 3SF and SSF. It is the minimal set of notions necessary to understand how 3SF and its two subprotocols work. There are five types of messages that are cast by validators in the form of tuples. The first element of a message tuple contains its type: BLOCK, CHECKPOINT, VOTE, FFG-VOTE, PROPOSE.

Blocks

A block $B = (\text{BLOCK}, b, t, v_i)$ where $b$ is the block body, $t$ the slot that $B$ was proposed, $v_i$ the validator that proposed $B$.

Checkpoints

A checkpoint $\mathcal{C} = (\text{CHECKPOINT}, B, t)$, $t$ is the slot where $B$ was justified. As a consequence, $\mathcal{C}.t \geq B.t$

Votes

  1. An FFG vote $(\text{FFG-VOTE}, \mathcal{C}_1, \mathcal{C}_2, v_i)$ is vote cast by validator $v_i$ on the link between two checkpoints, the source $\mathcal{C}_1$ and the target $\mathcal{C}_2$. FFG votes very ofter are represented as $\mathcal{C}_1 \rightarrow \mathcal{C}_2$
  2. A vote $(\text{VOTE}, \textsf{ch}, \mathcal{C}_1 \rightarrow \mathcal{C}_2, t, v_i)$ is cast by validator $v_i$ at slot $t$. It contains an FFG-VOTE as well as the chain $\textsf{ch}$ that $\mathcal{C}_1$ and $\mathcal{C}_2$ belong.

A validator $v_i$ is not allowed to cast an equivocation vote, that is send from the same slot $t$ two votes $(\text{VOTE}, \textsf{ch}, \cdot, t, v_i), (\text{VOTE}, \textsf{ch}^\prime, \cdot, t, v_i)$ for two different chain $\mathsf{ch},\mathsf{ch}^\prime$. Here, specifying checkpoints in the two FFG votes is not useful for the particular argument, so $\cdot$ is used as a shorthand notation.

Proposals

Proposal message vary based on the DA protocol employed:

  1. TOB-SVD: $(\text{PROPOSE}, \textsf{ch}_p, \textsf{ch}^C, \textsf{Q}^C, \mathcal{C}, t, v_i)$ where $\textsf{ch}_p$ is the proposed chain, $\textsf{ch}^C$ is a fast confirmed chain and $\textsf{Q}^C$ is the associated certificate, $t$ is the slot that $v_i$ proposed the block and $\mathcal{C}$ is a checkpoint.
  2. RLMD-GHOST: $(\text{PROPOSE}, \textsf{ch}_p, \mathcal{V}, t, v_i)$ where $\textsf{ch}_p$ is the proposed chain, $t$ is the slot that $v_i$ proposed the block and $\mathcal{V}$ is the view of $v_i$.

Ordering of checkpoints

Ordering between two checkpoints $\mathcal{C}_1,\mathcal{C}_2$ is defined as $\mathcal{C}_1 \leq \mathcal{C}_2$ if

  1. $\mathcal{C}_1.t < \mathcal{C}_2.t$ or
  2. $\mathcal{C}_1.t = \mathcal{C}_2.t$ and $\mathcal{C}_1.ch.t \leq \mathcal{C}_2.ch.t$

Notice that $\mathcal{C}_1 \leq \mathcal{C}_2$ and $\mathcal{C}_2 \leq \mathcal{C}_1$ do not imply $\mathcal{C}_1 = \mathcal{C}_2$. In this context equality ``$=$” means that $\mathcal{C}_1, \mathcal{C}_2$ are identical as chains.

Confirmation

Confirmation rules ensure that the chain that is outputted by the DA or the FFG-component satisfy some safety properties. Each of the two subprotocols has its own confirmation rules. FFG-component has finality, DA has two options called $\kappa$-deep confirmation rule and fast-confirmation rule.

Justification

A checkpoint is justified if it receives a link with more than $2/3$ votes according to the view $\mathcal{V}$ from a previously justified checkpoint. The greatest justified checkpoint of view $\mathcal{V}$ using the lexicographic ordering is denoted as $\mathcal{GJ}(\mathcal{V})$.

Finalisation

A checkpoint $\mathcal{C}$ is finalized if it is justified and there exists a supermajority link ($\geq 2/3$ votes) with source $\mathcal{C}$ and target $\mathcal{C}^\prime$ with $\mathcal{C} = \mathcal{C}^\prime + 1$

What happens during a slot?

A slot in 3SF is split into 4 pieces of equal duration $\Delta$, where $\Delta$ is the network latency. Consider a slot $t$:

TOB-SVD

  1. At $4 \Delta t$ the proposer $v_p$ for slot $t$ proposes the block and gossips it.
  2. At $4 \Delta t + \Delta$ validators cast a VOTE that contains an FFG-vote: $\text{greatest justified checkpoint} \rightarrow \text{available chain } \textsf{chAva}_i$. Assuming that the available chain is proposed by an honest validator, it will be finalized at the end of slot $t+2$ if the following assumptions hold: the network operates under synchrony, $2/3$ of validators are honest and stay active until slot $t+2$.
  3. At $4 \Delta t + 2\Delta$ each validator runs fast confirmation algorithm which checks and updates their $\textsf{chAva}_i$ and $\textsf{chFin}_i$
  4. At $4 \Delta t + 3\Delta$ validators merge their view with that of the block proposer i.e. they update: their view, fast confirmed chain and greatest justified checkpoint.
  5. At $4 \Delta (t+1)$ a new slot begins.

RLMD-GHOST

  1. At $4 \Delta t$ the proposer $v_p$ for slot $t$ proposes the block and gossips it.
  2. At $4 \Delta t + \Delta$ validators cast a VOTE that contains an FFG-vote: $\text{greatest justified checkpoint} \rightarrow \text{available chain } \textsf{chAva}_i$. Here, the $\textsf{chAva}_i$ is chosen among more candidates compared to TOB-SVD. For additional details look at Algorithm 7 of 3SF paper. Assuming that the available chain is proposed by an honest validator, it will be finalized at the end of slot $t+2$ if the following assumptions hold: the network operates under synchrony, $2/3$ of validators are honest and stay active until slot $t+2$.
  3. At $4 \Delta t + 2\Delta$ each validator runs fast confirmation algorithm which checks and updates their $\textsf{chAva}_i$ and $\textsf{chFin}_i$
  4. At $4 \Delta t + 3\Delta$ validators merge their view with that of the block proposer i.e. they update their view.
  5. At $4 \Delta (t+1)$ a new slot begins.

3SF_slot

Next steps

We made the following decisions regarding the next steps of proving Ream’s lean consensus block execution in a zkVM. We will begin with risc0. Utsav will work on the block proving and I will work on gossiping the proof on gossipsub and verifying it.