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.
This is equivalent to `assert_eq!(mock_prover.verify(), Ok(()))`, but
pretty-prints the verification failures instead of debug-printing them.
In its initial state, it just prints the `Display` impl.
are contained in the table, fixing a performance regression.
This includes an optimization for "fill rows", which are
assumed in this commit to be all-zeros.
closes#398
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
The verifier's check in the inner product argument used to assume that the
G'_0 value had an additional (trivial) blinding factor term, which makes
it slightly easier to reason that it never is the point at infinity.
However, we never sample challenges that are zeroes (both for security
and completeness reasons) so this element would never be the point at
infinity anyway. Thus, we can simplify the check with the added benefit of
matching the book's description of the protocol.
This changes variable names in the multiopen and commitment opening implementations
and the book's protocol description to keep names and indicies consistent with one
another.
Co-Authored-By: Jack Grigg <jack@electriccoin.co>
str4d
Sean Bowe
Daira Hopwood
ying tong
Dimitris Apostolou