eec 688/788 secure and dependable computing lecture 16 wenbing zhao department of electrical and...

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

[email protected]@ieee.org

22

04/18/2304/18/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



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



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



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



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



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



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



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




• 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



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



≤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




• 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




Confused Minority≤f non-faulty replicas



P

System StateIs it possible to continueprocessing requests?




YES ≥2f+1 replicas: enough for agreement

P

f faulty replicasf faulty replicas

1414








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



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



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



eec 688/788 secure and dependable computing lecture 16 wenbing zhao department of electrical and...

Documents