Baxos: Backing off for Robust and Efficient Consensus

TL;DR

Baxos tackles the vulnerability of leader-based consensus to liveness and DDoS-like attacks by substituting leader election with Random Exponential Backoff (REB) within the Synod Paxos core. It introduces a minimal, REB-based Paxos variant that supports lock-free termination, adapts to changing network delays, and remains attack-resilient while incurring modest overhead in attack-free settings. Through extensive wide-area experiments on AWS with micro-benchmarks and Redis/YCSB-A workloads, Baxos demonstrates up to 128% higher throughput under delayed view-change attacks, more uniform bandwidth utilization across replicas, and scalable performance up to nine nodes. These results suggest Baxos as a practical fallback for robust, high-availability consensus in adversarial or highly variable network environments.

Abstract

Leader-based consensus algorithms are vulnerable to liveness and performance downgrade attacks. We explore the possibility of replacing leader election in Multi-Paxos with random exponential backoff (REB), a simpler approach that requires minimum modifications to the two phase Synod Paxos and achieves better resiliency under attacks. We propose Baxos, a new resilient consensus protocol that leverages a random exponential backoff scheme as a replacement for leader election in consensus algorithms. Our backoff scheme addresses the common challenges of random exponential backoff such as scalability and robustness to changing wide area latency. We extensively evaluate Baxos to illustrate its performance and robustness against two liveness and performance downgrade attacks using an implementation running on Amazon EC2 in a wide area network and a combination of a micro benchmark and YCSB-A workload on Redis. Our results show that Baxos offers more robustness to liveness and performance downgrade attacks than leader-based consensus protocols. Baxos outperforms Multi-Paxos and Raft up to 128% in throughput under liveness and performance downgrade attacks under worst case contention scenarios where each replica proposes requests concurrently.

Figures (5)

• Figure 1: Illustration of Baxos termination.
• Figure 2: Throughput and median latency under delay view change attack - Five clients in five AWS regions generate requests at 2,500 requests per second arrival rate (aggregate 12,500 requests per second on average). The attacker starts the attack at 10s, and keeps attacking the leader node in Multi-Paxos and Raft, and a random node in Baxos for 30s. When the time is 40s, the attacker stops the attack. The workload consists of 8B request and response sizes with 1 $\mu$s service time. We use 5s view time out for Multi-Paxos and Raft in this experiment
• Figure 3: Normal-Case Performance. The workload consists of 8B request and response sizes with 1 $\mu$s service time. Five clients in 5 different AWS regions generate requests simultaneously -- exercises the worst case contention scenario (worst case performance).
• Figure 4: Average bandwidth usage of replicas. The leader nodes of Multi-Paxos and Raft algorithms are located in North Virginia. All five clients generate requests simultaneously at 1,000 requests per second
• Figure 5: Scalability with respect to increasing replica count. The workload is YCSB-A workload with 1kB request size with Redis key value store as the backend. All throughput values are measured under 1 second 99% percentile client perceived latency.