NOTE: This implementation saves secrets to disk! It is not
secure.
The storage API allows the caller to atomically record the state
of the protocol. The user can retrieve this recorded state and
re-commence the protocol from that point. The state is recorded
using a hard coded key, causing it to overwrite the previously
recorded state. This limitation means that this recovery
mechanism should not be used in a program that simultaneously
manages the execution of multiple swaps.
An e2e test was added to show how to save, recover and resume
protocol execution. This logic could also be integrated into the
run_until functions to automate saving but was not included at
this stage as protocol execution is currently under development.
Serialisation and deserialisation was implemented on the states
to allow the to be stored using the database. Currently the
secret's are also being stored to disk but should be recovered
from a seed or wallets.
Previously we were testing the protocol by manually driving Alice and
Bob's state machines. This logic has now be moved to an async state
transition function that can take any possible state as input. The
state transition function is called in a loop until it returns the
desired state. This allows use to interrupt midway through the protocol
and perform refund and punish tests. This design was chosen over a
generator based implementation because the the generator based
implementation results in a impure state transition function that is
difficult to reason about and prone to bugs.
Test related code was extracted into the tests folder.
The 2b and 4b states were renamed to be consistent with the rest.
Macros were used to reduce code duplication when converting
child states to their parent states and vice versa.
Todos were added were neccessary.
