hesela.devCURP
CURP overlaps primary execution with unordered recording at witnesses, using commutativity to preserve consistent recovery.
Completion: The primary-backup design needs the primary result and acceptance by every required witness for its fast path. A rejection or unavailable witness requires backup synchronization. Witnesses accept only requests that commute with their retained set, using operation parameters rather than database state. [1]
Recovery: Restore a backup, freeze one available witness, then replay its requests with duplicate suppression. Witness records may overlap updates already in the backup. RIFL binds request IDs and results atomically to the mutation, allowing replay to identify completed work. [1] [3]
Reads: A primary must synchronize before answering a read that conflicts with an unsynced update. A primary reply alone does not certify witness acceptance. [2]
Relations
- related
- Synchronous replication, Asynchronous replication, Retry deduplication, Linearizability, Harmonia
Limitations
- The protocol assumes fail-stop failures, not Byzantine behavior. [1]
Citations
- Seo Jin Park and John Ousterhout: Exploiting Commutativity For Practical Fast Replication, NSDI 2019, pp. 47-64, sections 3.1-3.6
- Park and Ousterhout: CURP presentation, NSDI 2019, slides 8-14
- Lee et al.: Implementing Linearizability at Large Scale and Low Latency, SOSP 2015, sections 3-4; DOI 10.1145/2815400.2815416
Sources & caveats
- Source review of the 2019 protocol and its 2015 duplicate-suppression dependency; no prototype execution or latency reproduction.