Encrypted data storage accessible by the enclave

[thanethomson]

We were talking about querying today (related to #145), and a question came up relating to storage of encrypted data accessible by the enclave.

Some assumptions first though:

• Let's say we allow for direct querying of data via the enclave (e.g. by way of this mechanism, which, as I currently understand it, is a more general approach than what Secret uses). In practice this would be against enclave "replicas", which would only read from chain and facilitate querying, but would need the same private key as the "primary" enclave/solver.
• We want to allow applications to define the types of queries that are allowable, which may include data that other users have submitted that's relevant to us (e.g. someone else submits an obligation, to which I'm a counterparty - I want to be able to see all obligations related to me; not just those obligations that I've submitted).
• There may be cases where enclaves would need to store such a large amount of state data that it won't be able to fit in available memory.

The question: how would we facilitate storage of encrypted obligations, tenders, acceptances, etc. such that the enclave can optimally facilitate querying of that data? Do we want to provide a general mechanism here? Is that even possible? Or is it purely application-specific?

A follow-up here is: is there any prior work on this (e.g. the way Signal stores data in its cloud services) that we can use for inspiration?

An example I can think of in the context of MTCS would be to start with the specific queries we have in mind that we'd like to facilitate, and then design a Postgres-based database architecture to allow us to store encrypted data - the data only being able to be decrypted within the enclave by way of its private key. This would involve quite a bit of thinking still to flesh out the details.