Add support for BLS12-381 curve operations (EIP-2537)

[cburgdorf]

What is wrong?

The EIP defines nine pre-compiles that Py-EVM currently does not support.

How can it be fixed

Need to dig into the EIP to find out how to add support for this.

[ralexstokes]

implementations exist in py_ecc however, i expect that to be unaffordably slow in the context of chain processing in block time.

[pipermerriam]

Would milagro-bls be the place to look? I recently figured out that the test runs I was doing in the eth2 codebase went from 7s per test to 0.1s per test when I got that optional dependency installed.

[ralexstokes]

anyone touching this issue should be aware there are two "BLS" (!)

One is a signature scheme and one is a particular elliptic curve. The signature crypto in eth2 uses the BLS signature scheme (that is efficiently aggregatable) on top of the BLS12-381 curve.

EIP-2537 adds precompiles for elliptic curve operations over BLS12-381. We have the curve and the signature algo in py_ecc.

As far as I can tell the curve ops are not exposed in the bindings we use (should be here: https://github.com/ChihChengLiang/milagro_bls_binding/blob/master/src/lib.rs#L146) but if poke thru to the underlying library, it looks like they could be. with some possible coordination w/ sigma prime who maintains the rust bindings...

[ralexstokes]

if we wanted a more direct binding, i believe these are accurate implementations of the precompiles in Rust: https://github.com/matter-labs/eip1962/blob/master/src/public_interface/eip2537/mod.rs

i can find a link to the bindings going into Geth as well if we want

[ralexstokes]

given how lightweight the wrapper looks in milagro_bls_binding, we possibly just make py-bindings over the above rust file? or at least start there -- we could quickly hit complicating dependencies....

[pipermerriam]

We historically made eth-keys to allow a backend agnostic way to do SECPK1 keys stuff agnostic of the implementation, allowing the slow pure-pythong or the fast but slightly harder to install implementations.

Without having any context on the actual code part, this pattern might be appropriate here as well. An eth-bls library that wraps py_ecc and milagro-bls as backends, unifying the API while allowing easy to install vs fast but slightly harder to install backends.

[ralexstokes]

Yep, we started w/ something in this direction here: https://github.com/ethereum/trinity/blob/master/eth2/_utils/bls/__init__.py

That module could definitely be clean up and factored out into a separate library if we think its worthwhile.

[carver]

Looks like #1933 has some steps toward BLS support, though that seems to not be in the Berlin roadmap anymore.