-
Notifications
You must be signed in to change notification settings - Fork 119
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
Pairing speed relative to the herumi/mcl implementation #84
Comments
The BN254 implementation compared in that post is from libsnark. Should this be refiled as a ticket against libsnark? |
Oh, also the BLS12-381 pairing implemented in bellman takes 2.5ms in that post (on @ebfull's i7-3770S). |
Also, BN254 can mean a lot of different things. It can mean some 254-bit BN curve or it can mean the specific 254-bit BN curve implemented in libsnark, which could have different performance for pairings due to the parameter and the extension tower. |
https://github.com/dfinity/random-beacon is a bit of a red herring; the actual pairing implementation it uses is https://github.com/herumi/mcl (which supports BLS12-381 now). The readme says that it is using code from xbyak, so it is presumably doing JIT compilation. We're fine with the safe Rust code for now, but it's probably worth investigating whether we can achieve comparable performance without the JIT compilation. (On the other hand, implementing batch proof validation would be a lower-hanging performance win.) |
Checking for spent notes in a block is still not completely constant time, due to filtering out negative results of the constant-time comparison. Part of #84.
For BN254, Dfinity's implementation does pairing in less than 0.8ms (see here):
This contrasts very favourably compared to the numbers given in this post where a BN254 pairing is done 2.5ms with
USE_ASM
. Why is the discrepancy so high, and does this suggest that this implementation can be sped up significantly?The text was updated successfully, but these errors were encountered: