Hello @jochem-brouwer
A PR with the clarification and explicit formulas for variable length cases is pending the bot approval at the moment, but you can still access the document here.
Sincerely, Alexander
1 Like
Thanks Alexander for the update!
I have a question about the encoding of Fp points. Sorry for my ignorance about this. Is the only check necessary for a Fp point to be on the curve that it is strictly less than the base field modulus? (I.e. < 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab).
Does the same apply for Fp2 points (c0 is less than the base field modulus)? Is there any requirement for the c1 point of Fp2?
Kind regards,
Jochem
Field elements (either Fp or Fp2) in pairs for the affine coordinates (x, y) of the curve point. They must satisfy the equation like y^2 = x^3 + b for the BLS12-381 curve (b coefficient can be found in the EIP itself). Then point is “on curve” and this check is always performed during deserialization. c0 and c1 elements of Fp2 element are just Fp elements, so all corresponding encoding rules apply.
The input to the mapToG1 precompile takes 64 bytes (top 16 bytes are zero). This is a single number. I don’t see how I can then check if they satisfy that equation? Shouldn’t this strictly less check as mentioned before be the sole check?
mapToG1 takes as an input a single Fp element (not a curve point) and outputs a valid curve point. So the only check here is that input element must be “in the field” (properly encoded).
Hey @shamatar, I just had a discussion with @MariusVanDerWijden on discord about this particular test.
Geth currently outputs a zero point of this multiexp call. However, to me it seems that per the EIP, these zero points are “not on curve” and thus should throw an error instead of returning the zero point (infinity point (?)) as output. See the pic below from the EIP which is the part which confuses me. Should thus the precompile yield an output and thus make the call succeed (current implementation) or should it throw? I think by the EIP it should throw?
Hey @jochem-brouwer
Well, it’s only a wording problem, that’s why I’ve called it “convention”. On BLS12-381 point of infinity is “virtual”, in a sense that there is no point O with some coordinates (x,y) that is on curve and that for any point P one has P + O = P. Do achieve necessary functionality nevertheless this EIP follows the BN254 one where “point of infinity” is encoded as (0,0) for both input and output purposes (it’s not that hardly needed for inputs cause it can be filtered out in Solidity if really necessary, but valid outputs can be points of infinity).
1 Like
Both this EIP and the existing BN254 precompile only allow performing pairing checks, not evaluations (get the result C = e(A, B) for further processing). What’s the reason for this?
It’s kind of no point to output Gt (Fp12) element in plain text we also don’t give the Fp12 arithmetic operations. But such addition would make this (already quite large) proposal really enormous.
1 Like
I’m interested in seeing this proposal move forward, and I’m rather new to the community. Right now it is listed as stagnant despite being implemented in go-ethereum.
1 Like
me (and many others) are also interested in BLS precompiles in the EVM!
we made a lot of good progress but there was some hesitation around this EIP as it adds a lot of very complex functionality to the EVM (in the form of BLS arithmetic) and it wasn’t super clear at the time it delivered enough value to justify going into a crowded upgrade schedule.
so activity around it has slowed and we are in a bit of limbo as development resources at the moment are nearly exclusively focused on the merge.
this EIP could conceivably go into the upcoming execution layer upgrade Shanghai but this will likely be the second half of 2022 at the earliest. this being said it facilitates a lot of use cases around scaling rollups with sharding so should become very important very quickly once we deploy the merge.
it is on my personal bucket list to track post-merge so hopefully we see BLS precompiles sometime soon 
edit: may see some progress here: Proposal to add EIP-2537 (BLS Precompile) to Shanghai · Issue #343 · ethereum/pm · GitHub
3 Likes
We have been waiting for this for sooo long … It is amazing it is taking so much time.
patience is rewarded
2 Likes
Quick update in May 2022:
Summary: The implementation of EIP-2537 has been completed and is now in go-ethereum codebase— it is only pending activation of this functionality.
Next steps: Enable the precompiles by editing /core/vm/contracts.go, similar to what is done for Byzantine/Istanbul/Berlin:
- Create a new default set of pre-compiled Ethereum contracts used in the next release, including the new precompiles of EIP-2537.
- Modify init() and ActivePrecompiles() functions to activate the new precompiles.
Other points to mention: There exist another implementation that is marginally more performant regards to gas consumption and running time (blst utilizing wasm). But the workload to move on to the other implementation is high and discarding the past hard work is unworthy.
1 Like
Does this EIP also add support for hash to curve operations used for BLS signatures? Specifically those used on the beacon chain…
Sure! Done now
Need 20 symbols…
2 Likes
so what is the result? it’s not included in shanghai?
we will discuss on the next ACD if there is time
there is a lot to squeeze into Shanghai so keep that in mind – many pieces to prioritize and everything needs to take its own time to get to mainnet
3 Likes