-
Notifications
You must be signed in to change notification settings - Fork 237
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
Remove is_recursive
flag
#4222
Comments
The value here would be making recursion tooling-agnostic, as in e.g. Nargo, NoirJS, etc. can then automatically handle the proving of a Noir program marked recursive, rather than requiring manual tooling tweaks on proving. Correct? |
Yeah right now we have the |
…nition (#4221) Resolves #4222 Currently in order to specify whether we want to use a prover that produces SNARK recursion friendly proofs, we must pass a flag from the tooling infrastructure. This PR moves it be part of the circuit definition itself. The flag now lives on the Builder and is set when we call `create_circuit` in the acir format. The proof produced when this flag is true should be friendly for recursive verification inside of another SNARK. For example, a recursive friendly proof may use Blake3Pedersen for hashing in its transcript, while we still want a prove that uses Keccak for its transcript in order to be able to verify SNARKs on Ethereum. However, a verifier does not need a full circuit description and should be able to verify a proof with just the verification key and the proof. An `is_recursive_circuit` field was thus added to the verification key as well so that we can specify the accurate verifier to use for a given proof without the full circuit description. --------- Signed-off-by: kevaundray <[email protected]> Co-authored-by: ledwards2225 <[email protected]> Co-authored-by: kevaundray <[email protected]>
…nition (AztecProtocol#4221) Resolves AztecProtocol#4222 Currently in order to specify whether we want to use a prover that produces SNARK recursion friendly proofs, we must pass a flag from the tooling infrastructure. This PR moves it be part of the circuit definition itself. The flag now lives on the Builder and is set when we call `create_circuit` in the acir format. The proof produced when this flag is true should be friendly for recursive verification inside of another SNARK. For example, a recursive friendly proof may use Blake3Pedersen for hashing in its transcript, while we still want a prove that uses Keccak for its transcript in order to be able to verify SNARKs on Ethereum. However, a verifier does not need a full circuit description and should be able to verify a proof with just the verification key and the proof. An `is_recursive_circuit` field was thus added to the verification key as well so that we can specify the accurate verifier to use for a given proof without the full circuit description. --------- Signed-off-by: kevaundray <[email protected]> Co-authored-by: ledwards2225 <[email protected]> Co-authored-by: kevaundray <[email protected]>
We currently require a flag to passed in by the tooling infrastructure to determine whether a prover that produces recursive friendly proofs should be used. We should move to specifying directly on a circuit's definition whether to use the recursive setting.
For example
This would put in the ACIR that we want this to be recursion friendly with a flag which indicate to the backend whether we want to generate a proof that is friendly for verification in another SNARK. This would eliminate the need for nargo to have a --recursive flag
The text was updated successfully, but these errors were encountered: