[Sapling] specify Pedersen hashes for a collision-resistant hash function inside the SNARK

[zookozcash]

from #2230

Ian Miers noticed that a pedersen hash is an exceptionally good application for this fast ECC. Pedersen hashes have been mentioned in papers spanning decades, but have been largely ignored due to inefficiency. However, in our case they are perfect. Inside the circuit they are very competitive with MiMC (a hash function submitted to Asiacrypt last year) except that a pedersen hash has collision resistance that reduces to discrete log -- far more believable than their construction.

In particular, we select a vector g of n group elements of unknown exponent, and given a vector x of n scalar bits, we compute:

g₁^x₁ g₂^x₂ ... g_n^x_n

It is trivial to see that finding a collision requires defeating discrete log in the group. Further, in our construction we can return the y coordinate of the result, which is a single field scalar. (Recall that in Edwards curves, the x coordinate encodes the sign.) Because the group order is an odd prime, collision resistance still reduces to discrete log.

[daira]

@ebfull wrote at #2230 (comment): Here's is an excerpt from an email I sent Matt/Ian a couple months ago.

Currently relying on per-bit point addition allows each addition to be 5 constraints, except the first (which is just 2) and the last (which is 3, because we end up discarding the x coordinate).

It doesn't immediately seem intuitive that a window table lookup is efficient inside the circuit, both because they scale poorly to large windows and because the general point addition becomes 7 constraints (and 4 constraints for the last addition).

However, for a window size of 4, there is a sweet spot. For input bits w, x, y, z, we precompute the following constraints:

yz = y * z
xy = x * y
xz = x * z
xyz = xy * z

Now, a window lookup can be performed for constants a, b, c, ..., o, p, by evaluating the following single gigantic R1CS constraint, which is a polynomial designed to vanish at the constants we aren't selecting:

w * (a(xyz) + a(xy) + a(xz) + a(x) + a(yz) + a(y) + a(z) - a + b(xyz) + b(xz) + b(yz) - b(z) + c(xyz) + c(xy) + c(yz) - c(y) + d(xyz) - d(yz) + e(xyz) + e(xy) + e(xz) - e(x) + f(xyz) - f(xz) + g(xyz) - g(xy) - h(xyz) -i(xyz) - i(xy) - i(xz) - i(x) - i(yz) - i(y) - i(z) + i - j(xyz) - j(xz) - j(yz) + j(z) - k(xyz) - k(xy) - k(yz) + k(y) - l(xyz) + l(yz) - m(xyz) - m(xy) - m(xz) + m(x) - n(xyz) + n(xz) - o(xyz) + o(xy) + p(xyz)) = r + a(xyz) + a(xy) + a(xz) + a(x) + a(yz) + a(y) + a(z) - a + b(xyz) + b(xz) + b(yz) - b(z) + c(xyz) + c(xy) + c(yz) - c(y) + d(xyz) - d(yz) + e(xyz) + e(xy) + e(xz) - e(x) + f(xyz) - f(xz) + g(xyz) - g(xy) - h(xyz)

(Note that there are errors in this polynomial, but the idea is valid.)

This means we can lookup the x, y coordinate pair from a window 4 table with just 6 constraints. After this window size, the cost of lookups explodes.

In our CRH, we have to do more than just base point multiplication. We need to unpack some input field elements -- for random field elements, this costs 255 boolean constraints, 1 packing constraint, and 254 constraints for performing a partial boolean subtraction to ensure the bit representation is actually in the field. This means just processing the inputs costs 1020 constraints.

By employing the windowed exponentiation above, the constraint complexity of the final output is:

1020 + 6(510/4) + (510/4 - 1) * 7 + 4 = 2674.5 constraints. (The fraction here is just because 4 does not divide 510, so the actual constraint complexity is 2675 as there are merely less terms in the final window table lookup constraints.)

This is quite a bit better than the (1020 + 5*508 + 3 + 2 = 3565) constraints before.

[daira]

In our CRH, we have to do more than just base point multiplication. We need to unpack some input field elements -- for random field elements, this costs 255 boolean constraints, 1 packing constraint, and 254 constraints for performing a partial boolean subtraction to ensure the bit representation is actually in the field. This means just processing the inputs costs 1020 constraints.

I believe we can reduce this. The modulus p is just under 255 bits. Let y be the y-coordinate of a CRH output, with binary representation y = ∑[2ⁱ.y_i for i from 0 up to 254]. We can express the condition ∑[2ⁱ.y_i for i from 0 up to 254] < p as a boolean circuit and then apply a general-purpose boolean logic minimizer such as SAT-ESPRESSO to this circuit. (The problem of finding an optimal solution is NP-complete, but we only need a good solution for a single instance.)