ethereum
Add support for BLS12-381 curve operations (EIP-2537)
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.
implementations exist in py_ecc however, i expect that to be unaffordably slow in the context of chain processing in block time.
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.
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...
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
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....
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.
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.
Looks like #1933 has some steps toward BLS support, though that seems to not be in the Berlin roadmap anymore.
