Replication-Aware Linearizability

• Replication-Aware Linearizability is a correctness criterion for replicated objects that ensures every active replica reflects a state obtained through a sequential linearization of visible updates.
• It employs both history-based and merge-based formulations to reconcile strong eventual consistency with per-replica sequential interpretations in asynchronous replication settings.
• The framework leverages algebraic equational reasoning and mechanized verification to reduce complex merge scenarios to a finite set of proof obligations, ensuring practical system correctness.

Searching arXiv for the cited RA-linearizability papers to ground the article in the current literature. Replication-aware linearizability (RA-linearizability, RA-Lin) is a correctness criterion for replicated objects that adapts the intuition of linearizability to geo-replicated and conflict-free replication settings. It was introduced for CRDT-style objects as a way to specify and verify replicated implementations against sequential specifications while respecting visibility rather than real-time order (Enea et al., 2019). In a later merge-based formulation for MRDTs and state-based CRDTs, RA-Lin combines strong eventual consistency with a per-replica linearization guarantee: every active replica must always be in a state obtainable by linearizing the updates received at that replica (Soundarapandian et al., 27 Feb 2025). The resulting notion is stronger than convergence alone, because it relates concrete replica states and query observations to a sequential witness, yet weaker than classical linearizability, because queries need not observe a single real-time global order.

1. Origins and conceptual role

RA-linearizability was proposed to address a gap between the guarantees typically provided by replicated data types and the guarantees expected by users of abstract data structures. Strong eventual consistency ensures that replicas that have received the same set of updates converge to the same state, but it does not by itself explain that state via a sequential interpretation of the updates. RA-Lin supplies that interpretation by requiring that updates admit a global order compatible with visibility, while queries are justified by the updates visible to them (Enea et al., 2019).

The criterion is explicitly inspired by classical linearizability, but it revises the shared-memory picture in two ways. First, it orders updates globally with respect to visibility rather than wall-clock returns-before. Second, queries may see only a prefix of the updates they have observed, rather than all prior updates in a real-time sense (Enea et al., 2019). This makes the criterion suitable for asynchronous, available replication where updates are accepted at any replica and propagated asynchronously.

In the merge-based setting, the same idea is reformulated as a per-replica state property. For MRDTs and state-based CRDTs, RA-Lin requires that all replicas always be in a state that can be obtained by linearizing the updates received at the replica (Soundarapandian et al., 27 Feb 2025). This shifts the emphasis from histories of delivered effectors to the algebra of local updates and merge.

2. Formalizations for operation-based and merge-based replication

In the 2019 formulation, a history is a pair $h=(L,\prec)$, where $L$ is a finite set of operation labels and $\prec$ is a partial order. A history is linearizable with respect to a sequential specification if there is a total order on the same labels extending $\prec$ and admitted by the specification. RA-linearizability modifies this by partitioning labels into updates and queries, applying a query-update rewriting $\gamma$, and requiring a total order on the rewritten labels such that: $(i)$ the visibility-derived order is preserved, $(ii)$ the projection onto updates is in the sequential specification, and $(iii)$ for every query, the visible updates preceding that query together with the query are also admitted by the specification (Enea et al., 2019).

This history-based account is paired with an operation-based system model. Each object is replicated at all replicas; an update has a generator at the origin replica and an effector $\delta\colon\Sigma\to\Sigma$; the effector is applied locally and then propagated at-most-once to other replicas; and effectors are delivered causally (Enea et al., 2019). The global configuration is written as

$$(\;G\in\Sigma,\;V\subseteq L\times L,\;M\subseteq \mathit{Rep}\times (\Sigma\times L)\;),$$

where $L$0 is the visibility partial order and $L$1 is the multiset of in-flight messages.

In the 2025 merge-based formulation, an MRDT implementation or state-based CRDT is a tuple

$L$2

where $L$3 applies an update at a replica with a fresh timestamp, $L$4 is a ternary three-way merge, $L$5 reads the state, and $L$6 is a partial conflict-resolution relation ordering non-commuting updates (Soundarapandian et al., 27 Feb 2025). Executions are represented by configurations

$L$7

where $L$8 maps versions to concrete states, $L$9 maps active replicas to head versions, $\prec$0 records for each version the set of update events that contributed to it, $\prec$1 is the DAG of version births, and $\prec$2 is the visibility order between events.

The merge-based definition then introduces a partial order $\prec$3 on generated events. For events $\prec$4, one has $\prec$5 if either $\prec$6 $\prec$7 and the two events do not commute, or $\prec$8 the events are concurrent, $\prec$9, and no later visible non-commuting event invalidates that ordering (Soundarapandian et al., 27 Feb 2025). RA-linearizability holds iff in every reachable configuration and for every active replica $\prec$0 there exists a total sequence $\prec$1 over the events in $\prec$2 such that

$\prec$3

and

$\prec$4

The state of each replica must therefore coincide exactly with a legal linearization witness for the updates it has incorporated (Soundarapandian et al., 27 Feb 2025).

3. Sequential specification and proof obligations

A central motivation for RA-Lin is that replicated implementations can still be specified by ordinary sequential specifications. In the 2019 framework, a sequential specification $\prec$5 defines an abstract state domain $\prec$6 and labeled transition rules such as

$\prec$7

which play the role of Hoare-style transitions (Enea et al., 2019). The examples given include a grow-only counter and a 2P-Set, each described as a sequential labeled transition system.

The proof methodology for operation-based CRDTs is organized around two ingredients: commutativity of concurrent effectors and a refinement map $\prec$8 (Enea et al., 2019). If two operations are concurrent, their effectors $\prec$9 must commute:

$\gamma$0

In addition, the refinement map must preserve both updates and pure queries, so that replaying causal effectors in the abstract specification yields a valid linearization. This is the basis of the paper’s proof methodology and its mechanized proofs.

In the merge-based verification setting, the proof obligations are stated directly as algebraic properties of $\gamma$1 and the update operator $\gamma$2. The key schemes are: commutativity of merge and update-application, commutativity of merge arguments, merge-idempotence on identical inputs, and conditional commutativity of concurrent updates not related by $\gamma$3 (Soundarapandian et al., 27 Feb 2025). These go beyond the standard notions of commutativity, associativity, and idempotence, because they are tailored to constructing a linearization witness across branches and merges.

When $\gamma$4 is non-empty, the basic commutation law between merge and updates is refined into a conflict-aware peel-off rule. If $\gamma$5, then

$\gamma$6

The framework also requires a “no-rc-chain” restriction,

$\gamma$7

together with “conditional commutativity” for cases in which non-commuting events are later overwritten (Soundarapandian et al., 27 Feb 2025). These restrictions are not cosmetic: they rule out pathological interleavings that defeat the bottom-up argument.

4. Bottom-up linearization

The principal technical device in the 2025 work is bottom-up linearization, an inductive proof principle for merge-based replication (Soundarapandian et al., 27 Feb 2025). When merging versions $\gamma$8 with lowest common ancestor $\gamma$9, the merge has three inputs $(i)$0 corresponding to the ancestor and the two branch states. Assuming

$(i)$1

the goal is to construct a single witness $(i)$2 such that $(i)$3 and $(i)$4 extends $(i)$5.

The bottom-up strategy repeatedly peels off the last event that appears in one of the three arguments. The paper states three core reduction rules. The two-branch rule is

$(i)$6

when $(i)$7 and $(i)$8. The one-branch rule applies when the other branch has no locals:

$(i)$9

The LCA-only rule is

$(ii)$0

These are combined with merge-idempotence $(ii)$1 and merge-commutativity $(ii)$2 (Soundarapandian et al., 27 Feb 2025).

The soundness argument is a two-level induction over the sizes of four event subsets $(ii)$3, $(ii)$4, $(ii)$5, and $(ii)$6. Theorem 1 states that if the implementation satisfies the five algebraic schemes, then it is RA-Lin (Soundarapandian et al., 27 Feb 2025). A plausible implication is that the proof obligation for replicated correctness can be reduced to a finite and highly structured equational core, instead of requiring bespoke global reasoning for each merge scenario.

5. Mechanized verification and automation

The 2025 framework is designed to make RA-Lin verification fully automated for MRDTs. The user supplies exactly the concrete type $(ii)$7 and $(ii)$8, the functions $(ii)$9, $(iii)$0, and $(iii)$1 in code, and the $(iii)$2 relation (Soundarapandian et al., 27 Feb 2025). From these ingredients, the framework automatically generates 12 verification conditions corresponding to the BottomUp-X-OP rules together with merge-idempotence and merge-commutativity.

The paper states that this framework can be implemented in F★, that the verification conditions are discharged by simple equational reasoning and SMT, and that once they all go through, Theorem 2 guarantees that the implementation is RA-linearizable (Soundarapandian et al., 27 Feb 2025). It further states that executable OCaml code is then extracted for use in a Git-style store. The metatheoretic statement is explicit: if $(iii)$3 satisfies the 12 mechanized VCs from Table 1, plus no-rc-chain, rc-non-comm, and cond-comm, then $(iii)$4 is RA-Lin.

The earlier 2019 work is likewise mechanized, though with a different proof architecture. For a wide spectrum of CRDTs, one writes down the payload, generator/effector code, a small sequential specification, a refinement map, checks that concurrent effectors commute or satisfy the weaker state-based lemmas, and discharges a handful of proof obligations in Boogie (Enea et al., 2019). The two papers therefore present complementary verification styles: refinement-and-commutativity for operation-based and state-based CRDTs in the original formulation, and equational VC generation with bottom-up linearization for merge-based replication.

6. Representative objects, composition, and scope

The two RA-Lin papers cover a broad range of examples. The 2019 work reports mechanized proofs for operation-based CRDTs including Counter (EO-lin.), OR-Set (EO), RGA list (TS-lin.), Wooki list (EO), and LWW-Register (TS), and for state-based CRDTs including PN-Counter (EO), 2P-Set (EO), Multi-Value Register (EO), and LWW-Element-Set (TS) (Enea et al., 2019). The 2025 work applies its automated method to complex MRDT and CRDT implementations, including an Observed-Remove Set and a polymorphic JSON MRDT (Soundarapandian et al., 27 Feb 2025).

Setting	Examples	Verification note
Operation-based CRDTs	Counter, OR-Set, RGA list, Wooki list, LWW-Register	Mechanized with commutativity, refinement, and Boogie (Enea et al., 2019)
State-based / merge-based objects	PN-Counter, 2P-Set, Multi-Value Register, LWW-Element-Set, OR-Set, polymorphic JSON MRDT	Verified via weaker state-based lemmas or via 12 algebraic VCs and SMT (Enea et al., 2019, Soundarapandian et al., 27 Feb 2025)

The Observed-Remove Set example in the 2025 treatment is fully concrete. Its state is $(iii)$5, its operations are $(iii)$6, and $(iii)$7; updates and merge are defined by set-algebraic expressions, and the 12 VCs are checked by case analysis on set algebra (Soundarapandian et al., 27 Feb 2025). The polymorphic JSON MRDT is defined by associating each key $(iii)$8 with a compile-time type $(iii)$9 of values, where each $\delta\colon\Sigma\to\Sigma$0 is a verified MRDT. Its update applies the underlying $\delta\colon\Sigma\to\Sigma$1 at one key, its merge is pointwise by $\delta\colon\Sigma\to\Sigma$2, and $\delta\colon\Sigma\to\Sigma$3 orders set-updates on the same key by $\delta\colon\Sigma\to\Sigma$4 (Soundarapandian et al., 27 Feb 2025). By simple parametricity, the JSON MRDT satisfies exactly the same VCs as each underlying $\delta\colon\Sigma\to\Sigma$5, hence is RA-Lin by Theorem 2 “for free” (Soundarapandian et al., 27 Feb 2025).

Composition is more delicate than might be expected. The 2019 paper states that the naïve product of two RA-Lin CRDTs need not be RA-Lin, because RA-Lin uses an arbitrary partial order of visibility, not an interval order as in shared-memory linearizability (Enea et al., 2019). However, if each object admits execution-order linearizations, then their synchronous composition is RA-linearizable and itself admits execution-order linearizations; if objects are timestamp-ordered, then composition requires a shared timestamp generator so that cross-object timestamps still respect visibility (Enea et al., 2019). This is one of the principal scope conditions of the criterion.

7. Misconceptions, limits, and significance

A common misconception is to treat RA-linearizability as merely another name for convergence. The papers explicitly separate the two. Strong eventual consistency guarantees that replicas receiving the same updates converge, whereas RA-Lin additionally requires a sequential explanation of each replica state or query result in terms of visible or incorporated updates (Soundarapandian et al., 27 Feb 2025, Enea et al., 2019). Another misconception is to read RA-Lin as classical linearizability under replication. The 2019 formulation states the opposite: RA-Lin is weaker than full linearizability and does not guarantee a real-time global order for queries; queries only need to be justified by the updates they have actually observed (Enea et al., 2019).

The criterion also does not fit every interface unchanged. The 2019 discussion notes that not every API can be given an RA-Lin specification under its original interface, with list addAt given as an example; one may need to revise the interface, as with readIds/write in OR-Set (Enea et al., 2019). In the merge-based automation setting, the algebraic proof method is subject to explicit side conditions such as no-rc-chain, rc-non-comm, and cond-comm (Soundarapandian et al., 27 Feb 2025). These are best understood as the boundary conditions under which bottom-up linearization is sound and automatable.

The significance of RA-Lin lies in the form of reasoning it enables. The 2019 work emphasizes sequential specifications, intuitive correspondence with linearizability, proof modularity, and mechanized support (Enea et al., 2019). The 2025 work sharpens this into an automated workflow that reduces merge-based replication correctness to a small finite list of purely equational VCs, discharged by SMT or equational reasoning, while yielding both convergence and per-replica sequential semantics (Soundarapandian et al., 27 Feb 2025). Taken together, these results position RA-linearizability as a specification and verification framework for replicated data types that is strong enough to recover sequential reasoning, yet tailored to the causality and merge structure of decentralized replication.