[[A Simple Single Slot Finality Protocol Paper]] Protocol combining synchronous dynamically available protocol with a partially synchronous finality gadget - Consensus protocol that can finalize one block per slot, and it can be the block proposed in that slot # Intro - Proposes the aforementioned protocol - Expands generalized sleepy model to accommodate partially synchronous setting # System Model Main difference for *generalized partially synchronous $\tau$-sleepy model:* the requirement for the active validators to be more than the adversarial + all non-active validators who were honest and active in the past $\tau$ rounds is only required to be true after GST # Protocol Specification - 5 message types: PROPOSE, BLOCK, CHECKPOINT, HEAD-VOTE, FFG-VOTE - FFG component aims to finalize one block per slot by counting FFG-VOTES cast at a given slot - A set of 2n/3 distinct FFG votes $C_{1}\to C_{2}$ is a *supermajority link* between $C_{1}$ and $C_{2}$ - A checkpoint C is *justified* if there's a chain of k >= 0 supermajority links - Checkpoint justified in a view V if V contains the chain of supermajority links justifying it - The justified checkpoint with the highest slot in v is the *latest justified checkpoint in V*, LJ(V) - Checkpoint C is *finalized* if there exists a supermajority link $C\to C'$ with C'.t = C.t + 1 - Fork-choice respects latest justified block and then runs RLMD-GHOST - Head votes are cast every slot based on output of fork choice - FFG votes use the latest justified checkpoint as their source (source -> target) - Target block is highest confirmed descendant of the latest justified block ### Protocol Execution - Slot t begins at round 4$\Delta$t **PROPOSE:** - Proposer merges its view with its buffer - Runs fork choice, inputting its view and slot to get the head of the chain - Extends head with a new block and updates canonical chain - Broadcasts proposal **HEAD-VOTE:** Rounds \[4$\Delta$t, 4$\Delta$t+$\Delta$] - Validator, upon receiving proposal message, merges its view with proposed view - At 4$\Delta$t+$\Delta$, validator updates canonical chain by running fork choice and setting head of chain to the tip - Casts head-vote **CONFIRM:** Round 4$\Delta$t+2$\Delta$ - Validator selects, for fast confirmation: - Highest canonical block $B_{fast}$ in its live chain such that it has more than 2n/3 votes from slot t for descendants of $B_{fast}$ - Updates confirmed chain to highest between $B_{fast}$ and the k-deep prefix of its canonical chain, as long as we're not reverting anything **FFG-VOTE:** Round 4$\Delta$t+2$\Delta$ - After updating confirmed chain - Validator casts FFG vote - Source: latest justified block in its view - Target: the highest block in the available chain at slot t **MERGE** Round 4$\Delta$t+3$\Delta$ - Every validator merges its view with its buffer # Analysis - Works in generalized partially synchronous sleepy model - $\tau$-secure ebb-and-flow protocol *if we strengthen $\tau$-compliance to require less than $\frac{n}{3}$ validators are ever slashable for equivocation* - If you substitute HFC with [[RLMD-GHOST]], ignoring justifications, then the resulting protocol is equivalent to RLMD-GHOST with fast confirmation # Single Slot Finality That protocol is an $\eta$-secure ebb-and-flow protocol that, at best, finalizes a block in every slot, but doesn't finalize a proposal within its proposal slot At best, lags behind by one slot - Adding an extra voting phase is expensive - Increasing slot time and requires aggregation of millions of BLS signatures - Expensive in terms of bandwidth and computation - Introduce new message, *acknowledgment*, and a new slashing condition - Don't influence the protocol, except for slashing, and consumed by external observed that want the earliest finality guarantees - They don't need to be gossiped to and verified by all validators - Can be gossiped in sub-networks - Observer can get faster finality guarantees than what they could get by following the chain or listening to global gossip - Participate in sub-networks and collect acknowledgments - **Acknowledgment** is tuple \[ACK,C,t,v] - C is checkpoint - *Supermajority acknowledgement of C* is set of $\geq \frac{2n}{3}$ distinct acknowledgments of C - At round 4$\Delta$t+3$\Delta$, after merging buffer, validator broadcasts the acknowledgement \[ACK,$LJ_{i}$, t,$v_{i}$], if $LJ_{i}$ has been justified in the current slot - Anyone who receives a supermajority acknowledgment of a justified checkpoint C may consider C to be finalized **Slashing rule for finality voting** - By broadcasting an acknowledgment of (C,t), validator acknowledging that it knows about C being justified at the end of slot t - FFG voting rules say the source of an FFG vote should be latest justified checkpointing - Thus, later FFG votes with a source whose slot is < t constitute a provable violation - Create a slashing rule to ensure finality via supermajority acknowledgment is accountably safe - **HOW DO THE VALIDATORS WHO DON'T OPT INTO THESE MESSAGES SEE THIS? DO OTHER VALIDATORS GOSSIP THE MESSAGE TO EACH OTHER? HOW DO THEY FIT INTO THE IDEA OF A VALIDATOR'S VIEW, WHICH MAY BE MERGED?** - Appears that all validators issue acknowledgments. With that in mind, how is it any faster than another option? Do they acknowledge to a specific place or network that doesn't clog the rest of the gossip? - A node doesn't necessarily have to listen for other acknowledgements, it's just attesting that it'll never build with another block at that slot ### Future Work Requiring every validator to vote at each slot is not ideal Need to refine voting mechanism to better manage and aggregate messages involved in this process