Added support for secp256r1 in Cairo

[yuvalsw]

This change is 

[orizi]

Reviewed 2 of 21 files at r1, all commit messages.
Reviewable status: 2 of 21 files reviewed, 2 unresolved discussions (waiting on @yuvalsw)

---

corelib/src/starknet/secp256.cairo line 12 at r1 (raw file):

#[derive(Copy, Drop)]
extern type Secp256EcPoint;

re-separate to k1 and r1.

Code quote:

#[derive(Copy, Drop)]
extern type Secp256EcPoint;

---

corelib/src/starknet/secp256.cairo line 14 at r1 (raw file):

extern type Secp256EcPoint;

trait Secp256 {

and probably filename as well - just as to not make it look too usable for users.

Suggestion:

trait Secp256Generic

[yuvalsw]

Reviewable status: 2 of 23 files reviewed, 2 unresolved discussions (waiting on @orizi)

---

corelib/src/starknet/secp256.cairo line 12 at r1 (raw file):

Previously, orizi wrote…

re-separate to k1 and r1.

Done.

---

corelib/src/starknet/secp256.cairo line 14 at r1 (raw file):

Previously, orizi wrote…

and probably filename as well - just as to not make it look too usable for users.

Done.

[orizi]

Reviewed 5 of 21 files at r1, 11 of 16 files at r3, all commit messages.
Reviewable status: 18 of 23 files reviewed, 1 unresolved discussion (waiting on @yuvalsw)

---

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

    ) -> Option<Secp256k1EcPoint> {
        super::secp256_trait::recover_public_key::<Secp256k1EcPoint>(msg_hash, r, s, y_parity)
    }

i think these should just be out of the trait and the impl (as using the function just through the module is much more neat)

Code quote:

    fn recover_public_key(
        msg_hash: u256, r: u256, s: u256, y_parity: bool
    ) -> Option<Secp256k1EcPoint> {
        super::secp256_trait::recover_public_key::<Secp256k1EcPoint>(msg_hash, r, s, y_parity)
    }

[yuvalsw]

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

Previously, orizi wrote…

i think these should just be out of the trait and the impl (as using the function just through the module is much more neat)

Why is it more neat?
Why specifically this?
This is part of the interface for secp, why not in the trait and impl?

[orizi]

Reviewable status: 18 of 23 files reviewed, 1 unresolved discussion (waiting on @yuvalsw)

---

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

Previously, yuvalsw wrote…

Why is it more neat?
Why specifically this?
This is part of the interface for secp, why not in the trait and impl?

Not just this one, all the outer ones, as the aim of this trait was to more easily implement the generics.
The usage itself from the user side would still be more fitting if it is just a normal module and not an impl.
Impl would have made more sense to me if some type would have carried all the secp information, and than a trait and impl would easily allow users to access it, which is not the case here.

[yuvalsw]

Reviewable status: 18 of 23 files reviewed, 1 unresolved discussion (waiting on @orizi)

---

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

Previously, orizi wrote…

Not just this one, all the outer ones, as the aim of this trait was to more easily implement the generics.
The usage itself from the user side would still be more fitting if it is just a normal module and not an impl.
Impl would have made more sense to me if some type would have carried all the secp information, and than a trait and impl would easily allow users to access it, which is not the case here.

I think the interface should be consistent.
With your suggestion, a test would now look like:

    let public_key = secp256_trait::recover_public_key::<Secp256k1EcPoint>(msg_hash, r, s, y_parity).unwrap();
    let (x, y) = Secp256k1Impl::secp256_ec_get_coordinates_syscall(public_key).unwrap_syscall();

(adding to the inconsistency, with it now being called secp256_trait, it's even weirder to have function in it as a module)

I prefer leaving it as is, let me know if you strongly object.

[orizi]

Reviewable status: 18 of 23 files reviewed, 1 unresolved discussion (waiting on @yuvalsw)

---

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

Previously, yuvalsw wrote…

I think the interface should be consistent.
With your suggestion, a test would now look like:

    let public_key = secp256_trait::recover_public_key::<Secp256k1EcPoint>(msg_hash, r, s, y_parity).unwrap();
    let (x, y) = Secp256k1Impl::secp256_ec_get_coordinates_syscall(public_key).unwrap_syscall();

(adding to the inconsistency, with it now being called secp256_trait, it's even weirder to have function in it as a module)

I prefer leaving it as is, let me know if you strongly object.

What I want is to simply leave the original interface for the user as is, and use the trait just to reduce the code duplication between r1 and k1

[yuvalsw]

Reviewable status: 18 of 23 files reviewed, 1 unresolved discussion (waiting on @orizi)

---

corelib/src/starknet/secp256k1.cairo line 51 at r3 (raw file):

Previously, orizi wrote…

What I want is to simply leave the original interface for the user as is, and use the trait just to reduce the code duplication between r1 and k1

Done.

[orizi]

Reviewed 3 of 5 files at r4, 5 of 5 files at r5, 11 of 11 files at r6, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @yuvalsw)

[yuvalsw]

Reviewed 4 of 6 files at r7.
Reviewable status: 23 of 25 files reviewed, all discussions resolved (waiting on @orizi)

[yuvalsw]

Reviewed 1 of 6 files at r7, all commit messages.
Reviewable status: 24 of 25 files reviewed, all discussions resolved (waiting on @orizi)

[yuvalsw]

Reviewed 1 of 11 files at r6, 1 of 1 files at r8.
Reviewable status: all files reviewed (commit messages unreviewed), all discussions resolved (waiting on @yuvalsw)

[orizi]

Reviewed all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @yuvalsw)