SSF wiki page

docs/wiki/research/SSF.md

@@ -0,0 +1,57 @@
+# Single slot finality (SSF)
+
+## Roadmap tracker
+
+| Upgrade |   URGE    | Track |          Topic           |                                               Cross-references                                               |
+| :-----: | :-------: | :---: | :----------------------: | :----------------------------------------------------------------------------------------------------------: |
+|   SSF   | the Merge |   -   | PoS upgrades, finality and security | intersection with: [MAX_EB](/docs/wiki/research/cl-upgrades.md), [ePBS](/docs/wiki/research/PBS/ePBS.md) |
+
+[Single Slot Finality](/docs/eps/week10-research.md) is a research concept of an improvement to Beacon Chain's consensus mechanism that addresses inefficiencies associated with the time it takes to finalize blocks. It's proposing a significant raise in blocks validation efficiency and a drastic reduction of time-to-finality.
+Instead of waiting for 2 epochs, blocks could get proposed and finalized in the same slot. The topic was also covered in (EPS week 10](https://github.com/eth-protocol-fellows/protocol-studies/blob/ssf/docs/eps/week10-research.md).
+
+## Context and Motivation
+Ethereum consensus layer implements Gasper protocol which includes Casper Friendly Finality Gadget. Casper FFG ensures that the network keeps producing blocks and accumulates validator attentions for each epoch. Finality is the ultimate state of PoS economic security and its change would require 2/3 of the validator set to be slashed. 
+Beacon Chain achieves finality every 2 epochs, or every 64 slots. With each slot being 12 seconds long, finalization takes around 12.8 minutes, at the moment of writing.
+This current time to finality has turned out to be too long for most users, and is inconvenient for apps and exchanges that might not want to wait that long to be certain their transactions are permanent. 
+The delay between a block's proposal and finalization also creates an opportunity for short reorgs that an attacker could use to censor certain blocks or extract MEV.
+
+## Benefits of SSF
+* More convenient for apps - transactions finalization time improved by an order of magnitude, i.e. 12 seconds instead of 12 minutes means better UX for all Ethereum users
+* Much more difficult to attack - multi block MEV re-orgs can be eliminated as it would only take 1 block for the chain to finalize instead of 64 blocks
+* The future consensus mechanism (in SSF scenario) would have a reduced complexity compared to current LMD-GHOST & Casper-FFG combination, which can lead to attacks (balancing attacks, withholding and savings attacks)
+
+## The fork-choice rule in SSF
+Today's consensus mechanism relies on the coupling[^1] between Casper-FFG (the algorithm that determines whether 2/3 of validators have attested to a certain chain) and the fork choice rule (LMD-GHOST is the algorithm that decides which chain is the correct one when there are multiple options). 
+The fork choice algorithm only considers blocks since the last finalized block. Under SSF there will not be any blocks for the fork choice rule to consider, because finality occurs in the same slot as the block is proposed. This means that under SSF **either** the fork choice algorithm **or** the finality gadget would be active at any time. 
+The finality gadget will finalize blocks where $2/3$ of validators were online and attesting honestly. If a block is not able to exceed the $2/3$ threshold, the fork choice rule would kick in to determine which chain to follow. This also creates an opportunity to maintain the inactivity leak mechanism that recovers a chain where $>1/3$ validators go offline. If a block is not able to exceed the $2/3$ threshold, the fork choice rule would kick in to determine which chain to follow.
+
+Some interaction issues between the fork choice and the consensus do remain in any such design, and it’s still important to work through them. 
+Short-term improvements to the existing fork choice (eg. view-merge) may also feed into work on the SSF fork choice.[^2]
+
+## What are the key questions we need to solve to implement single slot finality?
+Three open questions outlined by Vitalik[^4]: 
+
+* What will be the exact consensus algorithm?
+
+* What will be the aggregation strategy (for signatures)?
+
+* What will be the design for validator economics?
+
+## MAX_EB and Zipfian ETH distribution
+
+## References
+
+[^1]: Combining GHOST and Casper https://arxiv.org/pdf/2003.03052.pdf, [[archived]](https://arxiv.org/pdf/2003.03052.pdf)
+
+[^2]: SSF page on Ethereum.org https://ethereum.org/en/roadmap/single-slot-finality/#role-of-the-fork-choice-rule, [[archived]](https://web.archive.org/web/20240309234119/https://ethereum.org/en/roadmap/single-slot-finality/#role-of-the-fork-choice-rule)
+
+[^3]: EIP-7251: Increase the MAX_EFFECTIVE_BALANCE https://eips.ethereum.org/EIPS/eip-7251, [[archived]](https://web.archive.org/web/20240324072459/https://eips.ethereum.org/EIPS/eip-7251)
+
+[^4]: VB's SSF notes https://notes.ethereum.org/@vbuterin/single_slot_finality, [[archived]](https://web.archive.org/web/20240330010706/https://notes.ethereum.org/@vbuterin/single_slot_finality)
+
+[^5]: Sticking to 8192 signatures per slot post-SSF https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989. [[archived]](https://web.archive.org/web/20240105131126/https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989)
+
+[^6]: A simple Single Slot Finality protocol https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920, [[archived]](https://web.archive.org/web/20231214080806/https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920)
+
+[^7]: Notes on SSF Lincoln Murr https://publish.obsidian.md/single-slot-finality/Welcome+to+My+Research!,
+[[archived]](https://web.archive.org/save/https://publish.obsidian.md/single-slot-finality/Welcome+to+My+Research!)