Skip to content

Refactoring field serialization#179

Closed
davidnevadoc wants to merge 3 commits into
mainfrom
nev@refactor-serde
Closed

Refactoring field serialization#179
davidnevadoc wants to merge 3 commits into
mainfrom
nev@refactor-serde

Conversation

@davidnevadoc

@davidnevadoc davidnevadoc commented Oct 28, 2024

Copy link
Copy Markdown
Collaborator

This PR aims to:

  1. Fix the issue with is_less_than_modulus (Misuse of is_less_than_modulus #178)
  2. Improve / Introduce some clarity around SerdeObject and from_raw. [Still WIP] (Serialization #176)

is_less_than_modulus bug.

This issue was solved by simply removing the check from the SerdeObject functions: from_raw_bytes and read_raw.
This change makes the functions virtually identical to their _unchecked versions. I believe this is fine, as the design still makes sense for curve points, where there are other checks involved.
I haven't found a way to keep the check while maintaining the purpose of this interface, which is speed. I'm not sure if there is a way of checking if a value in Montgomery-form lies in the appropriate range w/o performing a Montgomery reduction or any other operation of similar cost.

Simplify SerdeObject and FromUniformBytes.

I've introduced the utility u64s_from_bytes, to facilitate transforming bytes into limbs. It is a minor change but I think it reduces boilerplate and improves readability.

from_raw [WIP]

Still working on a satisfactory solution for this function. Some possibilities are:

  • Remove pasta curves ( would be in line with Remove IPA / Part1 halo2#377 )
  • Simply document it with an emphasis on the fact that _raw here is canonical and not internal representation like in SerdeObject.

Other options have been tried ( exposing functionality through new trait, renaming... ) without success. The roots of the problems are:

  • Can't have const fn in traits.
  • Can't keep compatibility with pasta_curves without modifying them.

This commit introduces 2 changes:
 - Simplification of SerdeObject methods by using
   the aux function: u64s_from_bytes
 - Removal of [0, p-1] check in all versions, including
   _checked methods.
   (This should only be re-added if there is a method
   of performing such check in Montgomery-form directly).
@davidnevadoc

Copy link
Copy Markdown
Collaborator Author

Marking this as ready, since I haven't found a solution for the from_raw issue that can be implemented right away. IMO the best solution should be to get rid of pasta curves and rename appropriately. However, this involves moving the CurveAffine trait to remove the dependency completely and should be done in a separate PR. cc @adria0

@davidnevadoc davidnevadoc marked this pull request as ready for review November 13, 2024 10:23
@adria0 adria0 self-requested a review November 13, 2024 15:35
Comment thread derive/src/field/mod.rs
}
let elt = Self::from_raw_bytes_unchecked(bytes);
Self::is_less_than_modulus(&elt.0).then(|| elt)
Some(Self::from_raw_bytes_unchecked(bytes))

@adria0 adria0 Nov 13, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@davidnevadoc, so now from_raw_bytes_unchecked and from_raw_bytes is the same?
Then from_raw_bytes(&[0u8;#size]) and from_raw_bytes(&[255u8;#size]) will become a valid point.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Oh, I made a mistake while reading how the arithmetic in Montgomery form works. I believed that the Montgomery form of an element didn't necessarily have to be in the [0, p-1] range. But it does in order to have an efficient reduction after the multiplication.
The issue I opened is wrong then. I will re-introduce the check (for the checked version of course).
Without that change, this PR doesn't make much sense, since it just has some nits. Let's keep it on hold until we have all the planned changes to serialization and put them all together in a single PR.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Oh, I made a mistake while reading how the arithmetic in Montgomery form works. I believed that the Montgomery form of an element didn't necessarily have to be in the [0, p-1] range. But it does in order to have an efficient reduction after the multiplication.
The issue I opened is wrong then. I will re-introduce the check (for the checked version of course).
Without that change, this PR doesn't make much sense, since it just has some nits. Let's keep it on hold until we have all the planned changes to serialization and put them all together in a single PR.
For example, the docs added in #177

@adria0 adria0 mentioned this pull request Nov 13, 2024
@davidnevadoc davidnevadoc marked this pull request as draft November 15, 2024 05:00
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.

2 participants