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
This issue replaces #92 with a more concrete plan of action
The current Constantine has good foundations to build and test LLVM IR primitives for x86, ARM, Nvidia, AMDGPU and all other ISAs that support add-with-carry after:
The ultimate goal is to port multi-scalar multiplication to Nvidia GPUs, this will require the following steps:
Field arithmetic
Currently only add/sub/mul are implemented, we need to implement all primitives needed for shortweierstrass jacobian doubling/addition and shortweierstrass projective doubling/addition.
There is no need initially for primitives for serialization/deserialization/validation as those can be done on CPU and copied to GPU, for example sqrt is not on the critical path
## return true and update `P` if `x` leads to a valid point
## return false otherwise, in that case `P` is undefined.
##
## Note: Dedicated robust procedures for hashing-to-curve
## will be provided, this is intended for testing purposes.
##
## For **test case generation only**,
## this is preferred to generating random point
## via random scalar multiplication of the curve generator
## as the latter assumes:
## - point addition, doubling work
## - scalar multiplication works
## - a generator point is defined
## i.e. you can't test unless everything is already working
P.y.curve_eq_rhs(x, G)
result=sqrt_if_square(P.y)
P.x = x
Meaning at the very least:
ccopy
square
neg
cneg
I think square can be implemented as nsqr with "virtual" signature proc nsqr(r: var Fp, a: Fp, count: int) that loops from the count to 0 excluded as overhead is minimal and it will be helpful for primitives that need square_repeated (deserialization).
nonresidue_fp2: (1, 1) # 1+𝑖 1+𝑖 is not a square or cube in 𝔽p²
embedding_degree: 12
sexticTwist: M_Twist
Jacobian coordinates are probably slightly easier as they don't depends on the curve equation parameters (a, b) in y² = x³ + ax + b.
It is fine to focus on curves with a == 0 as all curves used for Ethereum (secp256k1, BN254_Snarks and BLS12_381) are in that case.
When there is a dependency on the curve equation, I am undecided yet whether to materialize b as a global in LLVM IR and let the optimizer do its job or doing directly in the code generator.
Addition, mixed addition and doublings are the priority. Due to GPU constraint, will start with the constant-time versions.
The text was updated successfully, but these errors were encountered:
This issue replaces #92 with a more concrete plan of action
The current Constantine has good foundations to build and test LLVM IR primitives for x86, ARM, Nvidia, AMDGPU and all other ISAs that support add-with-carry after:
The ultimate goal is to port multi-scalar multiplication to Nvidia GPUs, this will require the following steps:
Field arithmetic
Currently only add/sub/mul are implemented, we need to implement all primitives needed for shortweierstrass jacobian doubling/addition and shortweierstrass projective doubling/addition.
There is no need initially for primitives for serialization/deserialization/validation as those can be done on CPU and copied to GPU, for example sqrt is not on the critical path
constantine/constantine/math/elliptic/ec_shortweierstrass_affine.nim
Lines 105 to 128 in 65147ed
Meaning at the very least:
I think
square
can be implemented asnsqr
with "virtual" signatureproc nsqr(r: var Fp, a: Fp, count: int)
that loops from the count to 0 excluded as overhead is minimal and it will be helpful for primitives that need square_repeated (deserialization).Naming
see this https://github.com/mratsim/constantine/blob/65147ed815d96fa94a05d307c1d9980877b7d0e8/constantine/math_compiler/README.md
Elliptic curve arithmetic
Similar to the field descriptor, an EcDescriptor will likely be needed
constantine/constantine/math_compiler/ir.nim
Lines 142 to 160 in 65147ed
The following algebraic object configurations in SageMath and Nim Macro and the curve-specific calls will help guide what the descriptor should hold:
constantine/sage/curves.sage
Lines 123 to 137 in 65147ed
constantine/constantine/named/config_fields_and_curves.nim
Lines 252 to 270 in 65147ed
Jacobian coordinates are probably slightly easier as they don't depends on the curve equation parameters (a, b) in y² = x³ + ax + b.
It is fine to focus on curves with a == 0 as all curves used for Ethereum (secp256k1, BN254_Snarks and BLS12_381) are in that case.
When there is a dependency on the curve equation, I am undecided yet whether to materialize b as a global in LLVM IR and let the optimizer do its job or doing directly in the code generator.
Addition, mixed addition and doublings are the priority. Due to GPU constraint, will start with the constant-time versions.
The text was updated successfully, but these errors were encountered: