-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify aggregate verification #67
Conversation
// zero key & single hash should fail | ||
if n_hashes == 1 && public_keys[0].0.is_identity().into() { | ||
// zero keys should always fail. | ||
if public_keys.iter().any(|pk| pk.0.is_identity().into()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason to not check these up-front. We could check them in parallel later, but we already have an n^2
loop so this shouldn't have an appreciable impact on performance. Really, dropping the atomics will likely increase performance (even when taking relaxed ordering into account).
if res.is_err() { | ||
valid = false; | ||
break; | ||
if pairing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really not sure why the previous code was written with the valid
boolean that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it;'s definitely goofy. I'm guessing that this function was originally using combinators rather than for
loops.
6dc60e3
to
b408255
Compare
This comment was marked as resolved.
This comment was marked as resolved.
8962922
to
b408255
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I'd like to have another pair of eyes on it (@DrPeterVanNostrand maybe?).
Mostly remove all cases where we'd need to track a "valid" boolean and/or atomic: - Check that all there are no zero keys up-front in `verify`. - Use fallible mapping/reducing in `verify_message` instead of a "valid" boolean. - Use rayon's "reduce with" feature which should allow parallel processing?
b408255
to
19d735a
Compare
Mostly remove all cases where we'd need to track a "valid" boolean and/or atomic:
verify
.verify_message
instead of a "valid" boolean.This patch isn't necessary in any way, I just wrote it as I reviewed the code. I figured I'd submit it as it does simplify things a bit, IMO.