Impossibility of Distributed Consensus with One Faulty Process By, Michael J.Fischer Nancy A. Lynch Michael S.Paterson.

Slides:



Advertisements
Similar presentations
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Advertisements

Distributed Snapshots: Determining Global States of Distributed Systems - K. Mani Chandy and Leslie Lamport.
Impossibility of Distributed Consensus with One Faulty Process
Impossibility of Consensus in Asynchronous Systems (FLP) Ali Ghodsi – UC Berkeley / KTH alig(at)cs.berkeley.edu.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Chapter 15 Basic Asynchronous Network Algorithms
6.852: Distributed Algorithms Spring, 2008 Class 7.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Announcements. Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical.
Distributed Algorithms – 2g1513 Lecture 10 – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 13: Impossibility of Consensus All slides © IG.
Computer Science 425 Distributed Systems CS 425 / ECE 428 Consensus
Consensus Hao Li.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Failure Detectors. Can we do anything in asynchronous systems? Reliable broadcast –Process j sends a message m to all processes in the system –Requirement:
Structure of Consensus 1 The Structure of Consensus Consensus touches upon the basic “topology” of distributed computations. We will use this topological.
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
Asynchronous Consensus
1 Fault-Tolerant Consensus. 2 Failures in Distributed Systems Link failure: A link fails and remains inactive; the network may get partitioned Crash:
Consensus Krzysztof Ostrowski
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 5: Synchronous Uniform.
Impossibility of Distributed Consensus with One Faulty Process Michael J. Fischer Nancy A. Lynch Michael S. Paterson Presented by: Oren D. Rubin.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 6: Impossibility.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 12: Impossibility.
Distributed Algorithms: Agreement Protocols. Problems of Agreement l A set of processes need to agree on a value (decision), after one or more processes.
Distributed Systems Tutorial 4 – Solving Consensus using Chandra-Toueg’s unreliable failure detector: A general Quorum-Based Approach.
On the Cost of Fault-Tolerant Consensus When There are no Faults Idit Keidar & Sergio Rajsbaum Appears in SIGACT News; MIT Tech. Report.
Message Passing Systems A Formal Model. The System Topology – network (connected undirected graph) Processors (nodes) Communication channels (edges) Algorithm.
Message Passing Systems A Formal Model. The System Topology – network (connected undirected graph) Processors (nodes) Communication channels (edges) Algorithm.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
1 A Modular Approach to Fault-Tolerant Broadcasts and Related Problems Author: Vassos Hadzilacos and Sam Toueg Distributed Systems: 526 U1580 Professor:
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Lecture 8-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) September 16, 2010 Lecture 8 The Consensus.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 11: Asynchronous Consensus 1.
For Distributed Algorithms 2014 Presentation by Ziv Ronen Based on “Impossibility of Distributed Consensus with One Faulty Process” By: Michael J. Fischer,
Consensus and Its Impossibility in Asynchronous Systems.
Computer Science 425 Distributed Systems (Fall 2009) Lecture 10 The Consensus Problem Part of Section 12.5 and Paper: “Impossibility of Distributed Consensus.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 8 Instructor: Haifeng YU.
1 Chapter 9 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2014 Synchronization Algorithms and Concurrent Programming Synchronization.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch Set 11: Asynchronous Consensus 1.
1 Consensus Hierarchy Part 1. 2 Consensus in Shared Memory Consider processors in shared memory: which try to solve the consensus problem.
CS294, Yelick Consensus revisited, p1 CS Consensus Revisited
Distributed systems Consensus Prof R. Guerraoui Distributed Programming Laboratory.
Sliding window protocol The sender continues the send action without receiving the acknowledgements of at most w messages (w > 0), w is called the window.
Chap 15. Agreement. Problem Processes need to agree on a single bit No link failures A process can fail by crashing (no malicious behavior) Messages take.
1 CS 525 Advanced Distributed Systems Spring Indranil Gupta (Indy) Lecture 6 Distributed Systems Fundamentals February 4, 2010 All Slides © IG.
Agreement in Distributed Systems n definition of agreement problems n impossibility of consensus with a single crash n solvable problems u consensus with.
Chapter 21 Asynchronous Network Computing with Process Failures By Sindhu Karthikeyan.
Alternating Bit Protocol S R ABP is a link layer protocol. Works on FIFO channels only. Guarantees reliable message delivery with a 1-bit sequence number.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
DISTRIBUTED ALGORITHMS Spring 2014 Prof. Jennifer Welch Set 9: Fault Tolerant Consensus 1.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 9 Instructor: Haifeng YU.
CSE 486/586 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
The consensus problem in distributed systems
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Lecture 16-A: Impossibility of Consensus
Cloud Computing Concepts
Alternating Bit Protocol
Distributed Consensus
FLP Impossibility & Weakest Failure Detector
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
FLP Impossibility of Consensus
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Distributed systems Consensus
CSE 486/586 Distributed Systems Consensus
Presentation transcript:

