Support for reset and tail in the databus/ClientIVC #1111
Assignees
Comments
ledwards2225
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Oct 3, 2024
Prior to this PR, the IVC scheme made the assumption that every other circuit was a kernel, i.e. app, kernel, app, kernel, ... etc. In practice, however, it will be common to have two or more consecutive kernels without a corresponding app, e.g. an inner kernel followed immediately by a reset kernel. This PR updates the IVC so that whether or not a circuit is treated as a kernel is determined by the the already existing tag `circuit.databus_propagation_data.is_kernel`. When constructing circuits from noir programs, the above flag is set to true if and only if the circuit has calldata (which apps never do). This allows us to reinstate the full set of circuits in the ivc integration test suite which contains 3 consecutive kernels (inner, reset, tail). In accordance with this change I had to add explicit setting of `is_kernel` to various test suites and flows which previously utilized the default assumption that every other circuit was a kernel. (Many of these cases will soon go away once we are ready to do away with the `auto_verify_mode` version of IVC which exists for testing convenience and does not have any practical use case). Closes AztecProtocol/barretenberg#1111
AztecBot
pushed a commit
that referenced
this issue
Oct 3, 2024
Prior to this PR, the IVC scheme made the assumption that every other circuit was a kernel, i.e. app, kernel, app, kernel, ... etc. In practice, however, it will be common to have two or more consecutive kernels without a corresponding app, e.g. an inner kernel followed immediately by a reset kernel. This PR updates the IVC so that whether or not a circuit is treated as a kernel is determined by the the already existing tag `circuit.databus_propagation_data.is_kernel`. When constructing circuits from noir programs, the above flag is set to true if and only if the circuit has calldata (which apps never do). This allows us to reinstate the full set of circuits in the ivc integration test suite which contains 3 consecutive kernels (inner, reset, tail). In accordance with this change I had to add explicit setting of `is_kernel` to various test suites and flows which previously utilized the default assumption that every other circuit was a kernel. (Many of these cases will soon go away once we are ready to do away with the `auto_verify_mode` version of IVC which exists for testing convenience and does not have any practical use case). Closes #1111
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, BB assumes that every "odd" circuit in ClientIVC is a kernel for the databus. With resets and tails this is not the case. The identification of what is a kernel could be done via the usage of calldata or the recursive verifiers instead, to allow for the flexibility that the protocol needs.
The text was updated successfully, but these errors were encountered: