Have Vdaf.prep_init() output first round prep share

[cjpatton]

Closes #60.

Now that we have defined DAFs explicitly and removed the public
parameter, there is no longer a need to support 0-round VDAFs. This
change codifies the requirement that ROUNDS >= 1 in the syntax.

[schoppmp]

Is there a reason for requiring at least one verification round? I don't think it's immediately clear why the verification can't be non-interactive (e.g., the client provides separate NIZK proofs to each party).

[cjpatton]

Is there a reason for requiring at least one verification round? I don't think it's immediately clear why the verification can't be non-interactive (e.g., the client provides separate NIZK proofs to each party).

I agree it's not immediately clear. However, in particular for NIZKs I think the prover would need a public key, right? In fact, the draft-00 anticipated adapting something like https://isi.jhu.edu/~mgreen/advertising.pdf into a 0-round VDAF. Such a scheme would have used the public parameter to encode one of the Aggregator's public key (whoever does the verifying).

The downside to making room for this hypothetical construction is extra complexity for applications: see #60 (comment). At this point, my feeling is if we wanted to a VDAF that uses some form of public key crypto, it ought to be considered a different kind of object. Especially since it's likely to have different applications.

If someone comes along with a 0-round VDAF that doesn't use public key crypto, perhaps it would fit more or less into the new DAF syntax?

[schoppmp]

I'm not sure we should exclude VDAFs based on public-key cryptography. I was under the assumption that the issue with the public parameter was that it would need to be frequently rotated. Even without it, I can imagine a spec for a VDAF that has some out-of-band mechanism of retrieving public keys.

In your linked comment, both solutions don't look very complex to me... Is there maybe a way to have the simpler interface you propose in #60 without prescribing at least one communication round between aggregators?

[cjpatton]

I'm not sure we should exclude VDAFs based on public-key cryptography. I was under the assumption that the issue with the public parameter was that it would need to be frequently rotated. Even without it, I can imagine a spec for a VDAF that has some out-of-band mechanism of retrieving public keys.

I'm not suggesting we exclude this, I'm merely suggesting it can be treated as a different type of primitive, perhaps defined in this draft. Call it a PK-VDAF or something :)

In your linked comment, both solutions don't look very complex to me... Is there maybe a way to have the simpler interface you propose in #60 without prescribing at least one communication round between aggregators?

Maybe! We can hold off on merging this if you want to spend some time thinking about it.

[cjpatton]

FWIW, translating the vdaf-00 syntax into a Rust API unearthed at least one nasty edge case: In some applications it'll be necessary to serialize the Prepare state. (Concretely, consider a DAP helper, who needs to carry state across HTTP requests during the aggregation flow.) However it is never the case that you need to serialize the first state, since you immediately consume it to get the next output bound prep share. See divviup/libprio-rs#218 for details.

[schoppmp]

I'm not sure we should exclude VDAFs based on public-key cryptography. I was under the assumption that the issue with the public parameter was that it would need to be frequently rotated. Even without it, I can imagine a spec for a VDAF that has some out-of-band mechanism of retrieving public keys.

I'm not suggesting we exclude this, I'm merely suggesting it can be treated as a different type of primitive, perhaps defined in this draft. Call it a PK-VDAF or something :)

What I mean is that VDAF should include any DAF that has a verification procedure, even if it's public-key or zero-round. Otherwise I'd worry that standards like DAP could over-optimize towards particular VDAFs and for example be incompatible with your proposed "PK-VDAF" or non-interactive verification. So in overall I'd prefer generality when it comes to the VDAF interface, to ensure compatibility of various VDAFs that might be developed in the future with the DAP infrastructure that is being developed right now.

However it is never the case that you need to serialize the first state, since you immediately consume it to get the next output bound prep share.

I can see that this is a bit inefficient, although I don't think this will be a bottle neck in terms of performance. I guess one possibility would be to allow for an OPTIONAL combined function, but that seems like premature optimization to me.

[cjpatton]

I'm not suggesting we exclude this, I'm merely suggesting it can be treated as a different type of primitive, perhaps defined in this draft. Call it a PK-VDAF or something :)

What I mean is that VDAF should include any DAF that has a verification procedure, even if it's public-key or zero-round. Otherwise I'd worry that standards like DAP could over-optimize towards particular VDAFs and for example be incompatible with your proposed "PK-VDAF" or non-interactive verification. So in overall I'd prefer generality when it comes to the VDAF interface, to ensure compatibility of various VDAFs that might be developed in the future with the DAP infrastructure that is being developed right now.

Agreed, we absolutely want to plan for other applications beyond DAP (and even potentially PPM). From this perspective, I wonder if you feel like #62 was a regression after all? The concern would be that the syntax for input-share generation no longer includes an explicit public key.

#62 solved a specific problem, which is to allow DAP to rotate the verification parameters without having to push a new public parameter to the clients. The need to do so is inherent to a potential public-key VDAF, but not to the VDAFs we have today. The natural question to ask ourselves here is: At what point do we specialize syntax for specific classes of constructions?

So far we have addressed this question on a case-by-case basis, which I think is right. My rule of thumb is basically: "specialize as soon as the generalization creates a rough edge". In the case of #62, the rough edge was key distribution having different requirements for public-key and non-public-key schemes. Were we to add support for the latter into DAP, I think it would make sense to consider this an alternative "mode of operation" for the protocol.

However it is never the case that you need to serialize the first state, since you immediately consume it to get the next output bound prep share.

I can see that this is a bit inefficient, although I don't think this will be a bottle neck in terms of performance. I guess one possibility would be to allow for an OPTIONAL combined function, but that seems like premature optimization to me.

I agree that would be premature, and to be honest this isn't a problem we need to solve in the VDAF spec. It would be sufficient to make a note about this somewhere, e.g.:

Implementation note: For VDAFs with one round or more, it is necessary in some applications to serialize the Aggregator's Prepare state so that it can be stored while the Aggregator awaits a prepare message from the network. However it is not necessary to serialize the output of `prep_init()`, but only the output of of `prep_next()`.

[cjpatton]

Closed in favor of #78.