4 ms·

Not as inscrutable as these things usually are, but I still don't really know what one would use this for. This world feels like a parallel ecosystem to traditi

Not as inscrutable as these things usually are, but I still don't really know what one would use this for. This world feels like a parallel ecosystem to traditional software, and the paths rarely meet.

latchkey 2y ago
When people are working on things like this where I don't understand what it is used for, I tend to run towards it and find out as much as I can. It is easy enough to just google zk usecase and find all sorts of various applications. None may apply to _you_, but that doesn't mean it is not meaningful for _others_.
matthewdgreen 2y ago
1. Imagine a situation where someone must run a (publicly-known) program on your behalf, and produce an output. But you don't fully trust them to compute that output correctly. This problem crops up in all sorts of applications, from blockchains to cloud computing. 2. Of course there is a simple solution to this problem. You (as a recipient of the output) could simply ask for the inputs, including any random numbers used, and re-compute the program yourself. But there are cases where this doesn't make sense: a. If the inputs to the program are secret (for example, the computing party is running a statistical calculation on some confidential data), then this won't be possible. b. If many, many people have to verify the output is correct, then re-running the calculation millions of times might add up to a huge amount of extra computation. To deal with this, systems like this (zkVMs) allow you to solve problem #1 by producing a short "proof" that the program was run successfully on a virtualized processor, and that the output is the result of that computation. Anyone who has a copy of the program code can efficiently verify that proof in much less time than it would take to re-run the program. As a benefit, it's possible to keep (some of) the program inputs secret -- so the verifier just learns that the program was run on some input, but does not need to learn the raw inputs. The challenge here is that these VM "processors" run at speeds in the KHz if you're very lucky, rather than the GHz we're used to on real processors. So in order for this to be worthwhile you need to be willing to accept a (for example) 1-million-fold slowdown in calculating speed for the person doing the proving. For applications that satisfy 2(a) and 2(b) above, this still might be worthwhile! Currently most of the practical applications are in blockchains: in that setting you have one person making a transaction, and then the whole world (literally millions of people) need to know that the transaction was executed successfully, e.g., that it updated an account ledger correctly and didn't steal money from an unrelated account. So far zkVM proofs have fewer applications outside of that setting.

latchkey 2y ago

When people are working on things like this where I don't understand what it is used for, I tend to run towards it and find out as much as I can. It is easy enough to just google zk usecase and find all sorts of various applications. None may apply to _you_, but that doesn't mean it is not meaningful for _others_.

matthewdgreen 2y ago

1. Imagine a situation where someone must run a (publicly-known) program on your behalf, and produce an output. But you don't fully trust them to compute that output correctly. This problem crops up in all sorts of applications, from blockchains to cloud computing. 2. Of course there is a simple solution to this problem. You (as a recipient of the output) could simply ask for the inputs, including any random numbers used, and re-compute the program yourself. But there are cases where this doesn't make sense: a. If the inputs to the program are secret (for example, the computing party is running a statistical calculation on some confidential data), then this won't be possible. b. If many, many people have to verify the output is correct, then re-running the calculation millions of times might add up to a huge amount of extra computation. To deal with this, systems like this (zkVMs) allow you to solve problem #1 by producing a short "proof" that the program was run successfully on a virtualized processor, and that the output is the result of that computation. Anyone who has a copy of the program code can efficiently verify that proof in much less time than it would take to re-run the program. As a benefit, it's possible to keep (some of) the program inputs secret -- so the verifier just learns that the program was run on some input, but does not need to learn the raw inputs. The challenge here is that these VM "processors" run at speeds in the KHz if you're very lucky, rather than the GHz we're used to on real processors. So in order for this to be worthwhile you need to be willing to accept a (for example) 1-million-fold slowdown in calculating speed for the person doing the proving. For applications that satisfy 2(a) and 2(b) above, this still might be worthwhile! Currently most of the practical applications are in blockchains: in that setting you have one person making a transaction, and then the whole world (literally millions of people) need to know that the transaction was executed successfully, e.g., that it updated an account ledger correctly and didn't steal money from an unrelated account. So far zkVM proofs have fewer applications outside of that setting.