# Note on Single Slot Finality(SSF)

>:bulb: single slot finality is an active area of research and this article may obsolate at the time of reading. This is in reference with state of research as of 21nd Nov '24
>:warning: this article is being heavy edited. please check back when the warning is removed

### Pretext

To understand Single Slot Finality one must understand the rationale behind it. Currently Ethereum reaches finality on the beacon chain in about 65 to 95 slots about ~*15 minutes*. As one might notice that long of a delay introduces possiblity of reorgs in the system. While attacks like long range revision and castastrophic crashes is handled by the Gasper consensus protocol for PoS, but this does undermine the trust in honestly following the protocol due to greater incentivised MEV(Maximum Extractable Value) extraction through such reorgs.

taking notes from [Ben Edgington's eth2 book](https://eth2book.info/capella/part2/consensus/overview/).

In the above image it is evident that Gasper does a really good job of providing safety and liveness, but there's a small caveat: to this the longer the delay in finality, the more work nodes may have to perform applying LMD GHOST to find the beacon chain. However, with SSF or 3SF, as we further discuss, ambiguity is turned into lower forkfulness.

## Current tryst with finality

<!-- 
cc: v.buterin -->

Finality in Ethereum today is achieved using the casper FFG protocol. Here's a rather rudimentary explanation as to how Casper works: for Casper FFG to declare finality, it needs to process at least $2/3$ votes from the validator set. Now, one can clearly see the network and computational implication this brings if it were to be done per-slot basis. This is where the concept of epoch comes in handy, where $1/32$ validators are selected to cast their vote for the latest checkpoint(each validator votes exactly once in an epoch).

here's what a vote looks like that's gossiped over the network every slot

class AttestationData(Container):
    slot: Slot
    index: CommitteeIndex
    # LMD GHOST vote
    beacon_block_root: Root
    # FFG vote
    source: Checkpoint
    target: Checkpoint

For the sake of brevity FFG votes are combined with LMD GHOST votes. Casper FFG happens in a 2 phase commits fashion. First phase is justification consisting of disseminating the local view of validators and second phase involves the broadcasting the majority of the global view that the validator received during the justification phase.

The phases are pipelined, even though finality takes 12.8 minutes the network reaches finality on some $N-2$ checkpoint every epoch.

A good place to see finality in realtime [https://beaconcha.in/](https://beaconcha.in/)

For single slot finality to be implemented in Ethereum here are considered changes.

1. consensus protocol
2. validator set economics
3. signature aggregation

here we discuss various different proposals that have been published so far.

## Simple single slot finality

the security implicatiton in Gasper are neatly dicussed in the ethresear.ch post by fradamt et al.

Single Slot Finality proposal employees something called the RLMD GHOST and the same Casper FFG as finality gadget. RLMD(recent latest message delivered) where the protocol considers only latest messages from the recent slots.


RLMD can be looked at as a combination of both LMD and [Goldfish](https://arxiv.org/abs/2209.03255) by D'Amato et al. Using the latest message rule from LMD, view-merge and vote-expiry from goldfish. The protocol can be sumarised as

- Slots are divided into intervals of 4Δ seconds.
Each slot begins with a proposer (selected among validators) proposing a block.
- Validators merge their received messages with the proposer’s view and vote for a block after Δ seconds.
- Validators maintain:
- A buffer: Stores messages from other validators, protecting against attacks.
- A view: Admits only recent messages (from the last Δ seconds) to make consensus decisions.

Just like Data Avalability sampling is being slow rolled to Ethereum starting with PeerDAS and then moving forward towards FullDAS. SSF needs to be introduced as phase commits to the protocol. further we discuss the preliminary proposed changes introducing SSF.

## Orbit SSF

> this proposal requires [MaxEB EIP-7251](https://eips.ethereum.org/EIPS/eip-7251)

Orbit SSF aims to reach faster finality by selecting a smaller subset from the larger validator set and slowly rotating window on the subset selection hence the name orbit. This approach can roughly compared with mining pools in bitcoin. Everyone contributes stakes but work done is disproportionate the incentives are shared in a way that it is proportional to the compute provided(in case of PoS staked ETH).

The post on ethresear.ch by fradamt further discusses probabilistic equivalency to deterministic incentiviting for the same staked value.


## 3SF

3SF is a slightly modified version of the original SSF proposal. here are the modification

1. `FFG-vote`s are cast together with the `Head-vote`s at \DeltaΔ\Delta time into a slot, where \DeltaΔ\Delta represents the network latency.
2. Remove fast-confirmations.
Hence, the target of the `FFG-vote`s is the longest chain confirmed by the DA protocol. Under this condition, the DA protocol ensures that if the proposer is honest, all honest validators see the same chain as confirmed by the DA protocol.
3. No `Acknowledgment` votes.


## Resources

https://arxiv.org/pdf/2302.12745
https://ethresear.ch/t/3-slot-finality-ssf-is-not-about-single-slot/20927
[https://arxiv.org/pdf/1710.09437]
[https://arxiv.org/pdf/2209.03255]
https://ethresear.ch/t/streamlining-fast-finality/16591