# A comparison with TLA+¶

In this notebook we'll go through the example from Hillel Wayne's Learn TLA+ to find out how concepts in TLA+ correspond to concepts in Imandra.

This notebook is intended to be read side-by-side with Hillel's example. We'll quote certain snippets from Learn TLA+ and explain how we could achieve the same in Imandra.

## The Problem¶

You’re writing software for a bank. You have Alice and Bob as clients, each with a certain amount of money in their accounts. Alice wants to send some money to Bob. How do you model this? Assume all you care about is their bank accounts.

## Step One¶

For this example, we could model the transfer algorithm very simply as a single function in Imandra. However, for comparison we'll try to model in a similar way to the PlusCal style. To do this we'll write our algorithm as a state machine.

The example defines the PlusCal variables alice_account, bob_account and money. For this we'll define a state record:

In [1]:
type state =
{ alice_account : int
; bob_account : int
; money : int
}

let init =
{ alice_account = 10
; bob_account = 10
; money = 5
}
Out[1]:
type state = { alice_account : Z.t; bob_account : Z.t; money : Z.t; }
val init : state = {alice_account = 10; bob_account = 10; money = 5}

A: and B: are labels. They define the steps the algorithm takes. Understanding how labels work is critical to writing more complex algorithms, as they define the places where your concurrency can go horribly awry.

We choose to model the steps A and B as a variant type action. The function step, given an action and a state, computes one step of the algorithm.

In [2]:
type action =
| A
| B

let step action state =
match action with
| A -> { state with alice_account = state.alice_account - state.money }
| B -> { state with bob_account = state.bob_account + state.money }
Out[2]:
type action = A | B
val step : action -> state -> state = <fun>

Now we can put everything together to define the transfer algorithm:

In [3]:
let transfer state =
state |> step A |> step B
Out[3]:
val transfer : state -> state = <fun>

So how do we run this? Well, we can’t.

In Imandra, this is real code! We can execute it, leveraging the OCaml runtime. Let's take a look at the results of executing each step:

In [4]:
init;;
init |> step A;;
init |> step A |> step B;;
Out[4]:
- : state = {alice_account = 10; bob_account = 10; money = 5}
- : state = {alice_account = 5; bob_account = 10; money = 5}
- : state = {alice_account = 5; bob_account = 15; money = 5}

## Assertions and Sets¶

Can Alice’s account go negative? Right now our spec allows that, which we don’t want. We can start by adding a basic assert check after the transaction.

In Imandra, we encode contracts and properties using verify statements.

In [5]:
verify (fun state ->
state.alice_account = 10 &&
state.bob_account = 10 &&
state.money = 5
==>
let state' = transfer state in
state'.alice_account >= 0
)
Out[5]:
- : state -> bool = <fun>
Proved
proof
ground_instances:0
definitions:0
inductions:0
search_time:
0.017s
details:
Expand
smt_stats:
 rlimit count: 232 num allocs: 5.93556e+06 time: 0.007 memory: 15.96 max memory: 15.96
Expand
• start[0.017s]
let (_x_0 : int) = ….alice_account in
let (_x_1 : int) = ….bob_account in
let (_x_2 : int) = ….money in
(( :var_0: ).alice_account = 10)
&& ((( :var_0: ).bob_account = 10) && (( :var_0: ).money = 5))
==> (if B = A
then {alice_account = _x_0 - _x_2; bob_account = _x_1; money = _x_2}
else {alice_account = _x_0; bob_account = _x_1 + _x_2; money = _x_2}).alice_account
>= 0
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).alice_account in let (_x_1 : int) = ( :var_0: ).money in not ((_x_0 = 10) && (( :var_0: ).bob_account = 10) && (_x_1 = 5)) || (_x_0 + (-1) * _x_1 >= 0) expansions: [] rewrite_steps: forward_chaining:
• Unsat

Here we've used the ==> operator. a ==> b can be read as "a implies b". We're saying: if both Alice and Bob's accounts are 10, and money is 5, then after the transfer Alice's account will not be negative.

Imandra has shown that our statement is true!

At the very least, it works for the one number we tried. That doesn’t mean it works for all cases. When testing, it’s often hard to choose just the right test cases to surface the bugs you want to find. This is because most languages make it easy to test a specific state but not a large set of them. In TLA+, though, testing a wide range is simple.

The only thing we changed was money = 5 to money \in 1..20

Let's amend our verify statement to test the same range:

In [6]:
verify (fun state ->
state.alice_account = 10 &&
state.bob_account = 10 &&
List.mem state.money List.(1 -- 20)
==>
let state' = transfer state in
state'.alice_account >= 0
)
Out[6]:
- : state -> bool = <fun>
module CX : sig val state : state end
Counterexample (after 32 steps, 0.027s):
let state : state = {alice_account = 10; bob_account = 10; money = 11}
Refuted
proof attempt
ground_instances:32
definitions:0
inductions:0
search_time:
0.027s
details:
Expand
smt_stats:
 num checks: 65 arith assert lower: 26 rlimit count: 11116 mk clause: 82 datatype occurs check: 144 mk bool var: 341 arith assert upper: 8 datatype splits: 21 decisions: 113 propagations: 94 conflicts: 77 datatype accessor ax: 30 arith assert diseq: 22 datatype constructor ax: 72 num allocs: 1.16339e+07 final checks: 54 added eqs: 302 del clause: 70 arith eq adapter: 27 memory: 16.65 max memory: 16.65
Expand
• start[0.027s]
let (_x_0 : int) = ….alice_account in
let (_x_1 : int) = ….bob_account in
let (_x_2 : int) = ….money in
(( :var_0: ).alice_account = 10)
&& ((( :var_0: ).bob_account = 10)
&& List.mem ( :var_0: ).money (List.( -- ) 1 20))
==> (if B = A
then {alice_account = _x_0 - _x_2; bob_account = _x_1; money = _x_2}
else {alice_account = _x_0; bob_account = _x_1 + _x_2; money = _x_2}).alice_account
>= 0
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).alice_account in let (_x_1 : int) = ( :var_0: ).money in not ((_x_0 = 10) && (( :var_0: ).bob_account = 10) && List.mem _x_1 (List.( -- ) 1 20)) || (_x_0 + (-1) * _x_1 >= 0) expansions: [] rewrite_steps: forward_chaining:
• unroll
 expr: (|List.mem_402/server| (money_1259/client state_1276/client) (|List.--_642/boot| 1 20)) expansions:
• unroll
 expr: (|List.--_642/boot| 1 20) expansions:
• unroll
 expr: (|List.--_642/boot| 2 20) expansions:
