Enhancing Cadence/Flow with Expanded Elliptic Curve Operations Support for Zero-Knowledge Proofs

[highskore]

Issue to be solved

I've been thinking about the possibility of expanding our support for elliptic curve operations in Cadence/Flow. From my perspective, it seems there's a strong need for zero-knowledge proofs in the blockchain context, which appears to be somewhat absent in Flow currently.

I think it would be good to have a conversation about whether adding zero-knowledge proof verification could be possible and useful for our ecosystem. This could be a meaningful improvement for us in the future.

Suggested Solution

There's a pertinent Ethereum Improvement Proposal (EIP), specifically EIP-2537, that seeks to establish BLS12-381 curve operations for executing BLS signature and SNARK verifications:

EIP-2537 Link

Given its potential, it may be highly beneficial to consider incorporating the same operational framework into the Flow protocol. The EIP provides a detailed description of each function, which could be quite insightful for our purposes:

• BLS12_G1ADD - to perform point addition in G1 (curve over base prime field)
• BLS12_G1MUL - to perform point multiplication in G1 (curve over base prime field)
• BLS12_G1MULTIEXP - to perform multiexponentiation in G1 (curve over base prime field)
• BLS12_G2ADD - to perform point addition in G2 (curve over quadratic extension of the base prime field)
• BLS12_G2MUL - to perform point multiplication in G2 (curve over quadratic extension of the base prime field)
• BLS12_G2MULTIEXP - to perform multiexponentiation in G2 (curve over quadratic extension of the base prime field)
• BLS12_PAIRING - to perform a pairing operations between a set of pairs of (G1, G2) points
• BLS12_MAP_FP_TO_G1 - maps base field element into the G1 point
• BLS12_MAP_FP2_TO_G2 - maps extension field element into the G2 point with

The objective is to enable snark-based proof verification through a Cadence smart contract. I believe this could be achieved by integrating these "precompiles" into the Flow Protocol. However, I'm curious about potential computational limitations we may encounter during proof verification.

Here is an example of a zksnark verifier contract in Solidity:

https://gist.github.com/leonardoalt/bd8db502d620c16506eca81d85ff468c

As you can see, it involves quite a bit of mathematical computations and also uses precompiles. I'm interested in hearing everyone's thoughts on whether the computational limit could hinder our ability to verify proofs.

[turbolent]

Would we also need addmod and mulmod equivalents?

[tarakby]

@turbolent, Not necessarily. The tools listed above are elliptic curve group operations, and they use prime field operations under the hood (like the modular addition and multiplication you mentioned).
If we extend the elliptic curve operations properly (beyond the list above), we may not need the modular operations. For performance reasons, my preference is to keep the modular operations under the hood (I spare you the technical details here, but happy to talk about them) unless really necessary by the SNARK scheme.

You may be asking because you've seen modular operation being used in the example contract. It seems to me that they are all used as building blocks in elliptic curve operations (which I am proposing to export directly on Cadence).