Advanced Consensus: Multi-Paxos, Fast Paxos & Byzantine Fault Tolerance (BFT)

Distributed consensus is the algorithmic bedrock of linearizable replicated state machines. While basic Single-Decree Paxos and textbook Raft establish the theoretical foundations of consensus in partially synchronous networks, real-world mission-critical infrastructures—such as Google Spanner, Chubby, Apache BookKeeper, Tendermint, and enterprise blockchain ledgers—require advanced optimizations:

• Multi-Paxos: Amortizing proposal rights across stable leader leases to achieve 1-RTT steady-state commits.
• Fast Paxos: Bypassing the leader entirely to commit in 1 RTT directly from the client.
• Raft Dynamic Membership: Transitioning cluster topology safely from $N$ to $N+M$ nodes via Joint Consensus ($C_{old,new}$) without split-brain risk.
• Practical Byzantine Fault Tolerance (PBFT): Reaching consensus in adversarial environments where nodes may maliciously lie, forge signatures, or equivocate.

1. Context & Architecture Setting

+-------------------------------------------------------------------------------+
|                       CONSENSUS PROTOCOL SPECTRUM                             |
+-------------------------------------------------------------------------------+
| Protocol                | Fault Model         | Min Quorum Size | Commit RTTs |
+-------------------------+---------------------+-----------------+-------------+
| Single-Decree Paxos     | Crash (CFT)         | N >= 2f + 1     | 2 RTTs      |
| Multi-Paxos (Steady)    | Crash (CFT)         | N >= 2f + 1     | 1 RTT       |
| Fast Paxos (No collision| Crash (CFT)         | Qf = ceil(3N/4) | 1 RTT Client|
| Raft Joint Consensus    | Crash (CFT)         | C_old & C_new   | 1 RTT       |
| PBFT (Castro & Liskov)  | Byzantine (BFT)     | N >= 3f + 1     | 3 Phases    |
+-------------------------+---------------------+-----------------+-------------+

2. Multi-Paxos: Steady-State Optimization & Leader Leases

SYSTEM ARCHITECTURE BLUEPRINTDISTRIBUTED SYSTEMS

⤢Expand

ARCHITECTURAL FLOW · STEP 1 OF 3

1. Multi-Paxos and Fast Paxos & Multi-Paxos Steady-State Optimization

Establishes the ingress and structural boundary across Multi-Paxos and Fast Paxos & Multi-Paxos Steady-State Optimization: Phase 1 (Prepare/Promise) run ONCE during election; Leader acquires long-lived Master Lease; Steady State: ONLY Phase 2 (Accept/Accepted).

Architectural Invariant: Fast Quorum Size: Qf = ceil(3N / 4).

ARCHITECTURAL FLOW · STEP 2 OF 3

2. Raft Dynamic Membership Changes & The Direct Switching Hazard (Split-Brain)

Coordinates core data-plane execution and state transitions through Raft Dynamic Membership Changes & The Direct Switching Hazard (Split-Brain): Naive approach: Update cluster config from 3 to 5 nodes; If Node 1 and 2 switch to C_new, but Node 3 stays on C_old: ⚠ C_old majority: {Node 2, Node 3} elects Leader A ⚠ C_new majority: {Node 1, Node 4, Node 5} elects Leader B Catastrophic split-brain: Two independent leaders commit writes!; 1. Leader enters Joint Configuration: C_old,new.

Architectural Invariant: Overlapping majorities guaranteed when delta is 1.

ARCHITECTURAL FLOW · STEP 3 OF 3

3. Byzantine Fault Tolerance (PBFT) & CFT vs BFT Quorum Comparison

Enforces durability, state convergence, and output verification across Byzantine Fault Tolerance (PBFT) & CFT vs BFT Quorum Comparison: Crash Fault Tolerance (Raft/Paxos): N >= 2f + 1; Assumes nodes either follow protocol or crash; Byzantine Fault Tolerance (PBFT): N >= 3f + 1.

Architectural Invariant: Message complexity: O(N^2) all-to-all broadcasts.

In basic Single-Decree Paxos, deciding a single slot requires two phases:

1. Phase 1 (Prepare / Promise): Proposer acquires proposal number $n$ and discovers previously accepted values.
2. Phase 2 (Accept / Accepted): Proposer proposes $(n,v)$ and waits for a majority of acceptors.

If two proposers concurrently attempt to acquire rights, they repeatedly preempt each other with higher proposal numbers—the infamous dueling proposers livelock.

The Multi-Paxos Solution

1. Amortized Phase 1: When a leader is elected, it issues a single Phase 1 Prepare message covering all future log slots ($[i,\infty )$).
2. Leader Lease: The leader establishes an agreement with acceptors granting it exclusive leadership for a bounded lease duration (e.g., 5 seconds).
3. 1-RTT Steady State: For every new client write, the leader skips Phase 1 and broadcasts only Phase 2 Accept: $$\text{Leader}\stackrel{\text{Accept}(slot,term,v)}{\to }\text{Acceptors}\stackrel{\text{Accepted}}{\to }\text{Leader (Committed!)}$$

3. Fast Paxos: Client-Driven Fast Quorums

Fast Paxos (Leslie Lamport, 2006) eliminates the leader hop entirely during normal operations:

• The client sends its proposal directly to all acceptors.
• Acceptors immediately accept the first proposal they receive for that slot.

       [Client] ---------------------------------------+
          |                                            |
          | (1. Sends Proposal directly to Acceptors)  |
          v                                            v
    [Acceptor 1]       [Acceptor 2]       [Acceptor 3]       [Acceptor 4]
          |                  |                  |                  |
          +------------------+------------------+------------------+
                             | (Fast Quorum Qf = ceil(3N/4) Agree!)
                             v
                  [Value Committed in 1 RTT!]

The Fast Quorum Formula

Pairwise intersection ($|Q_f\cap Q_c|\ge 1$) is insufficient for Fast Paxos: because clients send concurrent uncoordinated proposals directly to acceptors in a fast round, a subsequent classic recovery coordinator querying classic quorum $Q_c$ might observe conflicting fast values and must unambiguously determine whether any single value could have reached a full fast quorum $Q_f$. Lamport (2006) proved that safety requires three-way quorum intersection between any classic quorum $Q_c$ and any two fast quorums $Q_{f1},Q_{f2}$: $$|Q_c\cap Q_{f1}\cap Q_{f2}|\ge 1⟺Q_c+2Q_f>2N$$

Substituting the minimal classic majority quorum $Q_c=\lfloor \frac{N}{2}\rfloor +1$ into $2Q_f\ge 2N+1-Q_c=2N-\lfloor \frac{N}{2}\rfloor =\lceil \frac{3N}{2}\rceil$ yields: $$Q_f=\lceil \frac{3N}{4}\rceil \text{and}{Q}_c=\lfloor \frac{N}{2}\rfloor +1$$

Equivalently, if the cluster must tolerate $f$ crashes in classic rounds ($Q_c=N-f$) and $e$ crashes in fast rounds ($Q_f=N-e$), then $(N-f)+2(N-e)>2N⟹N\ge 2e+f+1$ (so tolerating $e=f$ crashes on the fast path requires $N\ge 3f+1$).

• Worked Check ($N=5$): $Q_c=\lfloor 5/2\rfloor +1=3$ and $Q_f=\lceil 15/4\rceil =4$, satisfying $3+2(4)=11>10$. If value $X$ reaches $Q_f=4$ acceptors, any classic recovery quorum $Q_c$ of 3 acceptors contains at least $4+3-5=2$ acceptors holding $X$—a strict majority of $Q_c$!

If concurrent clients propose different values simultaneously in the same slot so neither reaches $Q_f$, a collision occurs. The classic Paxos coordinator steps in, executes a coordinated classic round, and resolves the tie safely.

4. Raft Dynamic Membership Changes: Joint Consensus

Changing cluster membership (adding or removing nodes) is fraught with risk. If nodes switch directly from $C_{old}$ to $C_{new}$, differences in message delivery times cause disjoint majorities to emerge, leading to split-brain states where two leaders commit divergent logs.

The Joint Consensus Protocol ($C_{old,new}$)

Raft solves this via Joint Consensus:

1. The leader creates a special configuration entry: $C_{old,new}$.
2. Under $C_{old,new}$, any election or log entry requires two independent majorities:
   • A majority of $C_{old}$, AND
   • A majority of $C_{new}$.
3. Once $C_{old,new}$ is committed to a majority of both groups, the leader creates the final entry: $C_{new}$.
4. Once $C_{new}$ is committed, old nodes that are not part of $C_{new}$ are safely decommissioned.

+-------------------------------------------------------------------------------+
|                       RAFT JOINT CONSENSUS TIMELINE                           |
+-------------------------------------------------------------------------------+
| C_old config only     | Joint Configuration: C_old,new     | C_new config only|
| [Majority of C_old]   | [Majority(C_old) & Majority(C_new)]| [Majority C_new] |
|                       |                                    |                  |
| Impossible for        | Overlapping majorities guarantee   | Old nodes safe   |
| split-brain to occur  | safety at every millisecond        | to shut down     |
+-----------------------+------------------------------------+------------------+

5. Practical Byzantine Fault Tolerance (PBFT)

In untrusted or adversarial environments, nodes may suffer Byzantine faults:

• Crashing or dropping packets.
• Sending contradictory messages to different peers (equivocation).
• Maliciously tampering with transaction records.

Castro and Liskov (1999) introduced PBFT, which guarantees safety and liveness in partially synchronous networks if: $$N\ge 3f+1$$ Where $f$ is the maximum number of Byzantine nodes.

The 3-Phase PBFT Protocol

Client Proposal: m
       |
       v
+--------------+ (Phase 1: Pre-Prepare)
| Primary Node | ------------------------------------+
+--------------+                                     |
       | Broadcast <PRE-PREPARE, v, n, d>            |
       v                                             v
  [Replica 1]                                   [Replica 2]
       | (Phase 2: Prepare Broadcast O(N^2))         |
       v                                             v
   Replicas exchange <PREPARE, v, n, d, i> signed certificates
   Wait for 2f matching valid PREPARE messages (Prepared Certificate)
       |
       | (Phase 3: Commit Broadcast O(N^2))
       v
   Replicas exchange <COMMIT, v, n, d, i> signed certificates
   Wait for 2f + 1 matching COMMIT messages (Committed Certificate)
       |
       v
   Execute transaction on State Machine and reply to Client!

6. Practical Engineering Simulation: Multi-Paxos Leases & PBFT 3-Phase Engine

The following self-contained TypeScript simulation implements a Multi-Paxos leader lease coordinator and a PBFT 3-phase consensus engine with simulated Byzantine traitor nodes.

/**
 * Systems Notebook - Multi-Paxos & PBFT Simulation
 */

// -------------------------------------------------------------
// Part 1: Multi-Paxos Leader Leasing
// -------------------------------------------------------------
class MultiPaxosLeader {
  public leaderId: string;
  public leaseExpiryMs: number = 0;
  private currentSlot: number = 0;

  constructor(leaderId: string) {
    this.leaderId = leaderId;
  }

  public acquireLease(durationMs: number, nowMs: number): void {
    console.log(`[Multi-Paxos] Phase 1: Acquiring master lease for ${this.leaderId}...`);
    this.leaseExpiryMs = nowMs + durationMs;
    console.log(`[Multi-Paxos] Master lease acquired until t=${this.leaseExpiryMs}ms. Phase 1 amortized!`);
  }

  public proposeValue(value: string, nowMs: number): { slot: number; committed: boolean; rtts: number } {
    if (nowMs > this.leaseExpiryMs) {
      throw new Error('Leader lease expired! Must re-run Phase 1 Prepare.');
    }

    this.currentSlot++;
    // In steady state: Only Phase 2 (Accept/Accepted) is executed -> 1 RTT!
    console.log(`[Multi-Paxos] Steady-State: Slot ${this.currentSlot} committed in 1 RTT via Phase 2 Accept.`);
    return { slot: this.currentSlot, committed: true, rtts: 1 };
  }
}

// -------------------------------------------------------------
// Part 2: PBFT 3-Phase Protocol Engine
// -------------------------------------------------------------
interface PBFTMessage {
  type: 'PRE-PREPARE' | 'PREPARE' | 'COMMIT';
  view: number;
  sequenceNumber: number;
  digest: string;
  senderId: string;
}

class PBFTNode {
  public readonly id: string;
  public readonly isByzantine: boolean;
  private acceptedPrePrepare: Set<string> = new Set();
  private prepareCertificates: Map<string, Set<string>> = new Map();
  private commitCertificates: Map<string, Set<string>> = new Map();

  constructor(id: string, isByzantine: boolean = false) {
    this.id = id;
    this.isByzantine = isByzantine;
  }

  public handlePrePrepare(msg: PBFTMessage, primaryId: string): PBFTMessage | null {
    if (this.isByzantine) {
      console.log(`[Byzantine ${this.id}] Traitor equivocated with forged digest!`);
      return {
        type: 'PREPARE',
        view: msg.view,
        sequenceNumber: msg.sequenceNumber,
        digest: 'forged_malicious_digest_deadbeef',
        senderId: this.id
      };
    }

    const key = `${msg.view}:${msg.sequenceNumber}:${msg.digest}`;
    this.acceptedPrePrepare.add(key);

    // Per Castro & Liskov (1999), only non-primary backup replicas broadcast PREPARE
    if (this.id === primaryId) {
      return null;
    }

    return {
      type: 'PREPARE',
      view: msg.view,
      sequenceNumber: msg.sequenceNumber,
      digest: msg.digest,
      senderId: this.id
    };
  }

  public receivePrepare(msg: PBFTMessage, primaryId: string, f: number): boolean {
    if (this.isByzantine || msg.senderId === primaryId) return false;
    const key = `${msg.view}:${msg.sequenceNumber}:${msg.digest}`;
    if (!this.prepareCertificates.has(key)) {
      this.prepareCertificates.set(key, new Set());
    }
    this.prepareCertificates.get(key)!.add(msg.senderId);
    return this.isPrepared(key, f);
  }

  public isPrepared(key: string, f: number): boolean {
    // Prepared certificate requires valid PRE-PREPARE + 2f matching backup PREPAREs (= 2f + 1 total)
    return this.acceptedPrePrepare.has(key) && (this.prepareCertificates.get(key)?.size ?? 0) >= 2 * f;
  }

  public receiveCommit(msg: PBFTMessage, f: number): boolean {
    if (this.isByzantine) return false;
    const key = `${msg.view}:${msg.sequenceNumber}:${msg.digest}`;
    if (!this.commitCertificates.has(key)) {
      this.commitCertificates.set(key, new Set());
    }
    this.commitCertificates.get(key)!.add(msg.senderId);

    // Node is 'Committed-Local' once Prepared AND 2f + 1 matching COMMIT messages arrive
    return this.isPrepared(key, f) && this.commitCertificates.get(key)!.size >= 2 * f + 1;
  }
}

// -------------------------------------------------------------
// Verification Demonstration
// -------------------------------------------------------------
function runAdvancedConsensusDemo(): void {
  console.log('=== Step 1: Multi-Paxos Steady-State 1-RTT Commits ===');
  const paxosLeader = new MultiPaxosLeader('node-us-east-1');
  paxosLeader.acquireLease(5000, 1000); // 5s lease
  paxosLeader.proposeValue('TXN_TRANSFER_100', 1200);
  paxosLeader.proposeValue('TXN_TRANSFER_200', 1400);

  console.log('\n=== Step 2: PBFT Consensus with 1 Byzantine Node (N=4, f=1) ===');
  const f = 1;
  const primaryId = 'replica-0';
  const nodes = [
    new PBFTNode('replica-0'), // Primary
    new PBFTNode('replica-1'),
    new PBFTNode('replica-2'),
    new PBFTNode('replica-3', true) // Malicious traitor
  ];

  const proposalDigest = 'sha256_digest_block_4910';
  const key = `0:1:${proposalDigest}`;
  const prePrepare: PBFTMessage = {
    type: 'PRE-PREPARE',
    view: 0,
    sequenceNumber: 1,
    digest: proposalDigest,
    senderId: primaryId
  };

  console.log('[Phase 1: Pre-Prepare] Primary broadcasts proposal...');

  // Phase 2: Backups validate Pre-Prepare and broadcast Prepare
  const prepareMessages: PBFTMessage[] = [];
  for (const node of nodes) {
    const prep = node.handlePrePrepare(prePrepare, primaryId);
    if (prep) prepareMessages.push(prep);
  }

  console.log(`[Phase 2: Prepare] Exchanging ${prepareMessages.length} backup PREPARE frames (including 1 forged traitor frame).`);

  for (const node of nodes) {
    for (const msg of prepareMessages) {
      node.receivePrepare(msg, primaryId, f);
    }
  }
  const honestNodes = nodes.filter((n) => !n.isByzantine);
  const preparedHonest = honestNodes.filter((n) => n.isPrepared(key, f));
  console.log(`Honest nodes reaching Prepared state: ${preparedHonest.length}/${honestNodes.length} (1 Pre-Prepare + 2f = 2 backup Prepares).`);

  // Phase 3: Commit phase (Prepared honest nodes emit valid COMMIT; traitor emits forged COMMIT)
  const commitMessages: PBFTMessage[] = nodes.map((n) => ({
    type: 'COMMIT',
    view: 0,
    sequenceNumber: 1,
    digest: n.isByzantine ? 'forged_malicious_digest_deadbeef' : proposalDigest,
    senderId: n.id
  }));

  let committedCount = 0;
  for (const node of honestNodes) {
    let nodeCommitted = false;
    for (const msg of commitMessages) {
      if (node.receiveCommit(msg, f)) {
        nodeCommitted = true;
      }
    }
    if (nodeCommitted) committedCount++;
  }
  console.log(`[Phase 3: Commit] Honest nodes executing state transition: ${committedCount}/${honestNodes.length} (Threshold >= 2f + 1 = 3).`);
  console.log('>>> PBFT Consensus Achieved Safely despite 1 Equivocating Byzantine Traitor! <<<');
}

runAdvancedConsensusDemo();

7. Design Alternatives & Consensus Protocol Trade-off Matrix

8. Failure Modes, Distributed Anomalies & Recovery

1. Multi-Paxos Lease Split-Brain Under Asymmetric Clock Drift

If a Multi-Paxos leader serves local linearizable reads purely from an unguarded wall-clock timer (now < leaseExpiry) and suffers a $3\text{-second}$ JVM/Go garbage collection pause or asymmetric NTP drift rate exceeding hardware bounds, a new leader may win Phase 1 and commit newer writes while the paused old leader wakes up and serves stale local reads.

• Recovery & Guardrail: Bind leader leases strictly to CLOCK_MONOTONIC bounded by maximum hardware oscillator drift ($\pm 100-200\text{ ppm}$), deduct safety guard margins from the proposer’s lease duration relative to acceptors’ promise locks, or execute lightweight ReadIndex quorum heartbeats.

2. Fast Paxos Collision Storms Under High Contention

When multiple clients concurrently target the same hot key/slot from different regions, acceptors receive interleaved proposals in opposite orders (A then B vs B then A), causing fast quorum $Q_f=\lceil 3N/4\rceil$ to fail repeatedly and forcing expensive 2-RTT classic coordinator recovery rounds.

• Recovery & Guardrail: Monitor fast_paxos_collision_rate; dynamically fall back to classic leader-serialized Multi-Paxos whenever slot collision rates exceed $5\%$, or use Generalized / EPaxos dependency tracking so non-interfering commands commute without collisions.

3. Disrupted Raft Membership Changes via Pre-Vote Starvation

During a Raft membership removal, a decommissioning node removed from $C_{\text{new}}$ stops receiving heartbeats from the leader, times out, increments its currentTerm, and sends RequestVote RPCs that force the active leader to step down repeatedly.

• Recovery & Guardrail: Enable the Raft Pre-Vote extension (PreVote = true in etcd/raft) and enforce leader lease checks whereby voters ignore RequestVote RPCs received within the minimum election timeout window of a valid leader heartbeat.

4. Malicious PBFT Primary Throttling & View-Change Storms

A Byzantine primary in PBFT cannot forge a committed state transition without $2f$ honest colluders, however it can selectively drop specific client requests or inject maximum allowable network delays just below the view-change timeout threshold.

• Recovery & Guardrail: Clients broadcast timed-out requests to all replicas; once $f+1$ backups observe an expired execution timer on a forwarded request, replicas multicast signed <VIEW-CHANGE, v + 1, ...> certificates with exponential timeout doubling across consecutive failed views to guarantee liveness after GST.

9. Observability & SRE Metrics

+-------------------------------------------------------------------------------+
|                       ADVANCED CONSENSUS TELEMETRY                            |
+-------------------------------------------------------------------------------+
| Metric Indicator       | Metric Source           | Alert Threshold & Action   |
+------------------------+-------------------------+----------------------------+
| Leader Lease Expiry    | paxos_lease_remaining_ms| Alert if remaining < 500ms;|
| Headroom               |                         | election storm impending   |
| Fast Paxos Collision   | fast_paxos_collision_   | Alert if collision rate    |
| Rate                   | count                   | > 5%; switch to classic    |
| Raft Joint Config State| raft_is_joint_consensus | Alert if true for > 5 min; |
|                        |                         | stuck membership change!   |
| PBFT View-Change Rate  | pbft_view_change_total  | Alert if > 0 in 1 hour;    |
|                        |                         | primary node compromised   |
+------------------------+-------------------------+----------------------------+

10. Comprehensive Architectural Summary & Decision Guide

Distributed consensus protocols balance round-trip latency, message complexity, and adversarial fault models:

• Multi-Paxos eliminates dueling proposers in steady state and delivers 1-RTT leader-driven commits via amortized Phase 1 leases.
• Fast Paxos removes the client-to-leader WAN hop for non-conflicting writes via three-way intersecting fast quorums ($Q_f=\lceil \frac{3N}{4}\rceil$).
• Raft Joint Consensus ($C_{\text{old,new}}$) (and single-server membership steps) guarantees that online cluster resizing never creates disjoint majorities or split-brain partitions.
• Practical Byzantine Fault Tolerance (PBFT) provides deterministic finality in adversarial environments using $N\ge 3f+1$ replicas and 3-phase PRE-PREPARE / PREPARE / COMMIT quorum certificates.

11. Guided Design Exercises

Exercise 1 (Foundational — Fast Paxos Three-Way Quorum Intersection & Collision Recovery)

Consider a 7-node consensus cluster ($N=7$) distributed across global regions.

1. Compute the minimum Classic Quorum size $Q_c$ and Fast Quorum size $Q_f$, and verify Lamport’s three-way intersection inequality $Q_c+2Q_f>2N$. How many simultaneous node crashes ($e$) can the cluster tolerate while still completing 1-RTT Fast Paxos commits vs. classic 2-RTT recovery commits ($f$)?
2. Suppose Client 1 and Client 2 concurrently propose "X" and "Y" in fast round $r$ across $N=7$. Trace what a recovery coordinator observes when querying $Q_c$ if "X" had actually reached $Q_f$ acceptors vs. if neither "X" nor "Y" reached $Q_f$.

Exercise 2 (Intermediate — Raft Joint Consensus vs. Unsafe Direct Membership Switching)

A 3-node Raft cluster $C_{\text{old}}=\{A,B,C\}$ is expanding to a 5-node cluster $C_{\text{new}}=\{A,B,C,D,E\}$.

1. Prove mathematically why a single-step transition $C_{\text{old}}\to C_4=\{A,B,C,D\}\to C_{\text{new}}=\{A,B,C,D,E\}$ (adding one voting node at a time) guarantees overlapping majorities without requiring an explicit $C_{\text{old,new}}$ entry, whereas jumping directly from 3 to 5 nodes allows two disjoint leaders.
2. Calculate the exact dual-majority requirement during $C_{\text{old,new}}$ when migrating a 3-node cluster $\{A,B,C\}$ to an entirely new hardware rack $\{D,E,F\}$.

Exercise 3 (Staff-Level — PBFT $3f+1$ Equivocation Proof & Quadratic Message Scaling)

1. Prove by contradiction why a 3-node Byzantine cluster ($N=3,f=1$) cannot safely reach consensus when 1 node is an equivocating traitor and network delays can stall 1 honest node.
2. An enterprise consortium deploys PBFT across $N=64$ validator nodes ($f=21$) committing $500\text{ batches/sec}$, where each signed PREPARE and COMMIT message is $512\text{ bytes}$. Calculate the aggregate cluster message rate and per-validator network bandwidth, and explain how HotStuff / BLS threshold signatures reduce per-phase complexity from $O(N^2)$ to $O(N)$.

12. Authoritative References & Version Context

• Version & Implementation Baseline: Protocol mechanics align with etcd v3.5 (Joint Consensus & Pre-Vote), CometBFT v0.38 (Tendermint BFT state machine), and Google Chubby / Spanner Multi-Paxos production specifications.
• Lamport, L. (2006). Fast Paxos. Distributed Computing, 19(2), 79–103.
• Castro, M., & Liskov, B. (1999). Practical Byzantine Fault Tolerance. Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation (OSDI ‘99), 173–186.
• Burrows, M. (2006). The Chubby Lock Service for Loosely-Coupled Distributed Systems. Proceedings of USENIX OSDI ‘06, 335–350.
• Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm (Extended Version, §6 Cluster Membership Changes). Proceedings of USENIX ATC ‘14, 305–319.