feat: Make commitment key generation configurable with an optional parameter

[huitseeker]

Summary

The size of the public parameters can vary depending on the method used to process them in a later SNARK. In particular, the memory checking techniques used for computational commitments (Spartan paper section 6) requires larger commitment keys.

However, because public parameters are created before any SNARK that might use them, their creation as a Rust object is harder to parametrize. So the size of the commitment key is currently set, for all public parameters, to the more conservative (larger) size required in spartan/ppsnark.rs.

The current PR allows parametrizing public parameter creation with an optional function of the R1CS shape of the circuits: the size of the parameters will be the min of the usual considerations (min of wire /constraint count) and its output. This function can then be provided by SNARKs as an associated function. It allows the mere type definition of the SNARK to convey its special needs in terms of public parameters.

The Spartan instance that does have those special needs now implements this function to convey its extra requirements, letting all other SNARKs enjoy smaller parameters.

In detail

• Implemented the Len trait for CommitmentKey to allow length quantification in terms of group generators. Made ppsnark::RelaxedR1CSSNARK fail setup if given commitment key with insufficient length, as measured by its own commitment_key_floor() (see below)
• Made RelaxedR1CSTrait include a fn commitment_key_floor() -> Box<dyn for<'a> Fn(&'a R1CSShape<G>) -> usize> with default implementation to quantify the Snark's additional commitment key size requirements, in the shape of a closure,
• Made PublicParams take a &dyn for<'a> Fn(&'a R1CSShape<G>) -> usize parameter for each circuit's group, to parametrize the CommitmentKey creation.

Other implementation details:

• defined type alias CommitmentKeyHint<G> = dyn Fn(&R1CSShape<G>) -> usize
• Modified numerous function calls and parameter setups to include parameter CommitmentKeyHint that gives a more flexible commitment key generation.
• Added the CommitmentKeyHint to the r1cs import list and expanded NovaShape trait to optionally accept it.

[CPerezz]

What's the purpose of the optional parameters passed to PublicParams creation?
What's the rationale behind this or what does it enable specifically to do that now is not possible?

[huitseeker]

@CPerezz thanks for the question, I have added a summary to the PR, please let me know if it addresses your concerns fully

[CPerezz]

kk so I see why you need this. But unsure why you can't do it differently:

• Why a trait associated const won't work here? You actually need some input to be able to estimate the lenght of the params needed by Spartan Sec.6? If so, isn't it possible to estimate that beforehand?
• nightly Tracking issue for Fn traits (unboxed_closures & fn_traits feature) rust-lang/rust#29625 is also an option (So using const fn inside trait defs). I understand in any case we might not want to introduce features like this.

I'm just saying this as it looks a bit odd in the API to have this hinting fn when it's only used for this particular Spartan setup. But maybe there's no better way to actually fit this in..

[huitseeker]

@CPerezz

Why a trait associated const won't work here? You actually need some input to be able to estimate the lenght of the params needed by Spartan Sec.6? If so, isn't it possible to estimate that beforehand?

I would love to use a trait constant. But as the current implementation of the computation-committing Spartan should make clear (in this PR, that’s in the commitment_key_floor function), the parametrization depends on the circuit (specifically, it is a function of the R1CS matrices), and that precludes using a constant.

Note that this Spartan variant differs from (and improves on) the literature’s SPARK-based Spartan, but since this was previously implemented in this repo, we can see that even then, the commitment key floor depended on the R1CS matrices, and could not be conveyed by a constant:
https://github.com/microsoft/Nova/pull/152/files#diff-3e805e07997f3ae585e243d1aa4f1e03383e9f64bbad0d619e804f7b1ae7015dR78

I concur with your thinking that depending on unstable nightly features is unwise.

Note: the commitment_key_floor function is a new member of the RelaxedR1CSTrait, but that field has a default implementation. A SNARK that does not use computation commitments requiring a larger commitment key does not have to care about, or implement anything related to this field.

[srinathsetty]

@huitseeker I wonder if the following might be a better solution. Eventually, there will be a trait (e.g., CycleEngineTrait) that specifies G1, G2, etc., which will eliminate unneeded complexity with many type parameters. The same trait could also specify a CompressedSNARK that will be later used to compress the produced IVC proofs. In that case, the setup could just ask the compressedSNARK type to tell its size requirements. Would we still need the modifications in this PR in that world?

[huitseeker]

@srinathsetty The question is a bit theoretical, since CycleEngineTrait doesn’t exist. In this PR, the commitment key sizing hint is passed through several « levels » from front-end to back-end (e.g. PublicParameters, NovaShape, R1CSInstance would be ordered from front to back).
At the top-level, you may be right that an all-inclusive trait may a way to pluck the necessary parameters. On the backend side, I would not advise using such a trait, as its use would prohibit using the defined types with anything but an entire Nova protocol defined. There, the parameters would still need to be passed piecemeal.