CCS implementation

[sjudson]

This PR implements the Customizable Constraint System (CCS) independently of the R1CS implementation, up to extracting the sparse matrix implementation so both can use it, and support for an R1CS -> CCS conversion:

let ccs_shape = CCSShape::from(r1cs_shape);

Todo:

• Implement CCS
• Implement Linearized CCS

[slumber]

@sjudson do you want to push lccs implementation to this branch? Alternatively, we can merge it in this state.

What's the 2nd step in PR description about implementing CCCS? I believe it's already there

nexus-zkvm/supernova/src/ccs/mod.rs

Lines 177 to 182 in 3873380

	pub struct CCSInstance<G: CurveGroup, C: CommitmentScheme<G>> {
	/// Commitment to witness.
	pub commitment_W: C::Commitment,
	/// X is assumed to start with a `ScalarField::ONE`.
	pub X: Vec<G::ScalarField>,
	}

(Regarding additional C in the type name: similar to R1CSInstance which is in fact committed and we just imply this without naming it CR1CSInstance. Note that spartan code on the other hand calls it CR1CS, but we could try to be consistent at least within the supernova crate)

[tess-eract]

good work! my only comments that affect correctness/performance are a) swapping i and j in the matrix_to_mle function, and b) avoiding using mle_to_mvp, working with eval vectors rather than coefficient vectors everywhere. the rest are suggestions, and more or less a matter of taste.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nexus-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 28, 2024 9:19pm

[tess-eract]

When we implement CycleFold, we'll also need to consider CCS instances over the secondary field. The commitments for these will just be Pedersen commitments, not coming from a polynomial commitment scheme. (KZG-style commitments won't exist for the secondary curve, because it doesn't support pairings). On the other hand, it is indeed important - for compression - that the commitment scheme for the primary curve does come from a PCS. In the nova repo, we define everything in terms of vector commitment schemes, and then to create the "compressible" version, we coerce the PCS for the primary field into a vector commitment scheme. Another approach would be to just define separate types, e.g. CCSInstanceSecondary<G: CurveGroup, C: CommitmentScheme<G>> - it's a bit redundant, but maybe cleaner.

[tess-eract]

Putting the other type definitions (CCSInstance etc.) above the impls might improve readability.

[tess-eract]

i and j should be swapped here: later, we will call fix_variables to get
the combination of the rows of M, it will bind the log_m lowest-order
bits.

I don't think this function is needed anymore. spartan uses a different method of turning sparse matrices into polynomials that's specialized for its "computational commitments". ;

[tess-eract]

To ensure endianness compatibility with sumcheck, we need to ensure that the polynomial P(v): DenseMultilinearExtension that we pass to ark-ml-sumcheck later on satisfies P(v).evaluate(r) == vec_to_mle(v).evaluate(r). The evaluate() function for DenseMultilinearExtension is little-endian, i.e. the first variable is encoded by the least significant bit of the index. That's the opposite of how evaluate() works on spartan's DensePolynomial, so we either need P(v) = DenseMultilinearExtension::from_coefficients_vec(v.rev_bits()) xor we need vec_to_mle(v) = DensePolynomial::new(v.rev_bits()). Since both of these maps use clones anyway, it shouldn't be more expensive to reverse the bits.