EECS 262a
32K - views

EECS 262a

Similar presentations


Download Presentation

EECS 262a




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:

Slide1

EECS 262a Advanced Topics in Computer SystemsLecture 25Byzantine AgreementDecember 1st, 2014

John

Kubiatowicz

Electrical Engineering and Computer Sciences

University of California, Berkeley

http://www.eecs.berkeley.edu/~kubitron/cs262

Slide2

Today’s Papers

The Byzantine Generals Problem, Leslie

Lamport

, Robert

Shostak

, and Marshall Pease. Appears in

ACM Transactions on Programming Languages and Systems

(TOPLAS), Vol. 4, No. 3, July 1982,

pp

382-401

Practical

Byzantine Fault Tolerance

, M. Castro and B.

Liskov

. Appears In

Proceedings of the USENIX Symposium on Operating Systems Design and Implementation

(OSDI), 1999.

Thoughts?

Slide3

Motivation

Coping with failures in computer systems

Failed component sends conflicting information to different parts of system.

Agreement in the presence of faults.

P2P Networks?

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.

Slide4

Problem Definition

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.

Slide5

Recall: The

Path of an OceanStore Update

Slide6

Recall: Archival Dissemination of

Fragments

Slide7

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

quickly

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!

Slide8

Naïve solution

i

th

general sends v(

i

) to all other generals

To deal with two requirements:

All generals combine their information v(1), v(2), .., v(n) in the same way

Majority (v(1), v(2), …, v(n)), ignore minority traitors

Naïve solution does not work:

Traitors may send different values to different generals.

Loyal generals might get conflicting values from traitors

Requirement:

Any two loyal generals must use the same value of v(

i

) to decide on same plan of action.

Slide9

Reduction of General Problem

Insight:

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

IC1.

Original problem: each general sends his value v(

i

) by using the above solution, with other generals acting as lieutenants.

Slide10

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.

Slide11

General Impossibility

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!!

Slide12

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.

Assures:

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.

Slide13

Oral Messages (Cont)

Algorithm OM(0)

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

i

)

Each Lieutenant acts as commander for OM(m-1) and sends v

i

to the other n-2 lieutenants (or RETREAT)

For each

i

, and each

j ≠

i

, let

v

j

be the value lieutenant

i

receives from lieutenant j in step (2) using OM(m-1). Lieutenant

i

uses the value majority (v

1

, …, v

n-1

).

Why j ≠

i

? “Trust myself more than what others said I said.”

Slide14

Restate Algorithm

OM(M):

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.

Slide15

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

Slide16

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.

Slide17

Expensive Communication

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

O(n

m

) – Expensive!

Slide18

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

choice(…)

to obtain a single order

choice

(V) = v if v if the only elem. in V

choice

(V) = RETREAT if V is empty

Slide19

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

distinct

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

Slide20

Algorithm’s Intuition

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.

Slide21

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.

Slide22

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?

Slide23

BREAK

Slide24

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

client

server

replicas

attacker replaces

replica’s code

Slide25

BFT Tolerates Byzantine Faults

Byzantine fault tolerance: no assumptions about faulty behaviorTolerates successful attacksservice available when hacker controls replicas

client

server

replicas

attacker replaces

replica’s code

Slide26

Byzantine-Faulty Clients

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

server

replicas

attacker replaces

client’s code

Slide27

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

Slide28

Asynchrony

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

Slide29

Algorithm Properties

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

clients

replicas

Slide30

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

Algorithm

replicas

client

Slide31

Ordering Requests

Primary-Backup:View designates the primary replicaPrimary picks orderingBackups ensure primary behaves correctlycertify correct orderingtrigger view changes to replace faulty primary

view

replicas

client

primary

backups

Slide32

Rough Overview of Algorithm

A client sends a request for a service to the primary

replicas

client

primary

backups

Slide33

Rough Overview of Algorithm

A client sends a request for a service to the primaryThe primary mulicasts the request to the backups

replicas

client

primary

backups

Slide34

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

replicas

client

primary

backups

Slide35

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

view

replicas

client

primary

backups

f+1

matching

replies

Slide36

Quorums and Certificates

3f+1 replicas

quorums have at least 2f+1 replicas

quorum A

quorum B

quorums intersect in at least one correct replica

Certificate

=

set

with messages from a quorum

Algorithm steps are justified by certificates

Slide37

Algorithm Components

Normal case operationView changesGarbage collectionRecovery

All have to be designed to work together

Slide38

Normal Case Operation

Three phase algorithm:

pre-prepare

picks order of requests

prepare

ensures order within views

commit

ensures order across views

Replicas remember messages in log

Messages are authenticated

•

(k)

denotes

a message sent by k

Slide39

Pre-prepare Phase

request : m

assign sequence number n to request m in view v

primary = replica

0

replica

1

replica

2

replica

3

fail

multicast

<

PRE-

PREPARE

,v,n,m

>

(0)

backups accept pre-prepare if:

in view v

never accepted pre-prepare

for v,n with different request

Slide40

Prepare Phase

m

pre-prepare

prepare

replica

0

replica

1

replica

2

replica

3

fail

multicast

<

PREPARE

,v,n,

D

(m),1

>

(1)

digest of m

accepted

PRE-PREPARE

,v,n,m

0

all collect

pre-prepare and

2f

matching prepares

P-certificate(m,v,n)

Slide41

Order Within View

If it were false:

replicas

quorum for

P-certificate(m’,v,n)

quorum for

P-certificate(m,v,n)

one correct replica in common

m = m’

No

P-certificates

with the same view and sequence number and different requests

Slide42

Commit Phase

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)

m

pre-prepare

prepare

replica

0

replica

1

replica

2

replica

3

fail

commit

multicast

<

COMMIT

,v,n,

D

(m

),

2>

(2)

all collect

2f+1 matching commits

C-certificate(m,v,n)

replies

Slide43

View Changes

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

Slide44

View Change Protocol

replica

0 =

primary v

replica

1=

primary v+1

replica

2

replica 3

fail

send

P-certificates

:

<

VIEW-CHANGE

,v+1,

P

,2

>

(2)

primary collects

VC-messages in X

:

<

NEW-VIEW

,v+1,

X,O>

(1)

pre-prepares messages

for v+1 view in O with the same sequence number

backups multicast prepare messages for pre-prepares in O

2f VC messages

Slide45

View Change Safety

Intuition: if replica has C-certificate(m,v,n) then

any quorum Q

quorum for

C-certificate(m,v,n)

correct replica in Q has

P-certificate(m,v,n)

Goal: No

C-certificates

with the same sequence number and different requests

Slide46

BFS: A Byzantine-Fault-Tolerant NFS

No synchronous writes – stability through replication

andrew

benchmark

kernel NFS client

relay

replication

library

snfsd

replication

library

kernel VM

snfsd

replication

library

kernel VM

replica 0

replica n

Slide47

Andrew Benchmark

BFS-nr is exactly like BFS but without replication

30 times worse with digital signatures

Configuration

1 client, 4 replicas Alpha 21064, 133 MHz Ethernet 10 Mbit/s

Elapsed time (seconds)

Slide48

BFS is Practical

NFS is the Digital Unix NFS V2 implementation

Configuration

1 client, 4 replicas Alpha 21064, 133 MHz Ethernet 10 Mbit/s Andrew benchmark

Elapsed time (seconds)

Slide49

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?