fix: Remove hardcoded first witness index #3813
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is a testing PR |
ledwards2225
added a commit
to AztecProtocol/aztec-packages
that referenced
this pull request
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
to AztecProtocol/barretenberg
that referenced
this pull request
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 pull request
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
|
Closing in favour of AztecProtocol/aztec-packages#3887 |
michaelelliot
pushed a commit
to Swoir/noir_rs
that referenced
this pull request
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Problem*
Resolves
Summary*
Quick testing with Luke
Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmton default settings.