1 / 17

EEC 688/788 Secure and Dependable Computing

EEC 688/788 Secure and Dependable Computing. Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org. Outline. Reminder: Midterm #3, November 30, Monday 2-3:50pm Project presentation:

isabelle-burton
Télécharger la présentation

EEC 688/788 Secure and Dependable Computing

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. EEC 688/788Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University wenbing@ieee.org

  2. Outline • Reminder: • Midterm #3, November 30, Monday 2-3:50pm • Project presentation: • December 9 2-5:50pm (?), attendance mandatory • Project report due: December 9 midnight • Practical Byzantine fault tolerance • By Miguel Castro and Barbara Liskov, OSDI’99 • http://www.pmg.csail.mit.edu/papers/osdi99.pdf EEC688/788: Secure & Dependable Computing

  3. Garbage Collection • Used to discard messages from the log • For the safety condition to hold, messages must be kept in a replica’s log until it knows that the requests have been executed by at least f+1 non-faulty replicas • Achieved using a checkpoint, which occur when a request with sequence number (n) is divisible by some constant is executed EEC688/788: Secure & Dependable Computing

  4. Garbage Collection • When a replica i produces a checkpoint it multicasts a message <CHECKPOINT, n, d, i> to other replicas • Each replica collects checkpoint messages in its log until it has 2f+1 of them for sequence number n with same digest d • This creates a stable checkpoint and the replica discards all the pre-prepare, prepare and commit messages EEC688/788: Secure & Dependable Computing

  5. View Changes • Triggered by timeouts that prevent backups from waiting indefinitely for request to execute • If the timer of backup expires in view v, the backup starts a view change to move to view v+1 by, • Not accepting messages (other than checkpoint, view-change, and new-view messages) • Multicasting a VIEW-CHANGE message EEC688/788: Secure & Dependable Computing

  6. View Changes • VIEW-CHANGE message is defined as <VIEW-CHANGE, v+1, n, C, P, i> where, C = 2f + 1 checkpoint messages P = set of sets Pm Pm = a PRE-PREPARE msg + all PREPARE messages for all messages with committed = false EEC688/788: Secure & Dependable Computing

  7. View Change - Primary • Primary p of view v+1 receives 2f valid VIEW-CHANGE messages • Multicasts a <NEW-VIEW, v+ 1, V, O> message to all other replicas where • V = set of 2f valid VIEW-CHANGE messages • O = set of reissued PRE-PREPARE messages • Moves to view v+1 EEC688/788: Secure & Dependable Computing

  8. View Changes - Backups • Accepts NEW-VIEW by checking V and O • Sends PREPARE messages for everything in O • These PREPARE messages carry view v+1 • Moves to view v+1 EEC688/788: Secure & Dependable Computing

  9. Events Before the View Change • Before the view change we have two groups of non-faulty replicas: the Confused minority and the Agreed majority • A non-faulty replica becomes Confused when it is kept by the faulty's from agreeing on a sequence number for a request • It can't process this request and so it will time out, causing the replica to vote for a new view EEC688/788: Secure & Dependable Computing

  10. Events Before the View Change • The minority Confused replicas send a VIEW-CHANGE message and drop off the network • The majority Agreed replicas continue working as long as the faulty's help with agreement • The two groups can go out of synch but the majority keeps working until the faulty's cease helping with agreement EEC688/788: Secure & Dependable Computing

  11. System State: Faulty Primary Is Erroneous View Change Possible? System State Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Confused Minority ≤f non-faulty replicas Adversary f non-faulty replicas P Adversary f non-faulty replicas f faulty replicas P f faulty replicas ≤2f replicas: NOT enough to change views EEC688/788: Secure & Dependable Computing

  12. Events Before the View Change • Given ≥f+1 non-faulty replicas that are trying to agree, the faulty replicas can either help that or hinder that • If they help, then agreement on request ordering is achieved and the clients get ≥f+1 matching replies for all requests with the faulty's help • If they hinder, then the ≥f+1 non-faulty's will time out and demand for a new view • When the new majority is in favor of a view change, we can proceed to the new view EEC688/788: Secure & Dependable Computing

  13. System State: Faulty Primary Is it possible to continue processing requests? System State Confused Minority ≤f non-faulty replicas Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas P Adversary f non-faulty replicas P f faulty replicas f faulty replicas YES ≥2f+1 replicas: enough for agreement EEC688/788: Secure & Dependable Computing

  14. Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas YES ≥2f+1 replicas: enough for agreement System State: Faulty Primary Majority now large enough to independently move to a new view Confused Majority 2f+1 non-faulty replicas Enough to agree to change views Adversary f non-faulty replicas P P f faulty replicas f faulty replicas Faulty replicas cease helping with agreement EEC688/788: Secure & Dependable Computing

  15. Liveness • Replicas must move to a new view if they are unable to execute a request • To avoid starting a view change too soon, a replica that multicasts a view-change message for view v+1, waits for 2f+1 view-change messages and then starts the timer T • If the timer T expires before receiving new-view message it starts the view change for view v+2 • The timer will wait 2T before starting a view-change from v+2 to v+3 EEC688/788: Secure & Dependable Computing

  16. Liveness • If a replica receives f+1 valid view-change messages from other replicas for views greater than its current view, it sends a view-change message for the smallest view in the set, even if T has not expired • Faulty replicas cannot cause a view-change by sending a view-change message since a view-change will happen only if at least f+1 replicas send view-change message • The above techniques guarantee liveness, unless message delays grow faster than the timeout period indefinitely EEC688/788: Secure & Dependable Computing

  17. Exercises • 1. Prove that the use of 3f+1 replicas to tolerate f Byzantine faulty replicas is optimal • 2. Prove the safety property of the BFT algorithm when all non-faulty replicas reach an agreement within the same view EEC688/788: Secure & Dependable Computing

More Related