search

supranational / sppark

Zero-knowledge template library
Apache License 2.0
183 stars 64 forks source link

Support halo2curves #26

Closed Iridescent-gcrace closed 11 months ago

Iridescent-gcrace commented 11 months ago

May I ask your guys if sppark plans to support halo2curves (github)[https://github.com/privacy-scaling-explorations/halo2curves]

dot-asm commented 11 months ago

One has to keep in mind that this project is very much focused on providing a foundation for applications we build (or help building) rather than on general why-not-this-n-that coverage. With this in mind. As far as MSM goes, Pasta curves are supported through pasta-msm, grumpkin can be put together by swapping fr_t and fp_t from alt_bn128 when instantiating MSM. As for NTT, there are parameters for Pasta curves, and NTT is not applicable to grumpkin. As for secp256* curves. While it's possible to instantiate secp256k1, there would be room for performance improvement left, both on GPU and CPU sides, hence no. As for secp256r1, it won't work as is, because for the moment of this writing sppark supports only y^2=x^3+b curves. Maybe some day...

Iridescent-gcrace commented 11 months ago

Thank you very much for your answer. I understand your point very well, and thank you for your contribution to sparkpark, which is very beneficial to me and my team. My recent work is trying to implement the interface of the bn256 curve in sppark (maybe that is, the bn254 curve on ark) to the halo2 algorithm to achieve GPU acceleration of the halo2 algorithm. Regarding this work, I would like to ask if there are any risks in this work in sppark? Or is there something wrong with my statement? By the way, I noticed that you mentioned "sppark supports only y^2=x^3+b curves." above, but in the actual sppark code, bn254 curves are supported. I am a little confused about this. Looking forward to your answer very much. Thanks again :)👍

dot-asm commented 11 months ago

I don't quite follow which "risks" you're referring to. bn254 (a.k.a. alt_bn128) was verified to work in production, if this is what you're wondering about... Just in case, "bn254" is an ambiguous term, because it can refer to a different curve. Additional reference to alt_bn128 removes the ambiguity.

As for the y^2=x^3+b formula. All mentioned curves except for secp256r1 are described by it. secp256r1 on the other hand is described by y^2=x^3+ax+b, it's that extra ax term that is not currently supported by sppark. And I brought it up, because the curve was mentioned on the url you've provided.