-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formal model for circuit randomization #294
Comments
The vRAM (Section III-D) and "Linear-Size Constant-Query IOPs for Delegating Computation" (should be online soon) papers formalize this sort of "interactive constraint generation"; maybe looking there can help? |
Thanks for the reference! |
Hi - can you recommend another rust library for R1CS ZK proofs that we can use until yoloproofs is stable? Just thought I'd ask the experts. Thanks. |
I'm not aware of any ZKP library that can be considered stable. Very few ZKPs are widely deployed (what comes to mind is Zcash, Monero and Liquid), and those are also a moving target. What does "stable" mean for you? To me, apart from the need for the formal proof as stated above, there's also a concern about API stability. On that, we have two data points: (1) the novel two-phase construction is entirely optional and even the proof size is smaller by 96 bytes if you don't use it; (2) we didn't break the API in over a year. So if your concern is some gigantic refactoring required in the future, that is as likely as having v1.0 today and deciding to make a much better v2.0 tomorrow. But for the hypothetical "v1.0" to be reasonably supported anyway, it needs to be actually used in deployed systems. Currently, we'd like to collect some feedback from people building on top of R1CS API (I myself is doing so with ZkVM) that may influence tweaks to the API, such as recent #313. |
Thanks. I think stable to me meant no security vulnerabilities. I'm not concerned about API changes. I'll start using the library right now if there is no concern about the proof. Thanks a ton. |
Well, you only live once ;-) |
My understanding is that there's not likely to be any problem with the construction, it's just that formalizing and proving correctness is a bunch of work, and nobody has done it yet. It should probably be done before someone deploys the proof system, but maybe someone who's hoping to make use of the deployment could put resources towards proving correctness.... |
I've looked at plookup paper (commentary) recently and it seems like it needs more than two phases than our API currently provides. TL;DR of plookup
where β is an extra random challenge. This yields The idea behind concatenation is that you'll have each value from lookup table found at least once. So if your program used it K times, it'll be found K+1 times. And the randomized "difference" would mean that for K times there's a match, you'd find it in Why more phases?
|
Our implementation of the R1CS system differs from the one described in the paper.
We extended the system to allow randomized constraints, obtained as Fiat-Shamir challenges bound to the entire previous proof transcript data. This makes the system more powerful: for example, we can do a proof-of-shuffle asymptotically faster (
O(n)
) than described in the paper (O(n log n)
).Our initial iteration of this idea had the limitation that the randomness could only be bound to the values of the externally committed wires (the individual
V
commitments), but for Cloak we needed to be able to bind the randomness to the values of internal wires (committed to by thea_L, a_R, a_O
vector commitments).To solve this problem, @oleganza came up with a two-phase construction where the vector commitments are "split" and randomized, e.g.
a_L = a_L' + e*a_L''
, wherea_L'
is a vector with nonzero "phase 1" entries,a_L''
is a vector with nonzero "phase 2" entries, ande
is a FS challenge. (More details on the construction are available in our internal documentation).Before we can release this API, we need to a) formalize the model for these randomized constraint systems and b) have a security proof in that model.
We described this problem to @bbuenz last fall and at the Stanford Blockchain Conference in January. As of ZCon1 I think he said that he had suggested the problem to an MSc student but I don't remember the details. I think this work would be done best in the open; this GH issue is a good place to keep track of it, because it blocks release of the R1CS API.
The text was updated successfully, but these errors were encountered: