80
Distributed Computing 8. Impossibility of consensus Shmuel Zaks [email protected] ©

Distributed Computing 8. Impossibility of consensus Shmuel Zaks [email protected] ©

Embed Size (px)

Citation preview

Page 1: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Distributed Computing 8. Impossibility of consensus

Shmuel [email protected]

©

Page 2: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

2

Consensus

Input: 1 or 0 to each processor

Output: Agreement: all procssors decide 0 or 1 Termination: all processors eventually decide Validity: if all inputs x , then decide x

Page 3: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

The result: No completely asynchronous

consensus protocol can tolerate even a single unannounced process death.

e.g., the stopping of a single process at inappropriate time can cause any distributed commit protocol to fail to reach agreement.

Page 4: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Motivation

This problem serves a role that is similar to the one served by “the halting problem” in computability theory.

Many problems equivalent to consensus (or reduce to it)

Page 5: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Protocols in the industry

How commit protocols in the industry dealwith this outcome ?Weaken an assumption. For example: Computation model: e.g., assume

bounded –delay network Fault model: e.g., assume faults only at

start.

Page 6: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

6

The Model

Message System Reliable

Delivers all messages correctly Exactly once

Processing Model Completely Asynchronous

No Assumptions about relative speeds

Unbounded time in delivering message

Page 7: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Weak Consensus

Every process starts with initial value in {0,1}

A nonfaulty process decides on a value in {0,1}by entering an appropriate decision state

All nonfaulty process that decide are required to choose the same value (note: termination not required)

Both 0 and 1 are possible decision values, although perhaps for different initial configurations.

(Trivial solutions – e.g., “0” - are ruled out)

7

Page 8: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

8

System Model

Communicate by means of one global message buffer

Atomic step Attempt to receive a message Perform local computation Send arbitrary but finite set of

messages

Page 9: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Consensus Protocol

N processes (N > 1) Each process has

xp – one-bit input register yp – output register with values in

{b,0,1} Unbounded amount of internal

storage PC – Program counter

9

Page 10: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

10

Consensus Protocol

N processes (N > 1)

process p

xp 0/1 yp 0/1/b memory

(unboundd)

PC

input register

output register

memory

Program counter

Page 11: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

11

Fixed starting valued at the memory (except the input register)

Output register starts with b The output register is “write once” when a value is written to the output

register, the process is “in a decision state”.

Process acts deterministically according to a Transition function

Page 12: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

12

Communication System

A message is a pair (p,m) p is the name of the destination m is a “message value”

message buffer Maintains messages that have been sent but

not yet delivered

We assume a clique topology

Page 13: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

13

two operations by a process : send (p,m) – place (p,m) in the message buffer

( “message (p,m) is sent to process p”)

receive (p)delete a message (p,m) from the message buffer and returns m ( “message (p,m) is received”)OR

returns (message buffer unchanged)

Page 14: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Message system nondeterministic.For fairness we will require in the proof: if receive(p) is performed infinitely many

times, then each message (p,m) in the message buffer is eventually delivered.

Now: the message system can return an infinite number of times in response to receive(p), even though a message (p,m) is in the message buffer .

Note: Assume a clique topology

Page 15: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

15

(P1,M)

Message Buffer

(P0,M’)

(P2,M’’)

(P1,M’’’)

Process 0 Process 2Process 1

receive(0) (P0,M’)

Page 16: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

16

(P1,M)

Message Buffer

Process 0 Process 2Process 1

receive(1)

(P2,M’’)

(P1,M’’’)

(P1,M’’’) send(2,m

)

(P2,m)

Page 17: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

17

Configurations

A configurations consists of Internal state of each process Contents of the message buffer

initial configuration each process p starts with xp=0 or xp=1 the message buffer is empty

Page 18: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

step – consists of a primitive step by a single process p. phase 1 – receive(p) is performed phase 2 – p enters a new internal

state and sends a finite set of messages

A step is completely determined by the pair e = (p,m), called an event.

18

Page 19: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

19

event e = (p,m) (“receipt of m by p”).

step of a single process p: receive(p) is performed ( p receives

m) p enters a new internal state p sends a finite set of messagesevent and step:

event: syntax

step: semantic

Page 20: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

20

Events and Schedules

e(C) – denotes the resulting configuration

(“e can be applied to C”) The event (p,) can always be applied A schedule from C is a finite/infinite

sequence of events that can be applied from C.

The associated sequence of steps is called a run.one: event - step

