We use VerifierInstance in the vanilla recursive verification tests #892
Labels
Comments
maramihali
changed the title
codygunton
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Mar 4, 2024
As the name says. Because of the previous PRs, this should be quite straightforward to review. Basic idea: - Replace `create_foo` functions calls with `Foo` constructor calls. - When using `Composer` in the type system, change to `Flavor` or `Prover` as the case may be. - Update includes to resolve dependencies that were implicit in ultra_composer.hpp dependency. Resolves AztecProtocol/barretenberg#892 as a side effect. Follow up to: #4848 --------- Co-authored-by: lucasxia01 <[email protected]>
AztecBot
pushed a commit
that referenced
this issue
Mar 5, 2024
As the name says. Because of the previous PRs, this should be quite straightforward to review. Basic idea: - Replace `create_foo` functions calls with `Foo` constructor calls. - When using `Composer` in the type system, change to `Flavor` or `Prover` as the case may be. - Update includes to resolve dependencies that were implicit in ultra_composer.hpp dependency. Resolves #892 as a side effect. Follow up to: AztecProtocol/aztec-packages#4848 --------- Co-authored-by: lucasxia01 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the recursive verifiers (except PG which doesn't have inner and outer), get_outer_composer uses a constexpr if clause to figure out the right type for the composer and other data structures. Before, this was enough, as we were computing the verification key through the composer but now we need the flavor. The most simple way to get the right type for the verification key for now is to create a VerifierInstance but we should refactor this as non-PG verifiers don't operate on VerifierInstances
The text was updated successfully, but these errors were encountered: