Change:
corresponding to a unique client report.  Sub-requests are structured as follows: <del> The "helper_share" field is the helper's encrypted input share as it appeared in the report uploaded by the client.  [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The "time" field should match the timestamp of the corresponding report.  The </del> <ins> The "time" and "jitter" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report. [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The </ins> remainder of the structure is dedicated to the protocol-specific <del> helper share and request parameters used for the current round. </del> <ins> request parameters. In order to provide replay protection, the leader is required to send aggregate sub-requests in ascending order, where the ordering on sub- requests is determined by the algorithm defined in anti-replay. Specifically, the leader constructs its request such that: * each sub-request follows the previous sub-request; and * the first sub- request follows the last sub-request in the previous aggregate request. </ins> The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PDA parameters "PDAParam" for which "PDAAggregateReq.task_id" is equal to the task ID derived from <del> "PDAParam". </del> <ins> "PDAParam".  It then filters out out-of-order sub-requests by ignoring any sub-request that does not follow the previous one (See anti-replay.) </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Discussion:
For privacy reasons, leaders should not be allowed to replay a given report more than once within the context of a single batch. The current verify+collect model runs in a "streaming mode," wherein the leader sends slices of batch shares to helpers for verification and aggregation. If we changed this to require the leader to send all batch shares in a single verify+collect flow, then replay prevention would be simpler: just scan the list and check for dupes. If we stick with the current model, then the helper must necessarily store some state (on the leader, most likely) representing the shares processed. This state could then be consulted when asked to verify+collect any new share. (We can probably spell out a number of ways to do store this state, but ideally it should not be linear in the number of shares collected so far.) We'd likely also need a way for the leader to request that the helper produce the final aggregate output once the batch is "done" being verified and collected.
One downside to this approach is that it requires the leader to queue up the entire batch of reports before sending the first aggregate request to the helper. This may be OK for some deployments, but it might not be workable for all. I think this is worth pursuing. This is already in the protocol. (See "output share request".)
We could require that the leader feed the helper reports with monotonically increasing timestamps, such that the helper can simply maintain a single timestamp and reject any report older than that. However I'm not sure if that's practical given that clients may submit reports out of order.
One intermediate option would be to maintain a jitter buffer on the leader, so that they keep reports for a few minutes and then feed them out in order. You would still lose some reports, but not too many.
I have a few questions but nothing blocking.