Different choices of curve for emulated element definition and compilation

[maoudia-via]

I am trying to define a circuit which uses the new emulated arithmetic element currently defined in the develop branch.
Element has a template argument which allows for the specification of the field parameters.
When compiling the circuit, it is also possible to choose the curve to be used for the compiled circuit.

So I am trying to understand the difference between the field used by the emulated Element and the curve used by compilation. My understanding was that emulated arithmetic does the underlying work of dividing the operands in smaller parts that fit the target field used by compilation.
What are the implications of using different curves ?

Thanks !

[ivokub]

Hi @maoudia-via, I would say there are three main criteria between choosing different curves:

• compatibility - sometimes the underlying curve is defined by other systems. For example, Ethereum only provides native bn254 operations. You could possibly implement full arithmetic for the other curves, but it would be too prohibitive gas-cost wise. There is hope that BLS12-381 will be also supported in the future, but not standardised yet.
• security -- different curves provide different security level. You normally want to have security level comparable to brute-forcing AES128 (i.e. 2^128 ops). BN254 doesn't provide it anymore, some curves way exceed it.
• recursion -- some curves have a nice property that the order of their scalar field matches the order of some other curve base field. This makes them very attractive for circuits where you need to have recursion (i.e. you generate a proof using bls12-377 and verify it over bw6-761). These curves are called 2-chains.

I definitely recommend reading (skimming) through a recent paper by @yelhousni et al: A survey of elliptic curves for proof systems.

[maoudia-via]

Thank you for your answer !