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.
The current graph traversal logic is depth first. Thus on the ZKP side, the multiplier gates corresponding to the inputs will not be contiguous as they are allocated into the prover's
Secret::{a_L,a_R}
. In fact, determining the location of the input gates is not generally feasible (any multiplications performed with said inputs are going to be evaluated during the graph traversal as soon as those inputs are .. inputted).This PR changes the graph traversal to be breadth first, so we allocate all the inputs first, in one contiguous block, and then we handle any downstream multiplications in the circuit.
Furthermore, since we're using a
VecDeque
to deque ready nodes, we may as well pop them from the front. This allows for a more intuitive traversal of the inputs in order, so we don't need to handle any reversal or odd pending final multiplier case when constructing the shared generators.The tests pass, so it seems we didn't have any correctness assumptions on this traversal. But this change is a low level detail of the compiler to both FHE and ZKP, so we ought to think carefully about any ramifications. There could be performance impacts to FHE/ZKP program compilation. If desired we could diverge the FHE/ZKP compilation so that only ZKP uses the breadth first approach, but only if there is a good reason to do so.