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

[DISCUSSION] Library Upgrade - Part 2 #64

Open
Bhargavasomu opened this issue Mar 16, 2019 · 3 comments
Open

[DISCUSSION] Library Upgrade - Part 2 #64

Bhargavasomu opened this issue Mar 16, 2019 · 3 comments

Comments

@Bhargavasomu
Copy link
Contributor

What is wrong?

The first part of the upgrade is over, where the fields used by different curves were generalized into the fields API. Regarding the 2nd part of the upgrade, this is what I had in mind.

  • Remove different modules for the different curves (bn128, bls12_381, optimized_bn128, optimized_bls12_381) and generalize it into the curves API.
  • In the curves API, all the common functionalities amongst all the above mentioned curves go into the class BaseCurve and class OptimizedBaseCurve. And the respective curves would inherit these base classes.
  • All the non-common functionalities go into each subcurve implementation.
  • We could then create an object of each of the curve, and place it in __init__.py so that users can directly import the respective curve object.
  • This could be considered as a Breaking API for the following reason. There are 2 scenarios regarding how the users import and use this library.

Scenario 1

from py_ecc import bn128
...
...
a = bn128.G1  # Some operation involving G1
b = bn128.G2  # Some operation involving G2
c = bn128.is_on_curve  # Some operation involving is_on_curve function
...
...

Scenario 2

from py_ecc.bn128 import (
    G1,
    G2,
    Z1,
    Z2,
   is_on_curve,
   ...
   ...
)
...
...
a = G1  # Some operation involving G1
b = G2  # Some operation involving G2
c = is_on_curve()  # Some operation involving is_on_curve function
...
...

Here, Scenario 1 won't be a breaking API, but Scenario 2 would be a breaking API for the further releases.

How can it be fixed

/cc @pipermerriam @carver @ChihChengLiang @hwwhww

@ChihChengLiang
Copy link
Contributor

The next step of BLS signature API is to rewrite some performance hot spots with Cython or gmp lib. How do these kinds of optimizations fit into the upgrade?

@carver
Copy link
Collaborator

carver commented Mar 18, 2019

My instinct is that it takes a while to even list all the breaking changes you might like to have in a major version upgrade. Since the performance bump is important and urgent (I'm assuming), we should just work on that first while we think about other breaking changes we might want to add to the list for v2.

@Bhargavasomu
Copy link
Contributor Author

Ok I will stall making progress on the part-2 of the upgrade process until the performance boost is done with.

pacrob pushed a commit to pacrob/py_ecc that referenced this issue Oct 29, 2023
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

3 participants