To facilitate the use of causal transactions, UniStore includes replicated
data types (aka CRDTs), which implement policies for merging concurrent
updates to the same data item [1]}.
Each data item in the store is associated with a type (e.g., counter, set),
which is backed by a CRDT implementation managing updates to it. For example,
the programmer can use a counter CRDT to represent an account balance. Then if
two clients concurrently deposit 100 and 200 into an empty account using
causal transactions, eventually the balance at all replicas will be 300. Using
ordinary writes here would yield 100 or 200, depending on the order in which
the writes are applied. More generally, CRDTs ensure
that two replicas receiving the same set of updates are in the same state,
regardless of the receipt order. Together with Eventual Visibility, this implies
the expected guarantee of eventual consistency [2]}. Due to space
constraints, we omit details about the use of CRDTs from our protocol
descriptions.
