diff --git a/notes/rabia.md b/notes/rabia.md new file mode 100644 index 0000000000000000000000000000000000000000..ec073c8ed97e9e562a61dd38d35d2735b42c8996 --- /dev/null +++ b/notes/rabia.md @@ -0,0 +1,45 @@ +# 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 + + + + + + +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 diff --git a/notes/rabiaFlow.png b/notes/rabiaFlow.png new file mode 100644 index 0000000000000000000000000000000000000000..1e0e076fb421f0c4cb0f61aba31e9fc920284baa Binary files /dev/null and b/notes/rabiaFlow.png differ diff --git a/notes/rabiaVsMultiPaxos.png b/notes/rabiaVsMultiPaxos.png new file mode 100644 index 0000000000000000000000000000000000000000..578743d29edbd442b25547600903c832b2ef4f7f Binary files /dev/null and b/notes/rabiaVsMultiPaxos.png differ