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

Interchangeability of NonNativeFieldVar and FpVar for FieldVar #99

Open
2 of 4 tasks
weikengchen opened this issue Aug 28, 2022 · 1 comment
Open
2 of 4 tasks
Labels
D-hard Difficulty: hard P-low Priority: low T-design Type: discuss API design and/or research T-tracking Type: tracking issue

Comments

@weikengchen
Copy link
Member

Summary

This issue is to discuss how to make NonNativeFieldVar a drop-in replacement for FieldVar in curve operations.

Problem Definition

One of the reasons that we implemented FieldVar for NonNativeFieldVar is to allow it to be a drop-in replacement of FpVar, so that one doesn't need to build a hierarchy of nonnative primitives.

This, however, is not covered by the current implementation, see:
https://github.com/arkworks-rs/r1cs-std/blob/master/src/groups/curves/short_weierstrass/mod.rs#L44

#[derive(Derivative)]
#[derivative(Debug, Clone)]
#[must_use]
pub struct ProjectiveVar<
    P: SWModelParameters,
    F: FieldVar<P::BaseField, <P::BaseField as Field>::BasePrimeField>,
> where
    for<'a> &'a F: FieldOpsBounds<'a, P::BaseField, F>,
{
    ...
}

It would be ideal, though, to lift this restriction. However, we want to make sure that we don't change the existing writing system---it would be highly inconvenient to use

pub struct ProjectiveVar<
    P: SWModelParameters,
    F: FieldVar<P::BaseField, CF>,
    CF: PrimeField,
> 

because it introduces one more param CF.

A possible workaround, though not favorable, is to define GeneralizedProjectVar<P, F, CF> and let Projective<P, F> = GeneralizedProjectVar<P, F, <P::BaseField as Field>::BasePrimeField>. This is not favored since nonnative field is not important to this level.

Proposal

We need to think about what would be the best way to do this.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@weikengchen weikengchen added D-hard Difficulty: hard P-low Priority: low T-design Type: discuss API design and/or research T-tracking Type: tracking issue labels Aug 28, 2022
@rubdos
Copy link

rubdos commented Jul 24, 2024

What about:

pub struct ProjectiveVar<
    P: SWModelParameters,
    F: FieldVar<P::BaseField, CF>,
    CF: PrimeField = <P::BaseField as Field>::BasePrimeField,
>  {
}

... would that not suffice here? I suppose that too will sit in the way quite often though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-hard Difficulty: hard P-low Priority: low T-design Type: discuss API design and/or research T-tracking Type: tracking issue
Projects
None yet
Development

No branches or pull requests

2 participants