Decentralized DOT<>ETH Bridges: A Comparison Thread

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.