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

Serialization example #188

Open
srinathsetty opened this issue Jan 7, 2025 · 2 comments
Open

Serialization example #188

srinathsetty opened this issue Jan 7, 2025 · 2 comments
Assignees

Comments

@srinathsetty
Copy link

I'm interested in serializing field elements in big-endian form and curve elements in uncompressed affine form. From looking at the latest code (https://github.com/privacy-scaling-explorations/halo2curves/blob/3bfa6562f0ddcbac941091ba3c7c9b6c322efac1/src/serde.rs#L1220 and

pub(crate) enum CompressedFlagConfig {
), both seem to be supported.

Do you have an example of how to specify these options with serde?

@davidnevadoc davidnevadoc self-assigned this Jan 9, 2025
@davidnevadoc
Copy link
Contributor

Unfortunately, these are note options for Serde. They are just options for the macros that derive the curves.
This means that you by selecting "little" o "big" in the endian field of the impl_field! macro, you select the behavior of the to_bytes and from_bytes methods. But there is no method that allows you to dynamically select the endianness.
The curve point serialization inherits the endianness of the base field.

To get an affine point in uncompressed affine form you can just use the methods in the UncompresssedEncoding trait:

  • from_uncompressed
  • from_uncompressed_unchecked
  • to_uncompressed

Some additional details on EC point serialization can be found in the description of this PR: #141

@srinathsetty
Copy link
Author

Hi @davidnevadoc, thanks for the response! This makes sense.

I wonder if this library is open to introduce a feature like "evm-compat", and when that feature is enabled, the field elements get serialized with big endian rather than the current default little endian format, and curve points are serialized in uncompressed form rather than compressed form in the current default.

Without this feature, upstream applications, with on-chain verification requirements, have two options: (1) use a hacky method to wrap types and control serialization (this is hard to maintain in the longer term), or (2) build field and curve implementations by directly invoking the macros provided by this library (this is again hard to maintain in the long term).

What do you think about adding a feature flag to control serialization?

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

No branches or pull requests

2 participants