This is necessary because the blinding factor r can be zero with greater
than negligible probability in an adversarial case, which with incomplete
addition would cause the circuit to compute a commitment that is not on
the curve.
Previously, fixed_y_q was a non-binary selector that both loaded
the y_Q value and toggled the y_Q gate.
Now, the gate is toggled by a q_s4 simple selector, while the value
is loaded into a separate fixed column.
The Sinsemilla chip witnesses message pieces in individual regions, and
then copies them into the `hash_piece` region to initialize the running
sum. Previously these occured in the same column, but we can reduce the
utilized rows of the Action circuit by moving these into a less-used
column.
If https://github.com/zcash/halo2/issues/334 is implemented, this change
would be unnecessary, as the witnessed message piece regions would never
be assigned into the circuit.
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.
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.
This has three const generic parameters: PATH_LENGTH, K, MAX_WORDS.
PATH_LENGTH is the length of the Merkle path being hashed. K and
MAX_WORDS parameterize the internal Sinsemilla instance used in
hashing the path.
These instructions were not making any assignments; instead, they
were calling through to witness_message_piece_field().
This PR also renames the witness_message_piece_field() instruction
to witness_message_piece().
This defines a Sinsemilla message in terms of pieces and subpieces.
This is useful when decomposing field elements and packing them
into K-bit messages.
SinsemillaInstructions has two const generic parameters: K, which
is the number of bits in each word of the hash, and MAX_WORDS,
which is the maximum number of words the hash can process.
For Orchard, K = 10, MAX_WORDS = 253.
Jack Grigg
Daira Hopwood
therealyingtong