Impossibility of Distributed Consensus with One Faulty Process By, Michael J.Fischer Nancy A. Lynch Michael S.Paterson

What is Consensus Problem? Consensus is the task of getting all processes in a group to agree on some specific value based on the votes of each processes. All processes must agree upon the same value and it must be a value that was submitted by at least one of the processes Example: Leader Election Transaction Commit Problem in a Distributed Database Systems

All data Managers must agree for the Transaction to be committed. Can I commit? Yes!! No!!

Consensus Protocol In our problem we have, N processes where N ≥ 2. Each process p has – input variable x p (v) : initially value in {0,1} – output variable y p (d) : initially b (b=undecided).Decides 0 or 1 and its register is “Write-once” only. Faulty Process: A process is non-faulty in a run provided that it takes infinitely many steps, and it is faulty otherwise For a Consensus problem: Design a protocol so that either 1.all non-faulty processes set their output variables to 0 2.all non-faulty processes set their output variables to 1 3.There is at least one initial state that leads to each outcomes 1 and 2 above.

Assumptions Processing is completely asynchronous:  No assumptions are made about the relative speeds of processes.  Unknown delay time in message delivery.  No access to synchronized clocks (no time - outs).  No ability to detect the death of a process. Window Of Vulnerability: An interval of time during the execution in which the delay or inaccessibility of one process can cause the entire algorithm to wait indefinitely.

p Global Message Buffer send(p’,m) receive(p’) may return null Message System p’p’ Supports two basic operations: Send(p,m): Places (p,m) in the message buffer where p is the name of Destination process and m its message to be sent. Receive(p):Deletes message (p,m) from buffer and returns m.

Terminology... Configuration – Consists of internal state of each process, together with the contents of the message buffer. – Initial configuration: A configuration in which each process starts at an initial state and the message buffer is empty. – A step takes one configuration to another Event: (on process p) e = (p,m) : In an atomic step, – Message m delivered to p. – Triggers state transition in p. – Finite number of message sent by p e(C): resulting configuration on applying event e on configuration C:

Schedule (run): finite/infinite sequence of events that can be applied on a configuration C 0. – The associated sequence of steps is called a run. – S = e 1 e 2 e 3 … e i … Reachable configuration: If a finite sequence of events take a configuration say C1 to C3, we say C3 is reachable from C1. If a configuration is reachable from the initial state C0, is said to be accessible. C0C0 C1C1 C2C2 CiCi e1e3 e2 e i+1 eiei … Terminology...

C C’C’ C’’ Event e’=(p’,m’) Event e’’=(p’’,m’’) Configuration C Schedule s=(e’,e’’) C C’’ Equivalent Schedule and Event

Terminology... Admissible run: a run with one faulty member at most and all messages to non-faulty members will be delivered eventually. Deciding run: some process reaches a decision states during the run i.e. a process sets its decision value (to either 0 or 1). Partially correct protocol: – All accessible configuration don’t have more than one decision value – There exists two accessible configurations G and H such that their decision values are {0} and {1} correspondingly Totally correct protocol: – Partially correct. – Every admissible run is a deciding run.

Valency Definition Let configuration C have a set of decision values V reachable from it – C is called bivalent if |V| = 2 – C is called univalent if |V| = 1; i.e., configuration C is said to be either 0-valent or 1-valent Bivalent means outcome is unpredictable A 0-valent configuration is followed by a 0-valent configuration A 1-valent configuration is followed by a 1-valent configuration

Lemma 1: Suppose that from some configuration C, the schedules s 1,s 2 lead to configuration C 1,C 2 respectively and if s 1 and s 2 are disjoint, then s 2 can be applied to C 1 and s 1 can be applied to C 2, and both lead to the same configuration C 3.

Lemma 1(show properties about events, schedules, configurations) C C1 C3 Schedule s1 s2 C2 Schedule s2 s1 Schedules are commutative Events are also commutative

Main Theorem No completely asynchronous consensus protocol is totally correct in spite of one fault.

Proof Sketch Messages Delivered Initial Undecided Configuration (Bivalent) More Messages Delivered Undecided State (Bivalent) Lemma 2: This always Exists Lemma 2: This always Exists Lemma 3: You can always get here Lemma 3: You can always get here

What we will show 1.There exists an initial configuration that is bivalent (Lemma 2) 2.Starting from a bivalent configuration, there is always another bivalent configuration that is reachable (Lemma 3)

Lemma 2 Some initial configuration is bivalent Proof: By Contradiction Suppose all initial configurations were predetermined either 0-valent or 1-valent. Place all initial configurations side-by-side, where adjacent configurations differ in initial x p value for exactly one process Definition: Two initial configurations are adjacent if they differ in the init value x p of a single process p. There has to be some adjacent pair of 1-valent and 0-valent configurations

Lemma 2 Some initial configuration is bivalent There has to be some adjacent pair of 1-valent (C1) and 0-valent (C0) configurations Let the process p be the one with a different state across these two configurations C0 and C1. Now consider the world where process p has crashed Both these initial configurations are indistinguishable. But one gives a 0 decision value. The other gives a 1 decision value. So, both these initial configurations are bivalent when there is a failure p

What we will show 1.There exists an initial configuration that is bivalent (Lemma 2) 2.Starting from a bivalent configuration, there is always another bivalent configuration that is reachable

Lemma 3 Starting from a bivalent configuration, there is always another bivalent configuration that is reachable

Lemma 3 A bivalent initial configuration Let e=(p,m) be an applicable event to the initial configuration Let C be the set of configurations reachable without applying e C X

Lemma 3 A bivalent initial configuration Let e=(p,m) be an applicable event to the initial configuration Let C be the set of configurations, reachable without applying e C0 C1 D0D1 e e e e e Let D be the set of configurations obtained by applying single event e to a configuration in C C D X

Claim. Set D contains a bivalent configuration Proof. By contradiction. suppose D has only 0- and 1- valent states (and no bivalent ones) There are states D0 and D1 in D, and C0 and C1 in C such that – D0 is 0-valent, D1 is 1-valent – D0=e(C0 ) followed by e=(p,m) – D1=e(C1) followed by e=(p,m) – And C0 and C1 are neighbors and hence C1 = e’(C0) followed by some event e’=(p’,m’) D C C0 C1 D0D1 e e e e e bivalent [don’t apply event e=(p,m)] Lemma 3 ’ e’

Proof. (contd.) Case I: p’ is not p e = (p, m) e’e’ e’ = (p’, m’) From C1 follows D1 is 1- valent From Lemma 1 follows D1 = e’(D0), successor of 0-valent configuration is 0- valent hence contradiction D contains a bivalent configuration Lemma 3 p’p’ p C0 D0 D1 C1

Proof. (contd.) Case II: p’ same as p Let A be a deciding run from Co D C e e e e e bivalent C0 D1 D0 C1 e e’e’ A E0 e s s E1 s e sch. s finite deciding run from C0 But A is then bivalent! Lemma 3 E s ss e’e’ e

Putting it all Together Lemma 2: There exists an initial configuration that is bivalent Lemma 3: Starting from a bivalent configuration, there is always another bivalent configuration that is reachable Theorem (Impossibility of Consensus): There is always a run of events in an asynchronous distributed system (given any algorithm) such that the group of processes never reaches consensus (i.e., always stays bivalent)

Theorem 2 There is a partially correct consensus protocol in which all process always reach a decision, provided no process die during its execution and a strict majority of the processes are alive initially.

Assumptions: All processes have a unique id and initial state and know the other processes involved. No processes knows in advance which processes are initially dead. No process die while in execution of protocol.

Working of Protocol Stage 1: The processes construct a directed graph G with a node corresponding to each process. Each process broadcasts a message contaning its process id and listens for messages from L-1 other processes where L=(N+1)/2. G has an edge from i to j iff j receives a message from i.

Stage 1 Each process creates a Directed graph. For ex:P1 will have an edge from P0 and P2 from P1. P3 Initially Dead

Working of Protocol Stage 2 : Construct Transitive Closure of G: G + Each process broadcasts to all its initial value, process number with the names of L-1 process it heard from Stage 1. Each process then waits until it has received a Stage 2 message from every ancestor in G it initially knew about. At this point, each process knows all of its own ancestors and G that incident on them.

Stage 2 Each process knows the edges incident on all its ancestors. Find source: node with no incoming edges. P0 is source

Hope You Had Fun Learning Thank You