EEC 688 Secure and Dependable Computing Lecture 16 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University

2 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Outline Reminder: –Midterm #3, May 4, Monday 4-5:50pm –Project presentation: May 6 4-5:50pm, attendance mandatory –Project report due: May 11 midnight Practical Byzantine fault tolerance –By Miguel Castro and Barbara Liskov, OSDI’99 –

3 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Commit Phase Replicas accept commit messages and insert them in their log provided signatures are same Define committed and committed-local predicates as –Committed (m, v, n) = true, iff prepared (m, v, n, i) is true for all i in some set of f+1 non- faulty replicas –Committed-local (m, v, n, i) = true iff the replica has accepted 2f+1 commit message from different replicas that match the pre- prepare for m If Committed-local (m,v,n,i) is true for some non- faulty replica i, then committed (m,v,n) is true

4 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Commit Phase Replica i executes the operation requested by m after committed-local (m, v, n, i) = true and i’s state reflects the sequential execution of all requests with lower sequence numbers The PRE-PREPARE and PREPARE phases of the protocol ensure agreement on the total order of requests within a view The PREPARE and COMMIT phases ensure total ordering across views

5 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Normal Operation Reply All replicas sends the reply, directly to the client v = current view number t = timestamp of the corresponding request i = replica number r = result of executing the requested operation c = client id Client waits for f+1 replies with valid signatures from different replicas, and with same t and r, before accepting the result r

6 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Normal Case Operation: Summery C Primary: Faulty: 3 Request Pre-prepare Prepare Commit Reply X

7 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

8 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao Garbage Collection When a replica i produces a checkpoint it multicasts a message 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

9 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

10 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao View Changes VIEW-CHANGE message is defined as 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

11 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao View Change - Primary Primary p of view v+1 receives 2f valid VIEW- CHANGE messages Multicasts a 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

12 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

13 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

14 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

15 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao System State: Faulty Primary Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas P System State Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas ≤2f replicas: NOT enough to change views Is Erroneous View Change Possible? P Confused Minority ≤f non-faulty replicas f faulty replicas

16 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

17 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao System State: Faulty Primary Confused Minority ≤f non-faulty replicas Agreed Majority ≥f+1 non-faulty replicas Adversary f non-faulty replicas P System State Is it possible to continue processing requests? 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 P f faulty replicas

18 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao System State: Faulty Primary Adversary f non-faulty replicas 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 Faulty replicas cease helping with agreement P P Confused Majority 2f+1 non-faulty replicas Enough to agree to change views Majority now large enough to independently move to a new view f faulty replicas

19 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

20 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao 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

21Exercises 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 Spring 2009EEC688: Secure & Dependable ComputingWenbing Zhao