Make native Field in SnarkyJS configurable #25
Conversation
bkase
force-pushed
the
rfc/generic-js-field
branch
from
5de7824
to
c147ec0
Compare
|
|
||
| ### Rust side: instantiating core Kimchi methods | ||
|
|
||
| TODO - does Rust enable us to dynamically instantiate traits (or whatever) as function return values? |
There was a problem hiding this comment.
https://doc.rust-lang.org/rust-by-example/trait/dyn.html , but it's "slow" since there is a few pointer jumps vs the static https://doc.rust-lang.org/rust-by-example/trait/impl_trait.html . I don't think it will be even remotely close to the bottleneck here though.
There was a problem hiding this comment.
But that example picks between 2 traits that both have been declared already, instead of creating a trait depending on a parameter like we can do in OCaml and JS
There was a problem hiding this comment.
Ah okay I get it, typically I use a “record of closures” to get that to work in these kinds of languages though I haven’t tried it in Rust.
The idea is for all the functions of the trait you add closures to the struct and the implementations of the trait is just calling the closures. Then you can, at runtime, swap implementations. I don’t see a reason why it won’t work in rust if you wrap things in enough boxes, but I’m not a Rust expert.
|
|
||
| It's work. | ||
|
|
||
| ## Rationale and alternatives |
There was a problem hiding this comment.
Other alternatives at the API level (though I like your proposal a lot!)
- Add a type parameter to the
Fieldclass: ie.Field<Bn128>orField<Pasta> - Dynamically change the behavior of Field at runtime:
Field.setBackendTo(Bn128()) - Statically instantiate the backends and tie that to the name of the class:
FieldBn128or the importimport Field from 'lib/field_bn128'<-- we can consider the latter as a shorthand built on top of the more general system you're proposing.
There was a problem hiding this comment.
Yeah I considered 2) but it's not very nice. 3) without a generic e2e solution is a reasonable fallback in case we can't make fully generic work (parts of the logic would still be generic).
I don't think 1) fully specifies an API because types in TS don't affect the runtime, so there would still have to be some runtime step of picking the field
|
Interesting - this only affects Kimchi proofs, right? Or will developers also be able to generate wrapper proofs with pickles? |
Yes only Kimchi proofs We might want to treat the Kimchi proof API with more love going forward |
I was about to say! I feel like this could be a nice opportunity to improve the kimchi API and making it generally more accessible. We have all the tools we need, but the Circuit API always felt a little odd. This is exciting |
No description provided.