65
Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint work with Alexey Gotsman (IMDEA, Spain), Carla Ferreira (U Nova Lisboa), Mahsa Najafzadeh, Marc Shapiro (INRIA)

Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Reasoning about consistency choices in distributed systems

Hongseok YangUniversity of Oxford

Joint work with Alexey Gotsman (IMDEA, Spain), Carla Ferreira (U Nova Lisboa), Mahsa Najafzadeh, Marc Shapiro (INRIA)

Page 2: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Global-scale Internet service

Page 3: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 4: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 5: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 6: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBs

First update. Propagate later.

{(A,4)}

{(A,4)}

{(A,4)}

Page 7: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.read() : {A}

✘{(A,4)}

{(A,4)}

{(A,2)}

First update. Propagate later.

Page 8: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.read() : {A}

✘{(A,4)}

{(A,4)}

{(A,2)}

First update. Propagate later.

Page 9: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.read() : {A}

✘{(A,4)}

{(A,2)}

{(A,2)}

First update. Propagate later.

Page 10: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.count(A): 4

✘{(A,4)}

{(A,2)}

{(A,2)}

Issue 1: Anomalies

First update. Propagate later.

Page 11: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.count(A): 4

✘{(A,0)}

{(A,2)}

{(A,2)}

Issue 2: Conflicting updates

cart.remAll(A)

First update. Propagate later.

Page 12: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Weakly consistent DBscart.rem(A,2)cart.count(A): 4

✘{(A,0)}

{(A,2)}

{(A,2)}

cart.remAll(A)

remAll(A)

rem(A,2)

First update. Propagate later.

Issue 2: Conflicting updates

Page 13: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

How to develop correct programs running on top of weakly consistent distributed databases?

Page 14: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

How to develop correct programs running on top of weakly consistent distributed databases?

1. Strengthen consistency selectively.2. Use rely-guarantee reasoning.

Page 15: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

How to develop correct programs running on top of weakly consistent distributed databases?

1. Strengthen consistency selectively.2. Prove the correctness of a program.

Page 16: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Simple bank account

class account { // invariant: amount >= 0 var amount = 0

def query() = { return amount } def inc() = { amount = amount+1; return true } def dec() = { if (amount > 0) { amount = amount-1; return true } else { return false } } }

Page 17: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Distributed bank account

class account { // invariant: amount >= 0 var[dis] amount = 0

def query() = { return (amount, (a)=>a) } def inc() = { amount = amount+1; return (true, (a)=>a+1) } def dec() = { if (amount > 0) { amount = amount-1; return (true, (a)=>a-1) } else { return (false, (a)=>a) } } }

Page 18: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

Page 19: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

Page 20: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

Page 21: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++

Page 22: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a—

a—

Page 23: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++

a—

a— skip

Page 24: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

Page 25: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++

Page 26: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a—

Page 27: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

Page 28: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

Page 29: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a— a—

Page 30: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

How to write correct prog.?

1. Strengthen consistency selectively.2. Prove the correctness of a program.

Page 31: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Causal consistency

• Message delivery preserves the dependency of events.

Axiom: HB is transitive.

Page 32: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a— a—

a++

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Page 33: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a— a—

a++

Not causally consistent.

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Page 34: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

use causality

class account { // invariant: amount >= 0 var[dis] amount = 0

def query() = { return (amount, (a)=>a) } def inc() = { amount = amount+1; return (true, (a)=>a+1) } def dec() = { if (amount > 0) { amount = amount-1; return (true, (a)=>a-1) } else { return (false, (a)=>a) } } }

Page 35: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Token system

• (T, 💔) where 💔 is a symmetric rel. on T.

• Examples:

1. T = {lock}, 💔 = {(lock,lock)}

2. T = {rd,wr}, 💔 = {(rd,wr), (wr,wr), (wr,rd)}

Page 36: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

On-demand consistency using a token system (T, 💔)

• Each operation acquires a set of tokens.

• Operations with conflicting tokens cannot be run concurrently.

Page 37: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

a—

Page 38: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

{lock}

{lock}{}

{}

T = {lock}💔 = {(lock, lock)}

a—

Page 39: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

{lock}

{lock}{}

{}

T = {lock}💔 = {(lock, lock)}

a—

Page 40: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

dec()

query()

[Q] What cannot be the result of query()?(a) 0 (b) -1 (c) -2 (d) all possible

Bob in UK

Alice in Korea

inc() dec()

Carol in USA

a++

a++ a— a—

{lock}

{lock}{}

{}

T = {lock}💔 = {(lock, lock)}

a—

skip

Page 41: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

use causality

class account { // invariant: amount >= 0 var[dis] amount = 0 use-token-system({lock},{(lock,lock)})

def query() with {} = { return (amount, (a)=>a) } def inc() with {} = { amount = amount+1; return (true, (a)=>a+1) } def dec() with {lock} = { if (amount > 0) { amount = amount-1; return (true, (a)=>a-1) } else { return (false, (a)=>a) } } }

Page 42: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

How to write correct prog.?

1. Strengthen consistency selectively.2. Prove the correctness of a program.

Page 43: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

Our proof rule

• Based on rely-guarantee.

• Incorporates guarantees from causal and on-demand consistency.

Page 44: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 45: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 46: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 47: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 48: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 49: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 50: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .. . .

Page 51: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .. . .

Page 52: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .. . .

Page 53: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .. . .

Page 54: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

Page 55: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

T⊥ = {𝝉 | ∄𝝉’∈T. (𝝉, 𝝉ʹ) ∈ 💔}

Page 56: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

Page 57: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

dec()

Page 58: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .{}

{lock}

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

dec()

Page 59: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

dec()

{}

{lock}

G*0

G0 ∪ G1(lock)

Page 60: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

dec()

{}

{lock}

G*0

G0 ∪ G1(lock)

Page 61: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

To prove that I is an invariant

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

. . .

. . .

I = { σ | 0 ≤ σ }G0 = {(σ, σ’) | σ ≤ σ’}G1(lock) = {(σ, σ’) | 0 < σ ∧ σ’ ≤ σ}

dec()

{}

{lock}

G*0

G0 ∪ G1(lock)if 0 < σ then σ’-1 else σ’

Page 62: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

What if no on-demand consistency?

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

Page 63: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

What if no on-demand consistency?

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

G*

G

Page 64: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

What if no causality?

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

G*

G

Page 65: Reasoning about consistency choices in distributed systems · 2015. 8. 14. · Reasoning about consistency choices in distributed systems Hongseok Yang University of Oxford Joint

What if no causality?

9G0 2 P(State⇥ State), G 2 Token ! P(State⇥ State)such that

S1. �init

2 I

S2. G0(I) ✓ I ^ 8⌧. G(⌧)(I) ✓ I

S3. 8o,�,�0. (� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤)

=) (�

0,F

e↵

o

(�)(�

0)) 2 G0 [G(F

tok

o

(�))

Exec(T ,F) ✓ eval�1F (I)

Figure 5. State-based proof rule for a token system T =

(Token, ./). For T ✓ Token we let G(T ) =

S⌧2T

G(⌧) andT

?= {⌧ | ⌧ 2 Token ^ ¬9⌧

02 T. ⌧ ./ ⌧

0}. We denote by R

the reflexive and transitive closure of a relation R. For a relationR 2 P(A ⇥ B) and a predicate P 2 P(A), the expression R(P )

denotes the image of P under R.

��

r

r�

(a) (b)

e

XX �

X ��F e↵

o (�)

Figure 6. Graphical illustrations of (a) the state-based rule; and (b)the event-based rule.

The key challenge of the above verification problem is theneed to consider infinitely many executions consistent with T andF . Our main technical contribution is the proof rule for solvingthis problem that avoids considering all such executions explicitly.Instead, the proof rule is modular in that it allows us to reasonabout the behaviour of every operation separately. Our proof ruleis also state-based in that it reasons in terms of states obtained byevaluating parts of executions or, from the operational perspective,in terms of replica states.

We give our proof rule in Figure 5 and explain it from the op-erational perspective. The rule assumes that the invariant I holdsof the initial database state �

init

(condition S1). Consider a compu-tation of the database implementation from §2 and a state � of areplica r at some point in this computation. The proof rule assumesthat � 2 I and aims to establish that executing any operation o at rwill preserve the invariant I . This is easy if we only consider howo’s effect changes the state of r, since this effect is applied to thestate � where it was generated:

8�. (� 2 I =) F

e↵

o

(�)(�) 2 I). (10)

The difficulty comes from the need to consider how o’s effectchanges the state of any other replica r

0 that receives it; see Fig-ure 6(a). At the time of the receipt, r0 may be in a different state�

