Will o1js support secp256r1 signature verification?

[wind matrix]

Seeing o1js's repo is introducing ECDSA gadget, so curious will it support secp256r1? This will bring possibilities for use cases of passkey 😉

[upper flicker]

that's another curve entirely

you can implement a custom gate for it yourself though

and use that custom gate using recursive proofs

[glass yew]

@wind matrix @upper flicker the curve that the ecdsa gadget uses is just a parameter. It'll be trivial to use on secp256r1 instead of secp256k1, I can also export the necessary curve parameters from o1js

Right now in my PR it's implemented for all curves that have a=0 and no cofactor. (Both of those cases would be easy additions)

[upper flicker]

so it's not part of the gate itself?

you can use an arbitrary gate?

at "runtime"?

[glass yew]

Gates can have coefficients, which are decided at circuit compile time. The base field modulus of an elliptic curve is such a coefficient which goes into the gates for foreign field arithmetic

[upper flicker]

what if you want to use multiple curves?

[glass yew]

Gate coefficients are set per-gate not per-circuit. So it's no problem to use multiple curves in the same circuit

[upper flicker]

great

I don't understand how you can set them at compile time but not later

[glass yew]

Gate coefficients are one of the parts that define the circuit.

You can set them differently during proving but then you'll have a proof for a different circuit, which you won't be able to create using the prover key of the original circuit

[upper flicker]

Makes sense, I was dumb

[wind matrix]

I feel that even if the new curve signature verification algorithm is currently implemented, it is still likely to be unable to be effectively adopted due to the limitations of circuit size and potential memory constraints in wasm.

[glass yew]

ecdsa + keccak in its initial release takes 45k constraints btw, for signing a 136 bytes message. Plus about 14k for every additional block of 136 bytes. So 272 bytes is doable in a single circuit right now, within the circuit and memory constraints.

so, I agree, the limitations you mention are annoying, while already allowing for cool use cases like verifying signatures on simple Eth txs. we're close to lifting the circuit limits with chunking, which allows for arbitrary-sized circuits in principle. after that we still have to work on the memory usage 👷

[wind matrix]

Absolutely, in a single circuit, there's usually more going on than just checking signatures; you often have to deal with other kinds of logic too. This can quickly bring you up against the circuit's size limit. Also, is it possible for you to export the secp256r1 (p256) curve parameters from o1js?

[glass yew]

@wind matrix Yep I can export the p256 params, can you create a gh issue so we don't forget?

[lone trench]

found this thread because I was looking for info regarding support for secp256r1 signature verification. Adding to the conversation here that i'm experimenting with passkeys (i.e. the Web Authentication API supported by all major browsers now) which are based on FIDO2 standard. Passkeys can generate signatures on the secp256r1 curve (https://www.w3.org/TR/webauthn-2/#sctn-alg-identifier) so if o1js added the curve parameters for it, zkApps would have the option to leverage browser-native passkey features in their circuits.

[glass yew]

You don't need o1js to add the parameters though, you can just pass them in yourself

[lone trench]

nice, good to know!

[wind matrix]

It seems that o1js does not support the parameters for secp256r1.

[glass yew]

Oh right 😅 didn't know it had a nonzero a. There's only a small amount of code to adapt to support that though