Asynchronous Models For Consensus

Similar documents
CS505: Distributed Systems

AGREEMENT PROBLEMS (1) Agreement problems arise in many practical applications:

Distributed Consensus

Impossibility of Distributed Consensus with One Faulty Process

CS505: Distributed Systems

Fault-Tolerant Consensus

Section 6 Fault-Tolerant Consensus

Lower Bounds for Achieving Synchronous Early Stopping Consensus with Orderly Crash Failures

Simple Bivalency Proofs of the Lower Bounds in Synchronous Consensus Problems

Early stopping: the idea. TRB for benign failures. Early Stopping: The Protocol. Termination

Coordination. Failures and Consensus. Consensus. Consensus. Overview. Properties for Correct Consensus. Variant I: Consensus (C) P 1. v 1.

Implementing Uniform Reliable Broadcast with Binary Consensus in Systems with Fair-Lossy Links

C 1. Recap: Finger Table. CSE 486/586 Distributed Systems Consensus. One Reason: Impossibility of Consensus. Let s Consider This

Agreement Protocols. CS60002: Distributed Systems. Pallab Dasgupta Dept. of Computer Sc. & Engg., Indian Institute of Technology Kharagpur

Randomized Protocols for Asynchronous Consensus

Unreliable Failure Detectors for Reliable Distributed Systems

Valency Arguments CHAPTER7

Failure detectors Introduction CHAPTER

Distributed Systems Byzantine Agreement

Optimal Resilience Asynchronous Approximate Agreement

Eventually consistent failure detectors

Finally the Weakest Failure Detector for Non-Blocking Atomic Commit

Consensus and Universal Construction"

Consensus. Consensus problems

Consensus when failstop doesn't hold

Effectively Nonblocking Consensus Procedures Can Execute Forever a Constructive Version of FLP

Combining Shared Coin Algorithms

Reliable Broadcast for Broadcast Busses

Distributed Computing in Shared Memory and Networks

Early consensus in an asynchronous system with a weak failure detector*

I R I S A P U B L I C A T I O N I N T E R N E THE NOTION OF VETO NUMBER FOR DISTRIBUTED AGREEMENT PROBLEMS

Model Checking of Fault-Tolerant Distributed Algorithms

Byzantine Agreement in Polynomial Expected Time

Easy Consensus Algorithms for the Crash-Recovery Model

Byzantine Agreement. Gábor Mészáros. CEU Budapest, Hungary

On the weakest failure detector ever

A Realistic Look At Failure Detectors

Byzantine behavior also includes collusion, i.e., all byzantine nodes are being controlled by the same adversary.

Byzantine Agreement. Chapter Validity 190 CHAPTER 17. BYZANTINE AGREEMENT

THE chase for the weakest system model that allows

How to solve consensus in the smallest window of synchrony

Network Algorithms and Complexity (NTUA-MPLA) Reliable Broadcast. Aris Pagourtzis, Giorgos Panagiotakos, Dimitris Sakavalas

Simultaneous Consensus Tasks: A Tighter Characterization of Set-Consensus

arxiv: v2 [cs.dc] 18 Feb 2015

Failure detection and consensus in the crash-recovery model

Abstract. The paper considers the problem of implementing \Virtually. system. Virtually Synchronous Communication was rst introduced

Failure Detection and Consensus in the Crash-Recovery Model

ROBUST & SPECULATIVE BYZANTINE RANDOMIZED CONSENSUS WITH CONSTANT TIME COMPLEXITY IN NORMAL CONDITIONS

On the weakest failure detector ever

Atomic m-register operations

Byzantine Vector Consensus in Complete Graphs

Faster Agreement via a Spectral Method for Detecting Malicious Behavior

Towards optimal synchronous counting

Weakening Failure Detectors for k-set Agreement via the Partition Approach

The Weakest Failure Detector to Solve Mutual Exclusion

Approximation of δ-timeliness

Can an Operation Both Update the State and Return a Meaningful Value in the Asynchronous PRAM Model?

Information and Computation

The Heard-Of Model: Computing in Distributed Systems with Benign Failures

Byzantine Agreement. Gábor Mészáros. Tatracrypt 2012, July 2 4 Smolenice, Slovakia. CEU Budapest, Hungary

Benchmarking Model Checkers with Distributed Algorithms. Étienne Coulouma-Dupont

Optimal and Player-Replaceable Consensus with an Honest Majority Silvio Micali and Vinod Vaikuntanathan

