-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make FieldElement
generic to simplify alternate backend creation.
#5055
Labels
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
May 28, 2024
# Description Step towards #5055 ## Summary\* This PR starts us down the road towards removing the compile-time flags for specifying which field is being used by replacing the usage of the `FieldElement` type with an `AcirField` trait. This trait is mostly all of the external methods from `FieldElement` dumped into it for now but we can break it down in future PRs (XOR and AND are looking ready for culling) I've taken this route rather than just using `generic_ark::FieldElement` as we'd need to have trait bounds for `PrimeField` anyway so we might as well have our own trait. I've had to delete a couple of trait implementations which fall afoul of the orphan rule now it's being implemented for a generic type (e.g. we need to use `MemoryValue::new_field` explicitly now) but nothing too bad. ## Additional Context ## Documentation\* Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [x] I have tested the changes locally. - [x] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
This was referenced Jun 10, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 10, 2024
# Description ## Problem\* Related to #5055 ## Summary\* This PR throws generics into more of the codebase. ## Additional Context ## Documentation\* Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [x] I have tested the changes locally. - [x] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 10, 2024
…r` (#5209) # Description ## Problem\* Related to #5055 ## Summary\* We don't need the field element to know about AND and XOR as we just need to be able to convert into byte arrays and back. I've then moved this into the blackbox solver crate (the only place we were actually using this) to simplify the `AcirField` trait. ## Additional Context ## Documentation\* Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [x] I have tested the changes locally. - [x] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Personally, I'm very bullish on the vision for Noir to become "the LLVM of ZK" which is why we recently attempted to (and somewhat succeeded) at developing an MVP alternate backend for Noir that targets a different proving system (AIR+FRI STARK) that also uses a different prime field (BabyBear).
This was made unnecessarily difficult by the fact that the commonly referred to
FieldElement
type is dynamically defined at compile time via feature flags propagated throughout the codebase (relevant snippet):This was further complicated by the fact that
bn254
is the default feature, meaning that despite adding a 3rd curve here and defining the feature for it the flags had to be changed in all relevant sub-crates of our fork as well as leading to hard to track downassert_unique_feature
errors arising from crates seemingly still referencing thebn254
feature (The difficulty of tracking down the issue was mainly because Rust wouldn't tell us which crate is implicitly using the conflictingbn254
feature flag but instead just point to the defined compile-time check).In the hackathon we fixed this by just deleting crates we didn't immediately need and updating the features wherever we could.
Happy Case
Ideally
FieldElement
would be defined and propagated through the crates as a generic type, only being fixed at top-level interaction points such asnargo_cli
so that forks can select/switch the field.Even better would be if custom prime fields were definable or pre-existing fields selectable via options in your
Nargo.toml
file.Project Impact
Blocker
Impact Context
When it comes to building alternative backends this is a fundamental blocker as creating and integrating a new one would require making the aforementioned non-trivial changes to the codebase, requiring devs to install, compile and run forks of noir which is sub-optimal.
Workaround
None
Workaround Description
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: