Precompiled contract for pairing check.

[chriseth]

Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.

Replaces #197

[pirapira]

On which ring is this equation evaluated?

[chriseth]

log_P is defined to map into F_q and that is the ring / field where this expression is evaluated.

[pirapira]

Is q common both to G_1 and G_2?

[pirapira]

Ah, the answer is there above.

[pirapira]

I guess it's G_1 and G_2

[pirapira]

I wonder if we should stick to X instead of i. An element of F_p^2 would look like a polynomial of X. (Of course i is an intuitive choice because i * i + 1 = 0.)

[chriseth]

Oh right, it should be consistent.

[pirapira]

I think it's worth clarifying if k = 0 is allowed (usually I don't say this, but now it's about protocol consensus).

[chriseth]

I would say of course it is, but it probably makes sense to be explicit about that.

[chriseth]

Mention that q=21888242871839275222246405745257275088548364400416034343698204186575808495617

[chriseth]

Mention explicitly that we have to check that the second elements are in the group G_2 (which is a subgroup of the full elliptic curve). In order to do that, verify that the order of the element is q=21888242871839275222246405745257275088548364400416034343698204186575808495617 (the prime group order of G_2).

TODO: Check that G_2 is the only subgroup of the elliptic curve with that order.

[pirapira]

Zcash does something slightly different for the purpose zcash-hackworks/bn@ef95df6

The Zcash implementation adds an element of G_2 at the end.

[pirapira]

I edited my post above because zcash does something else for input checking.

[chriseth]

The article by Barreto and Naehrig "Pairing-Friendly Elliptic Curves of Prime Order" mentions that the order of the curve twist is n(2p-n) (the proof is left to the reader, so it would be nice to find such a reader) where n is the order of the field and p the order of the original curve. Since G_2 has the same order p and both p and n are primes, it suffices to verify the order of the point is p as long as p does not divide 2p-n, which is the case with our numbers.

[vbuterin]

that the order of the curve twist is n(2p-n) (the proof is left to the reader, so it would be nice to find such a reader)

Consider a transformation that takes (x, y) into (x / cbrt(xi / 3), y / sqrt(xi / 3)). If one puts in an (x, y) pair that is on the original curve, with order n (ie. x**3 - y**2 = 3), into this transformation, then one should get out a value that satisfies x**3 - y**2 = 3/xi. However, xi / 3 is a quadratic nonresidue (though it is a cubic residue), so any x value that provides two points on the original curve would provide no points when transformed in this way, and because nonresidue * nonresidue = residue, any x value that provides no points on the original curve would provide two points when transformed. There are 2p possible points on the original curve (taking a possible point as a pair (x, parity of y), of which n turn out to be actual points; hence, the transformation gives us 2p - n points (though no proof yet that they are all linearly dependent).

I haven't gotten any further yet but this seems like the right path.

[pirapira]

In some libraries, I saw alt_bn128 is an alternative implementation of bn128. I got an impression they are for the same curve.

[NikVolf]

yes, this is the case, probably better call it just bn128, because alt_bn128 is just implementation-specific label for the same curve in one particular library (libsnark, https://github.com/scipr-lab/libsnark)

[chriseth]

@NikVolf the curve might be the same, but the generators used seem to be different:
https://github.com/scipr-lab/libsnark/blob/master/src/algebra/curves/bn128/bn128_init.cpp#L166 - https://github.com/scipr-lab/libsnark/blob/master/src/algebra/curves/alt_bn128/alt_bn128_init.cpp#L208 (but it might just be a different encoding)
In that case, we should perhaps move this wording closer to the specification of the generators.

[cdetrio]

Here are the permalinks.

alt_bn128 generator: https://github.com/scipr-lab/libff/blob/a44f482e18b8ac04d034c193bd9d7df7817ad73f/libff/algebra/curves/alt_bn128/alt_bn128_init.cpp#L208-L211

bn128 generator: https://github.com/scipr-lab/libff/blob/a44f482e18b8ac04d034c193bd9d7df7817ad73f/libff/algebra/curves/bn128/bn128_init.cpp#L166-L169

The numbers can be copy/pasted and they're both valid G2 points on the bn128 curve, so they are different generators (with the same encoding).

[cdetrio]

Also note that currently the cpp-ethereum implementation is not actually using the alt_bn128 optimization, but the bn128 generator points (if I remember correctly) ethereum/aleth#4450

[pirapira]

Let G_3 be the cyclic subgroup generated by P3, where P3 is very similar to P2 but uses -i instead of i. Is it the case that G_3 has the same order as G_2? If that's the case, the current input checking method checks <G_2, G_3> I guess.

[chriseth]

Why can't it be that P3 is just another element of the same cyclic group?

[pirapira]

The question is the other way around, why is it the case that P3 is just another element of the same cyclic group?

[pirapira]

(I guess Lagrange's theorem might be useful.)

[rphmeier]

This is a distinct break from the pattern of an infinitely zero-extended input. Why not prepend the number of elements?

[nicola]

How much would the cost to validate a zksnark?

[cdetrio]

To summarize some of the discussion (now hidden in outdated comments), and expand on it further:

• comments from @pirapira and @NikVolf that bn128 and alt_bn128 are the same curve. Specifying alt_bn128 is merely an optimization, and not strictly relevant to compatibility of precompile implementations. It could be relevant to the gas cost, if the chosen cost was based on a processing speed only attainable with the alt_bn128 optimization. But that isn't the case (currently the cpp client still uses an unoptimized implementation enable libsnark/libff alt_bn128 optimizations aleth#4450).
• bn128 and alt_bn128 use different generators, but the choice of generator points is also not relevant to precompile implementations. The text states as much: "Both generators have the same prime order q and the actual choice of the generators does not matter, as long as they have order q."
• The alt_bn128 generator was perhaps included because the pairing precompile is based on the zkSNARKs in Zcash. However, the pairing precompile is more general than the Zcash implementation. So while the alt_bn128 generator is a necessary input in order to verify a Zcash transaction, it is not necessary to implement the precompile. Other zkSNARK circuits and proofs may use different generator points, and the precompile can also verify those proofs because it is not dependent on any particular generator.

These points are hinted at in the text, in a confusing way: "the actual choice of the generators does not matter... The group G2 has generator P2 = (Xa + Xb, Ya + Yb)." If the choice doesn't matter, then why specify it? This is confusing to the average implementer, so some clarification would help.

[pirapira]

@cdetrio if we avoid mentioning a generator, we need an alternative way to specify a group on the curve.

[pirapira]

@cdetrio I doubt there is a shorter way than to mention a generator explicitly.

[pirapira]

@cdetrio and then, exploring an alternative definition is beyond editorship.

Maybe the BN parameters and so on can be added as an informational EIP. A link can be added from here then.

[pirapira]

Looks good to me.

Now I'm wondering if I should wait for @cdetrio 's alternative.

[pirapira]

I wouldn't believe the existence of those subgroups of order q without shown at least one generator. With a concrete generator, I can multiply it by q and then believe the existence of those subgroups.

The uniqueness part is not so hard. Basically, q is big enough.

[pirapira]

@cdetrio is this better now?

[pirapira]

I think @cdetrio's findings can be filed as an informational EIP, and this one can link to that.