Pure Operation-Based Replicated Data Types · HackerPapers discussions

Pure Operation-Based Replicated Data Types — mentioned by mweidner

Sun, 22 Mar 2026 21:55:18 GMT

You can think of the semantics (i.e., specification) of any CRDT as a function that inputs the operation history DAG and outputs the resulting user-facing state. However, algorithms and implementations usually have a more programmatic description, like "here is a function `(internal state, new operation) -> new internal state`", both for efficiency (update speed; storing less info than the full history) and because DAGs are hard to reason about. But you do see the function-of-history approach in the paper "Pure Operation-Based Replicated Data Types" [1]. [1] https://arxiv.org/abs/1710.04469

Paper and discussion history. A mention is not an endorsement.

Pure Operation-Based Replicated Data Types — mentioned by hardwaresofton

Thu, 01 Nov 2018 14:20:54 GMT

Hey if you guys are still considering solutions maybe one of the following derivations of Paxos will help: EPaxos[0] - flexible/minimal quorums + if you're willing to know ops are commutative you can fast-path, and you can flexibly quorum WPaxos[1] - flexible/minimal quorums + dynamic partitioning via object stealing for spreading writes around The main benefit of these is of course getting over raft's weakness of the leader being a SPOF. If you're willing to go with causal consistency there's also CmRDTs (operation/command Replicated Data Types) which are generalizable to "pure operation…

Paper and discussion history. A mention is not an endorsement.

Pure Operation-Based Replicated Data Types — HN submission

Tue, 17 Oct 2017 09:46:03 GMT

Pure Operation-Based Replicated Data Types

86 points; 52 discussion replies on HN. Paper and source history. A submission is not an endorsement.