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

2. EEC688/788: Secure & Dependable Computing
Outline
Practical Byzantine fault tolerance
Zyzzyva
12/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 2

3. 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/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 3

4. 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/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 4

5. 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 P
f faulty replicas
f faulty replicas
≤2f replicas: NOT enough to change views
12/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 5

6. 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
Can we have a confused majority while the remaining minority correct replicas keep working? No because they have no way to get 2f+1 matching messages to do anything
12/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 6

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

8. System State: Faulty Primary
Majority now large enough to
independently move to a new view
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
Confused Majority
2f+1 non-faulty replicas
Enough to agree to change views P
Adversary
f non-faulty replicas P
f faulty replicas
f faulty replicas
Faulty replicas cease helping with agreement
12/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao 8

9. EEC688/788: Secure & Dependable Computing
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/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao

10. EEC688/788: Secure & Dependable Computing
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
12/7/2018
EEC688/788: Secure & Dependable Computing
Wenbing Zhao

11. Zyzzyva: Speculative BFT
A replica speculatively executes a request as soon as it receives a valid pre-prepare msg
Commitment of a request is moved to the client
A request is said to have completed at the issuing client if the corresponding reply can be safely delivered
If a request completes at a client, the request will eventually be committed at the server replicas
Prepare and commit phases are reduced to a single phase
View change has one more additional phase

12. Zyzzyva: Speculative BFT
History hash: helps client determine if its request has been ordered appropriately
Server replica maintains a history hash for each request ordered and appends the history hash hs = H(hs-1,ds) to the reply for the request with sequence number s
ds: digest for the request
Previous hash: hs-1, new hash with request s executed: hs
H(): hash function
Prefix concept: h is is a prefix of hsj if sj > si, and there exist a set of requests with sequence numbers si+1, si+2, …, sj-1 with digests dsi+1, dsi+2,…,dsj-1 such that hsi+1=H(hsi, dsi+1), hsi+2 = H(hsi+1,dsi+2),…,hsj=H(hsj-1,dsj)

13. Zyzzyva: Speculative BFT
Safety: given any two requests that have completed, they must have been assigned two different sequence numbers. Furthermore, if the two sequence numbers are i and j and i < j, the history hash hi must be a prefix of hj
Liveness: if a nonfaulty client issues a request, the request eventually completes

14. Zyzzyva: Agreement Protocol
A client maintains a complete timer for each request
A request may complete at the client in one of two cases:
Case 1: client receives 3f+1 matching replies => all replicas have executed the request in the same total order
Case 2: client receives at least 2f+1 matching replies when timer expires. The client then initiates another round of msg exchange with the server replicas before the request is declared as complete

15. Zyzzyva: Agreement Protocol, Case 1

16. Zyzzyva: Agreement Protocol, Case 2

17. Zyzzyva: Case 2 Commit msg: contains a commit certificate:
A list of 2f+1 replica ids
Signed component of spec-response from each of the 2f+1 replicas
Local-commit: a replica sends a local-commit when it receives a valid commit msg from client
Verify history hash
When the client receives 2f+1 or more local-commit, the request is completed and can be delivered

18. Zyzzyva: View Change Protocol
When a view change is triggered
Sufficient number of backups timed out the current primary
When the client receives spec-response msgs with different sequence numbers or different history hash values
In the 2nd case, client broadcasts a POM msg to all replicas
Replica initiates a view change
A replica also rebroadcasts POM upon receiving one => to speed up view change

19. Zyzzyva: View Change Protocol
What is special in Zyzzyva
At most one round of msg exchange during normal operation for agreement => equivalent to prepare phase (or commit phase), for case 2. Replicas would have commit certificate
For case 1, replicas would not possess a commit certificate
Impact on view change:
Need an additional round msg exchange – “I hate the primary”
Need to change condition on including a request in new-view msg
Cannot use PBFT view change protocol: may lose liveness
Faulty primary could force f nonfaulty replicas to suspect itself, but cooperate with other f+1 nonfaulty replicas
f faulty replicas stops sending spec-response
Client cannot complete any request: only receive f+1 matching replies

20. Zyzzyva: View Change Protocol
PBFT view change
A replica abandons the current view as soon as it suspects the primary: stops participating agreement for current view
Zyzzyva view change
Make sure a view change will actually take place before abandoning the current view
Accomplished by using the “I hate primary” msg exchange: a replica abandons the current view only when it receives f+1 “I hate primary” msgs
If a replica receives f + 1 votes of no confidence in v’s primary, then it commits to a view change: It becomes silent, and multicasts to all replicas a VIEW-CHANGE message that contains a proof that f + 1 replicas have no confidence in the primary for view v. A correct replica that receives a valid VIEW-CHANGE message joins in the mutiny and commits to the view change.

21. Zyzzyva: View Change Protocol
Zyzzyva view change: deal with case 1
A replica includes all order-req msgs received since latest stable checkpoint, or the most recent commit certificate
New primary adopts request-seq# binding if f+1 or more matching order-req msgs
The primary may see multiple sets for same seq# (for different requests): can select any of the bindings because none of them could have been completed
A backup should accept the decision by the new primary for the ordering

22. Zyzzyva: View Change Protocol