ethereum / ethereum/py_ecc

Library refactor

Open
#31 11 comments 0 reactions 0 assignees View on GitHub
Good For Bounty
Dominant language
Python
Stars
231
Forks
88
PR merge metrics
No merged PRs in 30d

Description

By @Bhargavasomu from: https://github.com/ethereum/py_ecc/issues/24#issuecomment-442701351

The following things come to my mind.
* The classes `FQ`, `FQP`, `FQ2` and `FQ12` need not be reinitialized every time as they are not dependent on the type of curve or extension. So probably we could have these created in `field_elements.py` and we could use them everywhere (`bn128`, `optimized_bn128`, `bls`, `optimized_bls`).
* We could also have a general class `BaseCurve`, and then maybe every curve (`bn128_curve`, `optimized_bn128_curve`, ...) could inherit this and make the changes specific to the inherited class.
* We should probably move the constants into a seperate file (`constants.py`)
* We should also remove the assert statements which are not part of any function, but are part of the script in general, as shown
https://github.com/ethereum/py_ecc/blob/067a40261ad39526f6aa8bd69def7d6982993d13/py_ecc/bn128/bn128_pairing.py#L74-L83
* Also the type hinting should be further generalized wherever possible (in terms of removing redundant types; like `Optimized_FQPoint2D` could be replaced by `FQPoint2D`). Similary the type hinting should be carried out for the `bs12_381` and `optimized_bs12_381` submodules.

Also the only difference I see in all the curves is
* Difference in the constants such as `b`, `b2`, `b12`, `G2`, `G12` ...
* Difference in the `twist` function

@vbuterin are my facts right or am I missing anything.
@pipermerriam is the above design ok?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.