1 / 33

Byzantine Fault Tolerance

Byzantine Fault Tolerance. CS 425: Distributed Systems Fall 2011. Material drived from slides by I . Gupta and N .Vaidya. Reading List. L. Lamport , R. Shostak , M. Pease, “The Byzantine Generals Problem,” ACM ToPLaS 1982.

lynne
Download Presentation

Byzantine Fault Tolerance

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 CS 425: Distributed Systems Fall 2011 Material drivedfromslidesby I. Gupta andN.Vaidya

  2. Reading List • L. Lamport, R. Shostak, M. Pease, “The Byzantine Generals Problem,” ACM ToPLaS 1982. • M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” OSDI 1999.

  3. Byzantine Generals Problem A sender wants to send message to n-1other peers • Fault-free nodes must agree • Sender fault-free agree on its message • Up to ffailures

  4. Byzantine Generals Problem A sender wants to send message to n-1other peers • Fault-free nodes must agree • Sender fault-free agree on its message • Up to ffailures

  5. Byzantine Generals Algorithm value v S v v v 3 1 Faulty peer 2

  6. Byzantine Generals Algorithm value v S v v v 3 1 v v 2

  7. Byzantine Generals Algorithm value v S v v v 3 1 v v 2 ? ?

  8. Byzantine Generals Algorithm value v S v v v 3 1 v v 2 v ? ? v

  9. Byzantine Generals Algorithm value v S v v v 3 1 [v,v,?] v v 2 v ? [v,v,?] ? x

  10. Byzantine Generals Algorithm value v S v v v 3 1 v v v 2 Majority vote resultsin correctresult atgood peers v ? v ? x

  11. Byzantine Generals Algorithm S Faulty source v x w 3 1 2

  12. Byzantine Generals Algorithm S v x w 3 1 w w 2

  13. Byzantine Generals Algorithm S v x w 3 1 w w 2 x v v x

  14. Byzantine Generals Algorithm S v x w 3 1 [v,w,x] w w [v,w,x] 2 x v [v,w,x] v x

  15. Byzantine Generals Algorithm S v x w 3 1 [v,w,x] w w [v,w,x] 2 x v [v,w,x] Vote resultidentical atgood peers v x

  16. Known Results • Need 3f + 1 nodes to tolerate f failures • Need Ω(n2) messages in general

  17. Ω(n2) Message Complexity • Each message at least 1 bit • Ω(n2) bits “communication complexity” to agree on just 1 bit value

  18. Practical Byzantine Fault Tolerance • Computer systems provide crucial services • Computer systems fail • Crash-stop failure • Crash-recovery failure • Byzantine failure • Example: natural disaster, malicious attack, hardware failure, software bug, etc. • Need highly available service Replicate to increase availability

  19. Challenges Request A Request B Client Client

  20. Requirements • All replicas must handle same requestsdespite failure. • Replicas must handle requests in identical order despite failure.

  21. Challenges Client Client 1: Request A 2: Request B

  22. State Machine Replication Client Client How to assign sequence number to requests? 1: Request A 1: Request A 1: Request A 1: Request A 2: Request B 2: Request B 2: Request B 2: Request B

  23. Primary Backup Mechanism Client Client What if the primary is faulty? Agreeing on sequence number Agreeing on changing the primary (view change) 1: Request A 2: Request B View 0

  24. Normal Case Operation • Three phase algorithm: • PRE-PREPARE picks order of requests • PREPARE ensures order within views • COMMIT ensures order across views • Replicas remember messages in log • Messages are authenticated • {.}σk denotes a message sent by k

  25. Pre-prepare Phase Request: m Primary: Replica 0 {PRE-PREPARE, v, n, m}σ0 Replica 1 Replica 2 Replica 3 Fail

  26. Prepare Phase Request: m PRE-PREPARE Primary: Replica 0 Replica 1 Replica 2 Fail Replica 3 Accepted PRE-PREPARE

  27. Prepare Phase Request: m PRE-PREPARE Primary: Replica 0 {PREPARE, v, n, D(m), 1}σ1 Replica 1 Replica 2 Fail Replica 3 Accepted PRE-PREPARE

  28. Prepare Phase Request: m Collect PRE-PREPARE + 2f matching PREPARE PRE-PREPARE Primary: Replica 0 {PREPARE, v, n, D(m), 1}σ1 Replica 1 Replica 2 Fail Replica 3 Accepted PRE-PREPARE

  29. Commit Phase Request: m PRE-PREPARE PREPARE Primary: Replica 0 Replica 1 {COMMIT, v, n, D(m)}σ2 Replica 2 Fail Replica 3

  30. Commit Phase (2) Request: m Collect 2f+1 matching COMMIT: execute and reply PRE-PREPARE PREPARE COMMIT Primary: Replica 0 Replica 1 Replica 2 Fail Replica 3

  31. View Change • Provide liveness when primary fails • Timeouts trigger view changes • Select new primary (= view number mod 3f+1) • Brief protocol • Replicas send VIEW-CHANGE message along with the requests they prepared so far • New primary collects 2f+1 VIEW-CHANGE messages • Constructs information about committed requests in previous views

  32. View Change Safety • Goal: No two different committed request with same sequence number across views Quorum for Committed Certificate (m, v, n) View Change Quorum At least one correct replica has Prepared Certificate (m, v, n)

  33. Related Works

More Related