Closed davidnevadoc closed 5 months ago
Thanks for the recommendation @mratsim. I think following that separation is a good idea, I'll do that!
While working on this I started thinking about the order of the extensions in the towers. The most common ordering I've seen is Fp12:Fp6:Fp2:Fp. Do you think it is fine to have only this construction in mind or should we aim to also support others?
These changes have been mostly implemented in https://github.com/privacy-scaling-explorations/halo2curves/pull/161.
While working on this I started thinking about the order of the extensions in the towers. The most common ordering I've seen is Fp12:Fp6:Fp2:Fp. Do you think it is fine to have only this construction in mind or should we aim to also support others?
I forgot to reply, the Fp12->Fp4 for me is noticeably faster for BLS12-381
The tradeoff is that inversion suffers.
I suggest separating the extension fields logic from the pairing logic.
This would allow more flexibility in adding curves with embedding degrees != 12 like BW6-761 (that embeds BLS12-377) or BLS24 curves (which are more efficient than BLS12 curves for KZG as they can have a smaller base field).
For instance this works very well in Constantine:
extension fields:
with only core field operations
pairings:
see: https://github.com/mratsim/constantine/tree/5894a8da/constantine/math/pairings