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

Feat(Zeromorph PCS): Add Zeromorph Multilinear PCS Scheme #339

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

PatStiles
Copy link
Contributor

Refactors #66 for new Jolt CommitmentScheme Trait and addresses #249.

@PatStiles PatStiles marked this pull request as draft May 3, 2024 05:10
@PatStiles PatStiles marked this pull request as ready for review May 23, 2024 05:10
Copy link
Collaborator

@moodlezoup moodlezoup left a comment

Choose a reason for hiding this comment

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

This is huge, thank you @PatStiles !!

I'm going to read the zeromorph paper and do another pass tomorrow, but in the mean time here are some nits –– also, it looks like tests are broken after the recent git merge, could you fix those (and the other CI failures)?

Comment on lines 146 to 149
#[cfg(feature = "multicore")]
let iter = self.coeffs.par_iter_mut();
#[cfg(not(feature = "multicore"))]
let iter = self.coeffs.iter_mut();
Copy link
Collaborator

Choose a reason for hiding this comment

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

the multicore feature is a vestigial thing, we should get rid of it entirely

Suggested change
#[cfg(feature = "multicore")]
let iter = self.coeffs.par_iter_mut();
#[cfg(not(feature = "multicore"))]
let iter = self.coeffs.iter_mut();
let iter = self.coeffs.par_iter_mut();

Copy link
Collaborator

Choose a reason for hiding this comment

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

This AddAssign impl is a bit unintuitive, I'd expect adding a scalar to a univariate polynomial to only change the degree-0 coefficient. Maybe move this function to the struct impl and rename it shift_coefficients or something?

}

#[derive(Debug, Clone, Eq, PartialEq, Default)]
pub struct UVKZGPCS<P: Pairing> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit:

Suggested change
pub struct UVKZGPCS<P: Pairing> {
pub struct UnivariateKZG<P: Pairing> {

Comment on lines 191 to 193
fn kzg_verify<P: Pairing>(
vk: &KZGVerifierKey<P>,
commitment: &P::G1Affine,
point: &P::ScalarField,
proof: &P::G1Affine,
evaluation: &P::ScalarField,
) -> Result<bool, ProofVerifyError> {
let lhs = P::pairing(
commitment.into_group() - vk.g1.into_group() * evaluation,
vk.g2,
);
let rhs = P::pairing(proof, vk.beta_g2.into_group() - (vk.g2 * point));
Ok(lhs == rhs)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

let's move this to the UVKZGPCS impl

Comment on lines 133 to 137
let scalars = poly.as_vec();
let bases = pk.g1_powers();
let c = <P::G1 as VariableBaseMSM>::msm(
&bases[offset..scalars.len()],
&poly.as_vec()[offset..],
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's just make the coeffs field on UniPoly pub, so we can avoid these as_vec() calls

Comment on lines 155 to 156
&pk.g1_powers()[..poly.as_vec().len()],
&poly.as_vec().as_slice(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

same thing here

Comment on lines 173 to 174
&pk.g1_powers()[..witness_poly.as_vec().len()],
&witness_poly.as_vec().as_slice(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

...and here

@@ -50,6 +55,49 @@ impl<F: JoltField> UniPoly<F> {
gaussian_elimination(&mut vandermonde)
}

/// Divide self by another polynomial, and returns the
/// quotient and remainder.
pub fn divide_with_q_and_r(&self, divisor: &Self) -> Option<(Self, Self)> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit

Suggested change
pub fn divide_with_q_and_r(&self, divisor: &Self) -> Option<(Self, Self)> {
pub fn divide_with_remainder(&self, divisor: &Self) -> Option<(Self, Self)> {

Comment on lines 20 to 21
#[cfg(feature = "ark-msm")]
use ark_ec::VariableBaseMSM;
Copy link
Collaborator

Choose a reason for hiding this comment

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

we got rid of this feature

Suggested change
#[cfg(feature = "ark-msm")]
use ark_ec::VariableBaseMSM;

.take(num_vars + 1)
.collect();

// offsets of x =
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: delete comment

Comment on lines 212 to 216
.zip(offsets_of_x)
.zip(squares_of_x)
.zip(&vs)
.zip(&vs[1..])
.zip(challenges.iter().rev())
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: use izip! here

transcript: &mut ProofTranscript,
) -> Self::Proof {
let eval = poly.evaluate(&opening_point);
Zeromorph::<P>::open(&setup.0, &poly, &opening_point, &eval, transcript).unwrap()
Copy link
Collaborator

Choose a reason for hiding this comment

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

is there any reason to have this CommitmentScheme impl wrap the struct impl? If not, I'd prefer to get rid of the struct impl

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

2 participants