Open str4d opened 1 year ago
Something I want to consider for this is how easy each of the approaches makes implementing "backends": specialisations for different targets for improved performance (e.g. AVX2).
And I also have idea about code duplication.
We can separate interface and arithmetic(algorithm). The arithmetic is often the same for field and curve. We can implement it separately like following. https://github.com/zero-network/zero/tree/master/primitive/crypto/src/arithmetic And interface is just passing its arguments to arithmetic function. https://github.com/zero-network/zero/blob/master/primitive/crypto/src/dress/curve/edwards/group.rs#L76
If we apply the optimization to arithmetic, it affects for every component.
How about creating zkcrypto/crypto-arithmetic
and import arithmetic from components?
It will be a big refactoring but we can reduce code duplication and synchronizing workload.
I think macro is not good way to reduce code because it makes visibility bad. but we can use macro for the parts where visibility is not necessary as in RefOps. We can also implement it as module with the same way with above arithmetic.
Currently this library has two field implementations, the Pallas field and the Vesta field. They only differ in their prime modulus, and are otherwise almost identically implemented. This makes the library harder to maintain, as every change needs to be duplicated.
There are several possible approaches we could take to improve the situation:
ff_derive
pairing
crate, but we replaced that with a direct implementation of the field in thebls12_381
crate, andff_derive
hasn't been as effectively maintained since. If we switched to it, the majority of our field maintenance effort could go intoff_derive
instead of here.crypto-bigint
to implement the internal field details.crypto-bigint
is, though progress is being made.ff_derive
approach to make it easier to maintain as well.