0, due to operations executed at r0 concurrently with o. We canshow that it is sound to assume that this state �

0 also satisfies theinvariant. Thus, to check that the operation o preserves the invariantwhen applied at any replica, it is sufficient to ensure

8�,�

0. (�,�

02 I =) F

e↵

o

(�)(�

0) 2 I). (11)

However, establishing this without knowing anything about the re-lationship between � and �

0 is a tall order. In the bank accountexample, both � = 100 and �

0= 0 satisfy the integrity invari-

ant (5). Then F

e↵

withdraw(100)(�)(�0) = �100, which violates the

invariant. Condition (11) fails in this case because it does not takeinto account the tokens acquired by withdraw.

The proof rule in Figure 5 addresses the weakness of (11) by al-lowing us to assume a certain relationship between the state wherean operation is generated (�) and where its effect is applied (�0),which takes into account the tokens acquired by the operation. Toexpress this assumption, the rule uses a form of rely-guarantee rea-soning [25]. Namely, it requires us to associate each token ⌧ with aguarantee relation G(⌧), describing all possible state changes thatan operation acquiring ⌧ can cause. Crucially, this includes not onlythe changes that the operation can cause on the state of its originreplica, but also any change that its effect causes at any other replicait is propagated to. We also have a guarantee relation G0, describingthe changes that can be performed by an operation without acquir-ing any tokens. Condition S2 requires the guarantees to preservethe invariant.

Like (11), condition S3 considers an arbitrary state � of o’sorigin replica r, assumed to satisfy the invariant I . The conditionthen considers any state �

0 of another replica r

0 to which the effectof o is propagated. The conclusion of S3 requires us to prove thatapplying the effect F e↵

o

(�) of the operation o to the state �0 satisfiesthe union of the guarantees associated with the tokens F tok

o

(�) thatthe operation o acquires. By S2, this implies that the effect of theoperation preserves the invariant. Condition S3 further allows usto assume that the state �

0 of r

0 can be obtained from the state� of r by applying a finite number of changes allowed by G0 orthe guarantees for those tokens that do not conflict with any ofthe tokens acquired by the operation o, i.e., G0 [G((F

tok

o

(�))

?).

Informally, acquiring a token denies other replicas permissions toconcurrently perform changes that require conflicting tokens.

We now use our proof rule to show that the operations in thebanking application (Figure 4) preserve the integrity invariant (5).We assume that the initial state �

init

satisfies the invariant. Theguarantees are as follows:

G(⌧) = {(�,�

0) | 0 �

0< �};

G0 = {(�,�

0) | 0 � �

0}.

(12)

Since withdrawals acquire the token ⌧ , the guarantee G(⌧) for thistoken allows decreasing the balance without turning it negative;the guarantee G0 allows increasing a non-negative balance. Thencondition S2 is satisfied. We show how to check the condition S3in the most interesting case of o = withdraw(a). Consider � and�

0 satisfying the premiss of S3:

� 2 I ^ (�,�

0) 2 (G0 [G((F

tok

o

(�))

?))

⇤.

Since F

tok

o

(�) = {⌧}, we have that (F

tok

o

(�))

?= ;. Thus,

(�,�

0) 2 G

⇤0. This and � 2 I imply that

0 � �

0. (13)

If � < a, then F

e↵

o

(�)(�

0) = �

0. Furthermore, �0� 0 by

(13). Thus, (�0,F

e↵

o

(�)(�

0)) = (�

0,�

0) 2 G0, which implies the

conclusion of S3.If � � a, then F

e↵

o

(�)(�

0) = �

0� a. Since � �

0, by (13) wehave �

0� a. Thus, (�0

,F

e↵

o

(�)(�

0)) = (�

0,�

0� a) 2 G({⌧}),

which implies the conclusion of S3. Operationally, in this caseour proof rule establishes that, if there was enough money in theaccount at the replica where the withdrawal was made, then therewill be enough money at any replica the withdrawal is delivered to.This completes the proof of our example.

In a banking application with multiple accounts, we could en-sure non-negativity of balances by associating every account c witha token ⌧

c

such that ⌧c

./ ⌧

c

, but ⌧c

6./ ⌧

c

0 for another accountc

0. Thus, withdrawals from the same account would have to syn-chronise, while withdrawals from different accounts could proceedwithout synchronisation. Our proof rule easily deals with this gen-

6

σ’ ∈ I

Feff(σ)(σ’) ∈ Io