Async Reading Group on Consensus Protocols

[sa8]

We will use the discussion section in this repo to provide short summaries of consensus protocols that we read.
We will create a new discussion for each paper read and tag the "Journal Club" category.
We read these papers in the light of applying them to Filecoin's hierarchical consensus root protocol, i.e., top level. Informally the requirements that we look for when reading these papers are, by order of importance (in addition to the usual security properties considered by any consensus protocols):

• scaling to ten thousands nodes.
• censorship resistance. This specifically applies to WindowPosts that should be included in the chain 30 minutes after a sector is challenged on-chain.
• relatively low finality.
  • Ideally, checkpoints coming from subnets should be included in the chain within 5 minutes (this may however be too strong of a requirement).
  • It should not be feasible to rewrite the history of a length > PreCommitChallengeDelay (currently 150 blocks).
• fairness.
• simplicity.

List of papers

Priority

• Avalanche -> @xuechao2 reading
• Spacemesh -> @sa8 reading Summary

Already read (summary to appear)

• Algorand: Summary
• Colordag: Summary
• Order-Fair Consensus in the Permissionless Setting: Summary
• Ebb-and-Flow and its follow-ups: Summary
  • Checkpointed longest-chain
  • Accountability gadgets
• Parallel chain protocols: Summary
  • Prism
  • Ledger combiners
• Snow family of protocols: Summary
  • Snowball
  • Avalanche
  • Snowman (no full description available, only an video)
• Longest-chain protocols: Summary
  • PoSAT
  • Ouroboros Family

De-prioritized papers

• Hot-stuff -> not scalable enough
• ETH 2.0 -> many attacks vector (cf papers by Stanford)
  • Goldfish: Summary
• DAG-based protocols ->not scalable enough
  • Aleph
  • Multi-resource consensus?

[vukolic]

"Too long finality" is not in my opinion a sufficient, or perhaps detailed enough reason to dismiss longest chain protocols easily. How do we define exactly "too long finality"?

[sa8]

I've put it back in the list and I'll create another discussion for longest chain protocols where I'll add some numbers and we can discuss the different trade-offs from there!

[Amanuttam1192]

Maybe it can be be fully sufficient because the longest chain protocols may also have a time enimity that can also be incurred,maybe i am wrong,if please correct me

[sa8]

Hi @Amanuttam1192, I'm not sure I understand what you mean by "time enimity." Would you mind clarifying?

[Amanuttam1192]

I am sorry for the typo,by enimity i meant to write entity

[sa8]

No worries :). I agree that there is some sort of time entity with longest chain protocols, however there is still the issue of private attacks regardless. In the case of Filecoin this can be more problematic than in proof-of-stake due to some storage constraints.

[Amanuttam1192]

well i think that will solve my query

[sa8]

other suggestion from Akosh: Near protocol

[Amanuttam1192]

thanks a lot mam

[sa8]

Other suggestion: Internet Computer. Although I think there was some criticism about their protocol not being fully-open (to verify).

[Amanuttam1192]

ok ok

[sa8]

Suggestion from @guy-goren https://www.ndss-symposium.org/ndss-paper/bobtail-improved-blockchain-security-with-low-variance-mining/
Could be adapted for PoS and maybe tipsets.