Document storage assumptions

[yaymukund]

libzkchannels-crypto hands back structs that an application may serialize and deserialize. For example:

a. A customer application (e.g. Zeekoe) invokes Establish::new(...).
b. It stores the Establish somewhere on-disk.
c. Time passes.
d. It reads the value from the database and calls establish.complete(...).

So far, I've assumed that storage itself was immutable outside of the operations that zkAbacus exposes via its public API. I've treated it as no different from storing things in-memory in this regard in terms of its security properties. But lets' talk about it explicitly:

1. Do we want to support mutating the Establish on-disk between step b and d? Are there use-cases for supporting this directly rather than exposing a zkAbacus API?
2. If so, what kind of mutations do we support?
3. What are the risks of someone mutating state on-disk or in-memory? It looks like bincode guarantees that deserializing untrusted input won't be unsafe in the Rust sense. However, they could e.g. change balances or forge a revocation lock or any number of things.
4. If we expect applications not to mutate serialized data in between invocations, is this worth mentioning explicitly in libzkchannels-spec?

[marsella]

1. No. I think we do not want to support mutating zkabacus structs outside of the zkAbacus API. The whole point of that API is to prevent misuse / any requirements of understanding cryptography. I cannot think of a scenario under the current use case where manually changing that data would be good.

2. N/A.

3. I think that this would just result in invalid data that the protocol will catch when you try to pay or close. E.g. you can mutate stuff but that is malicious behavior and our protocol is secure against malicious behavior. I am happy to lean on that assumption without going back an re-analyzing everything to be sure

4. I don't know if it belongs in the spec, exactly. The spec says things like "you get x" and "you store x" and "you send x" and never says "you mutate x", so it is implicit. We could make it explicit, or we could update the docs for zkabacus public types to say "manually modifying this object will break the assumptions of the protocol and may result in loss of funds"