Public Input Check
The prover's data will consist of a long, length- vector of 64-bit words. By definition of our constraint system language, the constant and input–output segments of the prover's witness need to match public values known to the verifier, if that witness is to be considered valid.
Up to this point, we've postponed the verifier's actually checking the public portion of this data. Of course, we expect the verifier to have to do work proportional to the statement length, at the very least, if he is to verify the prover's proof about that statement. Here, we explain what our verifier does.
As usual, we write , and for the lengths—specified by the constraint system—of the prover's constant, public, and witness stretches of data, respectively. We abbreviate , and write —a vector of length words—for the values that the first entries of should take on, from the verifier's view. We assume that and are both powers of 2.
The Naïve Way
We've already agreed to work within a framework in which the verifier can read the prover's committed data at arbitrary positions. The most naïve possible public input check would direct the verifier to fully read the first words of , and check whether they match .
To achieve this, the verifier would need to query
for each and each . This would be far too much. As always, we write for the multilinear extension of .
Just One Query
The following idea brings the number of queries the verifier must make down to just one. We write for 's multilinear extension.
If and only if the prover's public input is correct, the -variate multilinear
vanishes at each point of of the form . It would thus suffice for the verifier to sample and —both random, and -dimensional and -dimensional, respectively—and to check whether
held. To evaluate this check, the verifier would need to evaluate —which it can do itself in time—as well as query once, namely at the point .
Homogenizing Query Point
At the very end of the shift reduction, the verifier outputs a single evaluation claim on . Set alongside that evaluation claim, the above technique would add a further evaluation claim on top. We would like to get away with just a single evaluation claim on , overall.
To do this, we use another sumcheck-based technique. First of all, we write for the variable of that name sampled by the verifier during the course of the first phase of the shift reduction. Since is sampled after is committed, we can freely reuse that randomness for our purposes here. We moreover stipulate that the verifier freshly sample , an -dimensional, fresh random challenge, at this point.
To check the prover's public input, it thus suffices for the verifier to check whether
Upon being sumchecked, this claim will resolve to a further claim, now on the value of
where , a fully random and -dimensional point, is sampled during the sumcheck. The verifier can evaluate the above quantity himself, up to exerting + work and making the single query .
The point of doing this is that the above sumcheck can be batched with the one we're already running during the second phase of the shift reduction. Doing exactly this lets us wind up with the same random value in both sumchecks; it follows that we can get away with just one query to the witness at the very end, namely at .