Permissioned queries


#1

I’m still learning about smpc - I know it enables non-revealing queries which allow a requester to know information about data without knowing the data itself (i.e. - “is this person over 21?”), but does it also enable permissioned queries? (i.e. - only someone I whitelist is even allowed to ask the question “is this person over 21” and nobody else has the faintest clue) - I guess it would be achieved by appending a Salt to my identifier within the secret contract itself? That way the only people who can ask if I’m over 21 are people who have the Salt, but that requires an off-chain datastore. So are there more sophisticated implementations possible via SMPC where a user can grant and revoke permissioned queries? Would this require an off-chain data store for the user to grant/revoke access credentials? Traditional blockchain enables free queries from anyone, so I guess I’m asking: does enigma simply change the nature of these queries to only answer questions about the data, or does it also enable permissioned queries of the data itself?


#2

I would imagine that a basic implementation would look like something as follows: user whitelists certain addresses for certain types of queries in a public contract; whenever someone sends a signed request to the secret contract, part of the computation that occurs is a check against the public whitelist contract; if the requester isn’t on the list (based on the signature), the computation ends, and the underlying result is not provided to the requester.


#3

The main thing I’m not sure of is whether the enigma computation is capable of taking in an external oracle, or if it can only compute on data that’s already encoded within the secret contract (in which case a whitelist would need to be set up-front, and a new secret contract would need to be deployed every time the user wants to update the whitelist, which would be prohibitive. Unless it’s possible for a user to modify data encoded within the secret contract without exposing the data itself? in which case the whitelist wouldn’t even need to be public, which would be ideal.


#4

Update: resolved - closely tied to: State encryption


#5

Essentially, this could be done through ‘permission predicates’, which are basically pieces of code that need to evaluate to true before allowing a computation to proceed. How is this enforced? Blockchain and incentives.

To give an example, imagine a secret contract should check if you have voted in an election contract, before you are able to request the results. There should be a simple predicate that first checks this condition, and exits the computation if this is false. Worker nodes in Enigma are incentivized to follow this, since they will receive no financial benefit by executing a computation for an unapproved user (also, the enclave itself provides an additional guarantee that the computation can’t be tampered with).

A simpler version of this is indeed whitelisting (a predicate that checks if a certain public key has been preapproved to run a certain computation) and should appear in the whitepaper.

On a tangent - Functional Encryption deals with a similar question from a purely cryptographic standpoint. It asks the question - how can we allow a user holding a specific key to learn only the result of a function over encrypted data.