In the COPS system for geo-replicated causally consistent storage, what does the '+' in 'causal+ consistency' add on top of basic causal consistency, and why did COPS need a separate mechanism (COPS-GT) for read-only transactions across multiple keys?

## What the '+' adds Basic causal consistency, on its own, has a gap: it only imposes ordering on operations that are causally related. Two writes to the same key that are concurrent — neither happened-before the other — have no ordering rule at all, meaning different replicas could apply them in different orders and, if nothing else intervenes, permanently disagree about that key's final value. **Causal+ consistency**, the model COPS (Clusters of Order-Preserving Servers, Lloyd et al., 2011) implements, closes this gap by adding **convergent conflict handling**: whenever two concurrent writes touch the same key, every replica must resolve the conflict using the same deterministic rule — commonly `last-writer-wins` by version number, though the system can plug in an application-supplied merge function — so every replica converges to the identical final value, even though they may have observed the conflicting writes in different orders along the way. This is what makes it 'causal, plus something': - **causal ordering** for related operations; - **plus** a guaranteed, agreed-upon resolution for unrelated ones. ## How COPS implements it per key COPS implements this at the granularity of individual key-value puts and gets. Every stored value carries a small amount of dependency metadata identifying its **nearest** causal dependencies — the same nearest-dependency bookkeeping used generally to keep causal consistency's overhead bounded. On a `put`, the server: 1. checks the new write's dependencies are already satisfied locally before applying it (the **causal-cut** rule); 2. if it conflicts with another concurrent put to the same key, invokes the conflict handler to decide the surviving value deterministically. Because every replica runs the identical handler on the identical set of conflicting writes, they converge to the same result without synchronous coordination at write time — exactly what preserves COPS's core goal of remaining available and low-latency across geographically distant data centers. ## Why single-key operations are not the whole story Single-key operations, however, are not the whole story for real applications, which routinely need to read several related keys together. This is where the second half of the question comes in: even with every individual `get` returning a causally consistent value for its own key, a client issuing several independent gets in sequence or in parallel can still end up with a causally inconsistent set across keys. The paper's motivating example is a social network: a user tightens their privacy setting (one key) and then deletes an old post that setting was meant to hide (a causally dependent write on another key); a viewer who reads the post-list key slightly before the deletion propagates, but the ACL key slightly after the tightened setting propagates, ends up seeing exactly the content the user tried to hide — each individual key was internally fine, but the pair, read together, wasn't causally consistent. ## What COPS-GT adds, in two rounds **COPS-GT** (get transactions) exists specifically to close this cross-key gap for read-only access, without resorting to full distributed transactions or locking. At a high level it works in a bounded two rounds of communication regardless of how many keys are requested or how deep their dependency chains run: 1. the first round fetches all requested keys, in parallel, from the local cluster, along with each returned value's dependency information; 2. the second round checks whether any returned value is missing a dependency that another returned value in the same set requires, and if so, re-fetches only the offending key at a version that satisfies it. This bounded-rounds design is the key engineering result — a naive approach walking the full dependency graph could need round trips proportional to the depth of the causal chain, unacceptable for interactive read paths. ## The trade-off The trade-off is real: - COPS-GT adds an extra round trip's worth of latency compared to a plain, non-transactional multi-get; - it only covers read-only access — it does not give general multi-key read-write transactions or full ACID semantics, and concurrent writes to different keys within the same logical operation still aren't atomically ordered; - it also inherits causal consistency's broader operational costs: dependency metadata still needs background garbage collection, and the conflict handler must genuinely be deterministic and commutative or replicas can still diverge. COPS's ideas were later extended by the **Eiger** system to cover read-write transactions as well, distinct follow-on work beyond COPS-GT itself.