# Single slot finality --- https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735  --- ### Discoveries since 2017: &nbsp; * **BLS aggregation** can decrease node overhead without sacrificing node count or TTF  --- ### Discoveries since 2017: &nbsp; * **Medium finality time has limited value**. There's a lot of value in truly low (single-slot) finality time. --- ### Discoveries since 2017: &nbsp; * **FFG + LMD GHOST hybrids are complex and prone to bugs**. There are security benefits to simplifying down to one (in the normal case)  --- Can we make Ethereum finalize in one slot? --- ## Let's do the math * 1 million validators (32M staked ETH) * Each one must vote *twice* per finality round (say, twice per 16s) * 1m * 2 / 16 = 125k signatures per second * With BLS aggregation, marginal cost of each signature is one ECADD (~500 ns) * Total verification time: 500ns * 125k = 62ms (plus some constant-time stuff) --- ### Tradeoff opportunity: super-committees  A 4M ETH-sized committee (only 125k validators) achieves ~1.3M ETH cost-of-attack --- ## Main bottleneck: aggregation &nbsp; Verifying huge BLS aggregates is easy. Aggregating them is hard. * Incrementally improve current approach, add more subnets * Multi-layer aggregation * Specialized aggregators ("PBS for aggregation") --- ## What would SSF look like?  * Still need BFT algo + fork choice hybrid * Under "normal conditions" (> ⅔ online) only the BFT algo runs * Any fork choice: LMD GHOST or other * The BFT algo can be more "conventional" --- ## BFT <-> fork choice interaction layer * Basic idea: the fork choice "suggests" what the BFT layer should finalize * Inactivity leak: if the BFT layer does not finalize for a long time, the validator balances change until it does * Some subtlety: need to finalize not just a block, but also * (i) how long it took to finalize the block * (ii) the growing non-finalized chain --- ## Other ideal goodies for a consensus algo * In a "51% censorship attack", censored validators should automatically coordinate on a chain that ignores censoring validators * Better treatment of entry/exit queues, partial deposits/withdrawals, variable balances... * Reduce incentives to join large pools as much as possible * Keep it simple!