many: schedule - run

Page 21: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

21

If a schedule is finite, (C) denotes the resulting configuration C’, which is “reachable from C “.

C’ is accessible if it is reachable from an initial configuration.

Page 22: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

22

Lemma 1 (‘commutativity’)

Lemma 1 : Suppose that from some configuration C, the schedules 1,2 lead to configurations C1,C2 , respectively.

If the sets of processes taking steps in 1 and 2 , respectively, are disjoint, then 2 can be applied to C1 , and 1 can be applied to C2 , and both lead to the same

configuration C3 .

Page 23: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

23

C2

C0

C1

C3

1

1

2

2

when 1 and 2 contain a single event (p,m) event

Page 24: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

24

(P1,M1) (P2,M2)

(P2,M2) (P1,M1)

12

12

The message buffer of

C3

The message buffer of

C1

The message buffer of

C2

The message buffer of

C0

Message buffer

Page 25: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

25

P1Internal state - A

P2Internal state - X

P1Internal state - B

P2Internal state - Y

P1Internal state - B

P2Internal state - X

P1Internal state - A

P2Internal state - Y

1 2

12

All other processors – change unchanged

states

Page 26: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

26

C2

C0

C1

C3

1

1

2

2

when 1 and 2 contain a single event (p,m) event - ok when 1 and 2 contain any run – use induction

Page 27: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

27

A configuration C has a decision value v if some process p is in a decision state

with yp = v (v =0 or v=1).

A consensus protocol is partially correct if it satisfies two conditions:

1. No accessible configuration has more than one decision value.

2. For each v {0,1}, some accessible configuration has decision value v .

good news - it is non trivial

- sometimes it decides

- it never decides incorrectly

bad news

- termination not guaranteed

- what about delivering all messages?

- what about failures?

Page 28: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

28

A process p is nonfaulty in a run if it takes steps. It is faulty otherwise.

bad news: a process can be declared faulty only at

!! A run is admissible if - at most one process is faulty, and - all messages sent to non-faulty

processes are eventually received.

Page 29: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

29

A run is deciding if some process reaches a decision state.

A consensus protocol is totally correct in spite of one fault if it is: partially correct, and every admissible run is a deciding run.

Page 30: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

30

Theorem: No consensus protocol is totally

correct in spite of one fault.

Page 31: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

31

Sketch of Proof: Assume that P is totally correct in spite of one fault.

show an initial configuration from which each decision is still possible ( Lemma 2 )

show that from such a configuration one can always reach another similar configuration

( Lemma 3 ) conclude – by induction – with an

admissible run that never decides – a contradiction.

Page 32: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

32

Let C be a configuration and let V be the set of decision values of configurations reachable from C.

C is bivalent if |V| = 2 C is univalent if |V| = 1

if V = {0} then C is 0-valent if V = {1} then C is 1-valent(Note: |V|≠0, since P is totally correct)

Theorem: No consensus protocol is totally correct in spite of one

fault.Proof: Assume that P is totally correct in spite of one fault. We will reach a contradiction.

Page 33: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

33

0-valent configuration

From now on:

1-valent configuration

2-valent configuration

Unknown

Page 34: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

34

Proof:Assume there is no bivalent initial

configuration.But P is partially correct.So, there are both 0-valent and 1-valent initial configurations.

Lemma 2: P has a bivalent initial configuration.

Page 35: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

35

.

.

.

.

.

.

bivalent

configurationinitial configurationsC

Page 36: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

36

C0

.

.

.

.

.

.

0-valentconfiguration C1

initial configurations

1-valentconfiguration

Page 37: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

37

Two initial configurations are called adjacent if they differ only in the initial value of a single process.

0 1 0 1 1

0 1 0 1 0

x0 x1 x2 x3 x4

Page 38: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

38

Claim: There exist a 0-valent initial

configuration C0 adjacents to a 1-valent

initial configuration C1.

Page 39: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

39

0 1 0 1 1

1 1 0 1 1

1 1 0 1 0

1 1 0 0 0

1 0 0 0 0

x0 x1 x2 x3 x4

C0

C1

Proof by example:

0-valent

1-valent

Page 40: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

40

So: There exist a 0-valent initial

configuration C0 adjacents to a 1-valent

initial configuration C1.

Let p be the process in whose initial value they differ

Page 41: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

41

P is a consensus protocol that is totally correct in spite of one fault.

Consider an admissible deciding run (with schedule ) from C0 in which process p takes no steps.

can be applied to C1

