Draft mini RFC for SnarkyJS API to expose ECDSA/Keccak gadgets

[bkase]

Initially the crypto team is going to expose these gadgets to SnarkyJS via OCaml bindings with the plan to push them down to the Rust layer later.

Foreign fields are triples of native fields which we should make opaque at the SnarkyJS layer.

Sometime in the latter half of May, crypto team should be able to provide stub APIs to work towards in SnarkyJS in order to parallelise the work.

Since this exposes the ability to prove a new thing, it would entail exposing a new surface area to the SanrkyJS API. As such, we can prepare by putting together a mini RFC that determines the API, interaction flows and test plan.

The feature essentially allows SnarkyJS to prove with an ECDSA signature that the signer owns a particular ethereum address. What does that look like in SnarkyJS? How would it fit into an interaction flow within a UI?

PRD for primitive support can be found here.

[stevenpack]

@nicc pushing this higher in the backlog for discussion next sprint planning.

ECDSA verification is blocking some of the more promising commercial / large scale uses of SnarkyJS. I tried to get a handle on all the moving parts here: https://www.notion.so/minaprotocol/Ethereum-Primitives-Dependencies-21e56244b1cd43b1807aac39fdd25117?pvs=4

It sounds like there are 2 things for Product eng. here:

1. Expose to SnarkyJS (item 3 in the doc)
2. Consume in SnarkyJS (item 5 in the doc).

If I got it right, 5) is a no-brainer for Product Eng, but it sounded like there was a chance to parallelize if Product eng could item 3, with crypto team providing a 'stub API' to work off, so the two streams could happen in parallel.

cc @bkase

[Trivo25]

see o1-labs/rfcs#9