’Cause I’m Strong Enough:
Reasoning about Consistency Choices in Distributed Systems
Alexey Gotsman
IMDEA Software Institute, Spain
Hongseok Yang
University of Oxford, UK
Carla Ferreira
NOVA LINCS, DI, FCT,
Universidade NOVA de Lisboa, Portugal
Mahsa Najafzadeh
Sorbonne Universit
´
es, Inria,
UPMC Univ Paris 06, France
Marc Shapiro
Sorbonne Universit
´
es, Inria,
UPMC Univ Paris 06, France
Abstract
Large-scale distributed systems often rely on replicated databases
that allow a programmer to request different data consistency guar-
antees for different operations, and thereby control their perfor-
mance. Using such databases is far from trivial: requesting stronger
consistency in too many places may hurt performance, and request-
ing it in too few places may violate correctness. To help program-
mers in this task, we propose the first proof rule for establishing
that a particular choice of consistency guarantees for various oper-
ations on a replicated database is enough to ensure the preservation
of a given data integrity invariant. Our rule is modular: it allows
reasoning about the behaviour of every operation separately under
some assumption on the behaviour of other operations. This leads
to simple reasoning, which we have automated in an SMT-based
tool. We present a nontrivial proof of soundness of our rule and
illustrate its use on several examples.
Categories and Subject Descriptors D.2.4 [Software Engineer-
ing]: Software/Program Verification; F.3.1 [Logics and Meanings
of Programs]: Specifying and Verifying and Reasoning about Pro-
grams
Keywords Replication; causal consistency; integrity invariants
1. Introduction
To achieve availability and scalability, many modern distributed
systems rely on replicated databases, which maintain multiple
replicas of shared data. Clients can access the data at any of the
replicas, and these replicas communicate changes to each other
using message passing. For example, large-scale Internet services
use data replicas in geographically distinct locations, and appli-
cations for mobile devices keep replicas locally to support offline
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
POPL’16, January 20–22, 2016, St. Petersburg, FL, USA.
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 978-1-4503-3549-2/16/01. . .$15.00.
http://dx.doi.org/10.1145/http://dx.doi.org/10.1145/2837614.2837625
use. Ideally, we would like replicated databases to provide strong
consistency, i.e., to behave as if a single centralised node handles
all operations. However, achieving this ideal usually requires syn-
chronisation among replicas, which slows down the database and
even makes it unavailable if network connections between replicas
fail [2, 24].
For this reason, modern replicated databases often eschew syn-
chronisation completely; such databases are commonly dubbed
eventually consistent [47]. In these databases, a replica performs
an operation requested by a client locally without any synchronisa-
tion with other replicas and immediately returns to the client; the
effect of the operation is propagated to the other replicas only even-
tually. This may lead to anomalies—behaviours deviating from
strong consistency. One of them is illustrated in Figure 1(a). Here
Alice makes a post while connected to a replica r
1
, and Bob, also
connected to r
1
, sees the post and comments on it. After each of
the two operations, r
1
sends a message to the other replicas in the
system with the update performed by the user. If the messages with
the updates by Alice and Bob arrive to a replica r
2
out of order,
then Carol, connected to r
2
, may end up seeing Bob’s comment,
but not Alice’s post it pertains to. The consistency model of a repli-
cated database restricts the anomalies that it exhibits. For example,
the model of causal consistency [33], which we consider in this pa-
per, disallows the anomaly in Figure 1(a), yet can be implemented
without any synchronisation. The model ensures that all replicas in
the system see causally dependent events, such as the posts by Al-
ice and Bob, in the order in which they happened. However, causal
consistency allows different replicas to see causally independent
events as occurring in different orders. This is illustrated in Fig-
ure 1(b), where Alice and Bob concurrently make posts at r
1
and
r
2
. Carol, connected to r
3
initially sees Alice’s post, but not Bob’s,
and Dave, connected to r
4
, sees Bob’s post, but not Alice’s. This
outcome cannot be obtained by executing the operations in any to-
tal order and, hence, deviates from strong consistency.
Such anomalies related to the ordering of actions are often ac-
ceptable for applications. What is not acceptable is to violate cru-
cial well-formedness properties of application data, called integrity
invariants. Consistency models that do not require any synchroni-
sation are often too weak to ensure these. For example, consider a
toy banking application where the database stores the balance of a
single account that clients can make deposits to and withdrawals
from. In this case, an integrity invariant may require the account
balance to be always non-negative. Consider the database compu-
add(post)
r
1
r
2
add(comment)
query:
{comment}
(a)
add(postA)
r
1
r
2
r
3
r
4
query:
{postA}
add(postB)
query:
{postB}
(b)
withdraw(100):
✔
r
1
r
2
query: -100query: -100
σ
init
= 100
(c)
withdraw(100):
✔
Figure 1. Illustrations of replicated database computations.
add(post)
add(comment)
query:
{post, comment}
(a)
add(postA)
query: {postA}
add(postB)
(b)
query: {postB}
withdraw(100):
{τ}, ✔
query: 0query: 0
σ
init
= 100, τ ⋈ τ
(c)
withdraw(100):
{τ}, ✔
Figure 2. Examples illustrating Definition 1. We omit return values when they are ⊥ and token sets when they are empty.
tation in Figure 1(c), allowed by causal consistency. Initially all
replicas store the same balance of 100. Alice and Bob, connected
to r
1
and r
2
, both withdraw 100, thinking that there are sufficient
funds available. Once the two replicas exchange the updates, the
balance becomes −100, violating the integrity invariant. To ensure
the integrity invariant in this example, we have to introduce syn-
chronisation between replicas, and, since synchronisation is expen-
sive, we would like to introduce it sparingly. To allow this, some
research [9, 32, 42, 44] and commercial [6, 10, 35] databases now
provide hybrid consistency models that allow the programmer to
request stronger consistency for certain operations and thereby in-
troduce synchronisation. For example, a consistency model may
execute some operations under causal consistency, and some under
strong consistency [32]. To preserve the integrity invariant in our
banking application when using this model, only withdrawal op-
erations need to use strong consistency, and hence, synchronise to
ensure that the account is not overdrawn; deposit operations may
use causal consistency and hence proceed without synchronisation.
Requesting stronger consistency in hybrid models is similar to the
use of fences in weak memory models of shared-memory multipro-
cessors and programming languages [11] (see §7 for a comparison).
Even though hybrid consistency models allow the programmer
to fine-tune consistency level, using these models effectively is far
from trivial. Requesting stronger consistency in too many places
may hurt performance and availability, and requesting it in too
few places may violate correctness. Striking the right balance re-
quires the programmer to reason about the application behaviour
on the subtle semantics of the consistency model, taking into ac-
count which anomalies are disallowed by a particular consistency
strengthening and whether disallowing these anomalies is enough
to ensure correctness. This difficulty is compounded by the peren-
nial challenge of reasoning about concurrency, present even with
strong consistency—having to consider the huge number of possi-
ble interactions between concurrently executing operations.
To help programmers exploit hybrid consistency models, we
propose the first proof rule and tool for proving integrity invariants
of applications using replicated databases with a range of hybrid
models. In more detail, our first contribution is a generic hybrid
consistency model (§2) that is flexible enough to encode a variety
of consistency models for replicated databases proposed in the lit-
erature [9, 32, 33, 42]. It guarantees causal consistency by default
and allows the programmer to additionally specify which pairs of
operations may not execute without synchronisation by means of a
special conflict relation. For example, to ensure the non-negativity
of balances in the banking application, the conflict relation may re-
quire any pair of withdrawals to synchronise, so that one of them
is aware of the effect of the other. This is equivalent to execut-
ing withdrawals under strong consistency. In general, different in-
stances of the conflict relation correspond to different interfaces
for strengthening consistency proposed in the literature. Our proof
rule is developed for the generic consistency model and, hence,
applies to existing models that can be represented as its instanti-
ations. We specify our consistency model formally (§3) using the
approach previously proposed for specifying variants of eventual
consistency [15]. In this approach, a database computation is de-
noted by a partial order on client operations, representing causality,
and the conflict relation imposes additional constraints on this or-
der.
Our next, and key, technical contribution is a proof rule for
showing that a set of operations preserves a given integrity invari-
ant when executed on our consistency model with a given choice of
conflict relation (§4). For example, we can prove that withdrawals
and deposits preserve the non-negativity of balances when executed
with the conflict relation described above. To avoid explicit reason-
ing about all possible interactions between operations, our proof
rule is modular: it allows us to reason about the behaviour of every
operation separately under some assumption on the behaviour of
other operations, which takes into account the conflict relation. In
this way, our proof rule allows the programmer to reason precisely
about how strengthening or weakening consistency of certain oper-
ations affects correctness.
The modular nature of our proof rule allows it to reason in
terms of states of a single database copy, just like in proof rules for
strongly consistent shared-memory concurrency. We have proved
that this simple reasoning is sound, despite the weakness of the
consistency model (§5). As part of this proof we have identified
a more general event-based rule that reasons directly in terms
of partial orders on events representing database computations,
instead of database states that these events lead to. The soundness
of the original state-based rule is proved by deriving it from the
event-based one. In this way, the event-based rule explicates the
reasons for the soundness of the state-based rule.
We have also developed a prototype tool that automates our
proof rule by reducing checking its obligations to SMT queries
(§6). Using the tool, we have verified several example applications
that require strengthening consistency in nontrivial ways. These
include an extension of the above banking application, an online
auction service and a course registration system. In particular, we
were able to handle applications using replicated data types (aka
CRDTs [40]), which encapsulate policies for automatically merg-
ing the effects of operations performed without synchronisation at
different replicas. The fact that we can reduce checking the correct-
ness properties of complex computations in our examples to query-
ing off-the-shelf SMT tools demonstrates the simplicity of reason-
ing required by our approach.
2. Consistency Model, Informally
We start by presenting our generic consistency model. Even though
this model is not implemented in its full generality by an existing
database, it can encode a variety of models that have in fact been
implemented. In this section we present the programming interface
of our consistency model and describe its semantics informally,
from an operational perspective. We give a formal semantics in §3.
2.1 Causal Consistency and Its Implementation
Our hybrid model guarantees at least causal consistency [33], al-
ready mentioned in §1. We therefore start by presenting informally
how a typical implementation of a causally consistent database op-
erates. Let State be the set of possible states of the data managed
by the database system. We denote states by σ and let σ
init
be a
distinguished initial state. Applications define a set of operations
Op = {o, . . .} on the data and interact with the database by issu-
ing these operations. For simplicity, we assume that an operation
always terminates and returns a single value from a set Val. We use
a value ⊥ ∈ Val to model operations that return no value. We do
not consider operation parameters, since these can be part of the
operation name.
The database implementation consists of a set of replicas, each
maintaining a complete copy of the database state; we identify
replicas by r
1
, r
2
, . . . For the purposes of the informal explanation,
we assume that replicas never fail. A client operation is initially ex-
ecuted at a single replica, which we refer to as its origin replica. At
this replica, the execution of the operation is not interleaved with
that of others. This execution updates the replica state determinis-
tically, and immediately returns a value to the client. After this, the
replica sends a message to all other replicas containing the effect
of the operation, which describes the updates done by the opera-
tion to the database state. The replicas are guaranteed to receive the
message at most once. Upon receipt, the replicas apply the effect to
their state.
In this paper, we abstract from a particular language in which
operations may be written and assume that their semantics is given
by a function
F ∈ Op → (State → (Val × (State → State))). (1)
To aid readability, for o ∈ Op we write F
o
instead of F(o) and let
∀o, σ. F
o
(σ) = (F
val
o
(σ), F
eff
o
(σ)).
Given a state σ of o’s origin replica, F
val
o
(σ) ∈ Val determines the
return value of the operation and F
eff
o
(σ) ∈ State → State its
effect. The latter is a function, to be applied by every replica to its
state to incorporate the operation’s effect: immediately at the origin
replica, and after receiving the corresponding message at all other
replicas.
For example, states in the toy banking application of §1 are
integers, representing the account balance: State = Z. We define
deposit
(20)
r
1
r
2
interest
query:
125
query:
125
(a)
deposit
(20)
interest
query:
125
query:
125
(b)
Figure 3. (a) An illustration of a database computation; (b) the
corresponding execution of Definition 1. We assume σ
init
= 100.
the semantics of operations for depositing an amount a > 0,
accruing a 5% interest and querying the balance:
F
deposit(a)
(σ) = (⊥, (λσ
0
. σ
0
+ a));
F
interest
(σ) = (⊥, (λσ
0
. σ
0
+ 0.05 ∗ σ));
F
query
(σ) = (σ, skip),
(2)
where skip = (λσ
0
. σ
0
). Figure 3(a) illustrates a database compu-
tation involving these operations. Note that interest first computes
the interest 0.05 ∗ σ based on the balance σ at the origin replica; its
effect then adds the resulting amount to the balance at each replica.
In particular, in Figure 3(a) interest at r
2
does not take into account
the deposit made at r
1
. This behaviour is the price to pay for avoid-
ing synchronisation between replicas. The good news is that, once
the replicas r
1
and r
2
exchange the effects of deposit and interest,
they converge to the same balance, which is returned by the query
operations.
Such convergence is not guaranteed for arbitrary operations. For
example, we could implement interest so that its effect multiplied
the balance by 1.05 at each replica where it is applied:
F
eff
interest
(σ) = (λσ
0
. (1.05 ∗ σ
0
)). (3)
In the scenario in Figure 3(a), this would lead the query operations
to return different values, 126 at r
1
and 125 at r
2
. In this case,
even after all messages are delivered, replicas end up in different
states. This is undesirable for database users: we would like the
implementation to be convergent, i.e., such that two replicas that
see the same set of operations are in the same state. In particular,
if users stop performing updates to the database, then once all
outstanding messages are delivered, all replicas should reach the
same state [47]. To ensure convergence, for now we require that the
effects of all operations commute (we relax this condition slightly
in §2.2):
∀o
1
, o
2
, σ
1
, σ
2
. F
eff
o
1
(σ
1
) ◦ F
eff
o
2
(σ
2
) = F
eff
o
2
(σ
2
) ◦ F
eff
o
1
(σ
1
). (4)
For example, this condition holds of the effects defined by (2). The
requirement of commutativity is not very taxing: as we elaborate
in §6, to satisfy (4), programmers can exploit ready-made repli-
cated data types (aka CRDTs [40]). These encapsulate commuta-
tive implementations of policies for merging concurrent updates to
the database.
As we explained in §1, asynchronous operation processing may
lead to anomalies, and causal consistency disallows some of them.
It ensures that message propagation between replicas is causal: if a
replica sends a message containing the effect of an operation o
2
after it sends or receives a message containing the effect of an
operation o
1
, then no replica will receive the message about o
2
before it receives the one about o
1
. In this case we say that the
invocation of o
2
causally depends on that of o
1
. Causal propagation
disallows the computation in Figure 1(a), but allows the one in
Figure 1(b).
Token = {τ }
= {(τ, τ )}
F
deposit(a)
(σ) = (⊥, (λσ
0
. σ
0
+ a), ∅)
F
interest
(σ) = (⊥, (λσ
0
. σ
0
+ 0.05 ∗ σ), ∅)
F
query
(σ) = (σ, skip, ∅)
F
withdraw(a)
(σ) = if σ ≥ a then (X, (λσ
0
. σ
0
− a), {τ})
else (7, skip, {τ })
Figure 4. Operation semantics for the banking application. Note
that a > 0.
2.2 Strengthening Consistency
The guarantees provided by causal consistency are too weak to
ensure certain integrity invariants. For example, in our banking
application we would like the state at each replica to satisfy the
invariant
I = {σ | σ ≥ 0}. (5)
To ensure this, an operation for withdrawing an amount a > 0
could check whether the account has sufficient funds and return X
or 7 depending on the result:
F
withdraw(a)
(σ) = if σ ≥ a then (X, (λσ
0
. σ
0
− a)) else (7, skip).
This is enough to maintain the invariant when all operations are
processed at the same replica, but not when they are processed
asynchronously at different replicas. This is illustrated by the com-
putation in Figure 1(c), already explained in §1.
The problem in this example arises because two particular op-
erations update the database concurrently, without being aware of
each other. To address this, our consistency model allows the pro-
grammer to strengthen causal consistency by specifying explic-
itly which operations may not be executed in this way. Namely,
the model is parameterised by a token system T = (Token, ),
consisting of a set of tokens Token and a symmetric conflict re-
lation ⊆ Token × Token. Tokens are ranged over by τ and
their sets, by T . For sets T
1
and T
2
of tokens we let T
1
T
2
if there exists a pair of conflicting tokens coming from these sets:
∃τ
1
∈ T
1
. ∃τ
2
∈ T
2
. τ
1
τ
2
.
Each operation may acquire a set of tokens. To account for this,
we redefine the type of F in (1) as
F ∈ Op → (State → (Val × (State → State) × P(Token)))
(6)
and let
∀o, σ. F
o
(σ) = (F
val
o
(σ), F
eff
o
(σ), F
tok
o
(σ)).
Thus, F
tok
o
(σ) ∈ P(Token) gives the set of tokens acquired by
the operation o when executed in the state σ. Informally, our con-
sistency model guarantees that operations that acquire tokens con-
flicting according to have to be causally dependent one way or
another: the origin replica of one operation must have incorpo-
rated the effect of the other by the time the former operation ex-
ecutes. Ensuring this in implementations requires replicas to syn-
chronise [9, 32].
In our consistency model, we can guarantee the preservation of
invariant (5) in the banking application by defining operation se-
mantics as in Figure 4. Thus, withdraw acquires a token τ con-
flicting with itself, and all other operations do not acquire any to-
kens. Then the scenario in Figure 1(c) cannot happen: one with-
drawal would have to be aware of the other and would therefore
fail. However, deposits and interest accruals can be causally inde-
pendent with all operations, and replicas can therefore execute them
without any synchronisation [9, 32]. In this example, the token τ is
analogous to a mutual exclusion lock in shared-memory concur-
rency. Our proof method (§4) establishes that this use of the token
is indeed sufficient to preserve the integrity invariant (5).
Since operations acquiring conflicting tokens have to be
causally dependent, causal message propagation (§2.1) ensures that
all replicas see such operations in the same order. This allows us to
weaken (4) to require commutativity only for operations that do not
acquire conflicting tokens:
∀o
1
, o
2
, σ
1
, σ
2
. (F
tok
o
1
(σ
1
) F
tok
o
2
(σ
2
)) ∨
(F
eff
o
1
(σ
1
) ◦ F
eff
o
2
(σ
2
) = F
eff
o
2
(σ
2
) ◦ F
eff
o
1
(σ
1
)). (7)
As we show in §3, this is sufficient to ensure the property of con-
vergence that we introduced in §2.1. For example, the operations
in Figure 4 satisfy (7). Furthermore, if all operations except query
acquired the token τ, then we would be able to implement interest
by the effect given by (3) without compromising convergence.
3. Formal Semantics
We now formally define the semantics of our consistency model,
i.e., the set of all client-database interactions it allows. To keep
the presentation as simple as possible, we define the semantics
declaratively: our formalism does not refer to implementation-level
concepts, such as replicas or messages, even though we do use
these concepts in informal explanations. We build on an approach
previously used to specify forms of eventual consistency [15].
Namely, our denotations of database computations consist of a
set of events, representing operation invocations by clients, and a
relation on events, describing abstractly how the database processes
the corresponding operations.
Assume a countably infinite set Event of events, ranged over
by e, f, g. A relation is a strict partial order if it is transitive and
irreflexive. For a relation R we write (e, f ) ∈ R and e
R
−→ f
interchangeably.
DEFINITION 1. Given a token system T = (Token, ), an execu-
tion is a tuple X = (E, oper, rval, tok, hb), where:
•
E is a finite subset of Event;
•
oper : E → Op gives the operation whose invocation a given
event denotes;
•
rval : E → Val gives the return value of the operation;
•
tok : E → P(Token) gives the set of tokens acquired by the
operation;
•
hb ⊆ E × E, called happens-before, is a strict partial order
such that
∀e, f ∈ E. tok(e) tok(f) =⇒ (e
hb
−→ f ∨ f
hb
−→ e). (8)
Operationally, each event represents an invocation of an opera-
tion at its origin replica. The applications of the operation’s effect at
other replicas are not recorded in an execution explicitly. Instead,
the happens-before relation records causal dependencies between
operations arising from such applications: e
hb
−→ f means that ei-
ther the operations denoted by e and f were executed at the same
replica in this order, or they were executed at different replicas and
the message containing the effect of e had been delivered to the
replica performing f before f was executed. Hence, if we have
e
hb
−→ f , then the effect of e is incorporated into the state to which
f is applied and may influence its return value. We give examples of
executions in Figures 2 and 3(b). The ones in Figures 2(b) and 3(b)
model the computations of the database informally illustrated in
Figures 1(b) and 3(a), respectively.
The transitivity of hb in Definition 1 reflects the guarantee
of causal message propagation in implementations explained in
§2.1 [15]. For example, in the execution of Figure 2(a), the tran-
sitivity of hb mandates the edge between the addition of a post
and the query (cf. Figure 1(a)). The condition (8) formalises the
stronger consistency guarantee provided by tokens: operations ac-
quiring conflicting tokens have to be causally dependent. For ex-
ample, since the two withdraw operations in Figure 2(c) acquire a
token τ with τ τ , they have to be related by happens-before.
Finally, we require executions to contain only finitely many events,
because in this paper we are only concerned with safety properties
of applications.
We write Exec(T ) for the set of all executions over the token
system T . In the following, we denote components of X and
similar structures as in X.E. We let X
init
be the unique execution
with X
init
.E = ∅.
We now define the semantics of our consistency model as the
set of all executions X ∈ Exec(T ) over a token system T whose
return values X.rval and token sets X.tok are computed using F as
informally described in §2. To define this set, we first let the context
of an event e in an execution X be
ctxt(e, X) = (E, (X.oper)|
E
, (X.rval)|
E
, (X.tok)|
E
, (X.hb)|
E
),
where E = (X.hb)
−1
(e) and ·|
E
is the restriction to events in E.
Operationally-speaking, the context consists of those events whose
effects have been incorporated into the state of the replica where
the operation X.oper(e) executes; it is these events that influence
the outcomes of e—the return value X.rval(e) and the token set
X.tok(e). For example, the context of each of the query events in
Figure 3(b) consists of the deposit and interest events. This reflects
the events that the corresponding replica has seen before executing
query in Figure 3(a).
It is technically convenient for us to initially formulate
definitions without assuming effect commutativity (7). In this
case, X.rval(e) and X.tok(e) are not determined by ctxt(e, X)
uniquely. In operational terms, this is because the state that a replica
will be in after seeing the events in ctxt(e, X) depends on the order
in which the replica finds out about these events: although causal
message propagation ensures that messages about causally depen-
dent events in ctxt(e, X) will be delivered to the replica in the order
consistent with X.hb, messages about causally independent events
may be delivered in arbitrary order. We therefore first define a func-
tion
eval
†
F
: Exec(T ) → P(State)
that yields the set of all possible states that a replica may end up
in after seeing the events in a given execution, such as ctxt(e, X).
For an execution Y , we define eval
†
F
(Y ) inductively on the size of
Y.E. If Y.E = ∅, then eval
†
F
(Y ) = {σ
init
}. Otherwise,
eval
†
F
(Y ) = {F
eff
Y.oper(e)
(σ
0
)(σ) | e ∈ max(Y ) ∧
σ ∈ eval
†
F
(Y |
Y.E−{e}
) ∧ σ
0
∈ eval
†
F
(ctxt(e, Y ))},
where
max(Y ) = {e ∈ Y.E | ¬∃f ∈ Y.E. (e, f ) ∈ Y.hb}. (9)
Thus, to compute eval
†
F
(Y ) for a non-empty Y , we choose an hb-
maximal event e in Y . Operationally, this is the event whose effect
is incorporated last by the replica r whose state we are determining.
We then pick a state σ that r could be in right before incorporating
the effect of e. The set of such states is obtained by invoking eval
†
F
on the execution Y |
Y.E−{e}
, describing the events r knew about
when it incorporated e. To determine the effect of e’s operation,
we pick a state σ
0
that the replica r
0
that generated e could be in
at the time of this generation. The set of such states is computed
by invoking eval
†
F
on the execution ctxt(e, Y ), describing the
events that replica r
0
knew about when it generated e. Then the
effect of e’s operation is F
eff
Y.oper(e)
(σ
0
), and we determine the
state of the replica r after e by applying this effect to the state σ:
F
eff
Y.oper(e)
(σ
0
)(σ).
To illustrate eval
†
F
, consider the execution Y consisting of the
dep osit and interest events in Figure 3(b) and the operation se-
mantics F in Figure 4. Recall that in this case σ
init
= 100. We
can evaluate Y in two ways, corresponding to the orders in which
replicas r
1
, respectively r
2
, apply the effects of the events in the
computation in Figure 3(a):
eval
†
F
(Y ) = {F
eff
interest
(σ
init
)(F
eff
deposit(20)
(σ
init
)(σ
init
)),
F
eff
deposit(20)
(σ
init
)(F
eff
interest
(σ
init
)(σ
init
))}
= {100 + 20 + 5, 100 + 5 + 20} = {125}.
Both ways of evaluation lead to the same outcome. This would not
be the case if we used a function F
0
identical to F, but with the
effect of interest defined by (3), which violates (7). In this case,
eval
†
F
0
(Y ) = {100 + 20 + 6, 100 + 5 + 20} = {126, 125},
which corresponds to the diverging database computation we ex-
plained in §2.1.
We note that, for notational convenience, eval
†
F
takes as a pa-
rameter a whole execution including return values (rval) and token
sets (tok) associated with its events. However, the function as we
defined it does not depend on these: the state is determined solely
based on the operations performed (oper) and happens-before rela-
tionships among them (hb).
DEFINITION 2. An execution X ∈ Exec(T ) is consistent with T
and F, denoted X |= T , F, if
∀e ∈ X.E. ∃σ ∈ eval
†
F
(ctxt(e, X)).
(X.rval(e) = F
val
X.oper(e)
(σ)) ∧ (X.tok(e) = F
tok
X.oper(e)
(σ)).
We let Exec(T , F) = {X | X |= T , F} be the set of executions
allowed by our consistency model.
PROPOSITION 3.
∀X ∈ Exec(T , F). ∀e ∈ X.E. (ctxt(e, X) ∈ Exec(T , F)).
Operationally, X |= T , F means that the outcomes in X can be
produced by the database implementation sketched in §2 with some
order of message delivery. The executions in Figures 2 and 3(b)
are consistent with the parameters in Figure 4 or the expected
semantics of operations on posts and comments. In particular, the
execution in Figure 2(c) is consistent because the context of the
right-hand-side withdraw includes the left-hand-side withdraw.
Evaluating this context yields a zero balance, which causes the
right-hand-side withdraw to generate skip as its effect.
LEMMA 4. If X |= T , F, then eval
†
F
(X) is a singleton set. Fur-
thermore, so is eval
†
F
(ctxt(e, X)) for any e ∈ X.E.
The lemma shows that in Definition 2 it does not matter how
we choose the order of evaluation in eval
†
F
. When viewed oper-
ationally, this independence implies the convergence property from
§2.1: two replicas that see the same events will end up in the same
state. The proof of Lemma 4, given in [26, §A], exploits proper-
ties (7) and (8). This proof is subtle because (7) does not require
commutativity for the effects of pairs of operations that acquire
conflicting tokens.
Motivated by Lemma 4, we define the evaluation of consistent
executions
eval
F
: Exec(T , F) → State
as follows: eval
F
(X) is the unique σ such that eval
†
F
(X) = {σ}.
To illustrate the flexibility of our consistency model, we show
how it can represent some of the existing models; we provide more
instantiations in §6.
