trusted call short-term memory for tracing

[brenzi]

Problem Statement

• As the recipient of a transfer, I'd like to know who sent me tokens and what for
• As a sender of a tranfer, I'd like to add a a note (i.e. invoice number)

Status quo is that the receiver only notices a change in balance on their account, without any other information

Requirements

• Minimize side channels: Don't rely on users using other tools like messengers for the basic operations
• state size must be bounded

Solution

Add a note argument to (some) TrustedCalls. The length of the note must be bounded.

• (optional) The note could consist of an ipfs cid + symmetric encryption key (but IPFS will leave meta traces! not good for privacy nor availability)

Implement a TrustedCallHistory pallet for the sidechain runtime which

• maintains a ring buffer of TrustedCalls
• maintains a mapping from recipient AND sender to TrustedCalls

Implement authenticated TrustedGetters to fetch history for self and get returned all TC's involving our account (either as sender or recipient)

extension

It could make sense not to restrict this log to TrustedCalls, but rather store "Events". can be substrate native Events but maybe we want something else. i.e. for the guess-the-number game, an Event could be that you won and therefore got a transfer of a reward. This is no TrustedCall as it is triggered by OnTimestampSet

this would also be a solution for #1051

Implementation Suggestion

• StorageDoubleMap TrustedCalls (bucket_id, tcindex) -> TC
• StorageDoubleMap TrustedCallLookup (bucket_id, account_id) -> Vec<txindex>
• StorageDoubleMap Buckets -> Vec<BucketData>

BucketData

• id
• size(byte counter. if limit is reached, start a new bucket)
• timestamp_start
• timestamp_end

Purging can be done based on the state limitations. Thanks to double_map clear_prefix, we can delete entire buckets with minimal complexity

Spin-Off: messenger

If the above is available, we can also use it as a private messenger, very similar to bitmessage, but with fee-based spam-prevention instead of PoW

Messages would be retained for a limited time T which gets shorter with increasing adoption! Receivers must query frequently to see if someone sent them a message

• (optional) a push service could be envisioned but comes with compromises on privacy