You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the design choices we made in halo2_proofs is that we want circuit synthesis and witness generation logic to be closely-coupled, to reduce chances for error (a design choice we adopted from bellman). As a result, all witness values are assigned via closures that are not executed during keygen (when we have no witnesses), and passed around as Option<T> (and are None during keygen). We then have gadgets that are meant to encapsulate this optionality, allowing the developers to only need to deal with it at the edges of their circuit logic.
We don't currently explain this well. In one example, a user misread the Orchard circuit logic they were using as an example, and tried making the gadgets in their circuit optional (which does not work, as it changes the circuit structure). It probably didn't help that the in-circuit gadgets are often named the same as their outside-circuit equivalents that are used for witnesses (e.g. the gadgets::ecc::Point gadget which can be instantiated from an Option<pallas::Point> witness).
We should add several new sections to the user guide:
A section that explains why witnesses need to be optional.
A tutorial on how to use gadgets, that includes an explanation of how we use them to wrap witness optionality.
The text was updated successfully, but these errors were encountered:
One of the design choices we made in
halo2_proofs
is that we want circuit synthesis and witness generation logic to be closely-coupled, to reduce chances for error (a design choice we adopted frombellman
). As a result, all witness values are assigned via closures that are not executed during keygen (when we have no witnesses), and passed around asOption<T>
(and areNone
during keygen). We then have gadgets that are meant to encapsulate this optionality, allowing the developers to only need to deal with it at the edges of their circuit logic.We don't currently explain this well. In one example, a user misread the Orchard circuit logic they were using as an example, and tried making the gadgets in their circuit optional (which does not work, as it changes the circuit structure). It probably didn't help that the in-circuit gadgets are often named the same as their outside-circuit equivalents that are used for witnesses (e.g. the
gadgets::ecc::Point
gadget which can be instantiated from anOption<pallas::Point>
witness).We should add several new sections to the user guide:
The text was updated successfully, but these errors were encountered: