auto

notes/rabia.md

+# Rabia: Simplifying State-Machine Replication Through Randomization
+
+Claims are that:
+- simpler
+  - no failover  (no leader elections)
+  - trivial subsidiary protocols: log-trimming, snapshotting, *reconfiguration*
+- faster
+  - 1.5x times faster than epaxos in *stable* single zone, 3 replicas
+  - comparable in multi-zone or larger quorums
+  
+- despite!
+  - more msg delays
+    - 3 min
+	- 5 average
+  - quadratic msg complexity
+  - long tail latency
+ 
+ - byzantine papers to look at:
+   - honeybadger
+   - algorand
+   
+
+![Ben-Or vs multipaxos](rabiaVsMultiPaxos.png)
+
+![Rabia flow](rabiaFlow.png)
+
+Definitions:
+- *weak validity:* choose either value proposed by client or NULL
+  ($\bottom$) ($$\bottom$$)
+
+Challenges:
+- staying on fast path whenever possible
+- avoiding long tail latency in stable environments
+
+Each replica can discard slot *j* or take a snapshot once it has executed the request stored in the slot. Why?
+- no need for leader selection (raft)
+- is this enough to bring lagging replicas up-to-date?
+
+Weak-MVC is guaranteed to use the fast path if:
+- all replicas have the same proposal
+- no majority of the replicas propose the same request
+  - prefer to output a null case because otherwise multiple requests might fight, leading to long tail
+  - during time to discard a slot, most replicas will have same
+    request, and *min priority queue* results in most agreeing right
+    away, i.e., fast path