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
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
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
@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
@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).
6 Likes
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).
I assume at this point, it’s safe to assume that this will not be a part of the Shanghai upgrade? 
Yes, safe to assume at this point.
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?
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.
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
Excited for this to get into a hardfork soon!
It will not be in a 2023 hard fork. No one on an ACD call was there to champion it during late scoping calls.
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.
What’s the path to get this activated?
Also very interested in its use to utilize drand beacons onchain.
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
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
I don’t think BLS pairings can be implemented in pure solidity. They’re very heavy.
1 Like
Has anyone evaluated the gas used if using solidity to impl BLS?