Skip to content
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

Merge nonnative #79

Merged
merged 110 commits into from Aug 11, 2021
Merged

Merge nonnative #79

merged 110 commits into from Aug 11, 2021

Conversation

Pratyush
Copy link
Member

@Pratyush Pratyush commented Aug 8, 2021

Description

Add NonnativeFieldVar to r1cs-std.


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (master)
  • Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
  • Wrote unit tests
  • Updated relevant documentation in the code
  • Added a relevant changelog entry to the Pending section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer

Pratyush and others added 30 commits October 19, 2020 11:07
Co-authored-by: Nicholas Ward <npward@berkeley.edu>
Add support for `no_std`, plus some `clippy` fixes
Adds constraints to check that the conversion to affine coordinates happened correctly.
The prior PR (#9) multiplied by `self.z` instead of `self.z.inverse()`.
This is related to a Zexe issue arkworks-rs/snark#289

Basically, ToBitsGadget for FpVar may produce shorter output for a constant value, which is undesired for a few reasons.
* Fix pre_eq_reduce

The pre_eq_reduce should directly reduce the value to the normal form rather than checking it.

* fmt
* allow cs being none for into_edwards
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
let res = (&a_times_b + &c_times_d)?.reduce()?;
```

It performs only one *reduce* operation and is roughly 2x faster than the first implementation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not have the default multiplication output NonNativeFieldMulResultVar, and reduce the inputs to multiplication implicitly? (You would need to keep track of potential overflow from long sequences of additions, and perhaps also handle reduction automatically in that case, but I think that's also a hazard with the current API.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For API reasons we can't return NonNativeFieldMulResultVar directly (the bound on FieldVar requires returning Self, which is NonNativeFieldVar. But I guess internally we could track the reduction state, and reduce if we invoke operations which require the canonical form (eg: to_bytes). cc @weikengchen ?

@Pratyush Pratyush changed the base branch from master to master-2 August 10, 2021 20:54
@Pratyush Pratyush changed the base branch from master-2 to master August 10, 2021 20:57
@Pratyush Pratyush marked this pull request as draft August 10, 2021 23:52
@Pratyush Pratyush marked this pull request as ready for review August 10, 2021 23:52
Comment on lines 129 to 134
pub mod reduce;

/// a macro for computing ceil(log2(x)) for a field element x
#[doc(hidden)]
#[macro_export]
macro_rules! overhead {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw @weikengchen is there a reason these two are public? AFAIK they are not used outside the crate, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked our use of these two modules.

I feel both should be private. And the two use cases above may suggest that we should move NonNativeFieldInputVar and bits_le_to_nonnative into here, and the external world should just call them. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the overhead macro and the reduce module private, and will file an issue for the other two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet