Add swig bindings for field element mapping to G1 and G2

[garyschulte]

In trying to use jblst (and therefore blst) for EIP-2537 implementation in Hyperledger Besu's besu-native project, I found that blst_map_to_g1 and blst_map_to_g2 were not exposed via SWIG.

I suspect there was a reason that these functions were left out of the swig bindings, but I don't know why. To get a complete implementation, I added them (disclaimer: not a C programmer nor familiar with SWIG).

Using BLST java bindings is the fastest implementation we have tested, so we are motivated to use it as the basis for EIp-2537 in besu. I did verify that java python and rust bindings still build correctly, but only tested Java bindings.

If this should go in blst_aux.h or elsewhere, or if there is another way to map field elements without adding these methods to the interface, LMK. TIA

[dot-asm]

I suspect there was a reason that these functions were left out of the swig bindings, but I don't know why.

Field types are not exposed though the SWIG interface, only EC points and fp12. Or in more practical terms the application code has no way of constructing arguments for the blst_map_to_g{1,2}. Which is why they are masked with #ifndef SWIG. But note that the #ifndef in question controls whether or not masked interfaces will be available on the application side of the SWIG interface, but not whether or not one can invoke them from the glue C++ code. In other words you didn't need to remove the #ifndef SWIG in blst.h in order to call them from blst.hpp.

EIP-2537

Then wouldn't it be appropriate to accommodate it with a method that consumes and produces data in the corresponding format? The thing about most of the bindings is that less transitions between languages are better. So why not something like static void eip2537_map_to(byte out[128], const byte u[64]), which in Java (and others) would look as x = P1.eip2537_map_to(u);. Well, this asks for a question why not accommodate remaining primitives, which would be a somewhat larger project than a normal support issue... Maybe we can compromise and limit the scope to adding EIP-2537-specific serialization and deserialization... To summarize, I'd suggest to close this request and open an issue instead to hash out the goal first, before moving on to implementing things.

[garyschulte]

Thx for the explanation. Closing this, and weighing the options of opening an issue asking for 2537 specific serialization/deserialization versus just implementing a c-wrapper in besu-native to call blst.

Other operations like MultExpr currently require considerable back and forth that would be nice to limit as well.

[dot-asm]

Other operations like MultExpr currently require considerable back and forth that would be nice to limit as well.

Let's take it step by step, smaller steps first :-)

[dot-asm]

Have a look at #223 as an initial step.