The two corresponding configurations are identical, except for the internal state in p

Both runs reach the same decision x

Page 42: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

42

x = 1 C0 is bivalent

x = 0 C1 is bivalent

Contradiction.

C1C0

C’

C’’

Decision: x x

0-valent

1-valent

Lemma 2: P has a bivalent initial configuration.

So , we proved:

Page 43: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

43

Lemma 3:Let: C be a bivalent configuration of P, e = (p,m) be an event that is applicable to C.

S be the set of configurations reachable

from C without applying e, and D = e(S) = {e(E)| ES and e is applicable to

E}.

Then, D contains a bivalent configuration.

Page 44: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

44

E

e2e1e4

ei ≠ e

bivalent configuration

eee e

S

e

D=e(S)

e

e5 e6e7

C

Need to prove: D contains a bivalent configuration

Page 45: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

45

Note:e =(p,m) is applicable to Cso: message (p,m) is in the message

buffer,so: e is applicable to every ES.

Page 46: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

46

Prove by contradictionAssume that D contains no

D=e(S)

ei ≠ e

e ee e

S

ee

C 0-valent

1-valent

Page 47: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

47

Step 1:

Claim: D contains both and

0-valent

1-valent

So: every configuration d D is or

The proof has three steps.

Page 48: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

48

Se

D=e(S)

D0 D1

e

e=(p,m)

Step 1

Page 49: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

49

1.

2. i

i

case E S

case E S

Î

Ï

C is bivalent There exist Ei, , i=0,1, i-valent

configurations reachable from C.

ei ≠ e

e ee e

S

e

D=e(S)e

C

Page 50: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

50

Let F0 = e (E0 ) .

0 1. case E SÎ

E00

e2e1

e4

ei ≠ e

bivalent configurati

onF0

e ee e

S

e

D=e(S)

e

e5 e6

e7

C

0-valent

1-valent

so: D contains

Page 51: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

51

e was applied in reaching E0

so, either E0 is in D, or there exists

F0 D from which E0 is reachable.

0 2. ( 0)case E S iÏ =

e2e1e4

ei ≠ e

bivalent configurati

on

e ee e

S

e

D=e(S)

e

e5 e6

e7

F0

E0

C

0-valent

1-valent

so: D contains

Page 52: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

52

So: Fi is i-valent (not bivalent) One of Ei and Fi is reachable from the

other.

both and

So, we know that D contains

0-valent

1-valent

End of step 1Start of step 2

Page 53: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

53

Step 2Claim: There exist C0 , C1 S such that:

C0 and C1 are neighbors

( C1 = e’(C0 ), e’=(p’,m’) ) D0 = e(C0) is D1 = e(C1) is

(two configurations neighbors if one results from the other in a single step.)

0-valent

1-valent

Page 54: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

54

Se

D=e(S)

D0 D1

e’C1C0

e

e=(p,m)

e’=(p’,m’)

Step 2

Page 55: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

55

e(C) is or . Suppose it is .

There is in D.

It has predecessor in S.

e(C)

S

D=e(S)

e(C)

C

e

e

0-valent

1-valent

Page 56: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

56

Consider the path in S from C to

the predecessor of

e(C)

S

e

D=e(S)

e

e(C)

C

0-valent

1-valent

Page 57: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

57

Applying e to each configuration on this path, we get a configuration in D, which is or .

bivalent configurati

on

S

e

D=e(S)

e

e(C)

eee

C

e

Page 58: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

58

So we get two configurations C0 and C1 , that

are neighbors in S; i.e., there is e’ s.t.

Se

D=e(S)

e(C)D0 D1

e’C1

C0C

e

0 1

e'C C

Page 59: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

59

So, we proved the claim:

There exist C0 , C1 S such that: C0 and C1 are neighbors

( C1 = e’(C0 ), e’=(p’,m’) ) D0 = e(C0) is D1 = e(C1) is

End of step 2 Start of step 3

Page 60: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

60

D1 = e’(D0) by Lemma 1Case 1 : p’ ≠

pcontradiction

Se

D=e(S)

e(C)D0 D1

e’C1

C0C

e

e’

Step 3: get to a contradiction

Recall: e=(p,m)

Page 61: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

61

Se

D=e(S)

D0 D1

e’C1C0

e

e=(p,m)

e’=(p’,m’)

p’ p

Case 2 : p’ = p

recall:

Page 62: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

62

C1

C0

D0D1

A

Case 2 : p’ = p

e

- deciding run from C0 in which p takes no steps A = (C0)

deciding run

1-valent

0-valent

e

e’

e’

e e

E0

E1A is a deciding run. But it cannot be

and it cannot be . a contradiction !!!

Page 63: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

63

Lemma 3:Let: C be a bivalent configuration of P, e = (p,m) be an event that is applicable to C.

S be the set of configurations reachable

from C without applying e, and D = e(S) = {e(E)| ES and e is applicable to

E}.

Then, D contains a bivalent configuration.

Lemma 2: P has a bivalent initial configuration.

So, we proved:

Page 64: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

64

Any deciding run from a bivalent initial configuration goes to univalent configuration, so there must be some single step that goes from a bivalent to univalent configuration.We construct a run that avoids such a step:

bivalent configuration

bivalent configuration

deciding run

bivalent configuration

univalent configuration

end of proof:

Page 65: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

65

we construct an infinite non-deciding run

bivalent configuration

bivalent configuration

non-deciding run

bivalent configuration

……

Page 66: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

66

Start with a bivalent initial configuration( Lemma 2)

The run constructed in stages. Every stage starts with a bivalent configuration and ends with a bivalent configuration

A queue of processes, initially in arbitrary order

Message buffer is ordered according to the time messages were sent

Page 67: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

67

In each stage:

C is a bivalent configuration that the stage starts with.

Suppose that process p heads the queue

Suppose that m is the earliest message to p in the message buffer if any (or otherwise)

e = (p,m)

Page 68: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

68

By Lemma 3 there is a bivalent configuration C’ reachable from C by a schedule in which e is the last event.

After applying this schedule: move p to the back of the queue

Page 69: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Message Buffer

eeee

P3 P2 P1 P0

(P1,M) (P0,M) (P2,M) (P3,M)

P0 P3 P2 P1

(P1,M) (P2,M) (P3,M)

P1 P0 P3 P2

(P2,M) (P3,M)

P2 P1 P0 P3

(P3,M)

P3 P2 P1 P0

Page 70: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

70

in any infinite sequence of stages every process takes infinitely many steps

every process receives every message sent to it

Therefore, the constructed run is admissible

never reaches a univalent configuration The protocol never reaches a decision The protocol is not totally correct in

spite of one fault.contradiction

Page 71: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Conclusion

Theorem: No consensus protocol is totally correct

in spite of one fault. Proof Construct the run that was shown

before which is an admissible run which never reaches a univalent configuration

The protocol never reaches a decision The protocol is not totally correct in

spite of one fault.

Page 72: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

72

Conclusion

Theorem:

No consensus protocol is totally correct in spite of one fault.

hw: which process fails in the infinite run that was constructed for the proof?

Page 73: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Main lesson:In an asynchronous system, there is no

way to distinguish between a faulty process and a slow process.

Page 74: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

74

One importance lesson:In an asynchronous system, there is no

way to distinguish between a faulty process and a slow process.

Other tasks not solvable with one faulty processor:

Input graph – connectedOutput graph - disconnected

Many extensions and uses

Page 75: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Other tasks not solvable with one faulty processor:

Input graph – connectedOutput graph - disconnected

Page 76: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Extensions

1 fault t faults

Page 77: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Non-Asynchronous Models Synchronous

f+1 rounds if f failures Asynchronous plus eventual sychrony

eventual synchronized clocks eventual message delivery bound d Some communication links good Consensus terminates:

O((f+4)*d) after stabilization

Asynchronous Consensus

1 stop failure - impossible Initially crash failures - possible

Page 78: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Other Consensus Problems Weak Consensus k-set Consensus Approximate Consensus Byzantine failures What if some nodes lie?

(Non-Asynchronous Models)

• Synchronous model • f stopping failures, n nodes• 2f+1 ≤ n

Page 79: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

Failure Detectors Assume total asynchrony Assume failure detector service

Notifies node i when node j fails Eventually…

Allow solving consensus Weakest failure-detector? Leader-election failure-detector

(Non-Asynchronous Models)

Page 80: Distributed Computing 8. Impossibility of consensus Shmuel Zaks zaks@cs.technion.ac.il ©

References

M. Fischer, N. Lynch, M. Paterson,Impossibility of distributed consensus with

one faulty processor, 1985O. Biran, S. Moran and S. Zaks,A Combinatorial Characterization of the

Distributed Tasks Which Are Solvable in the Presence of One Faulty Processor,

J. of Algorithms, 1990.