Visualization and detailed description of the interactive protocol for TQBF yielding IP = PSPACE
In complexity theory, it is well known that IP = PSPACE. In this post I would like to go over the private coin interactive protocol for TQBF typically used to prove that PSPACE is contained in IP and, in that context, present my detailed visualization of the entire protocol together with the Open Source tool I developed to run the protocol and render the animations. I would also like to note that when I was first studying the proof protocol for TQBF, I was a bit frustrated by the fact that most texts lack a precise and detailed description of some subtleties in the proof — this is what also motivated me to try my best to fill in the relevant but missing details in this post.
Shamir’s Theorem
In 1990, Adi Shamir proved that . I find this result quite surprising, because it shows that just allowing the verifier to toss coins increases the computational power of polynomially long lasting interactive proof systems drastically, namely from to . It is not hard to see why — this is the case because we can try running the interactive proof system for all possible random bits the verifier may use and messages the prover could potentially send. After that, it is possible to check whether we were able to find a way to convince the verifier for most possibilities of choosing random bits. More precisely, a decider for can be constructed as follows (pseudocode):
c = 0
threshold = ceil(2/3 * (total number of different ways the verifier can toss coins))
for all possible verifier's random bits {
for all possible message sequences the prover may send during the communication {
Run the verifier using the current message sequence and random bits;
if verifier accepted {
c++;
break;
}
}
}
if c >= threshold {
accept;
} else {
reject;
}
So the main challenge of showing is actually showing that . Since is closed under polynomial time Karp reductions and is -complete, it suffices to show that . There are multiple ways of proving it — I will generally follow Shamir’s approach and use a trick called linearization, which was introduced by Shen in this paper.
Arithmetization
The main tool used in the proof is arithmetization, that is, the representation of QBF sentences using polynomials. Assuming without loss of generality that the given quantified boolean formula
is in prenex normal form with matrix in CNF, we can obtain a polynomial by essentially thinking of disjunctions as negated conjunctions and by simulating conjunctions with multiplication. Formally, if is an arbitrary variable, is an arbitrary literal and is an arbitrary clause appearing in , then we can define the arithmetizing polynomial recursively as follows:
By definition of and the above discussion, for any values it holds that
Now we need to handle quantifiers. In this connection, note that for some boolean formula , or make the sentence evaluate to true if and only if or hold, respectively. This property remains true if contains more variables than just . We can simulate the disjunction with a sum of arithmetizations of and , wheras can be similarly arithmetized to a product. To sum up, we can arithmetize a given quantified boolean sentence as follows:
- Replace the matrix with .
- Replace with and substitute for in .
- Replace with and substitute for in .
More formally, while considering the quantifiers from right to left we have the invariant that the value of the polynomial considered so far is 0 iff the formula is false. Taking this invariant as an inductive hypothesis, we can easily see that and provide the semantically correct simulation of and , respectively, in the inductive step. Using the notation to denote the correct operation needed to simulate the current quantifier, we conclude that:
For example, the QBF
would get arithmetized as follows:
As a side note, I generated this animation using this tool I developed recently. At the end of the above visualization, we get:
Refinement of arithmetization
Before we can make use of the representation of QBF’s as polynomials in the interactive proof protocol, we need to ensure that they satisfy some “nice properties”. In this section, I will define such properties and show how we can ensure that they indeed hold. To make the notation introduced above more robust and easier to work with, we can first define the following functions that take a multivariate polynomial as input and produce another polynomial:
The main equivalence we got above (as a result of arithmetization) can now be rewritten as follows:
From now on, I will call a proof operator. The intuitive idea behind the interactive proof protocol we want to build is to check by iteratively considering proof operators from left to right and in each step asking the prover to describe how the “behavior changes” using a univariate polynomial. As we will see below, this can be done in such a way so that the verifier can easily check whether what the prover sent “makes somewhat sense”, and if yes, then if the prover indeed lied, he will be forced with high probability to lie again and again, which leads to a high probability of the verifier finding out that the prover is dishonest at some stage — if the verifier catches the prover, he dismisses the alleged proof.
Linearization
For the polynomial-time verifier to be able to work properly with polynomials, we (will) need to ensure that they have low degree, i.e., the degree must itself be bounded by a polynomial in the size of . Note that the degree of is low, because , where is the amount of clauses. While adds polynomials which doesn’t increase their degree, multiplies polynomials meaning that the degree can get doubled in the worst case. If this happens in every step, then the degree of the entire arithmetization may get exponential, which is unacceptable. To resolve this issue, we can introduce a linearity operator defined as follows:
The idea is the following: outputs a polynomial that agrees with on all such that the resulting polynomial is linear in . For example, linearizing in
gives us which is linear in . The correctness of the linearity operator follows from the fact that for all . By composing multiple linearity operators, we can ensure that the polynomial is linear in all variables. Continuing the example above, we can linearize in and obtain
which agrees with on all inputs from . We can now sprinkle in linearity operators in the proof sequence as follows:
Since we evaluate only on binary values and the linearization operators guarantee that the outputted polynomial agrees with on all values from , it holds that
which, in particular, implies that
meaning that the problem of designing an interactive proof protocol for reduces itself to the problem of designing a protocol for showing that
Modular arithmetic
In the previous section, we’ve ensured that the intermediate polynomials all have low degree. However, there is another problem — we still may not be able to evaluate such low degree polynomials in polynomial time, because the value can get exponentially large with respect to the previous value, at every proof operator, meaning that the tight upper bound for the value of the entire polynomial is . We can resolve this issue by picking a prime number and doing all computations modulo , that is, in the field. This doesn’t break any equivalence we have shown above, since there is a constant such that
holds. This is not hard to show using number theory — see Theorem 4 of Shamir’s paper for the details. Moreover, we can assume that — this will be important for the correctness of the protocol that I will discuss at the end of this post.
Note that, as stated above, if , then the same statement will be true modulo at least one prime number that can be encoded using polynomially many bits. This does not mean that any prime will work — the problem is that in the arithmetization polynomial we simulate quantifiers using a sum, but two non-zero values may become zero modulo once added together. For example, consider the formula
with variables. We could be tempted to just choose the first prime , which is . Calculating the value of the arithmetizing polynomial gives us:
However, although suggests that , is actually a true sentence. This example illustrates why we need to be careful when choosing .
Interactive protocol for TQBF
As mentioned earlier, the vague idea behind the protocol is to go over the operators from left to right and ask the the prover to describe “what has changed” using a polynomial. In the context of some polynomial we now formalize this notion by defining the following univariate polynomial:
Here, we assume without loss of generality that the variable of the first proof operator is (rename variables if this is not the case). Suppose we have some values and we want to check whether , where is a polynomial from the proof operator sequence, that is,
holds for some polynomial . This can be verified using the following interactive protocol, which I will refer to as the operator composition check protocol:
- Verifier: If , set , go directly to step 4 and accept if the check succeeded;
- Verifier: Otherwise, ask the prover to send .
- Prover: Sends that is allegedly equal to .
- Verifier: If , verify that , if , verify that and if , verify that . If one of these checks failed, reject.
- Verifier: Pick uniformly at random and re-run the same protocol to check that .
On top of this protocol, it is now easy to build the interactive proof protocol for :
- Verifier: Ask the prover to send the value of the entire proof operator polynomial.
- Prover: Sends ,
- Verifier: If , reject (because this means that the prover directly confessed that the value of the polynomial is 0 meaning that ).
- Verifier: Using the operator composition check protocol defined above, verify that
Example visualized
In this section I would like to present my tool that allows us to both obtain the interactive transcript in text format, as well as render a video animation showing in detail every aspect of the protocol. The implemented protocol is exactly the protocol defined in this post, all notations are also consistent. In the arithmetization section above, we have already arithmetized a concrete formula, namely
I will continue using this example formula. We obtain the following proof operator sequence:
For this particular formula , the value of the polynomial will always be regardless of the choice of , but from now on we will do all computations modulo . If we consider each operator in the above sequence separately and evaluate the part after that operator, then we obtain:
Here, I have included only the first 4 polynomials. It follows that the prover must in the first round send followed by in the second round. Then the verifier will change the polynomial and assign a randomly chosen but fixed value to the variable. If, for example, the verifier chooses , then it means that in the third round the verifier would need to send . More generally, the polynomial the prover must send to be able to convince the verifier that is essentially the intermediate evaluation of the proof operator sequence, with values the verifier chose substituted for all variables except the current one. This is exactly the reason why it is essential that we ensure that the intermediate polynomials in the proof operator sequence all have low degree — otherwise the prover might not be able to come up with the polynomial of degree polynomial in the size of .
The following interactive transcript gets produces for , of which I am including only first 4 rounds here:
Working modulo prime p = 17
[V]: Asking prover to send value of the entire polynomial
[P]: Value = 1 =: c
------------------------------
Starting round 1. Current operator: E_{x}
[V]: Random choices: none
[V]: Asking prover to send s(x) = h(x)
[P]: Sending s(x) = 1 - x
[P]: deg(s(x)) = 1
[V]: s(0) + s(1) = 1, expecting to be equal to c = 1
[V]: Chose a = 13 for variable x
[V]: Random choices: x := 13
[V]: s(a) = 5 =: c
------------------------------
Starting round 2. Current operator: L_{x}
[V]: Asking prover to send s(x) = h(x)
[P]: Sending s(x) = 1 - x**2
[P]: deg(s(x)) = 2
[V]: a_1 * s_1 + (1 - a_1) * s_0 = 5, expecting to be equal to c = 5
[V]: Re-chose a = 10 for variable x (while linearizing it)
[V]: Random choices: x := 10
[V]: s(a) = 3 =: c
------------------------------
Starting round 3. Current operator: A_{y}
[V]: Random choices: x := 10
[V]: Asking prover to send s(y) = h(y)
[P]: Sending s(y) = -3*y - 6
[P]: deg(s(y)) = 1
[V]: s(0) * s(1) = 3, expecting to be equal to c = 3
[V]: Chose a = 10 for variable y
[V]: Random choices: x := 10, y := 10
[V]: s(a) = 15 =: c
------------------------------
Starting round 4. Current operator: L_{x}
[V]: Asking prover to send s(x) = h(x)
[P]: Sending s(x) = 1 - 2*x
[P]: deg(s(x)) = 1
[V]: a_1 * s_1 + (1 - a_1) * s_0 = 15, expecting to be equal to c = 15
[V]: Re-chose a = 15 for variable x (while linearizing it)
[V]: Random choices: x := 15, y := 10
[V]: s(a) = 5 =: c
And running the tool in rendering mode produces the following visualization of the protocol applied to :
The animation consists of the following parts:
- At the very top, the sequence of proof operators is located. In every round of communication, the proof operator corresponding to the beginning of the polynomial being considered, namely , is highlighted with a yellow surrounding rectangle.
- Below the sequence of proof operators, the values that the verifier has assigned to variables so far, are displayed.
- In the center of the animation, the sequence of proof operators is visualized with a tree. This visualization allows us to very clearly see, in particular, the connection between and the sequence of proof operators, or, in other words, value of what part of the polynomial is currently being verified.
- In the bottom corners, the
V
andP
stand for verifier and prover, respectively. Between these labels, the communication is visualized. In particular, it is visualized which messages both parties exchange and how the verifier checks that what the prover says is correct, in accordance with the protocol defined above.
Correctness of the protocol
Finally, to make the description of the protocol in this post complete, I would like to explain in my own words why the protocol defined above is correct. The completeness property of holds obviously — if , then an honest prover will be able to convince the verifier no matter how the verifier tosses coins.
For the soundness analysis, we will first show the following lemma:
Lemma: Let be a polynomial, and suppose that we are checking whether using the operator composition check protocol, but actually . Then the probability of either
- the verifier rejecting the proof in that very round (at step 4), or
- the verifier forcing the prover to continue lying in the next round, that is, re-running the protocol to verify when it is actually the case that
is at least , where .
Proof: If the prover sends , then, depending on the current proof operator, one of the checks in step 4 will fail and the verifier will therefore reject with probability . On the other hand, if the prover sends , then the polynomial has degree at most . This means that has at most roots, i.e., there exist at most values such that . In other words, . Since the verifier uses the value in the next round, it holds that
This completes the proof of the lemma.
Now suppose that . Then it is clear that the probability of the verifier not being fooled by the prover is at least the probability of the prover being forced to lie again and again, until he is either caught at some (possibly last) round. By applying the above lemma inductively, we get:
Since , and for some constant , it holds that
We can calculate the limit of this probability using L’Hôpital’s rule:
By the definition of the limit, this means that for any there exists a fixed such that for all QBF sentences with at least variables the probability of the verifier rejecting is at least . This in particular implies the soundness requirement of the complexity class, thus completing the proof of the correctness of the protocol.