### Class Notes on Distributed Consensus and Paxos Algorithm

---

### **1. Introduction to Distributed Consensus**

In distributed systems, **consensus** refers to the process by which a group of

distributed nodes (computers, processes, etc.) agree on a single value or decision, even in
the presence of failures or network partitions.

**Key Challenges in Distributed Consensus**:

- **Fault Tolerance**: The system must tolerate node failures (crashes, network partitions)
and still reach a consensus.

- **Asynchrony**: Nodes may not have a synchronized clock or perfect communication.

- **Safety and Liveness**: The algorithm must guarantee that:

- **Safety**: No two nodes ever agree on different values.

- **Liveness**: The system eventually reaches a decision (consensus) despite faults.

### **2. Why is Consensus Important?**

- Ensures consistency across distributed databases (e.g., in replication).

- Ensures correctness in coordination and decision-making in distributed systems.

- Used in protocols like **leader election**, **database replication**, **distributed

locking**, and **transaction commit**.

### **3. Types of Consensus Problems**

- **Single-value consensus**: Agreeing on a single value (e.g., a transaction commit or

leader election).
- **Multi-value consensus**: Agreeing on multiple values (e.g., agreeing on a series of
operations or logs).

The **Paxos algorithm** is primarily designed to solve the single-value consensus

problem, ensuring that a group of nodes can agree on one decision, even if some nodes fail
or the network is unreliable.

---

### **4. Paxos Algorithm Overview**

The **Paxos algorithm** is a fundamental consensus algorithm that provides a way for a
set of nodes (participants) in a distributed system to agree on a single value, even in the
presence of failures. It was first proposed by **Leslie Lamport** in 1989 and has since
become the foundation of many modern distributed systems.

#### **Paxos Participants**

1. **Proposers**: Nodes that propose values for consensus.

2. **Acceptors**: Nodes that receive proposals and decide whether to accept them.

3. **Learners**: Nodes that learn the value that has been chosen.

#### **Key Phases of Paxos**

Paxos can be broken down into three main phases:

1. **Phase 1: Prepare Phase (Leader Election and Proposal Announcement)**

- A proposer chooses a proposal number **n** and sends a **prepare(n)** request to a

majority of acceptors.

- Each acceptor responds with:

 - **Promise** not to accept any proposal with a number less than **n**.

- **Accepted value** (if the acceptor has already accepted a proposal before).

- If an acceptor has previously accepted a proposal **(p, v)**, it sends back the pair **(p,
v)**. Otherwise, it simply promises not to accept proposals with numbers less than **n**.

2. **Phase 2: Propose Phase (Proposal Acceptance)**

- Once a proposer receives a majority of responses with **promises**, it sends a

**propose(n, v)** message to the acceptors, where **v** is the value associated with the
highest-numbered proposal (either new or inherited from the prepare phase).

- Acceptors then:

- Accept the proposal **(n, v)** if they have not already promised to reject proposals
with higher numbers.

- Once a majority of acceptors accept the proposal, the value **v** is chosen.

3. **Phase 3: Commit Phase (Agreement)**

- Once a majority of acceptors accept the proposal, the value **v** is considered
committed. All participants (proposers, acceptors, and learners) agree that **v** is the
chosen value.

#### **Key Points of Paxos**

- **Quorum-based**: The system requires a majority of acceptors (quorum) to reach a

consensus. This ensures fault tolerance, allowing the system to tolerate a minority of
failures.

- **Fault Tolerance**: Paxos can tolerate up to **floor(n/2)** failures in a system with

**n** nodes.

- **Safety**: If two values are chosen, it will never happen in the same run of Paxos.

- **Liveness**: The system will eventually reach consensus if no network partitions or

failures last indefinitely.
#### **Paxos Terminology**

- **Proposal number**: A unique identifier used by proposers to avoid conflicts when

sending proposals.

- **Prepared proposal**: A proposal that has been issued by a proposer but has not yet
been accepted by a majority of acceptors.

- **Accepted proposal**: A proposal that has been agreed upon by a majority of acceptors.

---

### **5. Problems in Paxos and Variants**

Although Paxos guarantees safety, its original design does not guarantee high efficiency or
liveness in all cases. Variants and optimizations of Paxos have been developed to address
these issues:

#### **Paxos Variants**

1. **Fast Paxos**: A variant of Paxos that allows for faster consensus by reducing the
number of rounds needed to achieve consensus, though it comes with trade-offs in terms
of complexity.

2. **Multi-Paxos**: A more practical form of Paxos that allows multiple values to be

decided without restarting the protocol for each one. This is achieved by having one leader
(proposer) in charge of coordinating the sequence of proposals.

3. **EPaxos (Egalitarian Paxos)**: A variant that optimizes for scenarios with multiple
proposers and allows for more efficient handling of concurrent proposals.

#### **Challenges with Paxos**

- **Leader Election**: Traditional Paxos requires a leader to handle the proposals, and
electing a leader introduces additional complexity.
- **Efficiency**: Paxos can be slow due to the multiple phases and the need for a majority
quorum to agree on a value.

- **Scalability**: As the number of nodes grows, the cost of communication and

coordination increases.

---

### **6. Paxos in Practice**

Paxos, in its raw form, can be difficult to implement due to its complexity and subtlety in
dealing with edge cases like network partitions and node crashes. However, several
distributed systems have adapted the Paxos protocol for real-world use:

- **Google Chubby**: A distributed lock service built using Paxos to ensure consistency in
distributed applications.

- **ZooKeeper**: A coordination service for distributed applications that uses a variation of

Paxos.

- **etcd**: A distributed key-value store that also uses a form of Paxos to ensure data
consistency in the face of network partitions and node failures.

### **7. Other Consensus Algorithms**

While Paxos is a widely studied consensus algorithm, other algorithms have been
developed to solve similar problems with different trade-offs:

- **Raft**: A more understandable consensus algorithm designed to be a practical

alternative to Paxos. It emphasizes ease of implementation and clear leader election and
log replication mechanisms.

- **Byzantine Fault Tolerant (BFT) Algorithms**: These algorithms, such as **Practical

Byzantine Fault Tolerance (PBFT)**, deal with situations where nodes may behave
maliciously or fail in arbitrary ways, as opposed to just crash failures in Paxos.
---

### **8. Summary**

- **Distributed Consensus** ensures that distributed systems can make consistent

decisions in the face of failures and asynchrony.

- The **Paxos algorithm** provides a way to achieve consensus despite node failures and
network delays.

- Paxos works by having **proposers**, **acceptors**, and **learners** coordinate to

propose, accept, and learn values.

- While Paxos guarantees **safety**, it has challenges in terms of **efficiency** and

**complexity**, leading to the development of variants like **Fast Paxos** and **Multi-
Paxos**.

- Many modern distributed systems use variations of Paxos or alternative algorithms like
**Raft** to solve consensus problems in practice.

---

### **Key Takeaways**

- Distributed consensus is fundamental to ensuring consistency in distributed systems.

- The Paxos algorithm is one of the oldest and most studied algorithms for achieving
consensus, but it requires careful consideration to implement efficiently.

- Variants like **Raft** and **Fast Paxos** attempt to address the scalability and usability
concerns inherent in the basic Paxos algorithm.