In-circuit implementation for BN254 precompiles: ecadd, ecmul and ecpairing.

[NikitaMasych]

What ❔

• Update yul wrappers for ecadd and ecmul from contract implementation to circuit.
• Add ecpairing contract-wrapper in yul to delegate in-circuit.

Why ❔

To improve performance and boost EVM equivalence.

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.

[vladbochok]

You should remove all unused code.

[NikitaMasych]

Hi, @vladbochok, the code I have left is used to check that the point is on the curve as well as coordinates are less than modulo

[vladbochok]

@NikitaMasych You also left code related to Montgomery form. It is useful when you do many operations with the numbers, but you only need to check that the numbers are less than the modulo and are in the curve. Please remove all code related to Montgomery and instead use traditional math as it would be cheaper.

[NikitaMasych]

Right, I have just though that it is better to not modify audited code as it serves its purpose. Additionally, there is premature handling of corner-case operations involving Montgomery form, such as Inf + 0 etc. In-circuit we bring only after passing all the corner-cases and checks.

[NikitaMasych]

Of course, I would however try to leverage in-circuit checks, leaving a blank call to it from yul code to achieve end-to-end best performance and security

[vladbochok]

Right, I have just though that it is better to not modify audited code as it serves its purpose

We will reaudit it fully, please go ahead change & simplify :)

[vladbochok]

if and(eq(x1, x2), eq(y1, y2)) {

I think circuit can handle this better than performing calculation in contract

[NikitaMasych]

think circuit can handle this better than performing calculation in contract

Probably yes, however I guess there might be a necessity of vanguard validation, so that we won't get any issues with proof generation failing for bad input

[vladbochok]

think circuit can handle this better than performing calculation in contract

Probably yes, however I guess there might be a necessity of vanguard validation, so that we won't get any issues with proof generation failing for bad input

I think this is specific if branching was introduced to optimize the edge case, not because it is a special case. So you can remove this optimisation as circuit will do bettter job anywat

[NikitaMasych]

Hey guys, @vladbochok @StanislavBreadless, I have simplified yul contracts as much as possible, moving all validations inside the circuits. Also, I am wondering what values shall be selected as GasPrice for each of ecadd, ecmul and ecpairing, because for now I've just put something akin to EVM equivalent prices.