You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many implementations of elliptic curves in libraries (e.g. bls12_381) internally make use of the montgomery form to represent field elements, where a number a mod P is stored as aR mod P for some factor R (for bls12_381, this is 2^384 mod P).
Currently, the existing non-native field operations supported all simply deal with regular a mod P representations of these numbers. In the case of addition and subtraction nothing changes, but when multiplication and division are involved, the R factor needs to be dealt with separately. This incurs overhead by requiring multiple additional operations. It would be desirable to have non-native field operations that natively directly support the montgomery form when performing multiplication and division/inversion.
This is not a high-priority blocking issue since we can work around this issue by using a field multiplication precompile to perform the reduction, i.e. multiplying by R^(-1) to remove the R factor, perform the usual operation, then multiply back by R to return it to its montgomery representation. There is still overhead in doing this though, specially in long-running computations that perform many of these roundtrips.
The text was updated successfully, but these errors were encountered:
Many implementations of elliptic curves in libraries (e.g.
bls12_381
) internally make use of the montgomery form to represent field elements, where a numbera mod P
is stored asaR mod P
for some factorR
(forbls12_381
, this is2^384 mod P
).Currently, the existing non-native field operations supported all simply deal with regular
a mod P
representations of these numbers. In the case of addition and subtraction nothing changes, but when multiplication and division are involved, theR
factor needs to be dealt with separately. This incurs overhead by requiring multiple additional operations. It would be desirable to have non-native field operations that natively directly support the montgomery form when performing multiplication and division/inversion.This is not a high-priority blocking issue since we can work around this issue by using a field multiplication precompile to perform the reduction, i.e. multiplying by
R^(-1)
to remove theR
factor, perform the usual operation, then multiply back byR
to return it to its montgomery representation. There is still overhead in doing this though, specially in long-running computations that perform many of these roundtrips.The text was updated successfully, but these errors were encountered: