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 FLP
 Addition of coin-flip to model
 Adversary

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.

Ben-Or’s Consensus Protocol
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.

Ben-Or’s Consensus Protocol
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.

Ben-Or’s Consensus Protocol
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
Ben-Or’s Consensus Protocol
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
Ben-Or’s Consensus Protocol

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).

Ben-Or’s Consensus Protocol

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.
Ben-Or’s Consensus Protocol

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 nonzero 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.
1
2n
Ben-Or’s Consensus Protocol
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).

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.

Chor-Israeil-Li Protocol
The model assumes that processors can
generate a random value and write the
new turn to shared memory in an atomic
operation. Chor-Israeil-Li Protocol
 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 = input
r=1
while true do
mark[p][r] = true
if mark[1-p][r+1] then
p’=1-p
else if mark[1-p][r] then
p’=SharedCoin(r)
else if mark [1-p][r-1] then
p’=p
else
return p
end
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.
Protocol’s Analysis
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.

Protocol’s Analysis
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 O  n 2 log n 
Uses shared registers, one for each process.
Each register contains a pair of (flips, ones).
Shared Coin Algorithm

Intuition
Cast 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.

Shared Coin Algorithm

Intuition
With 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.

Shared Coin Algorithm
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)
Shared Coin Algorithm
If total/ones >= ½ then
return 1
else
return 0
end
Shared Coin Algorithm
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.

Shared Coin Algorithm

Improved upon: Before hand, after each
vote the registers would be read. This
would bring the complexity to n^3.
Shared Coin Algorithm
Common votes: consist of all votes
generated before the sum of the r[p].total
fields exceeds n * n. Will be between
n * 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.

Shared Coin Algorithm
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)

Shared Coin Algorithm
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.

Shared Coin Algorithm

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.
