v2 new design - Githubissues

ingonyama-zk / icicle

A hardware acceleration library for compute intensive cryptography :ice_cube:

https://dev.ingonyama.com/icicle/overview

MIT License

329 stars 97 forks source link

v2 new design #443

Closed ChickenLover closed 6 months ago

ChickenLover commented 6 months ago

Status:

Curves supported:

[x] bls12-377
[x] bls12-381
[x] bn254
[x] grumpkin
[x] bw6

Primitives supported:

[x] NTT (supported, but not working correctly)
[x] ECNTT
[x] MSM
[x] Poseidon
[x] Tests

Hash supported:

[x] Keccak

To-Do before merge:

[x] Change to use a common curve_config.cuh / field_config.cuh
[x] Merge with current main
[x] Update CI configs
[x] Test if ECNTT works
[x] Test if G2 MSM works
[x] Merge device memory redesign
[x] Add babybear field

To-Do after merge:

[ ] Update golang API
[x] Add Rust crate for icicle_hash
[ ] Update all the examples to use new API
[ ] Add polynomial API
[ ] Update Rust curve template
[ ] Update docs
[ ] Expose c_api.h as proposed by @yshekel

ChickenLover commented 6 months ago

@yshekel RE: "freedom of implementation" example. We currently have a single NTT implementation that is being called for all the fields. If we want to have a different NTT algo for some specific field/fields (e.g. small fields twiddles generation), we will need to do smth like #if CURVE == smth

ChickenLover commented 6 months ago

@yshekel thank you for your review

about hashes, are they exposed in all the libs currently? Is this the intention?

Not sure what you meant. All the non-field hashes are compiled in ingo_hash lib. There are no Rust nor Golang wrappers atm. I am planning to add them later

About polynomials, they should probably link to a field and/or a curve in case coeffs/image are EC points, plus NTT. How would it fit? Is it a library per curve/field? or part of each curve/field library?

I think the most simple solution would be to make Polynomials part of each curve/field library, just like NTT is instantiated as NTT in field libs and as NTT + optional ECNTT in curve libs

yshekel commented 6 months ago

@yshekel thank you for your review

about hashes, are they exposed in all the libs currently? Is this the intention?

Not sure what you meant. All the non-field hashes are compiled in ingo_hash lib. There are no Rust nor Golang wrappers atm. I am planning to add them later

About polynomials, they should probably link to a field and/or a curve in case coeffs/image are EC points, plus NTT. How would it fit? Is it a library per curve/field? or part of each curve/field library?

I think the most simple solution would be to make Polynomials part of each curve/field library, just like NTT is instantiated as NTT in field libs and as NTT + optional ECNTT in curve libs

Makes sense yes. I probably missed the hash lib so yeah that's ok then.

ChickenLover commented 6 months ago

Ready to be merged. With the lack of examples and golang bindings, but everything else seems to work