Questions tagged [consensus]

In the context of distributed computing consensus is a fundamental problem that has received intense attention in research as problem like atomic compare-and-swap (CAS) registers or atomic transaction commit can be reduced to it. Furthermore consensus builds a foundation to realise applications like leader election, clock synchronisation and state machine replication. Although the problem can be explained in simple words, solving it is far more subtle and under certain circumstances not even possible.

In general consensus is the problem of reaching agreement among members of a group. Talking in terms of computing, it is the agreement on a certain value that is needed for during computation by nodes that participate in a cluster. This may not sound complicated but indeed gets as in a distributed system different types of unpredictable partial failures like:

• loss of packets
• duplication/reordering of packets
• arbitrary delayed packet delivery
• pause or even crash of a node

may happen and will happen, which impede solving the problem. Therefore a consensus algorithm needs to satisfy certain properties:

• Agreement: All decisions by non faulty processors must be the same.
• Integrity: No node decides twice.
• Validity: If all nodes decide on value v, then v was proposed.
• Termination: Every non-faulty node needs to eventually decide on a value.

Termination is a liveness property and requires that the algorithm is fault-tolerant. Without satisfying this property an algorithm could simply use a predefined leader that decides on values (like a 2PC). But if the leader fails the algorithm would not make progress anymore - hence the termination requirement. Agreement and integrity are safety properties and build the core of the consensus algorithm. Validity covers the trivial solution where nodes would always decide on the same pre given value and thus also reach consensus by definition.

Whether a solution, that is an actual algorithm, exist for the consensus problem, depends on the system model. Therefore one has to differentiate between a synchronous or asynchronous system model¹. Since mostly, in order to send messages, we have to rely on a shared communication channel, at least the communication is asynchronous and thus our real world applications fit that model better. Unfortunately in such kind of environment there is an impossibility proof by Fischer et al. (1), known as the FLP Impossibility, that shows in a fully asynchronous model even if just one node is faulty (not even considering byzantine failures), no algorithm exist that always reaches consensus. By proving that in every possible algorithm an execution exist that would never terminate, they have shown that no algorithm would always reach the point of agreement.

Nevertheless real solutions to this problem exist. Note that the impossibility result applies on fully asynchronous environments. Although our real world applications fit that model better, it does not mean all conditions are accurate (e.g processors do maintain an internal clock). Making less stringent assumptions about the model allows circumventing the result of the FLP Impossibility. Setting for example an upper bound for message delivery as an unreliable failure detection can turn the communication channel into a partial synchronous one. A system model in which the consensus problem is solvable. (2)

Algorithms that solve the consensus problem are: Paxos, Raft, Viewstamped Replication, Zab

¹ In synchronous models there are known bounds for message delivery and process execution. In an asynchronous model processors not even maintain an internal clock and hence no bounds exist.