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.
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