• unroll
 expr: (|List.mem_402/server| (money_1259/client state_1276/client) (|get.::.1_401/server| (|List.--_64… expansions:
• unroll
 expr: (|List.--_642/boot| 3 20) expansions:
• unroll
 expr: (|List.--_642/boot| 4 20) expansions:
• unroll
 expr: (|List.mem_402/server| (money_1259/client state_1276/client) (|get.::.1_401/server| (|get.::.1_4… expansions:
• unroll
 expr: (|List.--_642/boot| 5 20) expansions:
• unroll
 expr: (|List.--_642/boot| 6 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 7 20) expansions:
• unroll
 expr: (|List.--_642/boot| 8 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 9 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 10 20) expansions:
• unroll
 expr: (|List.--_642/boot| 11 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 12 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 13 20) expansions:
• unroll
 expr: (|List.--_642/boot| 14 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 15 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 16 20) expansions:
• unroll
 expr: (|List.--_642/boot| 17 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 18 20) expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_401/server| (|get.::.1_401/server| (|get.::.1_401/… expansions:
• unroll
 expr: (|List.--_642/boot| 19 20) expansions:
• unroll
 expr: (|List.--_642/boot| 20 20) expansions:
• Sat (Some let state : state = {alice_account = (Z.of_nativeint (10n)); bob_account = (Z.of_nativeint (10n)); money = (Z.of_nativeint (11n))} )

Now Imandra has found a counterexample to our verify statement. Like TLA+, Imandra gives us concrete values that make our statement false. We can also compute with these values to get more insight:

In [7]:
CX.state;;
CX.state |> step A;;
CX.state |> step A |> step B;;
Out[7]:
- : state = {alice_account = 10; bob_account = 10; money = 11}
- : state = {alice_account = -1; bob_account = 10; money = 11}
- : state = {alice_account = -1; bob_account = 21; money = 11}

We can fix this by wrapping the check in an if-block:

In [8]:
let transfer state =
if state.alice_account >= state.money then
state |> step A |> step B
else
state
Out[8]:
val transfer : state -> state = <fun>

Which now runs properly.

In [9]:
verify (fun state ->
state.alice_account = 10 &&
state.bob_account = 10 &&
List.mem state.money List.(1 -- 20)
==>
let state' = transfer state in
state'.alice_account >= 0
)
Out[9]:
- : state -> bool = <fun>
Proved
proof
ground_instances:0
definitions:0
inductions:0
search_time:
0.009s
details:
Expand
smt_stats:
 num checks: 2 arith assert lower: 1 arith tableau max rows: 3 arith tableau max columns: 9 arith pivots: 2 rlimit count: 787 mk clause: 3 mk bool var: 29 arith assert upper: 5 decisions: 2 arith row summations: 5 propagations: 5 conflicts: 4 datatype accessor ax: 3 arith conflicts: 1 arith num rows: 3 arith assert diseq: 1 datatype constructor ax: 2 num allocs: 2.03763e+07 added eqs: 25 del clause: 1 arith eq adapter: 3 memory: 16.92 max memory: 16.92
Expand
• start[0.009s]
let (_x_0 : int) = ( :var_0: ).alice_account in
let (_x_1 : int) = ( :var_0: ).money in
let (_x_2 : state) = {alice_account = …; bob_account = …; money = …}
in
(_x_0 = 10)
&& ((( :var_0: ).bob_account = 10) && List.mem _x_1 (List.( -- ) 1 20))
==> (if _x_0 >= _x_1 then if B = A then _x_2 else _x_2 else ( :var_0: )).alice_account
>= 0
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).alice_account in let (_x_1 : int) = ( :var_0: ).bob_account in let (_x_2 : int) = ( :var_0: ).money in not ((_x_0 = 10) && (_x_1 = 10) && List.mem _x_2 (List.( -- ) 1 20)) || ((if _x_0 >= _x_2 then {alice_account = _x_0 + (-1) * _x_2; bob_account = _x_1 + _x_2; money = _x_2} else ( :var_0: )).alice_account >= 0) expansions: [] rewrite_steps: forward_chaining:
• Unsat

Quick aside: this is closer to testing all possible cases, but isn’t testing all possible cases. Would the algorithm break if money was, say, 4997? If we actually wanted to test all possible cases, we could replace money \in 1..20 with money \in Nat, where Nat is the set of natural numbers. This is perfectly valid TLA+. Unfortunately, it’s also something the model checker can’t handle. TLC can only check a subset of TLA+, and infinite sets aren’t part of that.

Imandra is capable of handling infinite sets. We can do this by simply removing the constraint that state.money is in the range 1 to 20. Instead, we'll require that it is non-negative:

In [10]:
verify (fun state ->
state.alice_account = 10 &&
state.bob_account = 10 &&
state.money >= 0
==>
let state' = transfer state in
state'.alice_account >= 0
)
Out[10]:
- : state -> bool = <fun>
Proved
proof
ground_instances:0
definitions:0
inductions:0
search_time:
0.018s
details:
Expand
smt_stats:
 num checks: 1 arith assert lower: 2 arith tableau max rows: 3 arith tableau max columns: 7 arith pivots: 2 rlimit count: 796 mk clause: 3 mk bool var: 24 arith assert upper: 3 decisions: 1 arith row summations: 5 propagations: 3 conflicts: 2 datatype accessor ax: 3 arith conflicts: 1 arith num rows: 3 datatype constructor ax: 2 num allocs: 3.09665e+07 added eqs: 23 del clause: 1 arith eq adapter: 2 time: 0.009 memory: 17.04 max memory: 17.46
Expand
• start[0.018s]
let (_x_0 : int) = ( :var_0: ).alice_account in
let (_x_1 : int) = ( :var_0: ).money in
let (_x_2 : state) = {alice_account = …; bob_account = …; money = …}
in
(_x_0 = 10) && ((( :var_0: ).bob_account = 10) && (_x_1 >= 0))
==> (if _x_0 >= _x_1 then if B = A then _x_2 else _x_2 else ( :var_0: )).alice_account
>= 0
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).alice_account in let (_x_1 : int) = ( :var_0: ).bob_account in let (_x_2 : int) = ( :var_0: ).money in not ((_x_0 = 10) && (_x_1 = 10) && (_x_2 >= 0)) || ((if _x_0 >= _x_2 then {alice_account = _x_0 + (-1) * _x_2; bob_account = _x_1 + _x_2; money = _x_2} else ( :var_0: )).alice_account >= 0) expansions: [] rewrite_steps: forward_chaining:
• Unsat

Imandra has shown that this property holds for all possible non-negative integer values of money.

## TLA+ and Invariants¶

Can you transfer a negative amount of money? We could add an assert money > 0 to the beginning of the algorithm. This time, though, we’re going to introduce a new method in preparation for the next section.

TLA+ allows you write down invariants that will be checked for each state of the system.

We can achieve the same with Imandra:

In [11]:
verify (fun action state ->
state.alice_account = 10 &&
state.bob_account = 10 &&
state.money >= 0
==>
let state' = step action state in
state'.money >= 0
)
Out[11]:
- : action -> state -> bool = <fun>
Proved
proof
ground_instances:0
definitions:0
inductions:0
search_time:
0.016s
details:
Expand
smt_stats:
 num checks: 1 arith assert lower: 4 arith tableau max rows: 3 arith tableau max columns: 7 rlimit count: 795 mk clause: 3 mk bool var: 30 arith assert upper: 2 datatype splits: 1 decisions: 3 propagations: 8 conflicts: 4 datatype accessor ax: 5 arith conflicts: 1 arith num rows: 3 arith assert diseq: 1 datatype constructor ax: 2 num allocs: 4.34771e+07 added eqs: 36 del clause: 1 arith eq adapter: 3 time: 0.008 memory: 17.27 max memory: 17.67
Expand
• start[0.016s]
let (_x_0 : int) = ( :var_0: ).alice_account in
let (_x_1 : int) = ( :var_0: ).bob_account in
let (_x_2 : int) = ( :var_0: ).money in
(_x_0 = 10) && ((_x_1 = 10) && (_x_2 >= 0))
==> (if ( :var_1: ) = A
then {alice_account = _x_0 - _x_2; bob_account = _x_1; money = _x_2}
else {alice_account = _x_0; bob_account = _x_1 + _x_2; money = _x_2}).money
>= 0
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).alice_account in let (_x_1 : int) = ( :var_0: ).bob_account in let (_x_2 : int) = ( :var_0: ).money in not ((_x_0 = 10) && (_x_1 = 10) && (_x_2 >= 0)) || ((if ( :var_1: ) = A then {alice_account = _x_0 + (-1) * _x_2; bob_account = _x_1; money = _x_2} else {alice_account = _x_0; bob_account = _x_1 + _x_2; money = _x_2}).money >= 0) expansions: [] rewrite_steps: forward_chaining:
• Unsat

Imandra has proven that for any state and after processing any action, money is always non-negative: the invariant holds for all states of the system.

## One step further: checking Atomicity¶

So far we haven’t done anything too out of the ordinary. Everything so far is easily coverable in a real system by unit and property tests. There’s still a lot more ground to cover, but I want to show that we can already use what we’ve learned to find more complicated bugs. Alice wants to give Bob 1,000 dollars. If we’re unlucky, it could play out like this:

1. System checks that Alice has enough money
2. \$1,000 is deducted from her account 3. Eve smashes in the server with a baseball bat 4. Bob never receives the money 5. \$1,000 has completely disappeared from the system
6. The SEC shuts you down for fraud.

We already have all of the tools to check this. First, we need to figure out how to represent the broken invariant. We could do that by requiring the total money in the system is always the same:

In our Imandra model we could express this as follows: given any state and any action, the total money in the system at the start should be equal to the total money in the system afterwards:

In [12]:
let account_total state =
state.alice_account + state.bob_account

verify (fun action state ->
state.money >= 0
==>
let state' = step action state in
account_total state = account_total state'
)
Out[12]:
val account_total : state -> Z.t = <fun>
- : action -> state -> bool = <fun>
module CX : sig val action : action val state : state end
Counterexample (after 0 steps, 0.017s):
let action : action = B
let state : state = {alice_account = 8365; bob_account = 1796; money = 1}
Refuted
proof attempt
ground_instances:0
definitions:0
inductions:0
search_time:
0.017s
details:
Expand
smt_stats:
 num checks: 1 arith assert lower: 3 arith tableau max rows: 5 arith tableau max columns: 12 arith pivots: 3 rlimit count: 991 mk clause: 10 datatype occurs check: 5 mk bool var: 32 arith assert upper: 8 datatype splits: 1 decisions: 6 arith row summations: 8 propagations: 5 conflicts: 2 arith fixed eqs: 2 datatype accessor ax: 6 arith num rows: 5 arith assert diseq: 1 datatype constructor ax: 5 num allocs: 5.84968e+07 final checks: 1 added eqs: 31 del clause: 2 arith eq adapter: 3 time: 0.008 memory: 17.67 max memory: 18.05
Expand
• start[0.017s]
let (_x_0 : int) = ( :var_0: ).money in
let (_x_1 : int) = ( :var_0: ).alice_account in
let (_x_2 : int) = ( :var_0: ).bob_account in
let (_x_3 : state)
= if ( :var_1: ) = A
then {alice_account = _x_1 - _x_0; bob_account = _x_2; money = _x_0}
else {alice_account = _x_1; bob_account = _x_2 + _x_0; money = _x_0}
in _x_0 >= 0 ==> _x_1 + _x_2 = _x_3.alice_account + _x_3.bob_account
• #### simplify

 into: let (_x_0 : int) = ( :var_0: ).money in let (_x_1 : int) = ( :var_0: ).alice_account in let (_x_2 : int) = ( :var_0: ).bob_account in let (_x_3 : state) = if ( :var_1: ) = A then {alice_account = _x_1 + (-1) * _x_0; bob_account = _x_2; money = _x_0} else {alice_account = _x_1; bob_account = _x_2 + _x_0; money = _x_0} in not (_x_0 >= 0) || (_x_1 + _x_2 = _x_3.alice_account + _x_3.bob_account) expansions: [] rewrite_steps: forward_chaining:
• Sat (Some let action : action = B let state : state = {alice_account = (Z.of_nativeint (8365n)); bob_account = (Z.of_nativeint (1796n)); money = (Z.of_nativeint (1n))} )

When we run this, TLC finds a counterexample: between steps A and B the invariant doesn’t hold.

Imandra has found this same counterexample.

How do we solve this? It depends on the level of abstraction we care about. If you were designing a database, you’d want to spec the exact steps required to keep the system consistent. At our level, though, we probably have access to database transactions and can ‘abstract out’ the atomicity checks. The way we do that is to combine A and B into a single “Transaction” step. That tells TLA+ that both actions happen simultaneously, and the system never passes through an invalid state.

There are many different ways we could choose to model this in Imandra. Here is one:

In [13]:
type action =
| Transfer (* In this step we'll check whether Alice's balance is sufficient *)
| A (* In this step we'll transfer the funds *)
| End

type state =
{ alice_account : int
; bob_account : int
; money : int
; next_action : action (* The action that should be executed on the next call to step *)
}

let is_valid_initial_state state =
state.alice_account >= 0 &&
state.money >= 0 &&
state.next_action = Transfer

let step state =
match state.next_action with
| Transfer ->
if state.alice_account >= state.money then
{ state with next_action = A }
else
{ state with next_action = End }
| A ->
{ state with
alice_account = state.alice_account - state.money
; bob_account = state.bob_account + state.money
; next_action = End
}
| End ->
state

(* step_n repeatedly calls (step state) n times. *)
let rec step_n n state =
if n > 0 then
step_n (n-1) (step state)
else
state

let account_total state =
state.alice_account + state.bob_account

verify (fun n state ->
n < 5 &&
is_valid_initial_state state
==>
let state' = step_n n state in
account_total state = account_total state' &&
state'.alice_account >= 0
)
Out[13]:
type action = Transfer | A | End
type state = {
alice_account : Z.t;
bob_account : Z.t;
money : Z.t;
next_action : action;
}
val is_valid_initial_state : state -> bool = <fun>
val step : state -> state = <fun>
val step_n : Z.t -> state -> state = <fun>
val account_total : state -> Z.t = <fun>
- : Z.t -> state -> bool = <fun>
termination proof

### Termination proof

call step_n (n - 1) (step state) from step_n n state
original:step_n n state
sub:step_n (n - 1) (step state)
original ordinal:Ordinal.Int (_cnt n)
sub ordinal:Ordinal.Int (_cnt (n - 1))
path:[n > 0]
proof:
detailed proof
ground_instances:1
definitions:0
inductions:0
search_time:
0.010s
details:
Expand
smt_stats:
 num checks: 3 arith assert lower: 6 arith tableau max rows: 4 arith tableau max columns: 9 arith pivots: 2 rlimit count: 1163 mk clause: 5 datatype occurs check: 2 mk bool var: 17 arith assert upper: 3 decisions: 2 arith row summations: 3 propagations: 2 conflicts: 2 arith fixed eqs: 2 datatype accessor ax: 2 arith conflicts: 1 arith num rows: 4 num allocs: 7.55065e+07 final checks: 1 added eqs: 4 del clause: 5 arith eq adapter: 2 memory: 18.64 max memory: 18.64
Expand
• start[0.010s]
let (_x_0 : int) = if n >= 0 then n else 0 in
let (_x_1 : int) = n - 1 in
let (_x_2 : int) = if _x_1 >= 0 then _x_1 else 0 in
(n > 0) && ((_x_0 >= 0) && (_x_2 >= 0))
==> not (_x_1 > 0) || Ordinal.( << ) (Ordinal.Int _x_2) (Ordinal.Int _x_0)
• ###### simplify
 into: (n <= 0) || (n <= 1) || Ordinal.( << ) (Ordinal.Int (if n >= 1 then (-1) + n else 0)) (Ordinal.Int (if n >= 0 then n else 0)) expansions: [] rewrite_steps: forward_chaining:
• unroll
 expr: (|Ordinal.<<| (|Ordinal.Int_79/boot| (ite (>= n_565/server 1) (+ (- 1) n_565/server)… expansions:
• Unsat
Proved
proof
ground_instances:5
definitions:0
inductions:0
search_time:
0.015s
details:
Expand
smt_stats:
 arith offset eqs: 29 num checks: 11 arith assert lower: 150 arith tableau max rows: 35 arith tableau max columns: 59 arith pivots: 91 rlimit count: 15346 mk clause: 233 datatype occurs check: 69 mk bool var: 509 arith assert upper: 159 datatype splits: 26 decisions: 159 arith row summations: 374 arith bound prop: 15 propagations: 362 interface eqs: 8 conflicts: 38 arith fixed eqs: 108 arith assume eqs: 8 datatype accessor ax: 23 minimized lits: 12 arith conflicts: 4 arith num rows: 35 arith assert diseq: 39 datatype constructor ax: 26 num allocs: 9.41171e+07 final checks: 13 added eqs: 997 del clause: 130 arith eq adapter: 107 memory: 19.49 max memory: 19.49
Expand
• start[0.015s]
let (_x_0 : int) = ( :var_1: ).alice_account in
let (_x_1 : state) = step_n ( :var_0: ) ( :var_1: ) in
let (_x_2 : int) = _x_1.alice_account in
(( :var_0: ) < 5)
&& ((_x_0 >= 0)
&& ((( :var_1: ).money >= 0) && (( :var_1: ).next_action = Transfer)))
==> (_x_0 + ( :var_1: ).bob_account = _x_2 + _x_1.bob_account)
&& (_x_2 >= 0)
• #### simplify

 into: let (_x_0 : int) = ( :var_1: ).alice_account in let (_x_1 : state) = step_n ( :var_0: ) ( :var_1: ) in let (_x_2 : int) = _x_1.alice_account in not (not (5 <= ( :var_0: )) && (_x_0 >= 0) && (( :var_1: ).money >= 0) && (( :var_1: ).next_action = Transfer)) || ((_x_0 + ( :var_1: ).bob_account = _x_2 + _x_1.bob_account) && (_x_2 >= 0)) expansions: [] rewrite_steps: forward_chaining:
• unroll
 expr: (step_n_1314/client n_1319/client state_1320/client) expansions:
• unroll
 expr: (step_n_1314/client (+ (- 1) n_1319/client) (step_1312/client state_1320/client)) expansions:
• unroll
 expr: (step_n_1314/client (+ (- 2) n_1319/client) (step_1312/client (step_1312/client state_1320/clien… expansions:
• unroll
 expr: (step_n_1314/client (+ (- 3) n_1319/client) (step_1312/client (step_1312/client (step_1312/clien… expansions:
• unroll
 expr: (let ((a!1 (step_1312/client (step_1312/client (step_1312/client (step_1312/client state_1320/client… expansions:
• Unsat

## Multiprocess Algorithms¶

As a final part of our example, let’s discuss concurrency.

The accounts are global variables, while money is a local variable to the process.

In our model, we will treat state (which holds the accounts) as a global variable. The state of our processes will be represented by the process_state type - each has a local money variable. The world type will hold the global state of the accounts and the process_state for each process.

We'll then define a function run_world, which takes a world state and a scheduled execution order in the form of a list of process contexts, and executes the processes according to the schedule.

We want to verify that, given any initial world, the following invariants hold regardless of the order in which the processes are executed:

1. The total money in the system does not change.
2. Alice's account never goes negative.
In [14]:
(** Global state of accounts *)
type state =
{ alice_account : int
; bob_account : int
}

(** Actions for an individual process *)
type process_action =
| Transfer
| A
| End

(** The state of a process *)
type process_state =
{ money : int
; next_action : process_action
}

(** State of the world *)
type world =
{ state : state
; p1_state : process_state
; p2_state : process_state
}

(** Step a process's next_action. Returns the updated global accounts
state and the new state of this process. *)
let step_process state process_state =
match process_state.next_action with
| Transfer ->
if state.alice_account >= process_state.money then
(state, { process_state with next_action = A })
else
(state, { process_state with next_action = End })
| A ->
( { alice_account = state.alice_account - process_state.money
; bob_account = state.bob_account + process_state.money
}
, { process_state with next_action = End }
)
| End ->
(state, process_state)

(** Current execution context *)
type context =
| Process_1
| Process_2

(** Step the world forward for a given execution context. *)
let step_world context world =
match context with
| Process_1 ->
let (state, p1_state) = step_process world.state world.p1_state in
{ world with state; p1_state }
| Process_2 ->
let (state, p2_state) = step_process world.state world.p2_state in
{ world with state; p2_state }

(** run_world takes an initial world state and executes the processes
according to the schedule specified by contexts *)
let run_world world contexts =
contexts |> List.fold_right step_world ~base:world
Out[14]:
type state = { alice_account : Z.t; bob_account : Z.t; }
type process_action = Transfer | A | End
type process_state = { money : Z.t; next_action : process_action; }
type world = {
state : state;
p1_state : process_state;
p2_state : process_state;
}
val step_process : state -> process_state -> state * process_state = <fun>
type context = Process_1 | Process_2
val step_world : context -> world -> world = <fun>
val run_world : world -> context list -> world = <fun>

Now we can verify that, for any initial state of the world and for any possible sequence of contexts, the invariants hold.

In [15]:
(** A state is a valid initial state if the accounts are non-negative. *)
let is_valid_initial_state state =
state.alice_account >= 0 &&
state.bob_account >= 0

(** This function checks whether a process is in a valid starting state.
We'll use it to constrain the input to our verify statement below. *)
let is_valid_initial_process_state p =
p.money >= 0 &&
p.next_action = Transfer

(** The world is a valid initial state if the accounts and processes are all valid. *)
let is_valid_initial_world world =
is_valid_initial_state world.state &&
is_valid_initial_process_state world.p1_state &&
is_valid_initial_process_state world.p2_state

let account_total state =
state.alice_account + state.bob_account

verify (fun contexts world ->
(* Initial states are valid *)
is_valid_initial_world world
==>
let world' = run_world world contexts in
account_total world.state = account_total world'.state &&
world'.state.alice_account >= 0
)
Out[15]:
val is_valid_initial_state : state -> bool = <fun>
val is_valid_initial_process_state : process_state -> bool = <fun>
val is_valid_initial_world : world -> bool = <fun>
val account_total : state -> Z.t = <fun>
- : context list -> world -> bool = <fun>
module CX : sig val contexts : context list val world : world end
Counterexample (after 5 steps, 0.048s):
let contexts : context list = [Process_1; Process_2; Process_2; Process_1]
let world : world =
{state = {alice_account = 16382; bob_account = 2772};
p1_state = {money = 9042; next_action = Transfer};
p2_state = {money = 7582; next_action = Transfer}}
Refuted
proof attempt
ground_instances:5
definitions:0
inductions:0
search_time:
0.048s
details:
Expand
smt_stats:
 arith offset eqs: 538 num checks: 11 arith assert lower: 722 arith tableau max rows: 75 arith tableau max columns: 103 arith pivots: 280 rlimit count: 125748 mk clause: 1032 datatype occurs check: 407 mk bool var: 2191 arith assert upper: 786 datatype splits: 442 decisions: 1301 arith row summations: 2880 arith bound prop: 256 propagations: 4826 interface eqs: 14 conflicts: 250 arith fixed eqs: 671 arith assume eqs: 14 datatype accessor ax: 227 minimized lits: 362 arith conflicts: 18 arith num rows: 75 arith assert diseq: 206 datatype constructor ax: 328 num allocs: 1.28841e+08 final checks: 24 added eqs: 12236 del clause: 392 arith eq adapter: 499 time: 0.007 memory: 23.65 max memory: 23.65
Expand
• start[0.048s]
let (_x_0 : state) = ( :var_0: ).state in
let (_x_1 : int) = _x_0.alice_account in
let (_x_2 : int) = _x_0.bob_account in
let (_x_3 : process_state) = ( :var_0: ).p1_state in
let (_x_4 : process_state) = ( :var_0: ).p2_state in
let (_x_5 : state)
= (List.fold_right step_world ( :var_0: ) ( :var_1: )).state
in
let (_x_6 : int) = _x_5.alice_account in
(_x_1 >= 0) && (_x_2 >= 0)
&& ((_x_3.money >= 0) && (_x_3.next_action = Transfer)
&& ((_x_4.money >= 0) && (_x_4.next_action = Transfer)))
==> (_x_1 + _x_2 = _x_6 + _x_5.bob_account) && (_x_6 >= 0)
• #### simplify

 into: let (_x_0 : state) = ( :var_0: ).state in let (_x_1 : int) = _x_0.alice_account in let (_x_2 : int) = _x_0.bob_account in let (_x_3 : process_state) = ( :var_0: ).p1_state in let (_x_4 : process_state) = ( :var_0: ).p2_state in let (_x_5 : state) = (List.fold_right step_world ( :var_0: ) ( :var_1: )).state in let (_x_6 : int) = _x_5.alice_account in not ((_x_1 >= 0) && (_x_2 >= 0) && (_x_3.money >= 0) && (_x_3.next_action = Transfer) && (_x_4.money >= 0) && (_x_4.next_action = Transfer)) || ((_x_1 + _x_2 = _x_6 + _x_5.bob_account) && (_x_6 >= 0)) expansions: [] rewrite_steps: forward_chaining:
• unroll
 expr: (|List.fold_right_686/server| world_1372/client contexts_1371/client) expansions:
• unroll
 expr: (|List.fold_right_686/server| world_1372/client (|get.::.1_682/server| contexts_1371/client)) expansions:
• unroll
 expr: (|List.fold_right_686/server| world_1372/client (|get.::.1_682/server| (|get.::.1_682/server| co… expansions:
• unroll
 expr: (|List.fold_right_686/server| world_1372/client (|get.::.1_682/server| (|get.::.1_682/server… expansions:
• unroll
 expr: (let ((a!1 (|get.::.1_682/server| (|get.::.1_682/server| (|get.::.1_682/… expansions:
• Sat (Some let contexts : context list = [Process_1; Process_2; Process_2; Process_1] let world : world = {state = {alice_account = (Z.of_nativeint (16382n)); bob_account = (Z.of_nativeint (2772n))}; p1_state = {money = (Z.of_nativeint (9042n)); next_action = Transfer}; p2_state = {money = (Z.of_nativeint (7582n)); next_action = Transfer}} )

There’s a gap between when we check that Alice has enough money and when we actually transfer the money. With one process this wasn’t a problem, but with two, it means her account can go negative. TLC is nice enough to provide the initial state and steps required to reproduce the bug.

Imandra has also found a counterexample. We can see from the contexts in the counterexample that one process interrupted the other.

We can also execute the counterexample to see the final state of the world in this case:

In [16]:
run_world CX.world CX.contexts
Out[16]:
- : world =
{state = {alice_account = -242; bob_account = 19396};
p1_state = {money = 9042; next_action = End};
p2_state = {money = 7582; next_action = End}}

## Summary¶

We've shown how these TLA+ problems can be modeled in Imandra, in an apples-to-apples fashion.

In most cases we've translated the PlusCal examples into a state machine, which is closer to the underlying TLA+ representation. A PlusCal-like DSL for Imandra would be an interesting future project.

Both systems can go much deeper: TLA+ has theorem proving capabilities, and we haven't touched on Imandra's lemmas, theorems, rewrite rules or the induction waterfall. Browse the documentation to find out more!