@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).