Investigate acir tests where varnum != witness.size() #815
Assignees
Comments
|
I would think that |
seems to be the other acir opcodes, we will revisit this post break
|
|
Explanation: |
ledwards2225
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Jan 4, 2024
This work attempts to add a robust means for construction of bberg circuits from acir data. The difficulty comes primarily from different assumptions about constant variables added in the builder constructors. The problem is essentially that constraints are constructed from acir in two ways: directly and indirectly. Directly means the witness values themselves are known at the point of acir generation. In this case gates are specified directly via indices into a "witness" array. Most constraints are indirect in the sense that bberg is presented with an acir opcode, a sha hash say, and has to turn that into constraints using internal bberg mechanisms. This leads to issues when the "witness" array (and acir object) and the "variables" array (a bberg builder object) are offset from one another, as can happen when constant variables are added in the bberg builder constructors. The issue is further complicated by the fact that noir applies a PRE-offset (see [here](noir-lang/noir#3813)) to the indices in the directly specified gates to account for the fact that the Ultra builder historically added a single constant in its constructor. The GUH builder adds 3 more, which is how this issue arose in the first place. However the issue would have come up regardless once we removed that +1 from noir which everyone agrees should not be there. The solution was to add a new builder constructor that takes some data from acir (witness, public_inputs, etc.), populates the analogous structures in the builder, and then adds the necessary constant variables. This means that the indices encoded into explicit gates from acir correctly index into builder.variables, regardless of how many constants are added subsequently. This solution will also work once we remove the +1 from noir, with one additional tweak in bberg that is clearly indicated in the code. Closes AztecProtocol/barretenberg#815
AztecBot
pushed a commit
that referenced
this issue
Jan 7, 2024
This work attempts to add a robust means for construction of bberg circuits from acir data. The difficulty comes primarily from different assumptions about constant variables added in the builder constructors. The problem is essentially that constraints are constructed from acir in two ways: directly and indirectly. Directly means the witness values themselves are known at the point of acir generation. In this case gates are specified directly via indices into a "witness" array. Most constraints are indirect in the sense that bberg is presented with an acir opcode, a sha hash say, and has to turn that into constraints using internal bberg mechanisms. This leads to issues when the "witness" array (and acir object) and the "variables" array (a bberg builder object) are offset from one another, as can happen when constant variables are added in the bberg builder constructors. The issue is further complicated by the fact that noir applies a PRE-offset (see [here](noir-lang/noir#3813)) to the indices in the directly specified gates to account for the fact that the Ultra builder historically added a single constant in its constructor. The GUH builder adds 3 more, which is how this issue arose in the first place. However the issue would have come up regardless once we removed that +1 from noir which everyone agrees should not be there. The solution was to add a new builder constructor that takes some data from acir (witness, public_inputs, etc.), populates the analogous structures in the builder, and then adds the necessary constant variables. This means that the indices encoded into explicit gates from acir correctly index into builder.variables, regardless of how many constants are added subsequently. This solution will also work once we remove the +1 from noir, with one additional tweak in bberg that is clearly indicated in the code. Closes #815
Maddiaa0
pushed a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Jan 8, 2024
This work attempts to add a robust means for construction of bberg circuits from acir data. The difficulty comes primarily from different assumptions about constant variables added in the builder constructors. The problem is essentially that constraints are constructed from acir in two ways: directly and indirectly. Directly means the witness values themselves are known at the point of acir generation. In this case gates are specified directly via indices into a "witness" array. Most constraints are indirect in the sense that bberg is presented with an acir opcode, a sha hash say, and has to turn that into constraints using internal bberg mechanisms. This leads to issues when the "witness" array (and acir object) and the "variables" array (a bberg builder object) are offset from one another, as can happen when constant variables are added in the bberg builder constructors. The issue is further complicated by the fact that noir applies a PRE-offset (see [here](noir-lang/noir#3813)) to the indices in the directly specified gates to account for the fact that the Ultra builder historically added a single constant in its constructor. The GUH builder adds 3 more, which is how this issue arose in the first place. However the issue would have come up regardless once we removed that +1 from noir which everyone agrees should not be there. The solution was to add a new builder constructor that takes some data from acir (witness, public_inputs, etc.), populates the analogous structures in the builder, and then adds the necessary constant variables. This means that the indices encoded into explicit gates from acir correctly index into builder.variables, regardless of how many constants are added subsequently. This solution will also work once we remove the +1 from noir, with one additional tweak in bberg that is clearly indicated in the code. Closes AztecProtocol/barretenberg#815
michaelelliot
pushed a commit
to Swoir/noir_rs
that referenced
this issue
Feb 28, 2024
This work attempts to add a robust means for construction of bberg circuits from acir data. The difficulty comes primarily from different assumptions about constant variables added in the builder constructors. The problem is essentially that constraints are constructed from acir in two ways: directly and indirectly. Directly means the witness values themselves are known at the point of acir generation. In this case gates are specified directly via indices into a "witness" array. Most constraints are indirect in the sense that bberg is presented with an acir opcode, a sha hash say, and has to turn that into constraints using internal bberg mechanisms. This leads to issues when the "witness" array (and acir object) and the "variables" array (a bberg builder object) are offset from one another, as can happen when constant variables are added in the bberg builder constructors. The issue is further complicated by the fact that noir applies a PRE-offset (see [here](noir-lang/noir#3813)) to the indices in the directly specified gates to account for the fact that the Ultra builder historically added a single constant in its constructor. The GUH builder adds 3 more, which is how this issue arose in the first place. However the issue would have come up regardless once we removed that +1 from noir which everyone agrees should not be there. The solution was to add a new builder constructor that takes some data from acir (witness, public_inputs, etc.), populates the analogous structures in the builder, and then adds the necessary constant variables. This means that the indices encoded into explicit gates from acir correctly index into builder.variables, regardless of how many constants are added subsequently. This solution will also work once we remove the +1 from noir, with one additional tweak in bberg that is clearly indicated in the code. Closes AztecProtocol/barretenberg#815
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: