Decide on storage model for decryptor application

[jannikluhn]

• what data needs to be stored?
• what data needs to be persisted?
• how will it be accessed (by key, complicated queries, etc)?
• how should it be stored (relational database, key value store)?

[jannikluhn]

Keypers and decryptors deal with the following objects:

• decryption triggers (one per round)
• decryption key shares (n per round)
• decryption keys (one per round)
• cipher batches (one per round)
• decryption signatures, non-, fully or partially aggregated (n per round)

The objects need to be stored until the corresponding round is finished for two reason:

• processing in order to complete the round (i.e., the decryption key can only be computed once enough shares have been collected, so we need to store them until that time)
• serving them to peers who join the network and want to sync (i.e., a keyper wants to sync recent decryption triggers so that they can release their decryption key shares and help complete the open rounds)

Older state is nice to have:

• it prevents replay attacks that would force nodes to redo work (e.g., send an old trigger and force unsuspecting nodes to generate keys again).
• it prevents round results (decryption key for keypers, signatures for decryptors) from being lost if no one listens for some reason

All objects need to be accessible by round id. For syncing, recent objects need to be accessible as an ordered sequence (so that peers can ask for "5 objects, starting from x").

[jannikluhn]

Given this information, I would advocate for storing all data in a postgres database. I think this would be the easiest and safest solution: No need to think about what data can go and what needs to stay, less problems when something crashes. Easy to access simply by id or to respond to sync requests. Storage requiremets shouldn't bother us for the foreseeable future. The main disadvantages that I can see is that it makes testing more complicated and that users would have to run a separate process.