Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Purely upstream #94

Merged
merged 222 commits into from
Aug 19, 2022
Merged

Purely upstream #94

merged 222 commits into from
Aug 19, 2022

Conversation

ChihChengLiang
Copy link

This makes pse/main even with upstream. None of our changes is included. The intention is to keep our changes in #84 and the build #84 on top of the evened pse main.

3for and others added 30 commits September 18, 2021 18:38
In zcash#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.
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.
* use biimplication in the correctness argument to ensure both soundness and completeness;
* avoid introducing lambda at all; it's unnecessary and omitting it shortens the explanation.

Co-authored-by: Jack Grigg <[email protected]>
Signed-off-by: Daira Hopwood <[email protected]>
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 <[email protected]>
Add hardcoded proof to plonk_api test
halo2_proofs: rename variables for consistency
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.
str4d and others added 21 commits June 22, 2022 19:33
This means we only compute the degree in a verification context during
construction, instead of twice per proof in the permutation argument.
Cache values in `VerifyingKey` that can be computed on construction
`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#608 to make parallelism less fine-grained and
reduce the overhead of multi-threading.
Rework `halo2_proofs::plonk::BatchVerifier`
They are in code generated by macros from the `uint` crate, that we
can't do anything about from here.
Place `halo2_proofs::plonk::BatchVerifier` behind a (default enabled) crate feature called `batch`.
This is because "degree bound" is often defined to be exclusive.

Signed-off-by: Daira Hopwood <[email protected]>
@ChihChengLiang
Copy link
Author

To review this PR, check it has no diff with 8ff5b1e

@han0110
Copy link

han0110 commented Aug 19, 2022

Confirmed no changes with 8ff5b1e.

@ChihChengLiang ChihChengLiang marked this pull request as ready for review August 19, 2022 04:13
@ChihChengLiang ChihChengLiang mentioned this pull request Aug 19, 2022
1 task
@ChihChengLiang ChihChengLiang merged commit 2a19e44 into main Aug 19, 2022
jonathanpwang added a commit to axiom-crypto/halo2 that referenced this pull request Nov 9, 2022
REVERT: 1eddf54c Merge pull request privacy-scaling-explorations#94 from zkcrypto/trait-constants
REVERT: 6bf93ee5 Use associated constants of type `Self` in `Field` and `PrimeField`
REVERT: 9a844a72 Merge pull request privacy-scaling-explorations#93 from zkcrypto/field-trait-changes
REVERT: cc08c5ee Document that `Field::{sqrt, sqrt_alt}` provided impls use `sqrt_ratio`
REVERT: 58741b76 Add `ff::Field::{sqrt_ratio, sqrt_alt}`
REVERT: a35b5eb5 Merge pull request privacy-scaling-explorations#92 from zkcrypto/release-0.12.1
REVERT: b97576cf Add `ff::Field::pow`
REVERT: b98ca7f7 Release 0.12.1
REVERT: 7653f345 Merge pull request privacy-scaling-explorations#88 from GaloisInc/checked_shr
REVERT: 732b862b add test case
REVERT: 22bc4997 Update ff_derive/src/lib.rs
REVERT: 9ea208df Merge pull request privacy-scaling-explorations#83 from eqlabs/allow_clippy_on_mont_reduce
REVERT: bb379984 Use `checked_shr` instead of `>>` in `Field::random`
REVERT: 6a1c1e90 chore(derive): allow too_many_args at mont_reduce

git-subtree-dir: ff
git-subtree-split: 9b9a8d9c363ecbf7bb4c79998aaed32c1f8ce027
iquerejeta added a commit to input-output-hk/halo2 that referenced this pull request May 8, 2024
…hk/dev-fix/change-asserts-to-debug_asserts-unless-invariant-check

Add documentation for Duplex asserts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.