Distinguish between two calldata columns in noir #1070
Comments
ledwards2225
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Aug 7, 2024
Previously we could use a single calldata and return_data from noir with support from the bberg backend. With [this](https://github.com/noir-lang/noir/pull/5599/files) PR, noir has an interface for multiple calldata entities. The backend has support for two calldata columns (`calldata` and `secondary_calldata`). This work hooks up a second calldata column in dsl. The main limitation of this work is that there is no way to distinguish between the two calldata columns in dsl. This is OK for the operations within a single circuit because in that context there is no important distinction between the two calldata columns (`calldata`, `secondary_calldata`). It does cause a problem however in the mechanism for linking two circuits via the databus. This is because we need to know which calldata corresponds to app data and which corresponds to previous kernel data in order to prove that the connection was made faithfully. The ideal solution is probably to treat `secondary_calldata` (possibly rename to `app_calldata`?) as a unique entity in noir (similar to how `calldata` and `return_data` are treated as different entities), rather than allowing arbitrarily many individual `calldata` entities. I made an issue [here](AztecProtocol/barretenberg#1070). --------- Co-authored-by: sirasistant <[email protected]>
AztecBot
pushed a commit
that referenced
this issue
Aug 8, 2024
Previously we could use a single calldata and return_data from noir with support from the bberg backend. With [this](https://github.com/noir-lang/noir/pull/5599/files) PR, noir has an interface for multiple calldata entities. The backend has support for two calldata columns (`calldata` and `secondary_calldata`). This work hooks up a second calldata column in dsl. The main limitation of this work is that there is no way to distinguish between the two calldata columns in dsl. This is OK for the operations within a single circuit because in that context there is no important distinction between the two calldata columns (`calldata`, `secondary_calldata`). It does cause a problem however in the mechanism for linking two circuits via the databus. This is because we need to know which calldata corresponds to app data and which corresponds to previous kernel data in order to prove that the connection was made faithfully. The ideal solution is probably to treat `secondary_calldata` (possibly rename to `app_calldata`?) as a unique entity in noir (similar to how `calldata` and `return_data` are treated as different entities), rather than allowing arbitrarily many individual `calldata` entities. I made an issue [here](#1070). --------- Co-authored-by: sirasistant <[email protected]>
sirasistant
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Aug 12, 2024
AztecBot
pushed a commit
that referenced
this issue
Aug 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently noir allows for multiple calldata arrays via a syntax like:
y: call_data(0) [u32; 2], z: call_data(1) [u32; 4]. In dsl, this leads to two independent calldata block constraints, but the ID used in noir is not received. This is a problem because it means there is no way for bberg to determine which calldata corresponds to app data and which corresponds to previous kernel data, which is crucial for properly linking circuits via the databus mechanism. The solution is likely to implementsecondary_calldataorapp_calldataas its own unique entity in noir, rather than allowing for arbitrarily manycalldataentities.The text was updated successfully, but these errors were encountered: