Closed ghost closed 6 years ago
https://link.springer.com/chapter/10.1007%2F978-3-642-17455-1_2 describes a BN pairing library that takes less than a millisecond. It seems strange that a BN pairing library would take 300x as fast.
One of the reasons is that this particular curve is not tuned for pairing efficiency, but instead to work efficiently in the context of zk-SNARKs.
But the most important reason is just that this implementation is not that efficient.
If you want to use pairings in your software and want them to be fast, I recommend using https://github.com/ebfull/pairing instead.
It's a more secure curve, tuned better, and performs well. Pairings take less than 3ms on x86_64. Its API is very stable. It doesn't use any unsafe code.
I don't see any point in using the bn library for anything anymore unless you're trying to do something with Zcash/Ethereum maybe.
By the way, you're running the code with cargo run
when you should be doing cargo run --release
.. it would show a drastic performance improvement over the numbers you got.
Also note that all of the benchmarks at https://crypto.stanford.edu/pbc/times.html are for curves with less than 80 bits of security. (Caveat: those timings are for a 1GHz Pentium III.) A curve equivalent in security to BLS12-381 would at least need to have 4572 in the "Dlog security (bits)" column. It's not possible to directly compare based on those benchmarks because they're on a much slower processor, but they seem slow to me even taking that into account. Maybe that page is just out of date, though.
We rebuilt the project with cargo build --release
and the pairing time dropped to 12ms which was in line with expectations.
https://crypto.stanford.edu/pbc/
I was under impression pairings would take roughly 30 milliseconds according to the link above.
But my test shows otherwise:
My test code:
@chronusz