EIP-2537 (BLS12 precompile) discussion thread

EIPs EIPs core
, ,
21

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:

  1. Create a new default set of pre-compiled Ethereum contracts used in the next release, including the new precompiles of EIP-2537.
  2. 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
23

Does this EIP also add support for hash to curve operations used for BLS signatures? Specifically those used on the beacon chain…

24

@shamatar I think this EIP should be tagged with #shanghai-candidate?

25

Sure! Done now

Need 20 symbols…

2 Likes
26

so what is the result? it’s not included in shanghai?

27

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
28

Hey guys. This pre-compile is really important and under-rated. If it can be discussed on ACD that would be amazing. Thanks so much

1 Like
29

Any effort to prioritize this EIP in the Shanghai would be greatly appreciated. I believe this would benefit a lot of protocols since a lot of data relating to consensus layer would be verifiable on-chain.

1 Like
30

@vethereum @JustinZal thanks for chiming in, adding your support here makes community demand for this EIP more legible and is helpful when client developers are prioritizing what to include in Ethereum upgrades.

we didn’t have time on yesterday’s ACD but it is on the agenda for the next one

1 Like
31

@vethereum @JustinZal While the BLS precompile would make verifying data relating to the consensus layer easier, my team and I at Succinct have actually been able to get around this by verifying BLS signatures inside a zkSNARK and then verifying that proof on-chain.

Using this technique, we have created a gas-efficient trust-minimized light client for Ethereum which can be deployed on any execution layer that supports the BN254 curve (Proof of Consensus Bridging between Ethereum and Gnosis Chain | Succinct Labs Blog).

Inside our smart contract, we have a zkBLSVerify function which can be called to emulate the BLS precompile. The tradeoff is that a proof must be generated off-chain (< 2 minutes). The function below is taken from our smart contract (code here), so it’s specific to our use case, but it can very easily be generalized to any other application that requires the precompile.

function zkBLSVerify(bytes32 signingRoot, bytes32 syncCommitteeRoot, uint256 claimedParticipation, Groth16Proof memory proof) internal view returns (bool) {
        require(sszToPoseidon[syncCommitteeRoot] != 0, "Must map SSZ commitment to Posedion commitment");
        uint256[34] memory inputs;
        inputs[0] = claimedParticipation;
        inputs[1] = uint256(sszToPoseidon[syncCommitteeRoot]);
        uint256 signingRootNumeric = uint256(signingRoot);
        for (uint256 i = 0; i < 32; i++) {
            inputs[(32 - 1 - i) + 2] = signingRootNumeric % 2 ** 8;
            signingRootNumeric = signingRootNumeric / 2**8;
        }
        return verifySignatureProof(proof.a, proof.b, proof.c, inputs);
    }

If the BLS precompile is a blocker for an exciting application you have in mind, please let us know and we would be happy to help out (just email us at hello@succinct.xyz).

5 Likes
32

Agreed with @jtguibas. Without a precompile contract for BLS curve, verifying the signature can be difficult. By the way, when we talk about BLS signature, it is BLS12-381 BLS signatures right? (The two BLS are different).

33

I assume at this point, it’s safe to assume that this will not be a part of the Shanghai upgrade? :sweat_smile:

34

Yes, safe to assume at this point.

35

I was wondering if there is a motivation for not including compression/decompression in the EIP? Is it because providing uncompressed elements is cheaper at 16 gas/byte?

In that case, it may be that we need to reconsider this as for rollups this ratio will be different and data will be much more expensive as compared to computation. Since the desire of many rollups is to stay as close as possible to Ethereum L1, maybe we should add precompiles for decompression?

36

The reason to not include decompression is indeed the cost (on L1 ). There was already large scope in this EIP and so G1 and G2 decompressions were skipped.

37

Does anyone have an idea when this EIP can move to next stage? Do you think we can have BLS precompiles in 2023?

4 Likes
38

Excited for this to get into a hardfork soon!

39

It will not be in a 2023 hard fork. No one on an ACD call was there to champion it during late scoping calls.

40

Late to the party, but I’d like to express interest in the BLS12-381 precompiles for a variety of use cases it could open up on-chain:

  • registration of distributed validators
  • consumption and verification of drand randomness beacons on-chain (a threshold network for generating randomness, an alternative to RANDAO)
  • identity-based decryption (such as timelock decryption)

As another commenter noted, it would be amazing to have hash to curve and hash to field implemented as well.

41

What’s the path to get this activated?

Also very interested in its use to utilize drand beacons onchain.