-
Notifications
You must be signed in to change notification settings - Fork 236
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
chore!: cleanup recursion interface #3528
Conversation
…ject while building the circuit
barretenberg/cpp/src/barretenberg/dsl/acir_format/recursion_constraint.hpp
Show resolved
Hide resolved
barretenberg/cpp/src/barretenberg/proof_system/circuit_builder/circuit_builder_base.hpp
Show resolved
Hide resolved
This seems to be failing tests because the recursion tests don't actually set the inner public inputs, this was never flagged up before because we were using the values in the proof |
One last thing to note, is the fact that this PR does not allow one to pass a proof with an aggregation object to a std::verify_proof anymore. What we'd need to do is add the prepend the aggregation object to the proof since its a "proof system public input". Before doing this, we should clarify the possible usecases, that would require nested aggregation object and the usecases that would only require threading the output aggregation object |
Benchmark resultsNo metrics with a significant change found. Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Values are compared against data from master at commit L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
MiscellaneousTransaction sizes based on how many contracts are deployed in the tx.
|
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.
LGTM. We have things we need to discuss with regards to nested agg object and the add_recursive_method
but this can all be handled in follow-up work as this is a good improvement on the current interface.
barretenberg/cpp/src/barretenberg/dsl/acir_format/recursion_constraint.cpp
Show resolved
Hide resolved
barretenberg/cpp/src/barretenberg/dsl/acir_format/recursion_constraint.cpp
Show resolved
Hide resolved
barretenberg/cpp/src/barretenberg/dsl/acir_format/recursion_constraint.test.cpp
Show resolved
Hide resolved
barretenberg/cpp/src/barretenberg/proof_system/circuit_builder/circuit_builder_base.hpp
Show resolved
Hide resolved
barretenberg/cpp/src/barretenberg/proof_system/circuit_builder/circuit_builder_base.hpp
Show resolved
Hide resolved
noir/test_programs/execution_success/double_verify_proof/src/main.nr
Outdated
Show resolved
Hide resolved
…ain.nr Co-authored-by: Maxim Vezenov <[email protected]>
We can fixup the nits in a separate PR and add the nested aggregation object |
Will re-merge this into master when #3729 is merged |
This is a recreation of this PR (#3528) to handle PR #3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This is a recreation of this PR (AztecProtocol/aztec-packages#3528) to handle PR AztecProtocol/aztec-packages#3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This is a recreation of this PR (AztecProtocol/aztec-packages#3528) to handle PR AztecProtocol/aztec-packages#3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This is a recreation of this PR (AztecProtocol/aztec-packages#3528) to handle PR AztecProtocol/aztec-packages#3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This is a recreation of this PR (#3528) to handle PR #3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This PR adds a test that does a full recursive verification similar to `TestFullRecursiveComposition` under `recursion_constraint.test.cpp` but using Noir. A couple bugs fixes were done to enable the new `double_verify_nested_proof` test: - We have an assert in the recursion constraint that checks `num_public_inputs == RecursionConstraint::AGGREGATION_OBJECT_SIZE` when generating the dummy transcript for when we do not have valid witness assignments. If we want to recursively verify a recursive proof that itself has extra public inputs this assertion makes that impossible (in fact the cpp test does not use any public inputs for `TestFullRecursiveComposition` and this may be why this assertion wasn't hit earlier). - After moving to a definition of a proof as separate from its public inputs in (#3528) we were missing the accurate copy constraints in the case of no valid witness assignment. In the case of a nested proof the public inputs will contain an aggregation object for which we expect two accurate G1 points. Otherwise, even with the removed assertion above we will always hit a "trying to invert 0" error when working without valid witness assignments.
This PR adds a test that does a full recursive verification similar to `TestFullRecursiveComposition` under `recursion_constraint.test.cpp` but using Noir. A couple bugs fixes were done to enable the new `double_verify_nested_proof` test: - We have an assert in the recursion constraint that checks `num_public_inputs == RecursionConstraint::AGGREGATION_OBJECT_SIZE` when generating the dummy transcript for when we do not have valid witness assignments. If we want to recursively verify a recursive proof that itself has extra public inputs this assertion makes that impossible (in fact the cpp test does not use any public inputs for `TestFullRecursiveComposition` and this may be why this assertion wasn't hit earlier). - After moving to a definition of a proof as separate from its public inputs in (AztecProtocol/aztec-packages#3528) we were missing the accurate copy constraints in the case of no valid witness assignment. In the case of a nested proof the public inputs will contain an aggregation object for which we expect two accurate G1 points. Otherwise, even with the removed assertion above we will always hit a "trying to invert 0" error when working without valid witness assignments.
This is a recreation of this PR (AztecProtocol#3528) to handle PR AztecProtocol#3729 # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]>
This PR aims to fix some of the long-standing issues with the recursion interface, in particular:
Users needing to manually handle the aggregation objects
asking users to pass the barretenberg proofs as inputs, and the public inputs.
The first is fixed by removing the notion of aggregation objects from the Noir program and defining it as a "proof system public input".
The second is fixed by defining a proof as only containing the proof elements and public inputs separately. (There is a PR up to do this more extensively, but it was temporarily shelved as we applied the changes more upstream to see what broke, after the recursion changes are made, I think we can merge that PR).
There are a few other things that I'd like to address but may be left for another PR (due to them being significant breaking changes):
Users need to convert their proof and VK from bytes to packed fields. We currently have a 30K budget in terms of gates so it should be possible to do this conversion in circuit. The benefits of this is that proofs no longer look
is_recursive can be added as a circuit definition, removing the need for the
is_recursive
flagChecklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.