1 / 91

Understanding Byzantine Fault Tolerance in Public Blockchains - A Comprehensive Overview

Explore the concepts of Byzantine Fault Tolerance, Permissionless Blockchains, Participant Consensus, Adaptive Adversaries, PBFT, HotStuff, and more in this in-depth analysis of decentralized systems.

bobbyd
Download Presentation

Understanding Byzantine Fault Tolerance in Public Blockchains - A Comprehensive Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Byzantine Fault-Tolerance CS1952 L Spring 2019 Maurice Herlihy Brown University

  2. Permissionless (or Public) Blockchains Anyone can participate Rewards & punishments up-front No central authority Partly a myth: Blocksize fork Version 0.7/0.8 fork $54M DAO theft Alice’s Cryptocoupons are permissionless

  3. Permissioned (or private) Blockchains Participants vetted Can penalize after-the-fact Governance easier because authority Alice’s temperature sensors are permissioned

  4. Consensus: Each Party has a Private Input

  5. They Communicate

  6. They Agree on One Party’s Input

  7. Crash Failures

  8. Crash Failures

  9. Byzantine Failures

  10. He said, She said … ???

  11. He said, She said … ???

  12. Identifying Input Values sorry f

  13. Identifying Input Values ! f+1

  14. Byzantine Model There are n validators

  15. Byzantine Model As many as f may be dishonest, where f < n/3 (or f < n/2 with sigs)

  16. Synchronous Model known 

  17. Asynchronous Model

  18. Semi-Synchronous known 

  19. Semi-Synchronous Global Stabilization Time (exactly when unknown)

  20. Adaptive Adversary Adaptively decides which f to corrupt and when to corrupt them Example: DoS attack There are many kinds of adaptive adversaries …

  21. Adaptive Adversary How quickly can the adversary corrupt? Same round, next round, polylog rounds .. Rushing adversary can corrupt honest party in round r but cannot suppress honest round-r messages Strongly rushing adversary can suppress honest round-r messages Example: DoS attack

  22. Static Adversary Corrupts validators at start of protocol Like a “mole” in a spy story Leader-based protocols assume static adversary (or adaptive with slow corruption time)

  23. Practical Byzantine Fault-Tolerance First practical Byzantine agreement protocol Many improvements, optimizations Precedes blockchain Semi-Synchronous model

  24. Before PBFT Byzantine fault-tolerancewill be super-important! You Theory losers disgust me, wasting your lives on BFT! Mainstream Systems Research Distributed Computing

  25. After PBFT You theory losers disgust me: we just invented this super-important BFT thing! Why didn’t you do that? Um, blockchains? Mainstream Systems Research Distributed Computing

  26. HotStuff “Best of breed” improvement on PBFT Less communication Semi-Synchronous model

  27. BFT vs PoW Well-understood Many protocols, research papers Proofs and open-source implementations Way faster than PoW Decisions are final

  28. BFT vs PoW Requires node identities Because Sybil attacks

  29. Structure Hello, I’m your leader Hello, I’m an honest validator Hello, I’m honest Hello, I’m honest I’m evil, LOL

  30. Jargon Watch Different papers, different terms, same thing “proposer” == “leader” “replica” == “validator” HotStuff sometimes inconsistent But these mean the exact same thing

  31. All messages signed by senders All signatures checked by receivers Omitted from protocols for brevity

  32. PoW vs BFT

  33. Block Party Each block eventually: block Committed, or Rejected Goal is agreement on … A growing chain of committed blocks

  34. Parent Pointers block block block block block Transitive closure forms ancestors

  35. Parent Pointers block block block block height k+1 height k

  36. Parent Pointers Same branch block block block block height k+1 height k

  37. Parent Pointers conflicting (different branches) block block block block height k+1 height k

  38. Validators Hello, I’m an honest validator I only vote only once per height … Always at increasing heights If I vote on B, then I have seen B’s ancestors

  39. Quorum Certificates whatever I vote for B! Form a quorum certificate (QC) for B If 2f+1 votes collected,

  40. Quorum Certificates QC | B QC | B’ QC | W’ QC | W QC | W’’ Each block’s QC is for ancestor

  41. QC Chains 1-chain: 2f+1 correct validators voted for B at B.height QC | B QC | B’

  42. 2-chain: 2f+1 correct validators voted for B’’ and received 1-chain B B’ QC Chains 1-chain: 2f+1 correct validators voted for B at B.height QC | B QC | B’ QC | B QC | B’ QC | B’’

  43. 2-chain: 2f+1 correct validators voted for B’’ and received 1-chain B B’ QC Chains 1-chain: 2f+1 correct validators voted for B at B.height 3-chain: 2f+1 correct validators voted for B’’’ and received 2-chain B  B’  B’’ QC | B QC | B’ QC | B QC | B’ QC | B’’ QC | B QC | B’ QC | B’’ QC | B’’’

  44. Committed Block QC | B QC | B’ QC | B’’ QC | B’’’ height k height k+1 height k+2 height ? B is committed if there is a 3-chain B  B’  B’’  B’’, where B parent of B’ parent of B’’

  45. Validators Hello, I’m an honest validator

  46. Validators And these are my blocks … QC | B QC | B’ QC | B’’

  47. Validators B’  B’’ is the highest 1-chain I’ve seen QC | B QC | B’ QC | B’’

  48. Validators So B is my preferred block QC | B QC | B’ QC | B’’

  49. Validators I will vote for Bnew only if it has my preferred block as ancestor QC | B QC | B’ QC | B’’ QC | Bnew

  50. Only Two Kinds of Message propose vote

More Related