The theta challenge is used in the lookup argument to compress the
input and table expressions. This can be done fully in the
commit_permuted step, after which the original uncompressed
expressions are no longer needed.
Author: Ying Tong Lai <yingtong@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
`plotters 0.3.3` updated from `font-kit 0.10.0` to `0.11.0`. This is an
internal dependency and ostensibly wouldn't be a breaking change, except
that `font-kit 0.11.0` added a dependency on `yeslogic-fontconfig-sys`
which has additional system dependency requirements. This had the effect
of breaking compilation in a non-breaking release.
However, `font-kit` is only required for `BitMapBackend`, which is not
part of our public API and is only used by some of the `halo2_gadgets`
tests. So we can avoid affecting our downstream users by disabling the
default-enabled features of `plotters`.
The pattern is preserved in one location inside the inner product
argument, where we instead desire to avoid allocations by collapsing
p_prime into itself. Using `+=` here requires both mutable and immutable
borrows simultaneously, and assigning temporaries to avoid this makes
the implementation less clear.
Previously we used the existing `Polynomial::rotate` and
`EvaluationDomain::rotate_extended` APIs to rotate the polynomials we
query at non-zero rotations, and then stored references to the chunks of
each (rotated and unrotated) polynomial as slices. When we reached an
`AstLeaf`, we would then clone the corresponding polynomial chunk.
We now avoid all of this with combined "rotate-and-chunk" APIs, making
use of the observation that a rotation is simply a renumbering of the
indices of the polynomial coefficients. Given that when we reach an
`AstLeaf` we already needed to allocate, these new APIs have the same
number of allocations during AST evaluation, but enable us to completely
avoid caching any information about the rotations or rotated polynomials
ahead of time.
`poly::Evaluator` stores all of the polynomials registered with it in
memory for the duration of its existence. When evaluating an AST, it
additionally caches the rotated polynomials in memory, and then chunks
all of the rotated polynomials for parallel evaluation.
Previously, it stored a polynomial for every unique AST leaf, regardless
of whether that leaf required a rotation or not. This resulted in the
unrotated polynomials being stored twice in memory. However, the chunks
simply refer to slices over cached polynomials, so we can reference the
unrotated polynomials stored in `poly::Evaluator` instead of copies of
them stored in the rotated polynomial `HashMap`. This strictly reduces
memory usage during proving with no effect on correctness.
`BatchVerifier` now manages the entire batch verification process.
Individual proofs are verified on a threadpool, and the resulting MSMs
are then batch-checked as before. The addition of parallelism here
couples with zcash/halo2#608 to make parallelism less fine-grained and
reduce the overhead of multi-threading.
We also set `resolver = "2"` on the workspace; this is the default for
the root package in Rust 2021, but as we use a virtual workspace we need
to explicitly set it instead.
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.
The existing code will fold together a very deep AST that applies Horner's
rule to each gate in a proof -- which could include multiple circuits and
so for some applications will quickly grow such that when we recursively
descend later during evaluation the stack will easily overflow.
This change special cases the application of Horner's rule to a
"DistributePowers" AST node to keep the tree depth from exploding in size.
The published source code for each package needs to include the required
header file, and the path to that header file needs to be relative to
the package source (not the repository source). We therefore need to
have the header file present in each workspace package.
Closeszcash/halo2#506.