nii shonan meeting · 2019. 3. 31. · to prove that i is an invariant 9g 0 2 p (state ⇥ state),g...

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)

Upload: others

Post on 31-Aug-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Global-scale Internet service

Page 3: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 4: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 5: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Geo-replicated databases

• Every data centre stores a complete replica of data

• Purpose: Minimising latency. Fault tolerance.

Page 6: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Weakly consistent DBs

First update. Propagate later.

{(A,4)}

{(A,4)}

{(A,4)}

Page 7: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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

✘{(A,4)}

{(A,4)}

{(A,2)}

First update. Propagate later.

Page 8: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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

✘{(A,4)}

{(A,4)}

{(A,2)}

First update. Propagate later.

Page 9: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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

✘{(A,4)}

{(A,2)}

{(A,2)}

First update. Propagate later.

Page 10: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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

Page 14: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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

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

Page 15: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

How to write correct prog.?

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

Page 31: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Causal consistency

• Message delivery preserves the dependency of events.

Axiom: HB is transitive.

Page 32: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

How to write correct prog.?

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

Page 43: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

Our proof rule

• Based on rely-guarantee.

• Incorporates guarantees from causal and on-demand consistency.

Page 44: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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: NII Shonan Meeting · 2019. 3. 31. · To prove that I is an invariant 9G 0 2 P (State ⇥ State),G 2 Token ! P (State ⇥ State) such that S1. init 2 I S2. G 0 (I ) I ^8⌧ .G(⌧

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