HackerPapers

arXiv:1805.04263cs.DC

OpSets: Sequential Specifications for Replicated Datatypes (Extended Version)

Martin Kleppmann, Victor B. F. Gomes, Dominic P. Mulligan, Alastair R. Beresford

Abstract

We introduce OpSets, an executable framework for specifying and reasoning about the semantics of replicated datatypes that provide eventual consistency in a distributed system, and for mechanically verifying algorithms that implement these datatypes. Our approach is simple but expressive, allowing us to succinctly specify a variety of abstract datatypes, including maps, sets, lists, text, graphs, trees, and registers. Our datatypes are also composable, enabling the construction of complex data structures. To demonstrate the utility of OpSets for analysing replication algorithms, we highlight an important correctness property for collaborative text editing that has traditionally been overlooked; algorithms that do not satisfy this property can exhibit awkward interleaving of text. We use OpSets to specify this correctness property and prove that although one existing replication algorithm satisfies this property, several other published algorithms do not. We also show how OpSets can be used to develop new replicated datatypes: we provide a simple specification of an atomic move operation for trees, an operation that had previously been thought to be impossible to implement without locking. We use the Isabelle/HOL proof assistant to formalise the OpSets approach and produce mechanised proofs of correctness of the main claims in this paper, thereby eliminating the ambiguity of previous informal approaches, and ruling out reasoning errors that could occur in handwritten proofs.

arXiv comments
Journal reference
DOI
Subjects
cs.DCDistributed, Parallel, and Cluster Computing

On Hacker News

Linked by 4 identifiable commenters in 5 comments across 5 threads, from Jan 2020 to May 2026.

Comments linking this paper, per year.

Discussed in comments5 threads

    • For values that don't have a natural merge function (or where you don't want to bother writing one), would it make sense to sync update logs instead? That is: - The synced value is a history of client updates, sorted in some eventually consistent order (e.g. by hybrid logical…

      mweidnerView on HNParent context

    • Definitely a tricky problem for CRDTs. A possible solution is outlined in the OpSets paper; https://arxiv.org/abs/1805.04263 I hope that there are existing implementations of OpSets that perform well. I find the solution laid out in that paper to be really elegant and beautiful.

      rkallosView on HNParent context

    • Kleppmann, et al.'s paper on OpSets [1], a specification for building CRDTs with support for an atomic tree move operation, was the best one for me. Automerge [2] implements a variant of this. [1] https://arxiv.org/abs/1805.04263 [2] https://github.com/automerge/automerge

      miguelollerView on HNParent context

    • > How do you know that? It's not inferrable from the DAG. Is sequencing also provided "a layer up"? I jumped the gun there and made an assumption that the value of a node is the LWW ordering :) Ok, so without that assumption, the DAG 1 --> 2 --> 3 --> 4 `--> 5 --> 6 ...are the…

      haadcodeView on HNParent context

    • I’ve been doing a pretty deep dive on CRDTs and OTs to get the right user experience for our collaborative website builder[1]. I’m still not done with the implementation and subsequent testing (i.e., splitting text nodes, as mentioned in the post). But the core algorithm behind…

      miguelollerView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.