-
Notifications
You must be signed in to change notification settings - Fork 175
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
bindings/rust: implement MultiPoint for [Signature] and [PublicKey] #226
bindings/rust: implement MultiPoint for [Signature] and [PublicKey] #226
Conversation
Can we do the following? I take your commits and open another merge request with one extra thing for you to review and test. Because when it comes to performance, there is one additional thing that is worth implementing. In #225 I mentioned the significant parts, but I've omitted one common part, i.e. a step you would need to perform in either of the discussed cases, group checks. I suppose you won't need to perform group checks on public keys in your scheme, because you have proofs of possession, which implies the group check. But as far as signatures go, you have to vet them, and do so individually, i.e. it would be inappropriate to group-check the result of aggregation. On the plus side if you group-check the inputs, you don't need to group-check the result of the aggregation... |
In Ethereum I think most clients separate input flow into 2 layers:
Deserializing and group check are likely done in the networking layer in all clients. This is allows singling out a bad peer. And also it's easy to parallelize deserialization. |
When exactly the additional implementation will be used, or if at all, would be up to the application. The rationale is that since we provide options to perform group checks upon individual calls, for consistency it would be appropriate to provide it as option even with suggested aggregate_with_randomness. |
sounds good. As @mratsim said, we probably won't need to do group checks inside the add/mult operation for our purposes, but if it's desired for consistency then so be it :) |
Committed as 104ad64, and see v0.3.13. |
// test multi-point aggregation using mult | ||
let agg_pk = pks.mult(&rands, 64).to_public_key(); | ||
let agg_sig = sigs.mult(&rands, 64).to_signature(); | ||
let err = agg_sig.verify(true, &msg, dst, &[], &agg_pk, true); |
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.
Forgot to leave a remark. It's about the true
-s in the above line. Group-checks are expensive, which is why you want to minimize their amount. So the question is why isn't it here? Indeed, MSM [or sum] over in-group points is guaranteed to be in-group. At the same time it would be [cryptographically] inappropriate to pass non-in-group points to MSM [or sum]. What I'm trying to say is that in a sound application these true
-s would be actually redundant.
repr(transparent)
, see https://doc.rust-lang.org/nomicon/other-reprs.html#reprtransparent