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

[JayWhite2357]

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]

/bounty $100

[algora-pbc]

💎 $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 bounty • Share 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
🟢 @maujim	Nov 4, 2024, 5:20:18 AM	#335

[varshith257]

/attempt #228

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

[maujim]

/attempt #228

Options

• Cancel my attempt

[algora-pbc]

💡 @maujim submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[maujim]

@JayWhite2357 can you please take a look at the liked PR?