-
Notifications
You must be signed in to change notification settings - Fork 121
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
Error feedback on compile-prover discrepancies #1363
base: v1
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This contains new circuit runner, runCircuit()
, to debug constraints!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code in this new file consists of:
- Code that handles zkApp proof creation, which was moved here from
account_update.ts
- New method
debugInconsistentConstraints()
, which is triggered after encountering certain errors in the zkApp prover. It then runs the newrunCircuit()
twice, once in compile and once in prover mode, to identify any mismatch in the generated constraints. If a mismatch is found, we throw a very helpful error that points to it. Otherwise, we throw the original prover error.
type SnarkyVector = [0, [unknown, number, FieldVector]]; | ||
type ConstraintSystem = unknown; | ||
|
||
type SnarkyState = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type description of snarky's internal state
Closes #629
log_constraint
hook to collect constraints + their stack tracesbindings: o1-labs/o1js-bindings#236
mina: MinaProtocol/mina#14887
snarky: o1-labs/snarky#834
Results
The tooling in this PR helped me get to the root of a long-standing, complicated bug, by immedately giving a lead to the problem and enabling to fix it within a few hours: #706
As a simpler example, consider this zkApp method which hashes together a variable with a random value in order to create a blinding commitment to the input.
The catch is that
Field.random()
returns a random constant. Which means, this method creates a different constraint every time it runs, and is invalid.Before this PR, proving this would result in an error like this, with the stack trace pointing into the Kimchi prover -- so there was no way to tell where in your method the problem might be:
With the changes introduced here, we get precise feedback, which correctly identifies the problem and points us to the place in our code that generated different constraints on different runs: