Optimisations for Hash to Curve
- Dominant language
- Python
- Stars
- 231
- Forks
- 88
- PR merge metrics
- No merged PRs in 30d
Description
### What is wrong?
Currently we use a 'constant' time hash to curve function.
It is possible to significantly increase speeds by removing the constant time requirements.
### How can it be fixed
The two key areas where speeds could be made are in `py_ecc/optimized_bls12_381/optimized_swu.py`:
* Returning when a solution is found in `sqrt_division_FQ2()`
* Stopping the loop in `optimized_swu_G2()` when either `success` or `success_2` is true.
Contributor guide
Research direction
Start in py_ecc/optimized_bls12_381/optimized_swu.py, focusing on sqrt_division_FQ2() and optimized_swu_G2(). Review how these functions currently handle success and success_2, then measure the hash-to-curve operations before and after the optimization. Done means the functions return earlier as described while preserving their existing curve-operation results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cryptography
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 42/100