Add BLS Elliptic Curve support in Cryptol #14
Conversation
This will be needed for the `bls_modular_inverse` function.
These two functions are hardcoded to work for the BLS_MODULUS. There is currently no need to abstract them further. These functions match the implementations found in the Python specs: - https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#bls_modular_inverse - https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#div
See https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#compute_powers Note that because of the way Cryptol's type system and comprehensions work, we need to have the type constrain of `n >= 2`, whereas the Python spec only constrains `n >= 0`.
We need to use a GCD algorithm because Cryptol cannot perform expoentiation with negative exponents. This means we have an error in the BlsHelpers::bls_modular_inverse function. I'll fix that next.
Have bls_modular_inverse and bls_div call the corresponding utility functions with the hardcoded BLS_MODULUS. This fixes the previous error in the bls_modular_inverse function. This error was uncaught because the unit tests were wrong. The unit tests have now been confirmed with the following site: https://planetcalc.com/3298/
I switched the API to use the Integer type for these utility functions because it simplifies the code. The BlsHelper functions that call these utility functions have been updated and now handle the conversion of types (Integral <=> Integer) internally. This also exposed an error in the modular_inverse when a negative number was passed. A new test has been added to make sure we don't regress.
These were redundant and missed during the previous commit redesign of types.
And add note to the BlsHelpers::bls_modular_inverse about the inability to use pow and why that code now looks different than the Python spec.
These are needed as the building blocks as we start to implement the rest of the Deneb Python spec.
There was a problem hiding this comment.
I've only partly reviewed this but I'm going to give some feedback now since I think you started getting similar feedback in a separate channel.
I'm seeing some mixing of types that I think is introducing more potential bugs than you need. Some code uses bit vectors (integers mod 2^n for the width n), but they are actually holding integers mod p for p =\= 2^n, and also in other places they are converted to Integers.
Unless you are trying to do produce highly optimized implementations of these functions that minimize memory usage or something, I think you are better off using the Z type to represent your numbers. I've flagged several overflow concerns; these will all be handled by Cryptol if you use Z. The EC implementation in cryptol-specs uses that type if you would like to see it in practice.
Thanks for pointing out the |
Add the elliptic curve operations needed to continue to implement the Deneb Python spec BLS helper functions.
(Note for reviewers: I've made an effort to make this PR more easily reviewed on a per-commit basis. Hope this helps).