On the Number of Synchronous Rounds Required for Byzantine Agreement

Crashed router. Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Pearson Education

Time Free Self-Stabilizing Local Failure Detection

Shared Memory vs Message Passing

Byzantine agreement with homonyms

6.852: Distributed Algorithms Fall, Class 10

Synchrony Weakened by Message Adversaries vs Asynchrony Restricted by Failure Detectors

CS505: Distributed Systems

THE WEAKEST FAILURE DETECTOR FOR SOLVING WAIT-FREE, EVENTUALLY BOUNDED-FAIR DINING PHILOSOPHERS. A Dissertation YANTAO SONG

6.852: Distributed Algorithms Fall, Class 25

On Stabilizing Departures in Overlay Networks

How can one get around FLP? Around FLP in 80 Slides. How can one get around FLP? Paxos. Weaken the problem. Constrain input values

DEXON Consensus Algorithm

Verification of clock synchronization algorithm (Original Welch-Lynch algorithm and adaptation to TTA)

Degradable Agreement in the Presence of. Byzantine Faults. Nitin H. Vaidya. Technical Report #

The Weighted Byzantine Agreement Problem

Communication-Efficient Randomized Consensus

Byzantine Agreement in Expected Polynomial Time

On Equilibria of Distributed Message-Passing Games

On the Minimal Synchronism Needed for Distributed Consensus

Do we have a quorum?

(Leader/Randomization/Signature)-free Byzantine Consensus for Consortium Blockchains

Eventual Leader Election with Weak Assumptions on Initial Knowledge, Communication Reliability, and Synchrony

FAIRNESS FOR DISTRIBUTED ALGORITHMS

arxiv:quant-ph/ v2 23 Feb 2006

Clocks in Asynchronous Systems

Tolerating Permanent and Transient Value Faults

The Weakest Failure Detector for Wait-Free Dining under Eventual Weak Exclusion

Early-Deciding Consensus is Expensive

Asynchronous Leasing

Decentralized Control of Discrete Event Systems with Bounded or Unbounded Delay Communication

LOWER BOUNDS FOR RANDOMIZED CONSENSUS UNDER A WEAK ADVERSARY

Dynamic Group Communication

Uniform consensus is harder than consensus

Time. Lakshmi Ganesh. (slides borrowed from Maya Haridasan, Michael George)

Genuine atomic multicast in asynchronous distributed systems

Round-by-Round Fault Detectors: Unifying Synchrony and Asynchrony. Eli Gafni. Computer Science Department U.S.A.

The Extended BG-Simulation and the Characterization of t-resiliency

Transcription:

Distributed Systems 600.437 Asynchronous Models for Consensus Department of Computer Science The Johns Hopkins University 1 Asynchronous Models For Consensus Lecture 5 Further reading: Distributed Algorithms Nancy Lynch, Morgan Kaufmann Publishers, 1996. [FLP85] Fischer, Lynch and Paterson. Impossibility of Distributed Consensus with One Faulty Process. Journal of the ACM, 32, pages 374-382. April 1985. 2

Distributed Consensus Problem 1- Consensus, synchronous settings, unreliable communication : impossible. 3 Distributed Consensus Problem 1- Consensus, synchronous settings, unreliable communication : impossible. Problem 2 - Consensus, asynchronous settings, unreliable communication : impossible (Problem 1 is a special case of Problem 2). 4

The Asynchronous Model Asynchronous setting. Complete network graph Reliable FIFO unicast communication. Deterministic processes, {0,1} initial values. Fail-stop failures of processes are possible. (remember that this is solvable in a synchronous setting). 5 Solution Requirements for Consensus Agreement: All correct processes decide on the same value. Validity: If a correct process decides on a value, then there was a process that started with that value. Termination: All processes that do not fail eventually decide. 6

Impossibility Result (FLP[85]) Definitions: - x-fair execution: executions in which all channels execute fairly, and all processes but at-most x execute fairly. - 0-RCP : (0-resilient consensus protocol) - a protocol that solves consensus in all 0-fair executions. - 1-RCP: a protocol that solves consensus in all 0-fair and 1-fair executions. 7 FLP[85] (Cont.) FLP: There is no 1-Resilient Consensus Protocol! Question1: Can you think of a 0-Resilient Consensus Protocol? Question2: what can be problematic if one of the processes may crash? 8

More Definitions... - A finite execution α is 0-valent if 0 is the only decision value in all extensions of α. - A finite execution α is 1-valent if 1 is the only decision value in all extensions of α. - α is bivalent if it is neither 0-valent nor 1-valent. Lemma 1: In any 1-Resilient Consensus Protocol there is a bivalent initial execution. 9 Proof of Lemma 1 If (i1, i2,..., in) = (0, 0,..., 0) => decision is 0. If (i1, i2,..., in) = (1, 1,..., 1) => decision is 1. Assume that each vector (i1, i2,..., in) is univalent. Look at: (0, 0,, 0, 0), (1, 0,, 0, 0), (1, 1, 0, 0),, (1, 1,,1, 0), (1, 1,, 1, 1). from all the above, there exists two starting vectors that are identical except for one entry of some processor p, where v0 is 0-valent and v1 is 1-valent. Kill p at the beginning to reach a contradiction. 10

A Decider A Decider for algorithm A consists of execution α of algorithm A and a process p such that: Execution α is bivalent. There exists 0-valent extension α0 of α such that the suffix after α consists of steps of p only. There exists 1-valent extension α1 of α such that the suffix after α consists of steps of p only. 11 Illustration of a decider - p may receive a message and then send a message or send a message and then receive a message. - Alternatively p may receive 2 messages at different orders bivalent α (only p moves) α0 α1 (only p moves) 0-valent 1-valent 12

Correctness of FLP Lemma 2: Let A be a 1-RCP with a bivalent initial execution. There exists a decider for A. -- FLP is correct if Lemmas 1 and 2 are correct: Why? Lemma 1: In any 1-RCP there is a bivalent initial execution. Together they mean that : in any 1-RCP there exists a decider. 13 Correctness of FLP (Cont.) -- FLP is correct if Lemmas 1 and 2 are correct: bivalent α α0 α2 α1 0-valent 1-valent α 2 Note: only p moves in α0, α1 p fail-stop after α assume (WLG) that q decides 0 q has to decide 0 if we delay p s messages and this is a contradiction. 14

Proof of Lemma 2 For 1-RCP, we can delay messages from one process and still expect termination. (!) Suppose that after α, a bivalent execution, the delivery of m to p yields a univalent execution. WLG assume it yields 0-valent. α m delivered (to p) somewhere there will be a --> 1 o-valent 15 Proof of Lemma 2 (cont.) To reach a 1-valent extension of α there are two possibilities: 1. m is not delivered before decision is reached. 2. m is delivered somewhere before decision is reached. In the first case, we deliver m after the decision is reached. (i.e. after reaching a 1-valent execution). 16

Proof of Lemma 2 (cont..) Case 1 Case 2 α 1-valent m delivered m delivered (to p) m delivered 0-valent m delivered 0-valent bivalent m delivered 1/0-valent 0/1-valent In case 2, pick m. This process of going down has to be finite because of termination. 17 α Proof of Lemma 2 (end) We stick the delivery of m after each step (look at Case 1) α m delivered (to p) m delivered 0-valent 0-valent 0-valent 1-valent 1-valent 1-valent This is a decider! There has to be a step which before it we have 0-valent and after 1-valent. This step has to be made by p. 18

So, What can be done??? We need to pay something in order to gain something else. What can we pay? (what can we gain?) 19 A Randomize Protocol for Consensus A complete network graph (clique) n - total number of processes. f - total number of faulty processes. Assumption: n > 5f. This algorithm solves a more complex problem where the failure model is Byzantine, i.e. the failed processes can send arbitrary messages to arbitrary processes (may lie), or may fail. 20

The protocol (Ben-Or variation) Round=0; x = initial value Do Forever: Round = Round + 1 Step 1 Step 2 Step 1: Send Proposal(Round,x) to all processes wait for n-f messages of type Proposal(Round,*) if at least n-2f messages have the same value v then x = v (that value) else x = undefined 21 The Protocol (cont.) Step 2: Send Bid(Round,x) to all processes wait for n-f messages of type Bid(Round,*) v is the real value (0/1) occurring most often and m is the number of occurrences of v if m >= 3f+1 then Decide (x=v) else if m >= f+1 then x = v else x = random (0 or 1) 22

Other Ways to Bypass The Impossibility Result To allow the protocol not to guarantee agreement. To allow the protocol not to always terminate at all correct members: The Transis membership can exclude live but slow processes from the membership, and will reach agreement among the connected members. 23