Consider generalizing num_shares in Flp interface

[junyechen1996]

Under Flp interface, the APIs contain a parameter num_shares which seems to be something useful in certain FLP constructions, e.g., FLPs that need to normalize a constant if it's not multiplied with a secret-shared variable. I wonder if this parameter can be more generic to tailor the need for each FLP. Some use cases that may benefit from this:

• Avoid re-computation of variables that stay the same in each FLP proof in multiproof setting. In Prio3: Consider using a smaller field and re-running the proof verification multiple times #177 and Align draft with POC for multiproof changes #305 , the VDAF spec added support to allow a VDAF to run multiple proofs of its FLP to improve robustness. Inside the eval() function used by both prove() and query(), the FLP may compute "some variables" locally, which will then be fed as inputs to gadgets. Those variables don't change within each proof, so the VDAF may choose to compute those variables once, and feed them to each FLP's proof repetition to save computation time. Examples include the sum_check variable in Prio3Histogram, which only needs to be computed once, and stays the same for all FLP proof repetitions.

• FLPs that prefer to sample random values from a seed directly, instead of passing the random values as field elements in joint_rand to prove() and query(). The benefit include: (1) if the FLP uses a large number of field elements, it may prefer to sample the field elements on the fly instead of keeping all field elements in memory. (2) If the FLP prefers to not use field elements to represent its random values, (e.g., it may only want to sample binary values), so it's more convenient for FLP to sample from a random buffer directly, e.g., by looking at the random buffer bit by bit.

Perhaps we can generalize today's num_shares parameter to a FLP-specific struct to support these use cases? Note this won't be wire breaking to the VDAF interface, but improves the flexibility of the integration between VDAF and FLP.

[cjpatton]

This sounds like a useful improvement to me. I'm imagining something like an associated type for the Valid API. Call it something like Context, or EvaluationParam?

[junyechen1996]

I realized there is not enough motivation to complicate the spec with this change right now, so closing it.