The add_incomplete() and mul() APIs have been removed from the
Point gadget, since we cannot perform incomplete addition or
variable-base scalar multiplication on the identity.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
We were configuring multiple instances of this across all of the advice
columns, in order to spread their assignments. However, we are actually
more constrained by columns than rows, and we have comparatively few
rows of range check logic required for the Action circuit.
We now use a single LookupRangeCheckConfig for the entire circuit. The
reduction in lookup arguments and fixed columns cuts the proof size in
half (now at 6048 bytes when using `floor_planner::V1`).
Co-authored-by: therealyingtong <yingtong@z.cash>
- Move Poseidon into the right-hand advice columns. The Action circuit
has 33 Sinsemilla invocations with 510-bit inputs (the 32 Merkle path
hashes, and Commit^ivk). Poseidon fits within the row count of one of
these invocations, so we can run it in parallel with these.
- Share fixed columns between ECC and Poseidon chips. Poseidon requires
four advice columns, while ECC incomplete addition requires six, so we
could choose to configure them in parallel. However, we only use a
single Poseidon invocation, and we have the rows to accomodate it
serially with fixed-base scalar mul. Sharing the ECC chip's 8 Lagrange
coefficient fixed columns instead reduces the proof size.
- We position Poseidon in the right-most 6 fixed columns, anticipating
a further optimisation to Sinsemilla that will occupy the left-most
2 fixed columns.
- `halo2::plonk::{create_proof, verify_proof}` now take instance columns
as slices of values.
- `halo2::plonk::Permutation` has been replaced by a global permutation,
to which columns can be added with `ConstraintSystem::enable_equality`.
- The introduction of blinding rows means that various tests now require
larger circuit parameters.
In the Orchard protocol, only the NullifierK fixed base in used in
scalar multiplication with a base field element.
The mul_fixed_base_field_elem() API does not have to accept fixed
bases other than NullifierK; conversely, NullifierK does not have
to work with the full-width mul_fixed() API.
At certain points in the circuit, we need to constrain cells in
advice columns to equal a fixed constant. Instead of defining a
new fixed column for each constant, we pass around a single
shared by all chips, that is included in the permutation over all
advice columns.
This lets us load all needed constants into a single column and
directly constrain advice cells with an equality constraint.
In Orchard nullifier derivation, we multiply the fixed base
K^Orchard by a value encoded as a base field element. This commit
introduces an API that allows using a base field element as the
"scalar" in fixed-base scalar multiplication.
The API currently assumes that the base field element is output by
another instruction (i.e. there is no instruction to directly
witness it).
Simplify the canonicity check for variable-base scalar multiplication,
by range-checking the low 130 bits rather than the low 127 bits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Co-authored-by: ying tong <yingtong@z.cash>
Fixed points are represented by precomputed window tables. These
are not "initialized" in the circuit at any single point, but are
loaded into fixed columns at the offsets where the fixed points
are used.
Thus, we don't need FixedPoint and get_fixed() in the circuit.
Similarly, we can remove FixedPointShort and get_fixed_short().