1. 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.

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

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

8. 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

9. 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).

10. 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.

11. 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 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.

12. 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).

13. 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.

14. 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.

15. 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.

16. 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. Strong adversary can break this protocol. Chor-Israeil-Li Protocol

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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

23. Wait-free consensus using shared memory If mark[p][r+1] = false then p=p’ end r = r +1 end // while

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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).

30. 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.

31. 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.

32. 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)

33. Shared Coin Algorithm If total/ones >= ½ then return 1 else return 0 end

34. 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.

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

36. 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.

37. 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)

38. 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.

39. 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.