consensus problem

Consensus problem

Agreement. All processes that decide choose the same value.

Termination. All non-faulty processes eventually decide.

Validity. The common output value is an input value of some process.

Randomized Algorithm

Development induced by FLPAddition of coin-flip to modelAdversary

Strong adversary – a function from partial executions to operations

Weak adversary – All sorts of

Randomized Consensus

Termination – for all adversaries, the protocol terminates with probability 1.

No change to Agreement & Validity.Violation in a final amount of steps has

probability > 0.

Ben-Or’s Consensus Protocol

First protocol to achieve consensus with probabilistic termination in a model with a strong adversary (1983).

Tolerates t < n/2 crash failures.Requires exponential expected time to

converge in the worst case.


Operates in rounds, each round has two phases.

Suggestion phase – each process transmits its value, and waits to hear from other processors.

Decision phase – if majority found, take its value. Otherwise, flip a coin.


If enough processes detected the majority, decide.

If someone detected a majority, switch to the majority’s value.

Terminates, because eventually, all processes will flip coins correctly.

Pitfall – don’t wait for all processes, because they might be dead.


preference = input

round = 1

while true do

send (1, round, preference) to all processes

wait to receive n – t (1, round, *) messages

if received more than n / 2 (1, round, v) messages then

send (2, round, v, ratify) to all processes

else

send (2, round, ?) to all processes

end

wait to receive n – t (2, round, *) messages


If received a (2, round, v, ratify) message then

preference = v

if received more than t (2, round, v, ratify) messages then

output = v

end

else

preference = CoinFilp()

end

round = round + 1

end // while true


Agreement: At most one value can receive majority in

the first stage of a round. If some process sees t + 1 (2, r, v, ratify),

then every process sees at lease one (2, r, v, ratify) message.

If every process sees a (2, r, v, ratify) message, every process votes for v in the first stage of r + 1 and decides v in second stage of r + 1 (if hasn’t decided before).


Validity: If all process vote for their common value v in round 1, then all processes send (2, v, 1, ratify) and decide on the second stage of round 1.


Termination: If no process decides in round r, then each process either chooses it’s value according to the majority, or flips a coin. There is a non-zero probability that all processes think the same at the end of the turn. Since the majority (if exists) must be the same, then eventually, all processes will choose the same value.


Termination: The probability of disagreement for an infinite time is 0. (It is equal to the probability that every turn there will be one 1 and one 0 forever).

Complexity: The chance of n coins to be all 1 (assuming a fair coin) is ½^n. Hence, the expected time of the protocol to converge is O(2^n).

1

2n

Wait-free Protocols

A protocol that tolerates up to n – 1 crash failures.

Wait-free message-passing protocols for all but trivial problems are impossible, as a process running in isolation cannot tell whether it is the sole survivor or simply the victim of a network partition.

Shared-memory Protocols

When a process fails, all the data in the shared memory survives.

Eliminates the possibility of partition.Reads / Writes are atomic operations.Consensus problem becomes a problem

of getting the shared memory into a state that unambiguously determines the selected value.

Chor-Israeil-Li Protocol

Each processor writes to a shared memory his turn and his value.

If there is a processor far enough ahead, take its value.

Flip a coin to choose if to advance a turn or not, with chance of 1 / 2n to advance.

Eventually, there will be a leader far enough ahead.


The model assumes that processors can generate a random value and write the new turn to shared memory in an atomic operation.

Strong adversary can break this protocol.


Where To Now?

It is possible to solve consensus with a strong adversary.

With techniques similar to Ben-Or’s algorithm we get exponential time complexity.

Solution: Weak shared coin.

Weak Shared Coin

For each value 0 or 1 there is a constant minimum probability ‘e’ that all processes agree on that value as the value of the shared coin.

Can be achieved in different ways.We’ll see a protocol that uses weak

shared coin to achieve consensus.

Weak Shared Coin

Execute weak shared coin repeatedly, in a framework that detects when all processors agree.

Since probability of success is constant (larger than 0), then the expectation of the round number before agreement is reached, is constant.

Overall complexity is dominated by weak shared coin’s complexity.

Consensus from a shared coin -Intuition

If all values are the same at some round, we’ll decide at the next round. This means that Validity is guaranteed.

Use some mechanism to try and get all processes to think of the same value.

Can’t wait for ALL processes, since this will compromise Termination.

Consensus from a shared coin

Processors “race” each other.“Leaders” are the farthest ahead

processors.If leaders agree on a value, that value

will be selected.If leaders disagree, use weak shared

coin for leaders.Eventually they’ll agree.

Wait-free consensus using shared memory

p = inputr = 1while true do

mark[p][r] = trueif mark[1-p][r+1] then

p’=1-pelse if mark[1-p][r] then

p’=SharedCoin(r)else if mark [1-p][r-1] then

p’=pelse

return pend

Wait-free consensus using shared memory

If mark[p][r+1] = false then

p=p’

end

r = r +1

end // while

Protocol’s Method

Processor registers that he reached turn r with preference p.

If it sees that the value 1-p was already reached in r+1, it knows it’s behind and switches value.

If it sees that the value 1-p is reached in the same turn as it is, it assumes it is tied, and flips a coin.

Protocol’s Method

If it sees that there is no one in r-1 that thinks 1-p, then it can be sure that everyone will be p in the end, and chooses p.

Lastly, the process checks if there is someone in r+1 that thinks the same, if so, it doesn’t change its preference.

Protocol’s Analysis

Agreement: if some process has decided p, then in r+1, r, r-1 there are no processes that think 1-p. Therefore, even if a process is going to write 1-p in r-1, it will discover p in r and change its value to that value. Therefore, if some process decides a value, all processes decide that value.


Validity: a process changes its value only if there is a process with that value.

Termination: if leaders agree, then everyone will agree with them. If they don’t agree, then after flipping a coin, they will agree with probability > 0.Note: Some leaders might miss the coin flipping (therefore they all agree), but probability of agreeing is still > 0.


Each round takes O(1) times O(SharedCoin()).

There is a constant amount of rounds, because probability of agreement ‘e’ is a constant > 0.

Therefore, complexity is dominated by SharedCoin’s complexity.

Constant probability as opposed to a function of n, gives us the improvement.

Shared Coin Algorithm

Must ensure a constant ‘e’ (so complexity analysis will depend only on shared coin’s complexity).

Best known algorithm is Bracha and Rachman’s 1991 voting protocol.

Complexity is Uses shared registers, one for each process. Each register contains a pair of (flips, ones).

2 logO n n


IntuitionCast together many votes.Each time, a processor casts only one vote,

and writes it down.Adversary can stop up to n – 1 votes form

being written.Require more than n * n votes altogether.


IntuitionWith probability, the n – 1 votes the

adversary can withhold, won’t effect the outcome of the total voting.

Pitfall – want to avoid situation when a single processor votes many times and the complexity grows. Solution: Vote in batches of n/logn. Another solution: weighted votes.


repeat

for i = 1 to n / log n do

c = CoinFlip()

r[p] = (r[p].flips + 1, r[p].ones + c)

end

read all registers r[p]

total = sum(r[p].flips)

until total > n * n

read all registers r[p]

total = sum(r[p].flips)

ones = sum(r[p].ones)


If total/ones >= ½ then

return 1

else

return 0

end


Complexity: Loop may run up to n * logn times (in case a single processor casts the entire votes).

Each loop requires reading n registers, hence, the entire cost in time complexity will be n * n * logn.


Improved upon: Before hand, after each vote the registers would be read. This would bring the complexity to n^3.


Common votes: consist of all votes generated before the sum of the r[p].total fields exceeds n * n. Will be betweenn * n + 1 and n * n + n.

Extra votes: for process P are those votes that are not part of the common votes and that are generated by some process Q before P reads r[Q] (again).Each process contributes at most n/logn.


Hidden votes: for P are those votes which were generated by some process Q but not written when P reads r[Q]. Each process Q can contribute at most one hidden vote for P.

P sees (common votes) + (extra votes for P) – (hidden votes for P)


Every one reads the common votes.The extra votes are different from

process to process, but won’t be more than n*n / logn.

The hidden votes are also different but won’t be more than n - 1.

Common and extra votes aren’t biased, since the adversary lets the processor run after the value is known.


The following can be shown:Probability of [net majority of 1 in n*n votes

is at least 3*n] is a constant p.Probability of [n*n/logn additional votes,

changing the net majority by more than 2*n] is bounded by 1/(n*n).

Therefore, even if multiplied by the number of processes, we get a probability of 1/n.

Thus, we have probability of p*(1-1/n) that the hidden votes won’t change the result.

consensus problem

Documents