Update EIP-2537: rename PAIRING to PAIRING_CHECK; introduce PAIRING_PRODUCT precomiple

[zhenfeizhang]

this PR does the following

• rename BLS12_PAIRING to BLS12_PAIRING_CHECK.

The function does not return the actual pairing result but instead checks if the result is identity or not. This renaming reflects the actual behavior. EIP for BN256 also used pairing check terminology.

• introduce the BLS12_PAIRING_PRODUCT precompile.

In certain cases there may be a need to compute the actual pairing product, instead of checking the product is 1 or not. Without precompile, we cannot compute a pairing product in solidity. For future proof, I suggest to add this precompile.

Note that for BN256, such a precompile does not exist, but the developers can still code this function in solidity (and pay a high gas fee) as the base field fits in U256 and there exists precompiles for MULMOD. This is almost impossible for BLS12-381. Here the base field is of 381 bits. If one were to implement pairing product, they have to implement the base field operation first, and then implement the actual pairing operation. This base field operation is already very expensive as we don't have MULMOD for 381 bits objects. The overall gas cost will be prohibitively high.

[eth-bot]

✅ All reviewers have approved.

[ralexstokes]

@zhenfeizhang thanks for this! I'm open to updating the name from "pairing" to "pairing check"

I intend to get some feedback on tomorrow's ACDE and the next roll call around the necessity for the "pairing result" precompile

so until then let's just let this sit and see what we decide to do

[ralexstokes]

hi @zhenfeizhang !

we discussed on a recent ACD call and there was some pushback that:

1. while there are cryptographic applications that could use the pairing product, they are somewhat niche
2. exposing the product precompile commits us to a particular pairing implementation, while only exposing the "check" would let us upgrade to a better/faster implementation in the future with much less coordination/change
3. there is some ongoing work on "EVMMAX" which would strike a middle ground for doing arithmetic with arbitrary modulus sizes, which would likely support the use case of doing a pairing in the EVM interpreter like you suggest above

please let me know if you see it differently, but at the moment I'd lean towards keeping the EIP as is, and waiting for something like EVMMAX to land to unlock these other use cases

[Marchhill]

Hey @ralexstokes I have a few responses to your points:

1. One application which doesn't seem too niche is verification of aggregated SNARKs, these generally require taking the pairing result and performing further arithmetic
2. If we expose the pairing result the pairing check operation could still easily be upgraded. Additionally if we wanted upgradability for the pairing operation itself, some bits of the input could be used to specify the pairing version to use. Also this means less fragmentation as all contracts use a standard pairing version rather than all reimplementing their own potentially incompatible versions.
3. EVMMAX would be useful for doing operations in the target group, however this would require pairing to be reimplemented. If we're happy with then you could argue we don't need the precompile in the first place, as we could do everything in the interpreter

I'm in support of changing the name to "pairing check"

[asanso]

I'm in support of changing the name to "pairing check"

+1

[mratsim]

exposing the product precompile commits us to a particular pairing implementation,

To clarify, it would require us to settle on a specific ABI for Fp12/GT, and would be useless without Fp12/GT multiplication at minimum and ideally endomorphism accelerated GT exponentiation as well.

If this is the way we want to go, the ABI encoding should be canonical and should not be the default dump from Gnark and Kilic which are dependent on the Fp2 -> Fp6 -> Fp12 towering, see https://github.com/supranational/blst/issues/101#issuecomment-1015511522

[ralexstokes]

given that it seems it would require additional standardization work to settle on something for the pairing product (see prior comment from mratsim), I think it best to leave that for future work.

moving the name to PAIRING_CHECK makes sense -- @zhenfeizhang do you mind updating this PR w/ just that change? then im happy to merge

[zhenfeizhang]

given that it seems it would require additional standardization work to settle on something for the pairing product (see prior comment from mratsim), I think it best to leave that for future work.

moving the name to PAIRING_CHECK makes sense -- @zhenfeizhang do you mind updating this PR w/ just that change? then im happy to merge

Updated as proposed.

[github-actions[bot]]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[mratsim]

not stale. cc @asanso @ralexstokes for review/merge

[ralexstokes]

@zhenfeizhang thanks for updating this PR and sorry for the latency :)

if you have a few minutes to update the original comment above to remove the bits about the pairing product, that would be helpful as we reference this in the future, thanks!

[zhenfeizhang]

@zhenfeizhang thanks for updating this PR and sorry for the latency :)

if you have a few minutes to update the original comment above to remove the bits about the pairing product, that would be helpful as we reference this in the future, thanks!

@ralexstokes done. Repost the removed section here for future reference.

===============================

• introduce the BLS12_PAIRING_PRODUCT precompile.

In certain cases there may be a need to compute the actual pairing product, instead of checking the product is 1 or not. Without precompile, we cannot compute a pairing product in solidity. For future proof, I suggest to add this precompile.

Note that for BN256, such a precompile does not exist, but the developers can still code this function in solidity (and pay a high gas fee) as the base field fits in U256 and there exists precompiles for MULMOD. This is almost impossible for BLS12-381. Here the base field is of 381 bits. If one were to implement pairing product, they have to implement the base field operation first, and then implement the actual pairing operation. This base field operation is already very expensive as we don't have MULMOD for 381 bits objects. The overall gas cost will be prohibitively high.

[SamWilsn]

@zhenfeizhang you'll need to resolve the conflicts in this pull request before this can be merged.

[zhenfeizhang]

@zhenfeizhang you'll need to resolve the conflicts in this pull request before this can be merged.

done