Handling secure computation while respecting data owner privacy is considerably trickier than it might first appear. The main reason is that there are a number of stakeholders who have different needs. Let’s lay them out. First, there’s the data owner(s) who own the data which is to be computed on. There’s the secure computation purchaser who has paid for some secure computation to be performed on data. And finally there’s the compute node who will perform the actual computation itself.
The data owner would like to keep their data private. Ideally, they would prefer that the compute node is not able to view the raw data. This requires a technology such as fully homomorphic encryption, which will allow for computation to be performed on encrypted data. In addition, the data owner would like to limit the amount of information which the purchaser receives from their purchased computation so as to preserve privacy. This requires a technique such as differential privacy, which adds noise to datapoints before compute to prevent unnecessary information about the raw data from leaking out.
The compute node doesn’t have too much at stake here. It can be nosy, so it might store a copy of any data it happens to get access to. Worse, it can be malicious, so it may try to send nonsensical results to the purchaser if it can get away with. To prevent the compute node from getting away with this, a technology such as STARKs is required so that the purchaser has proof that the correct computation was performed on the correct data.
These needs together suggest a schema for truly effective secure computation. This scheme must allow for computation on encrypted data, the use of privacy techniques, and the ability to trustlessly verify computation. To put this into a crude equation, effective secure computation might require the following ingredients
SECURE_COMPUTATION = STARKS + HOMOMORPHIC_ENCRYPTION + DIFFERENTIAL_PRIVACY
Note that homomorphic encryption alone isn’t sufficient. There’s no privacy to the data owner from the purchaser provided by homomorphic encryption. STARKs alone aren’t sufficient, since the compute node can steal the raw data from the data owner. And differential privacy alone isn’t sufficient (how do you know the compute node didn’t just make up its answers?). However, if an effective scheme can be devised to combine these three technologies, it might be possible to enable more effective secure computation.
Note that even in this scheme, there’s one leakage of information. The compute node learns the program that the purchaser is attempting to run. For some applications, this might be infeasible. An interesting possibility is to have a “homomorphic interpreter” that can run a program which is itself encrypted, but it’s not currently clear how to design such a system.