ark-dalek discussion #812
Description
An interesting litmus test for #811 would be someone doing an ark-dalek crate that provides wrapers around curve25519-dalek types and supports ark-ec traits, so some discussion:
Why really do this? zka.lc reports ark-ed25519 MSMs as being faster, which is bullshit since zka.lc ignores that ark-ed25519 is multi-threaded and curve25519-dalek in single threaded. Multi-threaded helps when verifying large bulletproofs, shuffles, batched schnorr, etc but likely harms smaller use cases. Also, some wasm enviroments stay single threaded anyways, so the more fine tunned dalek code helps.
Also, ark_ec made VariableBaseMSM into a trait now, which could likely be implemented over some wrapers for dalek's EdwardsPoint and RistrettoPoint. I'm not sure everything stays straightforward though.
Who's fields?
- Implement ark-ff wrappers around the curve25519-dalek fields. This would likely require hazmat tooling here, hence this issue being related to Why do you use a fork of
curve25519-dalek? #811 This solution maybe most compatible with other RustCrypto curves. - Use the fields defined in ark-curve25519, like ark-ed25519 does, but then translate the field elements when making the elliptic curve calls into dalek. This costs something, but maybe this could be somewhat absorbed into other costs for MSMs. It'd maybe break the least in arkworks ala Yafa-108/146 https://github.com/DZK-Labs/ark-yafa
- Adjust the ark-curve25519 fields so they have the same internal representation as curve25519-dalek, and then do
unsafe { mem::transmute(..) }s and lock down crate versions.
Anyone have any opinions handling the fields? Or anything else?