Download Presentation - The PPT/PDF document "EECS 262a" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation on theme: "EECS 262a"— Presentation transcript:
ACM Transactions on Programming Languages and Systems
(TOPLAS), Vol. 4, No. 3, July 1982,
Byzantine Fault Tolerance
, M. Castro and B.
. Appears In
Proceedings of the USENIX Symposium on Operating Systems Design and Implementation
Coping with failures in computer systems
Failed component sends conflicting information to different parts of system.
Agreement in the presence of faults.
Good nodes have to “agree to do the same thing”.
Faulty nodes generate corrupted and misleading messages.
Non-malicious: Software bugs, hardware failures, power failures
Malicious reasons: Machine compromised.
Generals = Computer ComponentsThe abstract problem…Each division of Byzantine army is directed by its own general. There are n Generals, some of which are traitors.All armies are camped outside enemy castle, observing enemy.Communicate with each other by messengers.Requirements: G1: All loyal generals decide upon the same plan of actionG2: A small number of traitors cannot cause the loyal generals to adopt a bad planNote: We do not have to identify the traitors.
Path of an OceanStore Update
Recall: Archival Dissemination of
Differing Degrees of Responsibility
Inner-ring provides quality of service
Handles of live data and write access control
Focus utility resources on this vital service
Compromised servers must be detected
Byzantine Agreement important here!
Caching service can be provided by anyone
Data encrypted and self-verifying
Pay for service “Caching Kiosks”?
Archival Storage and Repair
Read-only data: easier to authenticate and repair
Tradeoff redundancy for responsiveness
Could be provided by different companies!
general sends v(
) to all other generals
To deal with two requirements:
All generals combine their information v(1), v(2), .., v(n) in the same way
Traitors may send different values to different generals.
Loyal generals might get conflicting values from traitors
Any two loyal generals must use the same value of v(
) to decide on same plan of action.
Reduction of General Problem
We can restrict ourselves to the problem of one general sending its order to others.
Byzantine Generals Problem (BGP):
A commanding general (commander) must send an order to his n-1 lieutenants.
Interactive Consistency Conditions:
IC1: All loyal lieutenants obey the same order.
IC2: If the commanding general is loyal, then every loyal lieutenant obeys the order he sends.
Note: If General is loyal, IC2
Original problem: each general sends his value v(
) by using the above solution, with other generals acting as lieutenants.
3-General Impossibly Example
3 generals, 1 traitor among them.Two messages: Attack or RetreatShaded – Traitor L1 sees (A,R). Who is the traitor? C or L2?Fig 1: L1 has to attack to satisfy IC2.Fig 2: L1 attacks, L2 retreats. IC1 violated.
In general, no solutions with fewer than 3m+1 generals can cope with m traitors.Proof by contradiction.Assume there is a solution for 3m Albanians with m traitors.Reduce to 3-General problem.
- Solution to 3m problem => Solution to 3-General problem!!
Solution I – Oral Messages
If there are 3m+1 generals, solution allows up to m traitors.
Oral messages – the sending of content is entirely under the control of sender.
Assumptions on oral messages:
A1 – Each message that is sent is delivered correctly.
A2 – The receiver of a message knows who sent it.
A3 – The absence of a message can be detected.
Traitors cannot interfere with communication as third party.
Traitors cannot send fake messages
Traitors cannot interfere by being silent.
Default order to “retreat” for silent traitor.
Oral Messages (Cont)
Commander send his value to every lieutenant.
Each lieutenant (L) use the value received from commander, or RETREAT if no value is received.
Algorithm OM(m), m>0
Commander sends his value to every Lieutenant (v
Each Lieutenant acts as commander for OM(m-1) and sends v
to the other n-2 lieutenants (or RETREAT)
, and each
be the value lieutenant
receives from lieutenant j in step (2) using OM(m-1). Lieutenant
uses the value majority (v
, …, v
Why j ≠
? “Trust myself more than what others said I said.”
Commander sends out command.
Each lieutenant acts as commander in OM(m-1). Sends out command to other lieutenants.
Use majority to compute value based on commands received by other lieutenants in OM(m-1)
Revisit Interactive Consistency goals:
IC1: All loyal lieutenants obey the same command.
IC2: If the commanding general is loyal, then every loyal lieutenant obeys the command he sends.
Example (n=4, m=1)
Algorithm OM(1): L3 is a traitor.
L1 and L2 both receive v,v,x. (IC1 is met.)
IC2 is met because L1 and L2 obeys C
Example (n=4, m=1)
Algorithm OM(1): Commander is a traitor. All lieutenants receive x,y,z. (IC1 is met). IC2 is irrelevant since commander is a traitor.
OM(m) invokes n-1 OM(m-1)
OM(m-1) invokes n-2 OM(m-2)
OM(m-2) invokes n-3 OM(m-3)
OM(m-k) will be called (n-1)…(n-k) times
) – Expensive!
Solution II: Signed messages
Previous algorithm allows a traitor to lie about the commander’s orders (command). We prevent that with signatures to simplify the problem.
By simplifying the problem, we can cope with any number of traitors as long as their maximum number (m) is known.
Additional Assumption A4:
A loyal general’s signature cannot be forged.
Anyone can verify authenticity of general’s signature.
Use a function
to obtain a single order
(V) = v if v if the only elem. in V
(V) = RETREAT if V is empty
Signed Messages (Cont)
Each lieutenant maintains a set V of properly signed orders received so far.
The commander sends a signed order to lieutenants
A lieutenant receives an order from someone (either from commander or other lieutenants),
Verifies authenticity and puts it in V.
If there are less than m
signatures on the order
Augments orders with signature
Relays messages to lieutenants who have not seen the order.
When lieutenant receives no new messages, and use choice(V) as the desired action.
If you want to protect against more traitors, increase m
All loyal lieutenants compute the same set of V eventually, thus choice(V) is the same (IC1)
If the commander is loyal, the algorithm works because all loyal lieutenants will have the properly signed orders by round 1 (IC2)What if the commander is not loyal?
V = “attack, retreat” => Commander is a traitor.
Missing Communication Paths
What if not all generals can reach all other generals directly?
P-regular graph – Each node has p regular neighbors.
3m-regular graph has minimum of 3m+1 nodes
Paper shows algorithm for variant of oral message algorithm – OM(m,p). Essentially same algorithm except that each lieutenant forwards orders to neighbors.
Proofs that OM(m,3m) solves BGP for at most m traitors.
I.e. if the communication graph is 3m-regular, and there are at most m traitors, the problem can still be solved.
Is this a good paper?
What were the authors’ goals?
What about the evaluation/metrics?
Did they convince you that this was a good system/approach?
Were there any red-flags?
What mistakes did they make?
Does the system/approach meet the “Test of Time” challenge?
How would you review this paper today?
Bad Assumption: Benign Faults
Traditional replication assumes:replicas fail by stopping or omitting stepsInvalid with malicious attacks:compromised replica may behave arbitrarilysingle fault may compromise servicedecreased resiliency to malicious attacks
BFT Tolerates Byzantine Faults
Byzantine fault tolerance: no assumptions about faulty behaviorTolerates successful attacksservice available when hacker controls replicas
Bad assumption: client faults are benignclients easier to compromise than replicas BFT tolerates Byzantine-faulty clients:access controlnarrow interfacesenforce invariantsSupport for complex service operations is important
Bad Assumption: Synchrony
Synchrony known bounds on:delays between stepsmessage delaysInvalid with denial-of-service attacks:bad replies due to increased delays Assumed by most Byzantine fault tolerance
No bounds on delaysProblem: replication is impossibleSolution in BFT:provide safety without synchronyguarantees no bad repliesassume eventual time bounds for livenessmay not reply with active denial-of-service attackwill reply when denial-of-service attack ends
Arbitrary replicated servicecomplex operations mutable shared stateProperties (safety and liveness):system behaves as correct centralized serviceclients eventually receive replies to requestsAssumptions:3f+1 replicas to tolerate f Byzantine faults (optimal)strong cryptographyonly for liveness: eventual time bounds
State machine replication:deterministic replicas start in same statereplicas execute same requests in same ordercorrect replicas produce identical repliesHard: ensure requests execute in same order
Primary-Backup:View designates the primary replicaPrimary picks orderingBackups ensure primary behaves correctlycertify correct orderingtrigger view changes to replace faulty primary
Rough Overview of Algorithm
A client sends a request for a service to the primary
Rough Overview of Algorithm
A client sends a request for a service to the primaryThe primary mulicasts the request to the backups
Rough Overview of Algorithm
A client sends a request for a service to the primaryThe primary mulicasts the request to the backupsReplicas execute request and sent a reply to the client
Rough Overview of Algorithm
A client sends a request for a service to the primaryThe primary mulicasts the request to the backupsReplicas execute request and sent a reply to the clientThe client waits for f+1 replies from different replicas with the same result; this is the result of the operation
Quorums and Certificates
quorums have at least 2f+1 replicas
quorums intersect in at least one correct replica
with messages from a quorum
Algorithm steps are justified by certificates
Normal case operationView changesGarbage collectionRecovery
All have to be designed to work together
Normal Case Operation
Three phase algorithm:
picks order of requests
ensures order within views
ensures order across views
Replicas remember messages in log
Messages are authenticated
a message sent by k
request : m
assign sequence number n to request m in view v
primary = replica
backups accept pre-prepare if:
in view v
never accepted pre-prepare
for v,n with different request
digest of m
Order Within View
If it were false:
one correct replica in common
m = m’
with the same view and sequence number and different requests
Request m executed after: having C-certificate(m,v,n) executing requests with sequence number less than n
replica has P-certificate(m,v,n)
2f+1 matching commits
Provide liveness when primary fails: timeouts trigger view changes select new primary ( view number mod 3f+1)But also need to: preserve safetyensure replicas are in the same view long enoughprevent denial-of-service attacks
View Change Protocol
VC-messages in X
for v+1 view in O with the same sequence number
backups multicast prepare messages for pre-prepares in O
2f VC messages
View Change Safety
Intuition: if replica has C-certificate(m,v,n) then
any quorum Q
correct replica in Q has
with the same sequence number and different requests
BFS: A Byzantine-Fault-Tolerant NFS
No synchronous writes – stability through replication
kernel NFS client
BFS-nr is exactly like BFS but without replication