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.
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>
Previously `plonk::verify_proof` took an `MSM` as an argument, to enable
batch verification. However, this also required that it take a source of
randomness in order to enforce separation of proofs within a batch. This
made single-proof verification unnecessarily non-deterministic.
We now have a `VerificationStrategy` trait encapsulating the necessary
details, and separate `SingleVerifier` and `BatchVerifier` structs for
the specific variants. Proof verifiers no longer need to create and
manage the `MSM` themselves, and single-proof verifiers no longer need
to supply a source of randomness.
Co-authored-by: Sean Bowe <sean@electriccoin.co>
Previously we were passing through the chunk size and index to each
thread's evaluation context, but this was insufficient for them to
determine whether or not they were processing the final chunk, or if
the final chunk was short. This led to constant and linear term chunks
being created with the full chunk size, even if the last chunk was
short. If this longer-than-short chunk reached the root of the AST, it
triggered a panic in the final `copy_from_slice()`.
The bug was obscured in two ways:
- Currently polynomials always have a power-of-two length, and on CPUs
with power-of-two threads this meant we never produced short chunks.
- The way that subsequent operations like `Ast::Add` were implemented
meant that if a constant or linear term occurred on the right-hand
side of an operation, the longer chunks were masked to the short chunk
length.
We fix this by passing the polynomial length into each thread's context,
so that we can compute the correct length for the final chunk.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
We don't want to provide a generic `map` function, since that would
enable users to arbitrarily alter the value connected to a given cell.
If a new value is being produced, that should either happen outside of
the context of a cell (e.g. intermediate values from witness generation)
or in the context of a newly-assigned cell.
However, in the case of the `Assigned<F>` type, we do need the ability
to evaluate the deferred inversion in some cases (e.g. to then operate
on the bits of the value). So for this `AssignedCell` specialization, we
provide a pass-through `evaluate()` method that otherwise preserves the
cell-value connection.
In zcash/halo2#383 we altered the bounds on region assignment methods
like `Region::assign_advice` to constrain the value closure's result on
`for<'vr> Assigned<F>: From<&'vr VR>` instead of `VR: Into<Assigned<F>>`.
This had the unintended side-effect that `Assigned<F>` could no longer
be returned from the closure, because we were previously relying on the
implicit `impl From<T> for T` provided by Rust, which no longer fits the
bound. This commit adds the missing from-reference impl to restore
functionality, re-enabling inversion deferrment.
Jack Grigg
parazyd
Sean Bowe
Daira Hopwood
ying tong
Dimitris Apostolou