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

Make opaque Scalar conversions explicit rather than using From/Into trait. #228

Open
3 tasks
JayWhite2357 opened this issue Oct 7, 2024 · 3 comments
Open
3 tasks
Labels
💎 Bounty good first issue Good for newcomers refactor Code cleanup or reorganization

Comments

@JayWhite2357
Copy link
Contributor

JayWhite2357 commented Oct 7, 2024

Background and Motivation

Currently, the Scalar trait requires various conversions using the From and Into traits. Some of these are confusing, while others are clear.
In general, the rule should be that for types with a natural embedding into the associated Scalar field, Scalar should implement From. In all other cases, the conversion should either be auto-implemented, or a trait method, where appropriate.

NOTE: The following issue also necessitates changes to Scalar, so be aware of potential merge conflicts:
#234

Changes Required

Each of these should be a separate PR.

  • Remove Into<[u64; 4]>, From<[u64; 4]>, and RefInto<[u64; 4]> bounds.
    • Replace these with the trait methods fn from_limbs(val: [u64; 4]) -> Self and fn to_limbs(&self) -> [u64; 4]
    • These three conversions are the base conversions that are used for many other conversions. A Scalar is a field element (number mod some prime) with slightly less than 256 bits. Usually, Scalars are internally stored in Montgomery form, so these conversions are non-free. However, they are needed in some situations.
  • Remove From<&'a String>, From<String>, and From<&'a str> bounds. These three implementations ultimately rely on the conversions to and from limbs. As a result, these should have blanket/default implementations.
    • Replace these with fn from_str_via_hash(val: &str) -> Self and add a default implementation.
    • While it would be nice to impl<S: Scalar> From<String> for S, this is not allowed by the Rust type system. Solutions other than the default implementation of a trait method are welcome.
    • This conversion requires that the string is hashed in order to convert it to 256 bits which are ultimately converted into the Scalar itself. This is different from a parsing method.
  • Remove the VarInt bound and replace it with a blanket impl<S: Scalar> VarInt for S implementation. The existing (and requested) implementation relies on the limb conversions only.
@JayWhite2357
Copy link
Contributor Author

JayWhite2357 commented Oct 7, 2024

/bounty $100

Copy link

algora-pbc bot commented Oct 7, 2024

💎 $100 bounty • Space and Time

Steps to solve:

  1. Start working: (Optional) Comment /attempt #228 with your implementation plan. Note: we will only assign an issue if you include an implementation plan with a time estimate. Additionally, to be assigned an issue, you must have previously contributed to the project. You can still work on an issue and submit a PR without being assigned.
  2. Submit work: Create a pull request including /claim #228 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to spaceandtimelabs/sxt-proof-of-sql!

Add a bountyShare on socials

Attempt Started (GMT+0) Solution
🟢 @b4s36t4 Oct 9, 2024, 5:27:42 AM WIP
🟢 @varshith257 Oct 13, 2024, 7:36:07 AM WIP

@spaceandtimelabs spaceandtimelabs deleted a comment from algora-pbc bot Oct 7, 2024
@spaceandtimelabs spaceandtimelabs deleted a comment from algora-pbc bot Oct 7, 2024
@spaceandtimelabs spaceandtimelabs deleted a comment from algora-pbc bot Oct 7, 2024
This was referenced Oct 7, 2024
@JayWhite2357 JayWhite2357 added enhancement New feature or request good first issue Good for newcomers refactor Code cleanup or reorganization and removed enhancement New feature or request labels Oct 8, 2024
@varshith257
Copy link
Contributor

varshith257 commented Oct 13, 2024

/attempt #228

Algora profile Completed bounties Tech Active attempts Options
@varshith257 15 bounties from 7 projects
Go, TypeScript,
Scala & more
﹟232
Cancel attempt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💎 Bounty good first issue Good for newcomers refactor Code cleanup or reorganization
Projects
None yet
Development

No branches or pull requests

2 participants