Feat/Switch Spartan Backend to Use Goldilocks Field #17
Conversation
Just delete unused code. We can get it back from the git history. At most you want to leave a comment that tells people what used to be there, and to check in the git history for details. |
We are cleaning up a lot in #17 Here we extract some of that cleanup, to make that other PR easier to review.
|
Currently, there are some compilation failures in |
* Delete all the things We are cleaning up a lot in #17 Here we extract some of that cleanup, to make that other PR easier to review. * Delete more
| pub struct ZKSumcheckInstanceProof<S: SpartanExtensionField> { | ||
| proofs: Vec<DotProductProof<S>>, | ||
| } |
There was a problem hiding this comment.
In our usage of spartan, we don't care about zero knowledge property. Moreover, it's also difficult to build zero knowledge sumcheck protocol based on hash function. Therefore, we can get rid of (i.e. remove) types like ZKSumcheckInstanceProof and only keep SumcheckInstanceProof.
|
I'm a bit concerned about eliminating all the function parameters and struct fields related to commitments because, well, we'll have to add them back in later when we connect it to our own PCS. I see the codebase provides a trait for commitment scheme, and a mock implementation for this trait. Isn't it simpler to just switching to the mock implementation, and only deleting the ECC-based implementations? |
The mock commitment seems to still be based on pairing. Notably there's a trait bound |
I see. The commitment scheme trait, and the implementations, aren't actually used at all. |
| /// Inner Goldilocks extension field | ||
| type InnerType: ExtensionField + Field; |
There was a problem hiding this comment.
It's pretty cumbersome to access its base field via <S::InnerType as ExtensionField>::BaseField, right?
There was a problem hiding this comment.
We need to use BaseField in a lot of places for performance. For example, the type of each cell's value in the R1CS matrices must belong to the base field.
| row: usize, | ||
| col: usize, | ||
| val: Scalar, | ||
| val: S, |
There was a problem hiding this comment.
If S itself extends the ExtensionField trait, then val's type should be S::BaseField. Otherwise, we need to use this cumbersome expression <S::InnerType as ExtensionField>::BaseField.
| let gens = DotProductProofGens::new(right.pow2(), label); | ||
| PolyCommitmentGens { gens } | ||
| } | ||
| Z: Vec<S>, // evaluations of the polynomial in all the 2^num_vars Boolean inputs |
There was a problem hiding this comment.
Need be more flexible to allow DensePolynomial to store either base elements or extension elements like https://github.com/scroll-tech/ceno/blob/master/multilinear_extensions/src/mle.rs#L163 did in ceno repo.
| ts * r_hash_sqr + val * r_hash + addr | ||
| }; | ||
| let r_hash_sqr = *r_hash * *r_hash; | ||
| let hash_func = |addr: &S, val: &S, ts: &S| -> S { *ts * r_hash_sqr + *val * *r_hash + *addr }; |
There was a problem hiding this comment.
This closure can be boosted by by changing the type of addr, ts from S to S::BaseField as extension field element multiply by base field element e*b (https://github.com/scroll-tech/ceno-Goldilocks/blob/master/src/extfield.rs#L24) is much faster than e * e
|
The features not included in this pr are tracked below |
Completed in this PR:
ristretto255scalar field definition. Use newgoldilocksScalarimpl.ceno-goldilocksrepo.Scalarfield struct to a generic.Scalaroperations and checks will be preserved.Scalar Checks Debugging progress:
[Done]
ProductCircuitEvalProofBatched->fn verify: 1 check[Done]
HashLayerProof->fn verify_helper: 4 checks[Done]
HashLayerProof->fn verify: 1 check