I’m asking this for clarity. As far as I understand, the structure in Kobi Gurkan’s article does not need eip-2537. For this reason, is it not suitable to be used for a bridge? I don’t quite understand the answer to this.
I apologise for the delay in answering this. Efficiency improvements to BLS signatures verification, regarding either individual signatures or aggregated signatures, are suitable and indeed may help signature aggregators and light client verifiers for bridges as formally described here and summarised here. We (the research team at Web3 Foundation) have been working on such improvements for a while and very recently we have published this formal pre-print. For more details, I have started a new thread with a summary description of our work here.
At the moment, compared to Kobi’s initial post, our proposed scheme benefits from more efficient verification for individual signatures as in our case we avoid expensive pairing operations. Additionally, we have a formal security model and a formal security proof. We are already working on more benchmarks and comparisons regarding implementation that we will include/publish soon and we are also planning further improvements regarding the verification for the proofs-of-possession that accompany public keys.
Good work, but I have to ask because the issue is related to Ethereum bridge, why is BN254 curve not used? For the Polkadot - Kusama bridge, anything is possible, but when it comes to Ethereum, as with BEEFY, choices should be made according to Ethereum.
In my understanding (with the disclaimer that my research has not directly involved bridges to Ethereum yet), there are two reasons why we could not/did not implement our research using BN254 curve:
First, in order to design/implement the bridge with the ultra light client we described here (that, among other things, makes use of very efficient SNARKs) we needed 2 curves: the one that contains the public keys (on which the BLS related operations are performed) and a second curve on which the SNARK proofs are computed. This construction works only if the base field of the first curve equals the scalar field of the second curve. A pair of elliptic curves with such a property is known as a “pairing friendly chain of elliptic curves”. Now, if we choose BN254 as the first curve, no one yet knows (or, at least I am not aware of) a second curve to complete the pairing friendly chain. Even if such a curve is discovered right away, adding the corresponding precompiles to its operations on Ethereum will take a long time.
The second reason why we decided to move away from BN254 is because this curve is regarded by some not to provide enough security: It is considered (see here and here) that BN254 provides around 100 bits of computational security and, at least some practitioners, regard this as not enough. So, as far as I understand, for those that work inside the Ethereum ecosystem and need EVM/on-chain verification and pairings (and hence, fast precompiles) they cannot move away yet from BN254, but, when building secure bridges, finding either alternative curves or alternative constructions that rely more on statistics is recommended.
I hope this makes some sense and answers your question. If not, hopefully my colleagues working on the Polkadot-Ethereum bridge research project would be able to help more.
I’m still a bit confused why not choose BLS12-381. I recently saw that the EIP-2537 has been added in Shanghai hardfork.
I’m still a bit confused why not choose BLS12-381. I recently saw that the EIP-2537 has been added in Shanghai hardfork
In general this thread has become a bit too unwieldy for productively discussing BLS, because we’ve ended up talking about 4-5 different kinds of light clients (BEEFY, ETH2, and SNARK variants of those), each with its own specific BLS curve requirements 
That said, it is certainly great to hear that BLS12-381 is going to be included in the Shanghai upgrade (ETA Sep 2023). However as Alistair mentioned, that doesn’t solve the problem of the gas cost of looking up and aggregating public keys for every signature verification.
On that point, I see Darwina has developed an ETH2 lightclient in Solidity, and optimized in such a way that the BLS public keys passed via calldata instead of being read from storage. I would be very interested to know the gas used to verify and aggregate those public keys, if you have those numbers on hand?
@Vincent Sorry for the late reply
I see Darwina has developed an ETH2 lightclient in Solidity, and optimized in such a way that the BLS public keys passed via calldata instead of being read from storage. I would be very interested to know the gas used to verify and aggregate those public keys, if you have those numbers on hand?
Yes, it is approximately 3M gas. You can see the contract in subscan:
I think everyone in this thread is already aware of this: Altair is no Light Client - by James Prestwich
Basically, Altair Ethereum light clients are not as secure as one would have hoped and seem unusable for light-client-based Ethereum bridges without significant modifications.
Would be great to get an assessment from Snowbridge and Darwinia on how this impacts their bridge security, whether they were aware of this issue, and what we do next.
Yeah we’re very aware of it and are researching the problem and possible mitigations. We also still need to do a proper economic and security analysis to see whether the concerns are warranted or not.
Assuming the mitigations are warranted, we’ve got some ideas at https://snowfork.notion.site/Beacon-Sync-Protocol-Sync-Committee-Exploitation-ec32d47ac6d94a9b9578d0427c18ea84
These mitigations increase fraud-resistance at the cost of censorship-resistance. However any censorship can easily be nullified by Polkadot governance if necessary. That’s a compromise we may have to make.
There are also other game-theoretic attacks on the Altair light client, besides those which James highlighted. For example long-range attacks. This latter problem is our current focus, which Clara is working on currently:
https://snowfork.notion.site/Light-Client-Attacks-999a0afb33a247b9971cfa746513cb02
To be clear though, we don’t see any of these game-theoretic attacks as critical flaws that invalidate our trustless bridging architecture. However it does obviously mean that final deployment will be delayed until we have the appropriate mitigations in place.
3 Likes
It’s not a great situation, but it’s also not a doomsday scenario either. I’ve outlined all the possible game theoretic attacks on light clients and their mitigations here: Trustless Bridging II: Byzantine Fault Tolerance
Data with holding attacks are the only thing the article doesn’t cover, but I’m exploring possible solutions in a final article of the trustless bridging series
3 Likes
First, in order to design/implement the bridge with the ultra light client we described here (that, among other things, makes use of very efficient SNARKs) we needed 2 curves: the one that contains the public keys (on which the BLS related operations are performed) and a second curve on which the SNARK proofs are computed. This construction works only if the base field of the first curve equals the scalar field of the second curve.
Do the two have to be the same? Large numbers in circom
Darwinia are trying to implement SNARK verification this way in solidity(verify BLS signatures in bn254) . It will be great if we can get suggestions from you @oana . cc @AlistairStewart
2 Likes
what Aki said is the previous research, currently Darwinia is understanding that paper, in consideration of doing some work based on this, hope to get @oana and @AlistairStewart suggestions
Wow thank you for your detailed and valuable post!
Whats the latest on this?