Support for compile-time folding: deprecate? #1164
Comments
codygunton
changed the title
codygunton
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Dec 3, 2024
- Establish API in purely virtual class - This is just a first pass. I will continue to work on this before showing dev rel and others to get buy-in. - Implement some API functions for ClientIVC: prove, verify, prove_and_verify - Support for constructing CIVC proof for input a single circuit - This is interpreted as a "compiletime stack" - Produces ECCVM and Translator proofs from dummy/empty data; future optimization could avoid. - Add `one_circuit` to CIVC to encode whether the MH part of the CIVC proof should be a hiding circuit (which takes a folding proof) or a proof for the single circuit. - Run almost all ACIR tests against ClientIVC - Previously only ran MegaHonk tests, which are not totally meaningful. - Four are skipped because they fail. These failures are expected to be superficial (see AztecProtocol/barretenberg#1164 and the references to it in the PR's new code). - fold_and_verify and mega honk flows go away in bb, but remain until bb.js alignment. - Delete large log file that should not be track (accounts for big negative diff).
AztecBot
pushed a commit
that referenced
this issue
Dec 4, 2024
- Establish API in purely virtual class - This is just a first pass. I will continue to work on this before showing dev rel and others to get buy-in. - Implement some API functions for ClientIVC: prove, verify, prove_and_verify - Support for constructing CIVC proof for input a single circuit - This is interpreted as a "compiletime stack" - Produces ECCVM and Translator proofs from dummy/empty data; future optimization could avoid. - Add `one_circuit` to CIVC to encode whether the MH part of the CIVC proof should be a hiding circuit (which takes a folding proof) or a proof for the single circuit. - Run almost all ACIR tests against ClientIVC - Previously only ran MegaHonk tests, which are not totally meaningful. - Four are skipped because they fail. These failures are expected to be superficial (see #1164 and the references to it in the PR's new code). - fold_and_verify and mega honk flows go away in bb, but remain until bb.js alignment. - Delete large log file that should not be track (accounts for big negative diff).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The original design for the Noir folding interface (iirc by @kevaundray) was that functions could be tagged by the developer and then this signal would be sent to the backend. I call this "compile-time folding". At present, Aztec's architecture does not support using this, rather, Aztec uses "run-time folding". The reason for this is that Aztec's prover must detect which kernels are to be constructed, and then interleave those kernels with the "app functions". The code that does this is written in Typescript code which is downstream of Noir. To handle this, Barretenberg got functions to process a "stack of circuits" assembled in typescript, rather than a single ACIR/witness pair that represents the stack.
Moreover, Aztec's Client IVC scheme requires that additional work be done outside of proving the kernel logic written in Noir. More specifically, the ClientIVC class must: detect which circuits are kernels; append folding verifiers to these; append databus (memory) consistency checks; handle recursive merge verification for correct execution of the Goblin subprotocol. To continue to test the old compile-time folding, it was necessary to either maintain a separate class just to test that functionality which currently has no use case; or continue to support compile-time folding via some hacks. We chose the latter.
We need to assess the future of compile-time folding, and either make a plan for supporting and properly testing it or deprecate it.
The text was updated successfully, but these errors were encountered: