Olga Kunyavskaya

> * The functions `bls12381_g{1,2}_sum` should take a list of (point, sign) pairs, similar to the existing API for alt_bn128. This will allow to negate points without having to pay...

> * For functions taking an array, empty input should not be an error, as there is a well-defined result for this case. fixed: https://github.com/near/NEPs/pull/488/commits/55f9d993a7913c57b84c2657ccfcc549022d6a89

> * The specification should be self-contained. In particular, the description of the mapping of field elements to points should be included, instead of linking to EIP-2537. fixed: https://github.com/near/NEPs/pull/488/commits/a24a22671abe312f867d284ee7a390149a22e070

> * Math and code formatting should be used consistently. I propose to use math formatting for all mathematical things (such as constants and formulas), and use code formatting for...

> * There are multiple smaller issues with language and style, which should be fixed after the bigger issues. Things like incorrect use of vocabulary ("wildly used"), incorrect spacing (no...

@abacabadabacaba @frol @mfornet @birchmd All comments are addressed and PR is ready for rereview.

> thanks for providing and update. I also agree that it is not possible to sensibly review this PR within 24hrs. To add some more context, we are also in...

> 1. Currently, the functions return an error if any input is invalid. This is problematic, because checking whether the input is valid is difficult, in some cases about as...

> 2. Currently, the functions `bls12381_map_fp_to_g{1,2}` require the input elements to be already reduced modulo p. But when checking a BLS signature, the input to those functions is a hash,...

> Overall, the motivation seems reasonable to me. I think the specification is, this time, _too_ detailed: re-explaining what subgroups and order are should be in the mathematical spec for...