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`.
- The crate module structure from `orchard` has been flattened.
- The book pages we want to include in `halo2` have been moved to their
target location, to avoid any conflicts during the merge.
- Common files that already exist in zcash/halo2 have been removed.
therealyingtong
Jack Grigg
Daira Hopwood