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

feat: general extensions and documentation #58

Merged
merged 8 commits into from
May 10, 2024
Merged

Conversation

Autoparallel
Copy link
Contributor

This PR will close #55

@Autoparallel Autoparallel marked this pull request as ready for review May 10, 2024 19:46
use super::*;

// TODO: An empty struct like this and G2Curve is a code smell. We should probably
Copy link
Contributor

Choose a reason for hiding this comment

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

This was a design @thor314 had taken I believe from artworks? (correct me if I am wrong). I am okay thinking about a single struct too.

Copy link
Contributor Author

@Autoparallel Autoparallel May 10, 2024

Choose a reason for hiding this comment

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

You could at least do a single struct like

struct CurveGroup<F: FiniteField> {
    _phantom: F,
}

This way you can just use one struct and define it over whatever field you'd like.

I think there's probably something even nicer we could do to better utilize the Curve as we have as of now.

}
}

// TODO: This should likely use a `Self::ScalarField` instead of `u32`.
Copy link
Contributor

Choose a reason for hiding this comment

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

not sure I see why? Scaler mult should work for any number (point can be doubled any amount of times), in the field or not. if we constrain the type here what does it give us? It seems like it would make the interface harder. I am down to turn it into the scalar field under the hood here, but that seems like an optimization

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My thought is that we should define a ScalarField for the curve anyway because we will eventually need access to this. It's a bit odd to multiply by a number that isn't in the scalar field of a curve, it's not really very intuitive to think about it that way to me at least since you should reduce mod SCALAR_FIELD_ORDER prior to computing it.

Copy link
Contributor

Choose a reason for hiding this comment

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

As far as i understand all elliptic curve points should be able to be multiplied by an arbitrarily large number. (under the hood this is just point doubling and point addition). No it's clear that it might be redundant to do so (especially if it is bigger than the scaler field order like you point out). But i think the interface should take any number and just abstractly mod the scaler order under the hood before point doubling. That just feels like a more flexible interface to me. But also i don't mind changing it since this is for learning.

Copy link
Contributor

@0xJepsen 0xJepsen left a comment

Choose a reason for hiding this comment

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

Looks nice, a clean abstraction for the extension field!

@0xJepsen 0xJepsen merged commit 7145ba3 into main May 10, 2024
4 checks passed
@Autoparallel Autoparallel deleted the feat/general-extensions branch May 10, 2024 20:32
@github-actions github-actions bot mentioned this pull request Jul 1, 2024
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.

feat: general extensions via polynomial division
2 participants