Add interface for bls12-381

[perturbing]

Hello Aiken stdlib maintainers,

I'm excited to submit my first pull request, which introduces a new BLS12-381 interface to the Aiken standard library!

As a summary, I propose to add three new submodules, all under the umbrella module bls12_381. These are:

• g1.ak: A simple interface for basic operations on G1 elements derived from builtin functions.
• g2.ak: A simple interface for basic operations on G2 elements derived from builtin functions.
• scalar.ak: An interface that implements the bls12-381 scalar field over the integers.

I have one remark on the scalar field. Currently, taking an exponential in plutus is costly. Which means that the operations, like scale/recip/div in this module, are very costly onchain, I still added these functions for completeness.

That said, most proof systems do use an exponent, but can rely on a little trick. That is, for scalar^n we can fix in our protocol that n=2^k for some k. Which means that we can reduce the complexity of the tree created in the repeated squaring method. I called this function pow_of_two.

Feel free to change any naming in this lib as you like to better fit the rest (I tried my best in following your standards).

[rvcas]

This looks super solid to me, I think @MicroProofs has some questions about Scalar

[rvcas]

We haven't forgotten this PR we're just putting merging it on hold until we decide how to handle the PlutusV3 script context changes.

[perturbing]

Sounds good, no rush :)

[logicalmechanism]

I wanted to comment on this as I have been working with BLS12381 a lot now in anticipation of V3.

Would be a good idea to add in a equals function that wraps around, builtin.bls12_381_g1_equal(left,right) and builtin.bls12_381_g2_equal(left,right).

Consider changing how scaler works all together. Very rarely do you ever want to be working with the integer type when building BLS encrpytion algorithms. The limitation of the datum int type at 2^64-1 is too small and not secure. It is very common to use bytearrays and do a conversion, let number: Int = builtin.bytearray_to_integer(True, number_bytearray). Then we are not limited by the integer size when a redeemer or datum needs to carry an integer type.

An example of this use case is given in my seed elf wallet implementation using a variation of a Schnorr signature.

Having these functions from this PR in the stdlib is really going to help avoiding mixing between stdlib and builtin calls.

With these addtions from this PR I will be implementing some BLS specific additions to the Assist library, specifically implementing all the algorithms from Registry type.

[perturbing]

HI @logicalmechanism , thank you for the review!

Would be a good idea to add in a equals function that wraps around, builtin.bls12_381_g1_equal(left,right) and builtin.bls12_381_g2_equal(left,right).

I added them :)

Consider changing how scaler works all together. Very rarely do you ever want to be working with the integer type when building BLS encrpytion algorithms. The limitation of the datum int type at 2^64-1 is too small and not secure. It is very common to use bytearrays and do a conversion, let number: Int = builtin.bytearray_to_integer(True, number_bytearray). Then we are not limited by the integer size when a redeemer or datum needs to carry an integer type.

I disagree that this would be a better interface as the low level operations always work over the integers (as you cannot add byte strings as integers in plutus yet (see bitwise primitives)), but how about I add a function scalar.add_from_bs and the reverse?

@rvcas , can you please consider from a UI perspective if I named all function properly?