It's essential to be able to separate the lifetime of the batch item from the
lifetime of associated data (in this case, the message). The previous API did
this mixed in to the Tower implementation, but it was removed along with that
code.
Making the `queue` function take `I: Into<Item>` means that users who don't
care about lifetimes just need to wrap the function arguments in an extra
tuple.
This changes the `VerificationRequest` type alias (now called `batch::Request`)
to an enum containing either a verification request or a request to flush the
batch. This allows both automatic and manual control of batch sizes, either by
setting a low batch limit on service creation or by setting a high limit and
manually sending flush commands.
To keep things ergonomic, the `Request` enum now has a `impl From` the previous
tuple, so to send a request, all that's necessary is to assemble a
pubkey-sig-message tuple and call `.into()` on it.
This will hopefully allow things like building a Tower layer with a timeout and
a retry policy that retries timed out requests (not a big enough concurrent
batch) with singleton verification, or retries a failed batch by falling back
to singleton verification to detect which element of a batch failed.
However, there are still some rough spots in the API, and it's not clear that
manually dropping the service is an adequate way to flush requests (see comment).
This implements the last suggestion in the previous commit message: the
verification service maintains a target batch size and periodically flushes
signature verification requests after reaching that many pending requests.
Requests can be manually flushed by dropping the service. In contrast to
flushing requests by calling an inherent method, this approach has the
advantage that the verification service can be wrapped in other tower
middleware without losing functionality (drops propagate through wrapped
services).
This approach still does not impose any maximum latency on verification
requests, but it seems potentially better to leave that out of scope for the
verification service itself, as consumers wishing to have latency bounds can do
so using a timeout layer, perhaps with a retry policy that does singleton
verification after a timeout, etc.
In fact the speedup can be slightly greater than the 2x predicted, because
although the multiexp is half the size, the remaining half has 128-bit scalars
instead of 256-bit ones.
Christian Poveda
Henry de Valence