-
Notifications
You must be signed in to change notification settings - Fork 109
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
Expose side loaded verification key to snarkyjs #673
Comments
This would enable more general-style rollups which could have a "network"-state on their own, making the development of more efficient and distributed rollups possible versus the current trustless but centralized per-contract idea. Also, more contract patterns could emerge, like upgradable proxy contracts, etc. |
Would an API like this possibly made sense? What are the technical limitations and requirements of side loading? class ZkApp extends SmartContract {
@method
verify(proof: AnyProof) {
// bring in a verification key as private input
const vk = Circuit.witness(VerificationKey, () => new VerificationKey())
// verify the VK is one of the 'right ones'
const isValidVk = vk.equals(vk1).or(vk.equals(vk2));
isValidVk.assertTrue();
// verify the proof
vk.verify(proof);
}
} |
That would be a nice API @maht0rz! I imagine something like this should be possible, I think the OCaml code that verifies zkApp proofs in a circuit looks similar |
@mitschabaude i'd love to contribute by implementing this but i am currently bottlenecked by my knowledge of Kimchi, and how it could be exposed into snarkyjs. I personally don't know why exactly this doesnt work already, so that makes it difficult to try and figure out what needs to change in the first place. |
I'd be very interested in the reasons why that is not exposed by default. Is it just a matter of API or is there a different mechanism for the side-loaded keys under the hood? How does the side-loading mechanism actually work on a abstract level? |
@maht0rz @rpanic it's not exposed already / by default because to expose something from ocaml generally some work needs to happen, and back when I exposed pickles to make proving work for smart contracts I didn't have this on my radar (#115) Work usually needs to happen on the ocaml side in this file: https://github.com/MinaProtocol/mina/blob/dfc3a21ce43904bd9d23a3d3ce2c3a2c570071f2/src/lib/snarky_js_bindings/lib/snarky_js_bindings_lib.ml#L2231 |
There's a different mechanism! Pickles supports two kinds of verification keys: "compiled" (these are what snarkyjs currently uses) and "side-loaded": |
I'd love to see this feature hit o1js as soon as possible, this will make circuit design & design of 3rd party libraries much easier. |
"Side-loaded" verification keys are used by Pickles to recursively verify proofs which aren't baked into the verifying circuit at compile time. This is for example necessary for zkApp proofs, which are verified in the transaction snark but can't be baked in at compile time. This seems to be an alternative way of using proof recursion, which is more flexible w.r.t. what proofs can be verified. A user reports needing this feature:
This would also be needed to develop ZkPrograms which are mutually recursive (they can verify the proofs of each other, not just in one direction). Right now, in ZkProgram there is a strict order in which the verification keys have to be compiled: If Program A wants to verify proofs of Program B, then compiling Program A requires the verification key / tag of Program B to be already available. So, there is no way that Program B could depend on Program A.
The goal is to expose the more flexible recursion style to snarkyjs.
The text was updated successfully, but these errors were encountered: