Update NEP-488(Precompile for BLS12-381 curve operations). Support addition and multiplication only for G1/G2 subgroup.

[olga24912]

In the original NEP-488, we supported addition and multiplication operations for any valid points on elliptic curves.

In this PR, I have restricted the input for bls_p1/p2_sum and bls_p1/p2_multiexp to elements from the G1/G2 subgroups only.

In all cases where we need these functions, support for elements from G1/G2 is sufficient. However, verifying that a point belongs to a subgroup is a costly operation, and users cannot ensure within a contract that a point is from G1/G2. By implementing this restriction, we can prevent certain errors.

Additionally, in the future, we will have more flexibility in choosing algorithms and libraries. If a library assumes that points are in the subgroup, we will be able to use it without issue.

[akhi3030]

@near/wg-protocol, @walnut-the-cat, @bowenwang1996: please take a look at this PR. We were doing a security audit of the original NEP and found this issue that we address here. The original NEP is not merged yet so we created another PR on top of the existing one. Please review and advise on how to move forward.

[abacabadabacaba]

What is the security impact of having sum and multiexp functions accept points outside of the G1/G2 subgroups?

[olga24912]

What is the security impact of having sum and multiexp functions accept points outside of the G1/G2 subgroups?

Not that there would be any serious security issues if we accepted any points as input.

And for the case in which I want to use these functions, I am completely confident that everything is fine. Because I can guarantee that the public keys are correct and belong to the necessary subgroup.

The main points:

1. The user has no good way to check within the contract whether a point belongs to the subgroup (well, by the way, if you pass one target point and zero into the pairing check, there might be a way...).
2. Theoretically, it might be possible to add several points not from G1 and get a point from G1. And then with incorrect data, the contract would work as if it were correct.
3. For a reasonable application of these functions, the points really should be from the subgroup. And I can't think of any cases where it would be reasonable to work with a point not from the subgroup. In other documents, such as EIP-2537, points from the subgroup are indeed used. Therefore, from a functional standpoint, it seems we are not losing anything.