This feature flag is not part of the public API, but only for
conditionally rendering sub-circuit graphs. Renaming it stops the
feature from being enabled in the workspace when we only want to enable
the `dev-graph` feature flag of `halo2_proofs`, which _is_ part of its
public API.
These are all cases inside the ECC chip, where we are inherently
producing valid coordinate pairs as a result of the constraints being
implemented, but it is useful to be explicit about the contract being
asserted at each point we construct `EccPoint` or `NonIdentityEccPoint`.
- We were redundantly storing the `x_p` and `y_p` columns.
- `Config::add_incomplete` was redundantly copying.
Co-authored-by: therealyingtong <yingtong@z.cash>
Both variable-base scalar mul and Sinsemilla use double-and-add with
incomplete addition on a single row, but they do so in slightly
different ways. Some of these are intentional (needing to look up the
y-coordinate vs constrain it), while others are accidental (different
concrete signs in otherwise-identical constraints that make their ASTs
incompatible).
The new `DoubleAndAdd` helper struct extracts the logic that is common
to both implementations, specifically the helper definitions of `x_r`
and `Y_A`. In a future breaking change, we can refactor both gadgets to
share more of this logic, so we are defining the incomplete addition
logic in fewer places.
The new `EccInstructions` instructions, and the corresponding changes to
existing instructions, enable chips to choose when to witness or constrain
the scalars, and simplify scalar reuse (though reuse is not implemented
for `EccChip` yet).
`FixedPoint::mul` and `FixedPointShort::mul` now has the same API style
as `NonIdentityPoint::mul`.
There are two existing patterns for constructing a gate from a set of
constraints with a common selector:
- Create an iterator of constraints, where each constraint includes the
selector:
```
vec![
("foo", selector.clone() * foo),
("bar", selector.clone() * bar),
("baz", selector * bar),
]
```
This requires the user to write O(n) `selector.clone()` calls.
- Create an iterator of constraints, and then map the selector in:
```
vec![
("foo", foo),
("bar", bar),
("baz", bar),
].into_iter().map(move |(name, poly)| (name, selector.clone() * poly))
```
This looks cleaner overall, but the API is not as intuitive, and it
is messier when the constraints are named.
The `Constraints` struct provides a third, clearer API:
```
Constraints::with_selector(
selector,
vec![
("foo", foo),
("bar", bar),
("baz", bar),
],
)
```
This focuses on the structure of the constraints, and handles the
selector application for the user.
Jack Grigg
ying tong
Dimitris Apostolou