3 ms·

not OP or a crypto expert, but: yes, zk-SNARKs are useful because you can prove you executed a program without revealing inputs or outputs. you can't send enc

not OP or a crypto expert, but: yes, zk-SNARKs are useful because you can prove you executed a program without revealing inputs or outputs. you can't send encrypted inputs to a zk-SNARK program and get encrypted outputs out, though. you're confusing this with homomorphic encryption. iirc, with Lurk you could, say, convince someone you'd correctly solved a difficult NP-complete problem, by writing a Lurk program that validates a solution to that problem, and publishing the output (Solved) along with the proof steps without revealing your answer. you could, theoretically, write an homomorphic encryption library in Lurk, and then when people send you their encrypted inputs you can send them encrypted outputs along with a proof you faithfully evaluated the FHE circuit. this is actually missing from FHE - a malicious evaluator can do whatever the hell they want with your input data, or make up outputs completely, they just can't see what's inside. that seems pretty neat to me actually, I wonder if the Lurk people are thinking about this. niche but it'd have its uses.

porcuquine 4y ago
> you can't send encrypted inputs to a zk-SNARK program and get encrypted outputs out, though. you're confusing this with homomorphic encryption. Not encrypted, but they can be 'hidden'. For example the input to one computation might have been the output of another — and might be entirely opaque. (For example, the hash corresponding to `(this is a list of data 1 2 3 9873)` will include 32 bytes of data from which it's impossible to compute the original expression unless you already know it. > that seems pretty neat to me actually, I wonder if the Lurk people are thinking about this. niche but it'd have its uses. We are thinking about it, and Lurk would lend itself well to expressing FHE programs. One of our team members has an academic background in FHE, and we're interested in such problems. It's not our top priority right now, but it's a natural area to explore when the core language is more mature.
emmorais 4y ago
Proving correct evaluation of FHE circuits is indeed a nice example of how Lurk can help. We are considering different possibilities regarding FHE, but not as a priority.

porcuquine 4y ago

> you can't send encrypted inputs to a zk-SNARK program and get encrypted outputs out, though. you're confusing this with homomorphic encryption. Not encrypted, but they can be 'hidden'. For example the input to one computation might have been the output of another — and might be entirely opaque. (For example, the hash corresponding to `(this is a list of data 1 2 3 9873)` will include 32 bytes of data from which it's impossible to compute the original expression unless you already know it. > that seems pretty neat to me actually, I wonder if the Lurk people are thinking about this. niche but it'd have its uses. We are thinking about it, and Lurk would lend itself well to expressing FHE programs. One of our team members has an academic background in FHE, and we're interested in such problems. It's not our top priority right now, but it's a natural area to explore when the core language is more mature.

emmorais 4y ago

Proving correct evaluation of FHE circuits is indeed a nice example of how Lurk can help. We are considering different possibilities regarding FHE, but not as a priority.