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

Enforce that Fr of Engine is the scalar for curve points #66

Merged
merged 1 commit into from
Nov 20, 2017

Conversation

ebfull
Copy link
Collaborator

@ebfull ebfull commented Nov 12, 2017

In bellman, I want to write:

pub struct Point<C: CurveProjective>(pub C);

impl<C: CurveProjective> Copy for Point<C> { }

impl<C: CurveProjective> Clone for Point<C> {
    fn clone(&self) -> Point<C> {
        *self
    }
}

impl<C: CurveProjective> Group<C::Engine> for Point<C> {
    fn group_zero() -> Self {
        Point(C::zero())
    }
    fn group_mul_assign(&mut self, by: &C::Scalar) {
        self.0.mul_assign(by.into_repr());
    }
    fn group_add_assign(&mut self, other: &Self) {
        self.0.add_assign(&other.0);
    }
    fn group_sub_assign(&mut self, other: &Self) {
        self.0.sub_assign(&other.0);
    }
}

However, this doesn't typecheck because the compiler cannot know that the Engine's Fr type (as dictated by the Group trait) is the same as the Scalar type of the CurveProjective point. This can be solved with a where bound over the trait (for now), but it is generally a good idea for this to be constrained in pairing.

@ebfull
Copy link
Collaborator Author

ebfull commented Nov 12, 2017

Actually, it can't be solved with a where bound yet in Rust. rust-lang/rust#20041

So, I think we need this in pairing.

@burdges
Copy link

burdges commented Nov 13, 2017

Amusingly, rustdoc itself already describes constraints like yours by an equality in the where clause.

Copy link
Collaborator

@daira daira left a comment

Choose a reason for hiding this comment

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

ACK

@ebfull
Copy link
Collaborator Author

ebfull commented Nov 20, 2017

@bmerge r+

@bmerge
Copy link
Collaborator

bmerge commented Nov 20, 2017

📌 Commit 471db6a has been approved by ebfull

@bmerge
Copy link
Collaborator

bmerge commented Nov 20, 2017

⌛ Testing commit 471db6a with merge 36ad8b6...

bmerge added a commit that referenced this pull request Nov 20, 2017
Enforce that Fr of Engine is the scalar for curve points

In bellman, I want to write:

```rust
pub struct Point<C: CurveProjective>(pub C);

impl<C: CurveProjective> Copy for Point<C> { }

impl<C: CurveProjective> Clone for Point<C> {
    fn clone(&self) -> Point<C> {
        *self
    }
}

impl<C: CurveProjective> Group<C::Engine> for Point<C> {
    fn group_zero() -> Self {
        Point(C::zero())
    }
    fn group_mul_assign(&mut self, by: &C::Scalar) {
        self.0.mul_assign(by.into_repr());
    }
    fn group_add_assign(&mut self, other: &Self) {
        self.0.add_assign(&other.0);
    }
    fn group_sub_assign(&mut self, other: &Self) {
        self.0.sub_assign(&other.0);
    }
}
```

However, this doesn't typecheck because the compiler cannot know that the `Engine`'s `Fr` type (as dictated by the `Group` trait) is the same as the `Scalar` type of the `CurveProjective` point. This can be solved with a where bound over the trait (for now), but it is generally a good idea for this to be constrained in `pairing`.
@bmerge
Copy link
Collaborator

bmerge commented Nov 20, 2017

☀️ Test successful - pairing-linux32-auto, pairing-linux64-auto, pairing-windows32msvc-auto, pairing-windows64msvc-auto
Approved by: ebfull
Pushing 36ad8b6 to master...

@bmerge bmerge merged commit 471db6a into master Nov 20, 2017
str4d pushed a commit that referenced this pull request Apr 30, 2020
str4d added a commit that referenced this pull request Aug 25, 2020
Block header parsing and transaction ID computation
@ebfull ebfull deleted the scalar-assoc branch September 8, 2020 21:53
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.

4 participants