Given an arithmetic circuit encoded as a Rank 1 Constraint System, it is possible to create a ZK-proof of having a witness, albeit not a succinct one. This article describes how to accomplish that.
A zero knowledge proof for an R1CS is accomplished by converting the witness vector into finite field elliptic curve points and replacing the Hadamard product with a bilinear pairing for each row.
Given a Rank 1 Constraint System where each matrix has rows and columns, we write it as
Where , , are matrices with rows and columns, and is the witness vector (containing a satisfying assignment to each of the signals in the arithmetic circuit). The vector has 1 column and rows and is element-wise multiplication (Hadamard product).
In expanded form, it looks like
In this setup, we can prove to a verifier that we have a witness vector that satisfies the R1CS simply by giving them the vector , but with the obvious drawback that this is not a zero knowledge proof!
Zero knowledge proof algorithm for an R1CS.
If we “encrypt” the witness vector by multiplying each entry with or , the math will still work properly!
To understand this, consider that if we carry out the matrix multiplication
and also
The discrete logs of the two elliptic curve points in the second matrix multiplication are the same value as the elements of the first matrix multiplication.
In other words, each time we multiply the column vector by a row in the square matrix, we carry out two elliptic curve point multiplications and one elliptic curve addition.
Notation for elliptic curves
We say is a elliptic curve point created from multiplying the field element by . We say is a elliptic curve point generated by multiplying with the generator . Because of the discrete log problem, we cannot extract given or . Given a and point, we say the pairing of the two points is .
Prover steps
Let’s encrypt our vector by multiplying each entry with the generator point to produce the elliptic curve point .
For the matrix , we are doing the following:
In anticipation of the Hadamard product becoming a list of elliptic curve pairings, we can use points to also encrypt the vector so the verifier can do the pairing.
After this operation, we have a single column of elliptic curve points in originating from the multiplication and a single column of points from .
The naive next step would be to encrypt the vector with points so that the verifier can pair the result of with to see if it equals , but points are massive, so we would rather have the verifier pair the elliptic curve points in then pair each entry with a point. Pairing with a point is, in a sense, “multiplying by one” but turning the point into a point.
The prover then hands the vector and the vector to the verifier.
Verification step
Thus, the verification step becomes
The above vectors of elements will be element-wise equal if and only if the prover has provided a valid witness.
Well, almost. We’ll get to that in a following section.
First we need to mention an important implementation detail
If our knowledge claim is “I know such that where ”, then our witness vector will probably look like the following:
where . In this case, we need to be public. To accomplish that, we simply don’t encrypt the first two elements of the witness. The verifier will check the public outputs, then encrypt the public inputs by multiplying them with a or point so that the verification formula does not change.
Dealing with a malicious prover.
Because the vectors are encrypted, the verifier cannot immediately know if the vector of points encrypts the same values as the vector of points.
That is, the prover is supplying and . Since the verifier doesn’t know the discrete logs of the vector of points, how does the verifier know that the vector of points has the same discrete logs as the vector of points?
The verifier can check for the equality of the discrete logs (without knowing them) by pairing both vectors of points with a vector of the opposite generator and seeing that the resulting points are equal. Specifically,
This algorithm is mostly academic
This algorithm is very inefficient for the verifier. If the matrices in the R1CS are large (and for interesting algorithms, they will be), then the verifier has a lot of pairings and elliptic curve additions to do. Elliptic curve addition is rather fast, but elliptic curve pairings are slow (and cost a lot of gas on Ethereum).
However, it is nice to see that at this stage, zero knowledge proofs are possible, and if you have a good grasp of elliptic curve operations (and haven’t forgotten your matrix arithmetic), they aren’t hard to understand.
Making this technique truly zero knowledge
As it is right now, our witness vector cannot be decrypted, however it can be guessed. If an attacker (someone trying to discover the unencrypted witness) uses some auxiliary information to make an educated guess at the witness, they can check their work by multiplying their guessed witness vector by the elliptic curve point generators and seeing if the result is the same as the prover’s witness vectors.
We will learn how to defend against witness guessing in our coverage of Groth16.
Also, keep in mind nobody does the described algorithm in the real world, as it is too inefficient. However, if you implement it, it will help you practice implementing meaningful elliptic curve arithmetic and build a functional end-to-end (almost) zero knowledge proof.
You can see an example implementation of algorithm described here by Obront in this repo.
Learn more with RareSkills
This material is from our Zero Knowledge Course.
Originally Published August 26, 2023