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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing Zhao Outline Reminder:  Midterm #3, next Monday 4/25  4/27 no class (work on your project)  Project presentation (oral exam): 5/2, 5/4, 5/11  Final Project due: May 11 midnight Typed project report All source code Practical Byzantine fault tolerance  By Miguel Castro and Barbara Liskov, OSDI’99 

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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 YES ≥2f+1 replicas: enough for agreement P f faulty replicas

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing 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

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 12/25/2015 EEC688/788: Secure & Dependable Computing Wenbing Zhao