-
Open TokenTransfer1.tla and MC1.tla.
-
Notice how
CHAINS
,ACCOUNTS
, andbanks
are declared. -
Run:
$ apalache-mc check MC1.tla
-
The tool reports no errors.
-
Open TokenTransfer2.tla and MC2.tla.
-
Inspect the operators
LocalTransfer
andNext
. Do you see any issues? -
Inspect the expected invariants
ReservesInv
andNoNegativeAccounts
. Do you see any issues? -
Check the property
ReservesInv
by running:$ apalache-mc check --inv=ReservesInv MC2.tla
-
The tool reports on a counterexample. Check
counterexample.tla
. Can you fix the issue? -
Check the property
NoNegativeAccounts
by running:$ apalache-mc check --inv=NoNegativeAccounts MC2.tla
-
The tool reports on a counterexample. Check
counterexample.tla
. Can you fix the issue?
-
Open TokenTransfer3.tla and MC3.tla.
-
See how we have fixed
NoNegativeAccounts
by usingNat
instead ofInt
. -
Notice how we introduced the constant
GENESIS_SUPPLY
and the operatorsSumAddresses
andChainSupply
. -
Check what has changed in
Init
andNext
. -
Inspect the new invariant
ChainSupplyUnchanged
. -
Observe how we have introduced
GENESIS_SUPPLY
in MC3.tla. -
Check the property
ChainSupplyUnchanged
by running:$ apalache-mc check --inv=ChainSupplyUnchanged MC3.tla
-
Apalache is stuck after some time. Any ideas why?
-
Check the detailed log by typing:
$ tail -f detailed.log
-
You can see the results of preprocessing steps in the directory that is called like
x/hh.mm-DD.MM.YYYY-.*
. The fileout-analysis.tla
is the final result of all preprocessing steps. -
You can tell Apalache to produce the log of SMT constraints:
$ apalache-mc check --inv=ChainSupplyUnchanged --debug MC3.tla
-
The log file can be found in
log0.smt
. If you are feeling adventurous today, you can install Microsoft Z3 and run the log directly withz3
:$ z3 -smt2 log0.smt
-
Open TokenTransfer5.tla and MC5.tla.
-
Notice that we have added two new operators:
TypeOK
andIndInv
. -
Run Apalache as follows:
$ apalache-mc check --init=IndInv --inv=IndInv --length=1 MC5.tla $ apalache-mc check --init=Init --inv=IndInv --length=0 MC5.tla $ apalache-mc check --init=IndInv --inv=ChainSupplyUnchanged --length=0 MC5.tla
-
Why do you think we have checked
ChainSupplyUnchanged
for the executions of arbitrary length?
- Open TokenTransfer6.tla and MC6.tla.
- Notice the changes:
- new constant
CHANNELS
- new variable
sentPackets
- new definition
Escrow == "escrow"
- update in
Init
andNext
- new operators
LocalStep
andSendPacketFromSource
-
Check the invariant
InFlyPacketIsSecured
by running:$ apalache-mc check --inv=InFlyPacketIsSecured MC6.tla
-
Do you think it is a good invariant? Can we improve it?
-
Can you write a version of
InFlyPacketIsSecured
that counts the sum of token over all in-fly packets?
-
Open TokenTransfer7.tla and MC7.tla.
-
Notice the changes:
- new field
seqno
in sentPackets - new variable
seqno
- new variable
deliveredNums
- new operators
MintCoins
andReceivePacketFromSource
- updates in
Init
andNext
- new field
-
Do you think our spec is still OK?
-
Check the property
ChainSupplyUnchanged
by running:$ apalache-mc check --inv=ChainSupplyUnchanged MC7.tla
-
If it takes too long, let's cheat a bit and check how to tune the model checker. Read the page on tuning parameters.
-
Create the file
apalache.properties
and write the follows:search.invariantFilter=[2-4] search.invariant.mode=after
The first option instructs Apalache to check the invariant only after 2, 3, or 4 steps. The second option instructs Apalache to check the invariant after choosing a transition in a step, not before.
-
Run Apalache with the tuning options:
$ apalache-mc check --inv=ChainSupplyUnchanged --tuning=apalache.properties MC7.tla
-
Apalache should find an error very quickly. Check
counterexample1.tla
. Do you understand what happened?
-
Open TokenTransfer8.tla and MC8.tla.
-
Notice the changes:
- new constants
DENOMS
andMK_DENOM
- new operator
Native
- updates in many operators to attach denomination to an account
- new constants
-
Check the property
NoForeignCoins
by running:$ apalache-mc check --inv=NoForeignCoins MC8.tla
-
Check
counterexample.tla
for an example. -
We can run Apalache again to check
ChainSupplyUnchanged
:$ apalache-mc check --inv=ChainSupplyUnchanged --tuning=apalache.properties MC7.tla
-
This time, Apalache does not come back that fast. If you want to prove this property for all executions, construct an inductive invariant, similar to what we did with
MC5.tla
.
- Open TokenTransfer9.tla and MC9.tla.
- Notice the changes:
- new constant
UNMK_DENOM
- new operators:
SendPacket
,BurnCoins
,SendPacketToSource
,ReceivePacketOnSource
-
Check the property
InFlyPacketIsSecured
by running:$ apalache-mc check --inv=InFlyPacketIsSecured MC9.tla
-
Check
counterexample.tla
for an example. -
Uncomment the precondition in the definition of
InFlyPacketIsSecured
and check the property again.
- Open TokenTransfer10.tla and MC10.tla.
- Notice the changes:
- new variables:
srcTimeoutNums
anddstTimeoutNums
- new operators:
RegisterTimeout
andApplyTimeout
-
Check the property
InFlyPacketIsSecured
by running:$ apalache-mc check --inv=InFlyPacketIsSecured MC10.tla
-
Check the property
AllChainsSupplyUnchanged
by running:$ apalache-mc check --inv=AllChainsSupplyUnchanged MC10.tla
-
Open Test10.tla.
-
Read the definitions of operators
TestApplyTimeoutRequires
,TestApplyTimeoutAction
, andTestApplyTimeoutEnsures
. -
Run the test as follows:
$ apalache-mc check --init=TestApplyTimeoutRequires \ --next=TestApplyTimeoutAction --inv=TestApplyTimeoutEnsures --length=1 Test10.tla
If you are not tired, you can check
ICS20
and improve TokenTransfer10.tla
to support the full token transfer protocol.