SP1: A performant, 100% open-source, contributor-friendly zkVM
blog.succinct.xyz
blog.succinct.xyz
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.
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.
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.
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/
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?
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.
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.
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.
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.
edit: The fact that its actually zkVM instead is even more confusing.
Why is it limited to LLVM-compiled languages? Wouldn't anything that compiles to RISC-V work?
And since the LLVM bitcode format completely changes every time there's a new LLVM release, how does that work?
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.
this is the only legit effort to use Bitcoin to verify ZKPs
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_.
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.
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.
Getting governments, banks, and other trusted third parties to sign documents is very difficult, but is happening in some cases.
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.
You don’t need to conceal all the data. Just the bits you don’t want to leak.
[1]https://ethresear.ch/t/zero-knowledge-proofs-of-identity-usi...
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.
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.
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.
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.
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.