EIP-2537 (BLS12 precompile) discussion thread

EIPs
, ,
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.

42

I understand there are no champions for the eip, but the situation is really bad. The operations are already present in consensus-layer clients, running on every node.

Right now, all zk apps are using bn254, which has terrible security level - much less than 128 bits.

At some point it would be, or already is - possible to forge proofs for such protocols.

Developing zk apps takes longer when compared to ordinary contracts, which means the sooner this is deployed, the better. Apps, especially ones without ownership, would not be able to easily upgrade from bn.

1 Like
43

Oh, sad. It seems another chicken-and-egg problem for requesting a precompile!

It seems a pattern that whenever a precompile is proposed, there will be a lot of debate about whether there is likely to be a lot of usage. The chicken-and-egg nature is that without deploying the precompile, we can’t calculate the adoption, and without the adoption, it’s hard to argue for making it a precompile and thus lack of interest

Good news, we are propose to have a “progressive path towards precompiles”, where author proposes a precompile, but instead of requiring it to be deployed as precompile first, they deploy a precompile candidate which is a traditional smart contract (with higher gas cost per operation, though), and see if there is usage. Once the usage is validated, the data can be used to (1) justify the need for such precompile, and (2) serve as call pattern to help client implementor tune performance

See more Progressive precompiles via CREATE2 shadowing

44

I don’t think BLS pairings can be implemented in pure solidity. They’re very heavy.

45

Has anyone evaluated the gas used if using solidity to impl BLS?

46

Just the G1 neg will use about 4956 gas, you can image the pairing will use how many gas.

47

I can see that the EIP needs a champion to take it through, hate to ask the obvious but do any of the original EIP authors intend to take on that role (courtesy ping to @shamatar @ralexstokes), failing that, could we have a long-standing community member take on that role (maybe @axic @matt @maxsam4), failing that, I would be happy to take on that role.

48

hi @QEDK ! I intend to push for inclusion of this EIP in the next hard fork after dencun

the core dev process hasn’t really focused on planning this next hard fork yet so there hasn’t been much activity as we all focus on the deneb/cancun EIPs

2 Likes
49

that’s great to hear, hopefully we can get this included in the fork after Dencun! Let me (or us at Avail) know if we can help speed up the process. :smile:

50

I just Implemented a KZG poly-commit to replace a Merkle Tree system though the interpolation, commitment, and proof generation were done in Rust, coming to write the verification contract now and just seeing this precompile has not been included yet :disappointed: