Wrt SNARKs, constructions based on the pasta curves occupy a different trade-off space to constructions based on pairing-friendly curves like BLS12-381. In particular, achieving sufficiently fast verification of SNARKs for non-trivial circuits requires very involved constraint optimization skills, whereas achieving fast verification with pairing-based SNARKs is straightforward.

Also, pairings are useful for tons of other cryptographic primitives, like IBE, short signatures, quadratically-homomorphic encryption, etc., which could find applications later on.

Also the trusted setup fundamentally is a property of the proof systems rather than the curves. For example, you can construct a proof system using BLS12-381/BN w/o trusted setup.

The only curve in ETH is very expensive. In most useful cases of m out of n (even for things like 11 out of 16) , is way cheaper to implement a trivial multisig using many ECDSAs than to use BLS.

So the most important question is to make it cheap.

But then what I am always curios about is security.

Curves that have more mathematical structure than “random” curves are
per se less secure, unless proven otherwise, since the existence of the structure
may be used for a compromise.

In most cases, people do not discuss this, and there were already examples in the
past that some of “specialized” curves have been hacked.

For example the Pasta curves mentioned here. Most of people do not know what they are, and only few will invest time in understanding them, I am not even talking about analyzing their security.

Compare this to the original Diffie Hellman algorithm that arguably any person in the world with a high school math degree can understand and argue to be secure.

I would love to see an example of “specialized” curves being hacked. Unless you refer to anomalous curves (or supersingular one) I am not aware of any “specialized” curve that got attacked. What do you actually mean with “specialized”?
If with “specialized” you mean being built with Complex Multiplication (CM) method well the fact that are less secure than “random” curves is a bit a bold claim (with our current knowledge). There is no evidence that are insecure indeed. Even the curve currently used in Bitcoin/Ethereum namely secp256k1 has been built using CM .

is way cheaper to implement a trivial multisig using many ECDSAs than to use BLS

BLS is used a) to construct aggregate signatures with constant-time verification b) for pairings. Can you show us how to construct such a signature with secp? It must be verifiable in O(1), not in O(n).

Most of people do not know what they are, and only few will invest time in understanding them

There are very few people who know how pairings work, that doesn’t matter for all the great apps that are being built with them.

Compare this to the original Diffie Hellman

So what? The progress train is moving, we need complex protocols.

Well - my argument is simply that the more mathematical structure an object has, the more work you need to prove that it is secure, simply because insecurity can come from combinatorial interactions of different mathematical the structure.

From this perspective:

Elliptic curves are less secure than regular numbers, and BLS is less secure than elliptic curves, because it has pairing structure, and Pasta curves are less secure than BLS, because it also has the Pasta thing

There has been very little work done on explaining why pairing-based crypto is secure.
People just hope for the most time.

There have been pairing curves with structure that people thought were secure and they turned out to be insecure.

99% of mathematicians that work in pairing-based crypto do not know how pairing works.

If you read the original BLS paper, they had no independent argument that pairing was secure, that just assumed it.

They just assume it exists and secure. The result is that several people on this planet understand things. Compare this to Diffie-Hellman algorithm based on simple numbers. Everyone understands it.

Complexity is equal to insecurity.

BTW pairing based crypto is still NOT approved for any use by NSA and US Gov

From my perspective(ZK-Crypto dev), the most common use cases for ZKCrypto are for example rollups and zkevm chains now. Things like TornadoCash or ZK.money, ZKEVM-Community edition or Polygon’s solution.

For these, it’s unfeasible to use IPA (pasta curves PCS to-go for) as the verification will take simply too much time considering how massive these circuits tend to be and the block times that we currently have. (Unless of course, a really cool design appears. But anyway they’d probably verify this proof inside of a SNARK and publish the SNARK proof instead).

Also it’s much more tricky to decide upon a cost for the MSM operations which would be variadic. And there’s a lot of MSM optimizations that require parallelism, AVX features and similar stuff that might not be possible to be integrated on all the node runners.

Pairings provide constant time results and are used always when you need to verify really big circuits in a really short period of time. You can still aggregate proofs anyway with aggregation circuits and verify a single one making verifier costs really cheap.

It’s also pretty difficult to imagine that in the short term that recursion would be taking over and making ETH chain unusable due to the abcense of precompiles in order to perform it.

While I agree that, all else being equal, simpler protocols are better, I don’t think your examples support this claim.

If by “regular numbers” you mean schemes based on the hardness of DL in finite fields, then we know that these are at most as secure as schemes based on standard elliptic curves (not pairing-friendly ones); we have non-generic attacks on FFDL, while we don’t know of any non-generic attacks on ECDL.

We don’t know that Pasta curves are “less secure” than pairing-friendly curves. In fact, we suspect the opposite: we have no known attacks on cycles of curves that are faster than the generic attacks, while for pairing-friendly curves we know of attacks that exploit the target group structure. Furthermore, there’s no indication that the Pasta curves (or any cycle of curves, for that matter) has a more complex implementation than a pairing-friendly curve. In fact, as somebody who’s implemented both kinds of curves, the Pasta curves required much less work to implement.

Except, the Pasta curves do not have a pairing structure. Also, every CM curve, including the BLS curves, is part of a “pasta pair”. Just because we don’t use its “pasta twin” doesn’t mean it doesn’t exist.

So by your logic we expect pasta curves to be more secure than BLS curves.

Quick correction, not every CM curve has a cycle; only prime-order CM curves have a cycle. However, secp256k1 has a cycle, so if we’re ruling out the Pasta curves by the cycle criteria, we should also abandon the secp256k1 curve.

Yes, one can. See the following papers for examples of who to do this.

Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin, Secure Distributed Key Generation for Discrete-Log Based Cryptosystems, J. Stern (Ed.): EUROCRYPT’99, LNCS 1592, pp. 295–310, 1999.

Sorry for resuscitating an old thread, but I’m not finding much about the pasta curves and I would be highly interested in having some pasta curves support in the EVM. We also use them in Mina protocol and supporting them on the EVM would allow us to have a fully verified light client for Mina running in Ethereum.

BN254 is estimated to have at most 103-bit security against STNFS. If this isn’t already within reach of well-funded adversaries, such as intelligence agencies, it will be. (See this talk for why attacks on discrete-log cryptosystems require only a single large precomputation to then break any given discrete logarithm quickly; this does apply to the target group of a pairing.) I don’t think it’s a good idea to essentially force designers into trade-offs that make their protocols potentially breakable by an intelligence agency.

While BN254’s scalar field has 2-adicity 28, Grumpkin’s scalar field has no 2-adicity, making it inefficient to perform FFTs for proof systems instantiated on Grumpkin.

Note that what Genya-Z and Pratyush have said about the relative security of the Pasta curves and pairing-friendly curves is correct. BN, BLS, and as far as I’m aware all other pairing-friendly curves used in cryptography, are constructed by CM. Pairing-friendly curves also have low embedding degrees. I’m skeptical of the value for security analysis of looking at “how structured” a construction is, but if we are going to do that then we should at least get things in the right order. At risk of oversimplifying, the ordering goes like this from least to most “structured”:

(general elliptic curves) < (CM curves like secp256k1) < (2-adic cycles like Pasta) <<< (half-pairing 2-adic cycles like Pluto-Eris) < (non-cyclic pairings) < (MNT pairing cycles) << (discrete log in \mathbb{F}_p)

All of the curves on the left of the “<<<” have high embedding degree. (A half-pairing cycle has high embedding degree for one of the curves in the cycle.) It is high embedding degree that prevents a curve from being subject to reductions that allow index calculus attacks. To my knowledge, the only attack that depends on CM structure is a slight speed up to Pollard rho in some cases. As we said in a footnote to the Halo paper:

A conservative estimate of the available improvement to Pollard rho is that on a group of prime order q with an automorphism group of order 6, the attack cost is \sqrt{\frac{\pi q}{12}}, as compared to \sqrt{\frac{\pi q}{4}} using only the negation map as described in [6]. That is, the maximum speed-up is only a factor of \sqrt{3} ≈ 1.732 for a given success probability.

(This footnote applies to j = 0 curves like secp256k1 or Pallas/Vesta, and also to BN or BLS12 pairing-friendly curves when Pollard rho is used.)

I’m obviously somewhat biased because I constructed the Pasta cycle and my colleague Sean Bowe constructed BLS12-381, but in my opinion there is a strong engineering and security justification for adding both of these as precompiles, and there’s no need to pit them against each other as is done in this thread.

Late to the party, but one cool application of BLS (and more generally pairing-based curves) that I don’t think pasta curves support is identity-based encryption such as timelock encryption.