Single slot finality

https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735

Discoveries since 2017:

• BLS aggregation can decrease node overhead without sacrificing node count or TTF

Discoveries since 2017:

• Medium finality time has limited value. There's a lot of value in truly low (single-slot) finality time.

Discoveries since 2017:

• 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

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!