Use a single committer_key and fft_precomputation for batch of proofs

[vicsn]

Motivation

To reduce memory and computation for batch proofs, we should only have to use a single committer_key and fft_precomputation for the biggest circuit of a batch proof. Previously we were computing these for every circuit. For a large batch this reduces the size of the ProvingKey by around 40%. We also don't need CommitterUnionKey anymore which was collecting the union of the committer keys.

Test Plan

The existing test suite seems to suffice.

[Pratyush]

I think we should change the API of to_universal_prover to take in a struct (maybe DegreeInfo?) containing the relevant information; as it stands we're just extracting some usizes from other structs and then passing these into to_universal_prover, which is creating a lot of repetition and room for errors stemming from accidentally switching the order of arguments.

[vicsn]

I think we should change the API of to_universal_prover to take in a struct (maybe DegreeInfo?) containing the relevant information; as it stands we're just extracting some usizes from other structs and then passing these into to_universal_prover, which is creating a lot of repetition and room for errors stemming from accidentally switching the order of arguments.

Agreed, in the past I also lost half an hour testing a bug caused by false ordering. 3383c94

Also worth noting: I renamed max_domain_size to max_fft_size because that is the only thing we use that particular domain/degree for at the moment.

[iamalwaysuncomfortable]

Made some comments about the web/wasm targets. The tl;dr of it is that I conjecture that web & wasm targets will make up an outsized portion of users proving with Aleo's implementation of Varuna (people like to use JavaScript, Rust is difficult for most application developers).

Therefore that there should be some asynchronous parameter download methods baked into enclosing structs which construct the UniversalProver & Universal verifiers. An example method for which to fetch these parameters is proposed here: https://github.com/AleoHQ/snarkVM/pull/1987/files#diff-d907035b6432d9b2ef95015b23710393694a19b111dfffc195499ff3da02c3bcR112-R126

This PR provides good decoupling and actually will make it easier to get parameters on the web, but we should ensure we include it so that web developers are fully supported prior to mainnet.

[vicsn]

Made some comments about the web/wasm targets. The tl;dr of it is that I conjecture that web & wasm targets will make up an outsized portion of users proving with Aleo's implementation of Varuna (people like to use JavaScript, Rust is difficult for most application developers).

Therefore that there should be some asynchronous parameter download methods baked into enclosing structs which construct the UniversalProver & Universal verifiers. An example method for which to fetch these parameters is proposed here: https://github.com/AleoHQ/snarkVM/pull/1987/files#diff-d907035b6432d9b2ef95015b23710393694a19b111dfffc195499ff3da02c3bcR112-R126

This PR provides good decoupling and actually will make it easier to get parameters on the web, but we should ensure we include it so that web developers are fully supported prior to mainnet.

For other reviewers reading this, we talked about it elsewhere and for now this PR can stay as is - PR #1987 will be rebased on this one.

[Pratyush]

I think we should roll supported Lagrange sizes and hiding_bound also into DegreeInfo

[vicsn]

I think we should roll supported Lagrange sizes and hiding_bound also into DegreeInfo

I would vote against that because we have tests which generate lagrange_sizes/hiding_bound independently from CircuitInfo. Both ways of doing does not seem obviously better and does not seem worth the (minor) refactor:

1. let CircuitInfo::degree_info() return an unfinished mutable DegreeInfo, which we then populate with lagrange_sizes and hiding_bound. This makes DegreeInfo less clean of an object and is not less prone to errors.
2. get max_degree/max_fft/degree_bounds separately from CircuitInfo and compose DegreeInfo outside of CircuitInfo. This regresses in terms of complexity, as the developer has to order the arguments correctly.

[Pratyush]

In any real world use case, CircuitInfo completely determines DegreeInfo. In tests, we should be mutating DegreeInfo to change lagrange_sizes and hiding_bound.

Also, the maximum supported degree of the SRS can depend on whether or not the committed polynomials are hiding. So logically hiding_bound affects circuit_info anyway.

[Pratyush]

I would also be fine if to_universal_prover always output all the SRS elements that correspond to hiding (This is fine, as there's only a small number of them). I just don't want there to be a knob that the user can forget to turn that suddenly means that there's no hiding.

[vicsn]

That makes sense, looks a lot cleaner now, also removed the Default which could lead to 0 hiding bound. f17ce31

[Pratyush]

LGTM modulo couple of small changes

[ljedrz]

I see that we can no longer keep UniversalProver as a 'static, but what about the UniversalParams? those could likely be made 'static so that we don't need to load them for every call to ProvingKey::{prove, prove_batch}

[vicsn]

Good idea! This would be a somewhat involved change so not sure I can get it in before the code freeze, will tackle in a new PR.

Currently, every time we create a proof, we indeed create UniversalParams and grow this according to the circuit size. For a simple transfer it grows to ~ 50MB. But it could grow to gigabytes. If we were to make the object static, we'll also need to add a method to shrink the parameters to our minimum parameter size (~ 10MB) so they don't take up memory forever.

[ljedrz]

LGTM with a suggestion regarding UniversalParams