Post on 04-Jan-2016
description
EEC 688/788EEC 688/788Secure and Dependable ComputingSecure and Dependable Computing
Lecture 16Lecture 16
Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering
Cleveland State UniversityCleveland State University
wenbing@ieee.orgwenbing@ieee.org
22
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
OutlineOutline• 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
33
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
Garbage CollectionGarbage 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
44
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
Garbage CollectionGarbage 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
55
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
View ChangesView 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
66
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
View ChangesView Changes
• VIEW-CHANGE message is defined as<VIEW-CHANGE, v+1, n, C, P, i> where, C = 2f + 1 checkpoint messagesP = set of sets PmPm = a PRE-PREPARE msg + all PREPARE messages
for all messages with committed = false
77
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
View Change - PrimaryView 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
88
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
View Changes - BackupsView 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
99
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
Events Before the View ChangeEvents 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
1010
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
Events Before the View ChangeEvents 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
1111
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
System State: Faulty PrimarySystem State: Faulty Primary
Confused Minority
≤f non-faulty replicas
Agreed Majority≥f+1 non-faulty replicas
Adversaryf non-faulty replicas
P
System State
Agreed Majority≥f+1 non-faulty replicas
Adversaryf 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
f faulty replicas
1212
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
Events Before the View ChangeEvents 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
1313
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
System State: Faulty PrimarySystem State: Faulty Primary
Confused Minority≤f non-faulty replicas
Agreed Majority≥f+1 non-faulty replicas
Adversaryf non-faulty replicas
P
System StateIs it possible to continueprocessing requests?
Confused Minority≤f non-faulty replicas
Agreed Majority≥f+1 non-faulty replicas
Adversaryf non-faulty replicas
YES ≥2f+1 replicas: enough for agreement
P
f faulty replicasf faulty replicas
1414
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
System State: Faulty PrimarySystem State: Faulty Primary
Adversaryf non-faulty replicas
Confused Minority≤f non-faulty replicas
Agreed Majority≥f+1 non-faulty replicas
Adversaryf non-faulty replicas
YES ≥2f+1 replicas: enough for agreement
Faulty replicas cease helping with agreement
PP
Confused Majority2f+1 non-faulty replicas
Enough to agree to change views
Majority now large enough to independently move to a new view
f faulty replicasf faulty replicas
1515
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
LivenessLiveness• 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
1616
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao
LivenessLiveness• 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
1717
ExercisesExercises
• 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
04/20/2304/20/23EEC688/788: Secure & Dependable EEC688/788: Secure & Dependable
ComputingComputing Wenbing ZhaoWenbing Zhao