Change:
Next, it attempts to decrypt the payload with the following procedure: <del> where "sk" is the HPKE secret key.  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.] Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PDA protocol. </del> <ins> where "sk" is the HPKE secret key and "server_role" is the role of the server ("0x01" for the leader and "0x00" for the helper).  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.]  Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PDA protocol. </ins> After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. 3.4.2.1.1. <ins> The leader is required to issue aggregate requests in order, but reports are likely to arrive out-of-order.  The leader SHOULD buffer reports for a time period proportional to the batch window before issuing the first aggregate request.  Failure to do so will result in out-of-order reports being dropped by the helper. 3.4.2.1.2. </ins> The helper state is an optional parameter of an aggregate request that the can helper use to carry state across requests.  At least part of the state will usually need to be encrypted in order to

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.