Skip to content
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

Closed
vezenovm opened this issue Jan 25, 2024 · 2 comments · Fixed by #4221
Closed

Remove is_recursive flag #4222

vezenovm opened this issue Jan 25, 2024 · 2 comments · Fixed by #4221
Assignees
Labels
C-barretenberg Component: barretenberg cryptography library

Comments

@vezenovm
Copy link
Contributor

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

#[recursive]
fn main(x: Field, y: pub Field) {
    assert(x == y, "x and y are not equal");
}

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

@github-project-automation github-project-automation bot moved this to Todo in A3 Jan 25, 2024
@vezenovm vezenovm self-assigned this Jan 26, 2024
@vezenovm vezenovm added this to Noir Jan 26, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jan 26, 2024
@vezenovm vezenovm added C-protocol-circuits Component: Protocol circuits (kernel & rollup) C-barretenberg Component: barretenberg cryptography library labels Jan 26, 2024
@vezenovm vezenovm modified the milestone: Execution Environment Jan 26, 2024
@vezenovm vezenovm removed the C-protocol-circuits Component: Protocol circuits (kernel & rollup) label Jan 26, 2024
@Savio-Sou
Copy link
Member

Savio-Sou commented Jan 26, 2024

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?

@vezenovm
Copy link
Contributor Author

Yeah right now we have the is_recursive flag threaded throughout our tooling and even extra methods such as generateIntermediateProof and generateFinalProof which adds extra confusion. If we ever want to expand this flag we have to also change its usage in all these different places of the tooling. We should instead have it as part of the circuit description which a backend should handle how it sees fit.

vezenovm added a commit that referenced this issue Feb 1, 2024
…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]>
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Feb 1, 2024
@github-project-automation github-project-automation bot moved this from Todo to Done in A3 Feb 1, 2024
michaelelliot pushed a commit to Swoir/noir_rs that referenced this issue Feb 28, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-barretenberg Component: barretenberg cryptography library
Projects
Archived in project
2 participants