I feel like I read and ‘understood’ the text of the blog post, but I’m still none the wiser about what sort of things this can prove and what the values of those proofs is.
I'm not involved in the project in any way, but I can probably give an explanation.
This is a risc-v virtual machine that supports rv32im instruction set (the bare minimum + multiplication). You can compile and run programs there as you would on a usual microcontroller.
The "ZK" thing means that you can pass program code + data to this virtual machine, and as a result of execution get some output and a short sequence of bytes that allow the "other side" to verify that the result of program execution is correct without having to re-execute the program. This verification is computationally cheap. In order to do the verification the "other side" only needs that sequence of bytes and a hash of original code+data.
Blockchains use this in context of achieving "byzantine consensus", especially in cases where multiple systems that lack mutual trust are involved. Think for example about if you want to relay information that's been computed on one blockchain to the other. If both blockchains can prove their state transitions with such virtual machine, then it is possible to make a sort of trusted "event queue" between them. There are of course caveats that rollbacks can happen, so it's not a silver bullet.
Not sure how this applies to day-to-day software, but the thing that comes to mind is that it could serve some cases where TPM (hardware modules) are traditionally utilized. The TPM assumes you don't have means to break the hardware, and so it can attest to certain computation by signing the result with a baked-in key.
> pass program code + data to this virtual machine
If you have to pass the data, then how can this possibly help solve, as others have said, scenarios that prove something about data without revealing the data?
In order to verify the proof, you only need a "commitment" to the fact that you passed specific input data. This can be in the form of calculating a cryptographic hash.
Imagine that you represent a program and data as a flat byte array (which is the typical case for risc-v). Your program contains a prologue at the very start (0x0) that calculates the hash of the rest of the memory and checks that the hash is equal to some value hardcoded right after the prologue and if it doesn't match - then it panics. Then if you can prove that the VM followed all steps exactly as the hardware architecture prescribes, it's just impossible for the result to be any other way. What you need now is to only send to other side this prologue together with the hash. You don't have to reveal the rest of the memory.
Of course I'm simplifying a bit, but I hope the idea is clear.
You don't _have_ to, I think the parent poster is just giving an example of how this can be used.
The "Zero Knowledge" part is that you can tell me "for this particular program code, I know an input that gives an output of 'foobar'" and I can be convinced that you're telling me the truth without seeing what that input actually is.
Let's put it this way. If you can break it and are willing to commit crime - you can earn a lot of money. I'm personally not equipped to judge the level of security, because I'm not a cryptography researcher. What I understand is that the overall ZK cryptography space has been around for a long time, and basic properties are well researched. I tried to read the PLONK paper for entertainment purposes and it's quite easy to understand.
If you want to prove a program, you need to convert it to what is called "arithmetic circuits". This is a clever way of saying "a system of polynomial equations". It is as if you're converting the code to logic gates but instead here you use arithmetic: addition, raising to a certain power, etc. It is a process called "arithmetization".
The proof calculation involves folding this system of equations in various ways and collecting a "witness". Not sure if I'm explaining this correctly, but it's probably in the right direction at least.
The problem with all ZK proofs is that the last bit of calculating the witness is very computationally expensive. What takes milliseconds to run on the CPU can take many hours to prove. And a lot of research is focused on clever mathematical tricks that allow to speed up the proofs while keeping the risks of circuit compromise low enough. As you may guess, the more bleeding edge the research the less it is peer-reviewed.
So I'd say that "it depends".
As for DRM - probably not. At least not in a way that companies installing the DRM would want it to work. They likely want you to be unable to decrypt something at all outside of a particular chip, and watermark the video on top of that to be sure that you're not screen-capturing it.
UPD: there's a decent free into course into modern ZK cryptography: https://zkiap.com/
Proving performance is improving at a rapid pace though, like 10X/year. And converting to circuits is automatic now; there are compilers that can do it for arbitrary Rust code.
Think of zk proofs as an extension of asymmetric cryptography to arbitrary logic.
A zkVM makes encoding the arbitrary logic as easy as writing a normal Rust program.
A proof is a probabilistic statement that a specific program run with some public inputs and maybe some private inputs was executed correctly.
For crypto zk proofs are mostly for their succinctness property, not for privacy.
Outside of crypto privacy is the more important property, let's say a government issues a signed document, I could prove any arbitrary statement about that document without revealing the document. We could use zk proofs for anything we use canonical documents for today and we would gain privacy. Will we do this, probably not, but it would be an improvement.
One simple application is making blockchains vastly more scalable.
For a blockchain to be secure you have to store each transaction on chain, with enough information so everyone can verify that it's valid. Normally this means storing the sender's signature, which is bulky.
With ZK, you can bundle up thousands of transactions, skip all the signatures, and include a single 256-bit proof that all the transactions had valid signatures.
For those looking for applications outside crypto, this might also be interesting: https://docs.ezkl.xyz/
It's similar to Succinct but for proofs of ML models instead of RISCV. So you could generate a proof on some private data, on your computer or in a trusted environment, and submit the proof to show that you pass a fraud check without revealing any of your data.
I wasn’t sure if adding text is considered good form when submitting a link to a project I’m not part of. I followed the guidelines and did not editorialize the title. Surprisingly, ‘zkVM’ is a unique acronym, and search only returned relevant results.
While it's commendable that you're trying to extend BitVM to handle RISC-V...
Why though? The dispute resolution game is eminently trollable and can be made very expensive by an adversary.
Then you try to make it N-party, which reduces all of the security assumptions down to one which isn't verifiable on-chain and doesn't inherit any of Bitcoin's security.
Yes, technically it's possible, should it be done? Probably not... Would I trust it? No... Does it come anywhere near the security of SP1... Absolutely not.
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.
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.
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_.
Allow me to add some context. The idea behind "proving" computation relies on the assumption that someone wants to verify it.
Some systems require verification. Most notably: distributed systems that don't rely on a centralized authority to enforce rules.
Historically, you either don't verify compute: you don't verify that AWS runs correctly code on the cloud, nor do you verify the algorithm used to compute your taxes.
Or you verify compute via re-execution (to make sure a program ran correctly, just run it locally on given inputs): e.g. every participant in the Bitcoin protocol re-executes all transactions on the network. This means that all payments on this platform are verified by peer-to-peer nodes. Moreover, anyone who desires to convince themselves that the system runs with integrity can simply boot a node and join the network. This adds robust security characteristics! Nonetheless, this creates great friction as every time a transaction is verified on these distributed systems, it is re-executed. This does not scale.
Enters "ZK" (zero-knowledge), a technology able to grant verifiability to computation that does not rely on re-execution but rather checking a succinct certificate of correct computation. Anything that refers to succinct proofs of computation is currently referred to as ZK. Nonetheless, ZK can grant either Scalability or Privacy. It is usually known to refer to privacy. ZK-VMs are mostly used to achieve scalability.
The disruptive advantage of ZK is the separation of two actors: Prover and Verifier. The prover runs a computation once and generates a proof that it did so with integrity (following some pre-defined rules such as "i can't create new money"). Verifiers are then able to check the integrity of the network with overwhelmingly low hardware requirements.
TL;DR: ZK compresses compute. The first use case for ZK (in terms of scalability) is to prove Blockchain transactions to greatly increase scalability of blockchains. Many use cases will follow.
Yes, it could replace all government ids, while allowing you to prove arbitrary statements about said signed government documents without revealing them (not saying it will happen).
Let's say the usecase is to prove that you're 21+ to enter a bar in the US. I don't want to have to hand over my ID with my personal information on it.
On my phone, I could have the "proof", which can be validated by the door guard with a simple NFC device (ie: another phone) that is compatible with that proof.
The door guard needs to validate your face matches your ID. In you example you provide the door guard with proof that you are in real-time communication with a real ID, not that it's yours.
A challenge response would be the door guard provides you with a picture of yourself, and then you run their verification code with the picture and your ID.
However, you would also want to take into account multi-venue barring lists, which would require you to provide that you're not on a list of people (that you don't have access to).
In reality, this gets complicated very fast, and I would much prefer to just show the door guard my ID rather than involve computers in any way shape or form, let alone ZK systems.
If you have digital id signed with government keys (like passport) you would prove that person has ID where the age is above 18, attached to this photo and that all the info comes from a single government sanctioned id.
You don’t need to conceal all the data. Just the bits you don’t want to leak.
If you're going with a "digital id signed with government keys", then we don't need a ZKP, we can just use digital signatures. A certificate from the government that says "the holder of this id is 18+" is all the information that needs to be contained in the certificate.
That is a moving target. I could be 17 today and 18 tomorrow. Also it is not feasable to make all the different variations of ID but they do give out single one with all the info.
Part of the problem is that "normal" digital signatures create correlation factors that can be used to track/profile users, whereas a zero knowledge proof (over knowledge of a valid signature) could prevent this.
How is this different from showing a non-digital driver's license that says you're 21+? Underage kids borrow each others' driver's licenses, so they can borrow each others' phones.
I'm failing to parse your argument here. We're talking about an example usecase of zkProofs as a way to better explain the technology. We're not trying to solve the problem with every different random way to sneak into a club that you can think of.
I actually was a club owner in San Francisco at one point in time. Even went through the ABC training. Got sued at one point by the ABC cause they snuck someone in under age. No system is perfect.
But, I'll tell you that having someone show me a cell phone with my picture on it, nicely large and backlit and saying I'm 21, is a great solution to requiring people to present an ID that could come from one of 1000 places.
> But, I'll tell you that having someone show me a cell phone with my picture on it, nicely large and backlit and saying I'm 21, is a great solution to requiring people to present an ID that could come from one of 1000 places.
I agree, but I already have a California DMV app that does this. It doesn't need a ZKP.
> I'm failing to parse your argument here. We're talking about an example usecase of zkProofs as a way to better explain the technology.
Indeed my argument is that ZKP seems unnecessary in this example, and yes it's extremely hard for me to appreciate the usefulness of a ZKP with an example where it seems useless.
> I agree, but I already have a California DMV app that does this. It doesn't need a ZKP.
What happens when you aren't in California? Or what happens when someone from outside of California comes to a bar.
> Indeed my argument is that ZKP seems unnecessary in this example, and yes it's extremely hard for me to appreciate the usefulness of a ZKP with an example where it seems useless.
Then go find better examples if you're this interested.
It lets you to prove a program without having to execute it, and without needing to send the potentially private bytes over the wire.
Privacy and identity is one example; like having a proof of some record of your identity that you can submit to an app (ie: age, citizenship, # of followers on twitter), without the need to share your personal details.
Succinct proofs is another application. If you have a distributed compute environment (think folding@home), you may want receipts that proves a user in the network correctly executed a program. With ZK, the idea is that it can be cheaper to prove a program executed correctly, rather than re-execute it.
I feel like I read and ‘understood’ the text of the blog post, but I’m still none the wiser about what sort of things this can prove and what the values of those proofs is.