I think the digest computations removed in 9f9d45c are there so that applications (like Lurk) can generate accurate cache keys for public parameters. In particular, we need to invalidate caches whenever circuits change.

I think the digest computations removed in 9f9d45c are there so that applications (like Lurk) can generate accurate cache keys for public parameters. In particular, we need to invalidate caches whenever circuits change.

R1CSShape is an internal type that isn't exposed, I don't think, to users of Nova. If so, how will Lurk determine when the R1CS digest changes? The public parameters type still has a digest field. Please let me know if I misunderstood the intended usage of digest field on R1CSShape type.

I think the digest computations removed in 9f9d45c are there so that applications (like Lurk) can generate accurate cache keys for public parameters. In particular, we need to invalidate caches whenever circuits change.

R1CSShape is an internal type that isn't exposed, I don't think, to users of Nova. If so, how will Lurk determine when the R1CS digest changes? The public parameters type still has a digest field. Please let me know if I misunderstood the intended usage of digest field on R1CSShape type.

Please open an issue and/or a PR (or reply here) if the digest on R1CS is still required.

On this PR

[#229] makes the verifier compute digests on its own

I am not sure that I understand this statement with precision. In #229, as in prior behavior, both spartan::snark and spartan::ppsnark exit the setup() function with a verifier key which digest is computed and populated (that is, the OnceCell it contains is set). That is because the digest of the VerifierKey needs to be populated in the Proverkey. There is no digest re-computation involved past that point: further .digest() calls resolve to a simple getter.

The difference introduced in #229 is that should the VerifierKey in question then be serialized and deserialized, the first access of the digest() would need to recompute it. This is so that it's not possible to pass the verifier a struct with a digest that doesn't match the associated contents of the verifier key.

In other terms, in order for this line:

Are you saying that for the verifier to be passed a VerifyingKey which digest works for the purpose of the FS heuristic, but contains a wrong parameter (e.g. a wrong num_cons, an incorrect basis in the evaluation engine's verifier key) is ok? If not, then shouldn't that line involve a digest re-computation anyway?

On R1CS digests

• the R1CSShape type is part of the Nova public API, through e.g. RelaxedR1CSSNARKTrait,
• by and large, the Nova Public parameters are not universal, due to the embedded R1CSShape dependent items it contains. Everything else is: the constants are the same from one proof to another, and the only constrain on CommitmentKeys is that they be of sufficient sizes for the proof at hand. Having separate digests for the universal and circuit-specific portions of the logic is useful.