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

Prover code for permutation argument #485

Merged
merged 2 commits into from
Feb 16, 2022
Merged

Prover code for permutation argument #485

merged 2 commits into from
Feb 16, 2022

Conversation

dlubarov
Copy link
Contributor

It's slightly complex because we batch constraint_degree - 1 permutation arguments into a single Z polynomial. This is a slight generalization of the technique described in the Halo2 book.

Without this batching, we would simply have num_challenges random challenges (betas and gammas). With this batching, however, we need to use different randomness for each permutation argument within the same batch. Hence we end up generating batch_size * num_challenges challenges for all permutation arguments.

@dlubarov dlubarov requested a review from wborgeaud February 13, 2022 23:02
Copy link
Contributor

@wborgeaud wborgeaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me otherwise!

Comment on lines 218 to 258
/// Compute a single Z polynomial.
fn compute_z_poly<F: Field>(
instance: PermutationInstance<F>,
trace_poly_values: &[PolynomialValues<F>],
) -> PolynomialValues<F> {
let PermutationInstance { pair, challenge } = instance;
let PermutationPair {
lhs_columns,
rhs_columns,
} = pair;
let PermutationChallenge { beta, gamma } = challenge;

let degree = trace_poly_values[0].len();
let mut reduced_lhs = PolynomialValues::constant(gamma, degree);
let mut reduced_rhs = PolynomialValues::constant(gamma, degree);

let both_cols = lhs_columns.iter().zip_eq(rhs_columns);
for ((lhs, rhs), weight) in both_cols.zip(beta.powers()) {
reduced_lhs.add_assign_scaled(&trace_poly_values[*lhs], weight);
reduced_rhs.add_assign_scaled(&trace_poly_values[*rhs], weight);
}

// Compute the quotients.
let reduced_rhs_inverses = F::batch_multiplicative_inverse(&reduced_rhs.values);
let mut quotients = reduced_lhs.values;
batch_multiply_inplace(&mut quotients, &reduced_rhs_inverses);

// Compute Z, which contains partial products of the quotients.
let mut partial_products = Vec::with_capacity(degree);
let mut acc = F::ONE;
for q in quotients {
partial_products.push(acc);
acc *= q;
}
PolynomialValues::new(partial_products)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something, but it seems like this could be done over batches of quotient_degree_factor instances.

If I understand correctly, this does (in the case of two lhs columns l_0, l_1 and two rhs columns r_0, r_1):

Z(gx) = Z(x) * (gamma + l_0 + beta * l_1) / (gamma + r_0 + beta * r_1)
=>
Z(gx) * (gamma + r_0 + beta * r_1) - Z(x) * (gamma + l_0 + beta * l_1) = 0.

This last constraint is of degree 2, whereas the vanishing polynomial can be of degree up to 3 (with rate_bits=1).

So it seems like having Z take batches of quotient_degree_factor instances would yield a constraint of degree constraint_degree, and would result in fewer Z polynomials.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, that was my intention but I forgot to actually implement the batching logic here. I'll just merge the non-batch version for now, as I'm not sure when I'll have time to finish this and want to minimize conflicts, but I added a TODO and I'll come back to this when I have a chance.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good 👍

@dlubarov dlubarov force-pushed the permutation_pairs branch 2 times, most recently from e8df217 to 33d1e03 Compare February 16, 2022 08:34
It's slightly complex because we batch `constraint_degree - 1` permutation arguments into a single `Z` polynomial. This is a slight generalization of the [technique](https://zcash.github.io/halo2/design/proving-system/lookup.html) described in the Halo2 book.

Without this batching, we would simply have `num_challenges` random challenges (betas and gammas). With this batching, however, we need to use different randomness for each permutation argument within the same batch. Hence we end up generating `batch_size * num_challenges` challenges for all permutation arguments.
@dlubarov dlubarov force-pushed the permutation_pairs branch 4 times, most recently from 6e9e1ea to dc91ca2 Compare February 16, 2022 09:14
@dlubarov dlubarov merged commit 72d13d0 into main Feb 16, 2022
@dlubarov dlubarov deleted the permutation_pairs branch February 16, 2022 16:38
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.

None yet

3 participants