Flash and JavaScript are required for this feature.
Download the video from Internet Archive.
Description: Quickly reviewed last lecture. Discussed the arithmetization of Boolean formulas. Finished the theorem: #\(SAT\) ∈ IP and concluded that coNP ⊆ IP.
Instructor: Prof. Michael Sipser

Lecture 26: coNP ⊆ IP
[SQUEAKING]
[RUSTLING]
[CLICKING]
MICHAEL SIPSER: Greetings, everybody. Welcome to our last lecture of the term. We have survived a semester online in 18.404 and we are going to conclude our last topic today, which is interactive proof systems that we started last time. And with the big-- well, the big theorem of interactive proof systems is that IP equals PSPACE. And we're going to give the main idea for that in a slightly weaker theorem, as we'll see.
So why don't we jump in? So we have been doing interactive proofs. We gave an example of showing that the graph isomorphism problem, the complement of that is an IP, as I hope you remember. We had that interaction with the approver and a verifier. We're going to go through it quickly. Not that protocol, but just the setup. And then we're going to finish by showing that this number SAT problem is an IP and should conclude that coNP is a subset of IP.
All right, so let's go for it. Yes. So just remember, interactive proof systems, there are these two parties, the prover and the verifier. The prover has unlimited computational ability. I kind of model that as an army of students perhaps who can-- where we don't-- they can work all night. They can use computational resources. And the prover, however, we're not going to measure the computational power of the prover. That's unlimited. And so the prover can do things like find certificates. It can test whether things are satisfiable. It can factor numbers. We don't care. It can do whatever we'd like and there is no charge for the prover's computational demands.
OK. So the setup we had was the prover and the verifier. Both see the input. The exchange of polynomial number of messages. And then the verifier accepts or rejects. And we had this notion of the probability that the verifier ends up accepting when paired with a particular prover. And what we want is that for strings in a language, that probability should be high for some prover.
And for strings not in the language, that probability should be low no matter what the prover does. So there's nothing the prover can do. And the way it kind of suggests that at any prover. But whatever the prover's strategy cannot make the verifier accept with high probability. Just doesn't have enough information or it doesn't-- it's just not able to make the verifier accept with high probability.
You might think of the prover as trying to make the verifier accept. So the P tilde is a crooked prover. I don't think that went down very well with everybody. So I have it here. Another way of looking at it, maybe it looks a little bit more like NP here where IP is the collection of languages where there's a verifier, just like we had. You can think of NP as having a verifier which can check certificates. Here the prover is going to be like the certificate so that for strings in the language, there's a prover which can interact with the verifier and make it accept a high probability. And you're not in the language, there is no prover, which can interact with the verifier and make the verifier accept with even more than low probability.
What's important is this gap, just like with BPP, between acceptance or rejection. And that gap is there because we want to be able to use the amplification lemma. And if there was no gap, then you wouldn't be able to amplify and make the probability of acceptance extremely high when you want it to be in the language, when you're in the language, and extremely low when you're not in the language.
OK. So I hope that refreshes your memory as to how that works. We're going to walk ourselves through the-- well, through what we did last time. But let's set the stage for that. So the surprising theorem, as I mentioned, is that IP equals PSPACE. One direction of that is a fairly standard simulation. With PSPACE, you can basically work your way through the tree of possibilities for an interactive proof protocol. And you can calculate the probability that the verifier would end up accepting if you had the best possible prover that would try to make the verifier accept. And you can just do that calculation. It's in the book. You're not going to be responsible for knowing that, actually. We haven't covered it in lecture. But it's not very hard. A little technical, I suppose.
The other direction is the interesting one, and that's the direction we're going to be moving toward today. We won't quite get there, but the way it works is that to show that everything in PSPACE, which is kind of amazing, is contained with an IP. So everything in PSPACE can be done with an interactive proof system. And the way that is done is by using a PSPACE complete problem, TQBF, and showing that that problem itself is an IP. But we're not going to prove that. That would be sort of the next thing we would prove if we had a little bit more time. But we're going to be satisfied with just the somewhat weaker but very similar statement that coNP is contained in IP here.
Again, still very surprising, because you have to be able to show, for example, that a formula is not satisfiable with a prover. How can a prover convince a verifier that a formula is not satisfiable? Showing that it is satisfiable, you just give the certificate, which is the satisfying assignment. But how do you show something's not satisfiable? It's unexpected. And the proof of that is pretty much similar, slightly is one kind of technical point which we don't have to get into. So it's slightly easier but very much in the same spirit.
So remember this number set problem is you're given a formula and a number, and that number is supposed to be exactly the number of satisfying assignments of the formula. So in particular, a formula's unsatisfiable, then it would be paired with the number 0. And that's why the number set problem is coNP-hard, because you can easily reduce the unsatisfiability to number set. An unsatisfiability is coNP complete.
OK, so remember we introduced this notation last time. This is going to be critical for understanding this proof. So let's go through it once again. So if you have some formula, what I'd like to do is preset some of the variables of that formula. So that's going to be a formula on m variables x1 to xm. And I'd like to preset the first i variables to zeros or ones as I wish.
So I'm going to indicate that by phi with 0 means I'm setting x1 to 0 and the rest of the variables remain variables. And more generally, phi of i values a1 to ai, which to start off with are going to be just zeros and ones, just Boolean values. That's going to be the formula with those first x1 to set to a1 dot, dot, dot xi set to ai for those i constants, which were zeros and ones. I'm going to call those presets, because we're presetting some of the variables in the formula. And the rest of the variables we're going to leave as variables.
So we get a new formula on fewer variables by doing this pre-setting process. And we're going to get to do the same thing in terms of counting the number of satisfying assignments. So remember the notation number phi is the number of satisfying assignments. Number phi with a preset of 0 is the number of satisfying assignments when you've set x1 to 0. And no phi of a1 to ai is where you set the first i variables to those i values. And then you're going to look at the number of satisfying assignments with those presets in mind.
So there were two facts. I'm going to call them identities, because we're going to rely on those and we're going to actually extend those to the non Boolean case, as we'll see shortly. So these two identities say that, first of all, if I preset, I think understanding the first one is clear just by thinking about it in the case where i equals 0. So this is the case where the number of satisfying assignments altogether is the number of satisfying assignments when I've set x1 to 0 plus the number of satisfying assignments when I've set x1 to 1. And this just generalizes that when I look at having already preset the first i variables.
So if I preset the first i variables to these i values, the number of satisfying assignments I get there is the number of satisfying assignments I get with those presets plus the next variable being set either to 0 or to 1. And then you add those up. The same idea. And lastly, if I set all of the variables to values, so I have no variables left, and I look at the number of satisfying assignments consistent with that fully set variables, so there's no variables left, everything is set, everything is preset, that's just whether or not those values have satisfied the formula already or not. So this is going to be equal to 0 or 1, the number of consistent satisfying assignments with those m presets where m is a number of variables is just whether those m values satisfy the formula, in which case, I get 1, or they don't satisfy the formula, in which case, I get a 0.
Critical to understand these in the Boolean case, because we're going to generalize this to the non Boolean case, and it's going to be just more abstract. The formulas are going to look the same. We're going to have to kind of-- we're going to lose the intuition that those things correspond to satisfying assignments. Or counting the number of satisfying assignments.
All right. So let's have a quick check-in here. So we're just going to do an example to hope to nail this in, this idea. So here's a particular formula phi. And now remember, number phi is the number of satisfying assignments. So phi, the number of satisfying assignments where I've set x1 to 0 and so on. And here I'm really kind of giving you two options in each row for the value. Now you have to check all that are true. So it's really going to be at most one per row, presumably.
All right. Let's see if you're with me here. So the number of satisfying assignments for altogether, well, there are two ways of satisfying this formula. This is really like exclusive or. So either x1 is 1, x2 is 0, or x1 is 0 and x2 is 1. So one of the variables has to be true. The other one has to be false. And then you're going to end up satisfying both clauses, as you can easily see. So b is correct in the first line.
Now, if I'm going to already commit to saying the first variable is set to 0, now how many satisfying assignments can there be? Well, the second variable just has to be set to 1 in order to satisfy. So now there's going to be only one satisfying assignment consistent with setting the first variable to 0.
Now if I set both variables to 0, now how many satisfying assignments can there be consistent with that assignment? There can be 0, because in order to satisfy this formula, one of the variables has to be 0. The other one has to be 1. If I'm presenting them both to 0, there's not going to be any satisfying assignments, because 0, 0 not satisfy the formula. OK, apologies for messing up that check in on the last day. Oh well.
All right. Let's first go over the protocol we attempted for number SAT last week on Thursday. So we're given the input, the formula, and a k. And remember what we want to happen. We want the verifier to end up accepting with high probability when k is the correct value and with low probability when k is not the correct value. Now, this is going to be, as you may remember from last time, this is going to end up being a flawed protocol, because it's exponential. We're only allowed to have a polynomial size protocol.
But just looking ahead in this protocol, the verifier is going to end up accepting with probability 1 for an honest prover and with probability 0 no matter what the prover tries to do. So for any prover, the verifier cannot be made to accept. So this is kind of an extreme case where there's not going to end up being any probabilities. But it's an exponential protocol. So in that sense, it doesn't do what we need. So let's go through it, because it really sets us up for the polynomial protocol with the non Boolean values.
All right. So first the prover sends-- let's just look at it and not rush it. The prover sends the number of satisfying assignments according to the prover. The verifier checks that is equal to k. And I think it's best to understand this first with the case that the input is in the language. So k is correct and we have an honest prover. And then we'll understand what happens if k is not in the language. And we'll see that no matter what the prover tries to do, the verifier is going to end up not accepting.
And again, this is just a setup for the real protocol. So this is kind of a dopey protocol. You're going to think, what in the world, why am I doing this? It seems like I'm making something that's very simple complicated, but it's really just the framework that I'm putting together. Because, well, you'll see. All right. So the proof is going to send the claim for the number of satisfying assignments, which in the honest case is going to be the correct value. The verifier checks that it matches the input.
Now the verifier says, well, I want to be convinced that your claim is correct. So the prover is going to justify that claim by saying, well, the total number of satisfying assignments is whatever it is, 100 because the number when I have x1 set to 0 is 60. And the number when I have x1 set to 1 is 40. And that adds up to 100, which is what you would need to have happen. So the verifier checks that the sum is correct and then says, well, now how do I know those two values are right?
So then the prover unpacks it one level further. So breaks those two down by justifying that phi 0 was correct, that value 60 was correct, by saying, well, now if I set the next variable, x2 to 0 and 1, that's going to have to add up to phi 0. So maybe to get 60, I had 50 and 10. And to get 40 for number phi of one, I had 20 and 20. So these I have to add up. So each level justifies the preceding level. We're going to have that happen again.
Now, the prover says, well, I mean, I need to be convinced. I don't trust you. I need to be convinced that these values are correct. So level by level, the prover is going to be setting more and more of the variables in all the possible ways until it gets down to the very bottom where it's setting the variables in all possible ways. So exponentially many settings here. And the verifier now checks that the previous round was correct. So that's where we set only the first m minus 1, the very last variable hadn't yet been set. So checks all of those 2 to the n minus 1 possible settings in terms of the new settings that we got where we set those m minus 1 settings, but we extended it by 0 and by 1. Again, this is the same identity that we used from before.
And now that the prover has sent all of those possible values, the verifier needs to be sure that those are still correct. But the thing is that at this point, those are all zeros and ones because they all say whether that assignment satisfies the formula or doesn't satisfy the formula. So the verifier can check those directly. Checks each of those, whether just by plugging into the formula and seeing does it satisfy the formula or not.
So each one of these is a 0, 1 value, which is supposed to correspond to whether the formula was satisfied or not. Those all are correct and everything else along the way has been correct. The verifier is going to accept. Otherwise if at any point one of those checks failed, the verifier has already rejected or at this point it just rejects. So that is the protocol, the exponential protocol.
And I'm not sure if this is helpful to you or not, but I like to think of it sort of as a tree of possibilities. So these yellow values are what the prover is sending. So the prover first sends the number of satisfying assignments all together. The verifier in white is checking-- are doing these checks. So it checks that it equals k. And then the prover sends the next level. The verifier checks that the addition works out. Then the prover unpacks it further, assigns values to the first two variables, and the verifier checks that just the assignments, just a single variable are consistent with that and so on. And to assign all m variables and then it checks directly with the formula.
Now, what happens-- and here is the case. It's going to be important to understand in both here and in the non Boolean case. What happens if we had an incorrect value for the input? And what I want to show you is that the prover is going to-- I want to show you that the verifier is going to end up rejecting in this case with certainty. Later on it's just going to reject with high probability. But for this protocol, it's going to accept with certainty. And why is that?
Because first of all, if the prover, if k was wrong, so I'm indicating the wrong values in red. If k was wrong, so it did not equal the number of satisfying assignments, if the prover sends the correct value, the verifier is just going to say it doesn't match up. I reject right away. So what can the prover possibly do to prevent the verifier from accepting? You're going to see that there's nothing you can do. But later on, there's a chance that the prover can get lucky. But here there's nothing you can do. Let's try to humor me and see-- let the prover try to manage to keep the verifier going as long as possible.
So the prover in order to prevent the verifier from rejecting at the beginning would have to lie about the number of satisfying assignments. But then the prover is going to say, well, OK, you're claiming there's only 99 satisfying assignments. Prover doesn't know what the right real answer is. But we know it was 100, let's say. But let's say k was equal to 99. The prover claimed it's 99 now. And so the verifier says, OK, well, it's 99. Convince me of that.
So now the prover is going to have to say the number of satisfying assignments for 0 and the number of satisfying assignments for 1, they have to add up. At least one of those has to be wrong, because you can't have the two correct values adding up to the false value. So a lie here has to yield a lie in at least one of those two places. And then a lie there is going to have to yield a lie in one of those two places, just like each lie kind of forces more lies. As you know, you're trying to lie. The story gets more and more complicated in order to try to justify all this.
And so in the end, you're going to get an inequality. And the verifier is going to end up rejecting. Somewhere along the line, there's going to have to be an inequality, if not along the way then at the very end when the verifier does the check itself. Because one of those, you could trace that down, there's going to be lies and lies and lies and then there's going to be at the very bottom one of these values is going to be wrong. And when the verifier checks them all, it's going to find out that there is an inequality there. And so one of those checks is going to fail.
So I'm getting one question here. Why is this any better than just checking all possible assignments without a prover? It isn't. The only reason I'm doing this is to get us ready for the arithmetized protocol where we have non Boolean values coming in. So questions on this? I think it's important to understand this one. Don't ask the question why. The why is just going to be we are getting ourselves ready for something later, which you don't know yet. But I want you to understand it for what it is, even if it seems unnecessarily complicated.
OK, so let's keep going. So how are we going to fix that protocol so it's not exponential? So again, here is a picture of that exponential protocol. And we have that exponential blow up occurring because at every stage, each value is going to be justified in terms of two values at the next stage. So it's going to be exponentially many values after a while. So instead, we're going to try to justify each value here in terms of just a single value at the next stage.
But it's not going to be good enough just to pick either the 0 or the 1 at random. Because it might be each-- there might be just a single course of lies going through here. And the only way you would be to catch that would be to guess correctly at each stage which was the lie. And then you would catch it at the end. If you're just going to be randomly picking zeros and ones, you're not going to have a high probability of catching the prover when it's lying.
And so that's not going to be good enough. The input might be the wrong value and you might have a prover which just has one path of lies, and then your probability, you would still have a high probability of accepting in that case, even though the input was wrong. It's not what you want. When the input is wrong, you have to have only a tiny chance, a very small chance of accepting. So the way we're going to achieve that is by having these-- instead of picking a 0 or a 1 for these random values, we're going to have non Boolean assignments to the variables. And we have to make sense of that. And we've already seen an example of that. It's going to be very much the same.
All right. Are we all together here? So this is a place where we could try, if you have a question, we can try to answer that. Are we good? Let's keep moving.
OK, so how are we going to arithmetize Boolean formulas? It's, again, the same idea we had before. Simulating ands and ors with plus and times. So we had this from before, same exact picture. Actually it's even simpler, because now we're going to be using the true simulation of or instead of some kind of a special case simulation of or, which we had in the branching program case. So these faithfully do what and and or does when you plug in 0 for false and 1 for true.
So that means that we can take an entire formula and arithmetize it. The formula built out of ands and ors and negations. And you're going to get a polynomial that comes out. And that polynomial, what's going to be important for us is not going to be of extremely high degree. The actual degree is going to be at most the length of the formula in terms of the number of symbols it has. You can check that on your own. But for now you can just trust me. The degree of the polynomial, because it only goes up during the multiplications, but the degree doesn't become too big.
And we're going to be doing-- and I don't want this to be a confusing issue here. We're going to be doing-- but we have to be correct. I don't want to be cheating here. So all of the arithmetic is going to be done in a field. So we have to do plus and times mod some number, which turns out needs to be a prime number for reasons I'm not going to get into. But it doesn't really matter. It's just modular arithmetic. And that's one thing that enables us to pick random values in a natural way, because there's only finitely many values in the field. And so you're just going to pick one at random.
But here we want to be able to represent-- it's going to be more important for us to have a larger field, because we want to be able to represent the number of satisfying assignments which can be a number between 0 and 2 to the m. So we have to have a field which has at least 2 to the m elements in it so that we can in a sensible way write down those numbers. Let's not get caught up with that. But we can try to answer those questions offline if you want. But just think about it for this first pass. We're doing the arithmetic mod sum prime.
So now we have the same notion of presets as we had before. So if we have a formula and we preset some of the values but now those values may be non Boolean values. We may be plugging in values for the formula. Not just zeros and ones, but we might be plugging in sevens or 23's or whatever. And the formula is going to in order to have a value, a meaning to that, we're going to treat that formula as the polynomial from the arithmetization.
And just plug in those values into the polynomial and see what the polynomial does for you. So here we're going to be presetting some of the values of the formula like we did before. And now it's going to be the same thing. But now in the polynomial, we're going to be pre-assigning some of the values of the variables to these a's from the field. And the remaining variables are going to stay as unset.
Now we have to give an interpretation. So the new polynomial here. So I'm getting a question. Well, maybe I better take this. Let me hold off on that for now what the degree is. I'll answer the questions in a second.
So now remember from before, number phi was the number of satisfying assignments when I preset the first i values. It no longer makes sense to talk about satisfying assignments, because these values may no longer be Booleans. So I'm going to have to write this formally as I'm going to plug in those values, those i values, for the first i variables. And the remaining are variables which I have not set. I'm going to assign them to zeros and ones in all possible ways. Only to zeros and ones.
Because what I want to have, you might think, well, why aren't we assigning these to other values in the field? Well, because what I'm aiming at is that if I were to plug in zeros and ones at this point into the polynomial, I'm supposed to get exactly the same values as I had before, because I'm simulating and's and or's. So I'm just extending the definition, the evaluation into a new realm. But I shouldn't change the values on the old Boolean realm.
So I'm going to be adding up the unassigned, the unset variables in all possible Boolean ways. And the first i values could be non Boolean values. So you have to just accept this as an abstract notion. No longer has an interpretation as satisfying assignments.
So as I said, what's important is that if I happen to put Boolean values in now, then phi and number phi give the same values as they would have before. Because the polynomial acts identically to the formula on Boolean values. OK. So this is what I'm repeating what I said.
And there's another point that also you have to check, which is that the identities that we had earlier that connected up what happens when I set the first i values and I set the first i plus 1 values, those still hold. So if I set the first i values now to possibly some non Boolean assignment, that's what I get when I extend those values to one more variable being assigned. But I just need to assign that variable to 0 and to 1 and add those up because of the way I've defined things over here. So I've assigned those variables to zeros-- the unset variable to zeros and ones when I'm defining the number phi function.
And then lastly, when I assign everything now to possibly non Boolean values, that's going to be-- there's no longer anything to add up. So I'm going to get exactly the same as I got from before when I-- so assigning number phi of totally preset input, it's the same as phi with a totally preset input. Because in that case, there are no variables left to add up over. So there's just one. I just get one single. I sum it as just one element in it.
So I got a question here for earlier. What happens to the degrees of the polynomials? Well, the degree of number phi is going to be at most the degree of phi, because I'm just adding things up. And addition doesn't change degrees. As I preset values, the number of variables goes down, but the degree may not necessarily go down. So the question was I got are the new polynomials having lower degrees? Not necessarily. They have fewer variables but not a smaller degree.
So let's do this check. Let's see if that-- now again, this is I think I have messed up on this. Well, there's one of these that's-- I'll give it away in part. There's only one of them that was true anyway. So you can check the one that's true according to the way we've defined it. So this is a little bit of a trick question here, as I'll explain. But there's only one of them that faithfully does the arithmetization as I described on this page. And that's the one you should check.
So remember, over here this is the formula. This is the recipe for how I'm doing the arithmetization. This whole process here. So one of these lines, one of these, a, b, or c, corresponds to doing that. I'm going to close this down. So are we all in? Yeah.
So a is the correct answer. A does the arithmetization according to the recipe that I just described. Because if you look at x1 or x2, we can just check it in the very first part of the polynomial. x1 or x2. Well, it's x1 plus x2 minus the product x1 x2. So you can just see it right there. The others don't have that. And similarly for x1 bar and x2 bar. It becomes 1 minus x1, 1 minus x2, and then the product of those. So a is pretty straightforward as the arithmetization of phi.
Now, in fact, any of those would work. I don't want to confuse you here. But any of those would have worked, because they all agree on the Boolean assignment. And that's all that really matters. So if you have any-- all I care about is that they agree. The formula agrees with the polynomial and the Boolean cases, and these all happen to agree and zeros and ones. Doesn't matter though. I put those there just in case you tried it by just substitution of zeros and ones in. You might have picked the wrong thing.
OK. So let's take a break here, and then we will see about how to go about fixing the protocol after the break. All right. So also happy to take any questions. We haven't really done a whole lot. We basically, this has all been review of what we did last time. But let me start the timer. But feel free to ask questions.
I'll tell you where we're going. This whole proof really comes down to understanding one line, which is going to be in the second half. So I'm really kind of-- this is all big setup here to get you ready to be able to understand that one. I'll tell you when it's coming. So you won't have to worry that you'll miss it. But that line is not easy to understand. So I think it's important to get all of the framework and all of the context all set up for you so then you can understand that line and hopefully you see that line and understand it.
OK, so the important fact. So let's go back. You wanted to see the important fact. OK. So this is what I was saying before. If I plug in Boolean values into the arithmetization, I get the same exact thing as I would have if I applied the Boolean operations before I did the arithmetization. So plus and times in the arithmetization give a faithful simulation of and and or according to these little formulas. That's all I'm saying with this. And so if I plug in Boolean values for the a's I get exactly the same as I would have gotten before I did the arithmetization. Because the arithmetization is a faithful simulation. Not sure how else to say it. Let's see.
What does the or rule now-- why does the or rule now contain the minus ab term while the previous instance of arithmetization didn't? Remember in the case of branching programs, we didn't need the minus ab term over here. And that was because we could argue that it was a disjoint or in the case of the branching programs. I don't want to get confusing by trying to explain why that was. But in that earlier case, we never took an or of two ones.
It was an of 0, 0 or possibly 0, 1 or possibly 1, 0. So therefore we never had to deal with a case when we had an or of a 1, 1. And here we can have that. So we have to subtract off that ab term, because otherwise we'd have-- if we just had a plus b, then the 1, 1 case, we would end up with a 2. And that would not be a faithful simulation of the or operation, because 1 or 1 should be just 1, not 2.
So this is a good question here. Do all the numbers need to be zeros and ones? I'm not sure how negation would work with larger numbers. The negation, you just blindly follow it. Even though we're going to be plugging in non Boolean values, it's going to be 1 minus 7. So you're going to get minus 6. You have to do that mod P, mod Q, whatever that value you get. But you can no longer think about it as negation in the former sense.
Now it just becomes a formal thing. You're just plugging along doing what the polynomial says. Numbers are coming out. You think this is just nonsense. But the thing is it's going to have a meaning that's going to be useful to us. That's what this protocol is going to show. So you can't think about it as negation anymore. It's just negation becomes 1 minus x in the arithmetized world and you just have to live with that. Let's see.
Another question here. If all the phi are equivalent for Boolean inputs in the check in, so this is back into this check in here, so if all of the-- yeah. So the question is if they're all equivalent in the Boolean case, why is only a correct? Because I defined P sub phi in a particular way. And so this was the value you got if you follow the way I define P sub phi. The others would work, they just weren't the way I defined it.
Any other questions here? We should probably move on. Can arithmetization be used in other contexts? Offhand, I don't know. There are these two cases where arithmetization works. Whether there are other cases too, I'm actually not sure. OK, so let's move on. So our timer is up. The candle has burned down.
OK. So this was-- OK, here we go. This is the real protocol. So I'm going to present it to you the way I did before. Let's think about it with the case first where the input is in the language and we have an honest prover. So we start off the same way. The prover sends phi, sends number phi. Which in the old sense was the number of satisfying assignments.
It actually still is, because since we're not presetting anything, there's no non Booleans in the picture yet. So this is going to be the same value as before. The verifier checks that k equals number phi. So that's why we have to have a big enough field there, so that we can represent numbers up to the number of potential number of satisfying assignments. But that's a side note. But anyway, this is exactly what we did before. No change. The number of satisfying assignments if you like.
Now, let's just see. Let's remember. And this is one of those cases where not having a big blackboard hampers us. So I'm just going to remind you what we did last time. But I'm going to change this. So remember before P sent-- and unpacked at one level. Sent the number of satisfying assignments said number phi of 0 and number phi of 1. And then we did that check to justify the previous value, which the verifier doesn't necessarily trust.
OK. Fasten your seatbelts, everybody. This is the whole proof in the next line. But it's a doozy. All right. P is going to send phi of z as a polynomial in z. It's going to send just a single object. But that object is an entire polynomial. And the way it's going to send that is by sending the coefficients of that polynomial. So let's digest that statement.
So first of all, let's understand the value of doing that. So if I can send the entire polynomial phi sub z represented as a polynomial, I can plug in 0 and 1 into that polynomial and allow the verifier to do the check that it needs to do to demonstrate that number phi is correct. So it's going to check that number phi is number phi of 0 plus number phi of 1. But instead of getting those values directly from the prover, it's going to take that polynomial it got and evaluate that polynomial at 0 and 1.
And just to remember, let's go back and remember how we defined-- defined number phi to make sure that we understand what it means to have a polynomial here. So remember, here we're just taking the very first value. But you are OK with putting a constant 0 or 1 and then adding up over all possible extensions, all possible Boolean extensions to that. And maybe it's OK to put in a non Boolean value here, like 7. And then you take the remaining variables and assign them zeros and ones in all possibilities and add it up.
Now I'm going to do something even a little wilder. I'm going to put in a variable for a1. Some symbolic, if you want, symbolic value. So I'm going to put in a value z for a1. So now I plug in z for a1 here. And a2 through am are going to be zeros and ones in all possible ways. So I just get a polynomial in z. The other variables get assigned and added up over the various Boolean assignments. And now I get some polynomial. So I get some expression in z. That's just going to be a single variable polynomial. Whose degree is it going to be? At most the degree of number phi. So degree is not going to be too big. So it sends the coefficients so the degree of that is not too big. So there are not too many coefficients to send.
So the coefficients are in terms of the xi's. No. I'm not sure what the mean-- the coefficients are not in terms-- the xi's are gone at this point. The xi's, we've added up the xi's being assigned to zeros and ones in all possible ways. So there are no other variables left. There's only z. So I'm going to do the same protocol in a more pictorial way in a minute. So you're going to see this whole thing twice. But try to get it. You'll have two chances to get this. Try to get it. Try hard each time.
So I've got send phi of z as a polynomial in z. Now, that's going to be enough for me to figure out what number phi of 0 and number phi of 1 is, because I plug it in for 0 and 1 for z. But now I can figure out what number phi of 2 is also, because I can plug 2 in for z or number phi of 7. I plug 7 in for z.
So let's stop here and see are there other questions. So is the size of number phi-- I don't understand. This question about the size of no phi. Is it 2 to the m? No, it's not 2 to the m, because the degree of that polynomial, number phi of z, I mean, it's a very large expression if you want to initially-- yes, it's going to be an exponentially big sum. But the prover adds it all up for you, and you're just going to have at most a small number of coefficients, because the polynomial is only of a certain degree. And a polynomial in one variable of degree d has at most d or d plus 1 coefficients to worry about. So it's not that many coefficients as an expression.
So shouldn't the summation take 2 to the m time? I'm not caring about the prover's time. The prover has a lot of work to do. But the prover sends phi of z. So yes, the prover has an exponential job. I don't care. The verifier needs to be able to check it in polynomial time. And that checking is going to, well, we'll have to see. How does the verifier know that that polynomial is right? That's a question maybe you should be asking.
Yeah. I'm getting lots of questions about how much time the prover needs to take. Yeah, the prover is going to have to spend exponential time to figure out that polynomial. That's all right. We don't care about the prover's time. Yeah. So the summation here is going to be adding up polynomials. That is correct.
I'm happy to spend time, because really here this is the whole proof. You have to understand. Well, we have to understand why this works. But we kind of understand half of it, because knowing that polynomial is enough to-- if you could certify that that was the correct polynomial for number phi of z, then we can use that polynomial to confirm the previous value, what number phi was, because you just plug in zeros and ones for z, and you add it up.
But now how are we going to justify that the polynomial is correct? Because this looks like even a worse job. Now we have a whole bunch of coefficients and have to make sure all of those coefficients are right. And so instead of just two values, now we have d values where d is the degree of that polynomial, which could be at most the length of the formula.
So here is the next idea. So the prover needs to show that phi of z is correct. The way it's going to do that, so even before we do that, so phi of z is going to be some polynomial. Now, the prover may be lying, may be sending the wrong polynomial. How does the prover convince the verifier that the polynomial is the right polynomial?
Well, that seems like a tough job. So what it's going to do is remember that the-- so there is a correct polynomial that you would get by plugging in to this expression for the correct value. So there's some correct polynomial. The prover may be sending some incorrect polynomial. So now we have the correct polynomial and the possibly incorrect polynomial. And the point is those two can only agree in a small number of places by that fact we proved a couple of lectures back regarding polynomials. So two different polynomials can agree only rarely.
So what we're going to do, the way the prover is going to justify that this polynomial was the correct one, is by evaluating it at a random place and then demonstrating that that value you get is a correct value. If the polynomial was the wrong polynomial, then evaluating it at a random place is probably going to disagree with the correct polynomial at that place, because they can only agree rarely.
So the prover is going to demonstrate that by evaluating that polynomial at a random place, that value you get is going to be the correct value, and it's going to continue to do that in the way, using the same protocol, as we'll see. So that's where we're going. So in order to show that phi of z is correct, the verifier now gets to pick a random value in the field. And the prover is going to show that evaluating that polynomial at r1 is correct. Remember this looks a lot like what we had from before where we were showing that number phi of 0 is correct and number phi of 1 is correct. Now we're trying to show that number phi of r1, this random value from the field is correct.
So the way we're going to do that is now by unpacking it one level down. And we're going to be using that identity, because this value here is going to be equal to number phi of r1 comma 0 plus number phi of r1 comma 1. But we don't want to send both of those. So we're going to send them combined into a polynomial of number phi of r1 of z as a polynomial in z. This is a new polynomial in z.
So now if you understood the previous line, then hopefully this one won't be too hard to swallow. Because now we're going to check the identity, but here by evaluating the polynomial again but one level at the next level. So this is perhaps a good place to take questions, because this is the-- this is really what I spent all the time setting things up for so that you would be ready to get this thing hopefully without-- and hopefully be able to appreciate it and understand it. So I'm not getting questions. Let's move on a little further.
So now again, the prover had sent this polynomial in stage two. Now the verifier needs to be sure that that polynomial is correct. So it's going to evaluate that new polynomial at a random location. So by picking a random value r2 in the field. And now we need to show that this value is correct, because if that polynomial had been the wrong polynomial, it disagreed with the correct polynomial almost everywhere.
And by picking a random place, it's probably not going to be the right value and so on. Until we get to the end where we have almost all of the values have been picked, and so we have one last value to select a 0 and 1. This corresponds to the n-th. It would be great if I could put both pictures on your screen, but I can't. So this very much corresponds to what happened in the exponential protocol but just along sort of this arithmetization single path.
So it checks that the previous value is correct in terms of expanding it with 0 and 1. But again, the 0 and 1 comes from evaluating the polynomial. And now the verifier needs to be convinced that that polynomial was right. So it picks a random value, but now it doesn't rely on the prover anymore. It's going to see whether that assignment that it gets by evaluating the polynomial with that random value rn plugged in is the same as what I get by evaluating the polynomial for the formula itself that the verifier can do directly. Because this is now a polynomial now just plugging into the formula and using the arithmetization to get a value out. So this was the last line of the identity. We had those two identities. So this is the second identity. And we had to check that this is correct.
So I'm going to show this to you in a picture. Not sure it'll help if you're confused. But why don't we take some questions on this? So as I said, I'm going to give you two chances to understand this. Because I know it's tough. Especially with the constraints of Zoom, this is a particularly challenging idea to explain.
OK, so let's see. So the benefit of this approach is that the prover only sends one item for each depth level instead of multiple items. That's right. But that one item is the polynomial. So that captures all of the values for the entire field. But taking advantage of the arithmetization, that one polynomial has a lot of information in it. And what's nice is that you can check that polynomial by just evaluating it at one random place. You can check that that polynomial is correct.
So I'm getting another question here. Where does this come from here? V checks that this here. So this where does this-- so you have to look-- to understand where this is coming from, you have to-- we're at the n-th round now. So you have to look back like at round two. V has to check that phi of r1, which comes from the end of the first round. So this checks that this phi of r1 is correct because that was how we justified the polynomial with just a single variable. The very first polynomial was correct. A little hard to say. But this comes from the previous round, this guy here. So this is the polynomial for the current round. This is the value from the previous round. All right. More questions.
So why doesn't this run in exponential time? Another question I'm getting. Doesn't V need to check twice at each layer? Yes. The verifier needs to check-- gets two values, but those two values come from the one polynomial. So there's no blow up anymore. Those two values. Maybe you'll see it in the picture that I'm going to show. So maybe just hold that question. Maybe this will become clearer in the diagram.
So another question. Does this work because the polynomial kind of encodes all the possible values together? I think that's sort of true. It sort of mixes them all together into one object. Then you have to check that one object, which can be done with this sort of random probing of it.
So this is another good question that we'll see explained in the next slide. So similarly in attempt one, the prover can keep lying by picking polynomials by continuing to pick polynomials, by lying about the polynomials. But eventually it's going to get caught, because this value is going to be the wrong value. If the polynomial in the previous stage and the m minus-- if a polynomial that the prover sent in the m stage is the wrong polynomial, then you evaluate it, you're going to get the wrong value probably. And so then that wrong value is not going to match the correct value, which is you can read off yourself by reading the formula.
I think we need to move on to the next slide. All right. So same proof, version two, but looks different. Again, the input is that. Here is what the prover sends. Here is what the verifier sends. I'm going to sort of whimsically design this as a telephone chat where they're sending each other messages through messaging. So the prover sends the number phi to start off with. And then off on the side, these are the checks that the verifier is going to be doing.
So here in our first round of the chat, the prover is going to send phi of z. Remember this is just a polynomial in not too many coefficients. So it's a polynomial in one variable. The degree is small. So there are not too many coefficients here. So this is just pretending this is what it might look like. So from that polynomial, the verifier can plug in 0 and 1 and see that that adds up.
Now the verifier, to check that this polynomial is correct, it picks a random value to evaluate this polynomial on. And so now it's going to have to check that this is correct. So this is nothing to check. You're just writing this down in anticipation of the next check. Now, the prover to justify that this value is right, that this polynomial is right, so we evaluate-- the prover in order to check that this value is right is going to send the polynomial for the next level.
Now, we can from that, we can plug in 0 and 1 for z. See if that adds up. And now to be sure that this polynomial is right, we evaluate it at a random place, calculate that value, and then have to see that this value is correct. So now we expand to one level further. We take a polynomial for the next variable. And we see that adds up. OK, I'm not sure whether this is helping or not.
But we keep doing that until we get to the very last round with a prover sending a polynomial. Make sure that this adds up correctly. And the verifier to see that this polynomial is right picks a random value and evaluates it and now checks that this agrees with the formula. Because we've now assigned all of the variables. And then we can check this number phi directly in terms of the phi, because they have to agree. And so the verifier would accept if everything checks out.
Let's see what happens. So this answer will answer some questions. Why don't I walk through what happens if the input was wrong. And we'll see how the verifier is likely to catch the prover but not guaranteed to catch the prover in this case. So if k was correct, the verifier will accept with the honest prover. But if k was wrong, so I'm going to, again, indicate the wrong values in red. I want to show you that the verifier is almost certainly going to accept but not guaranteed. So did I say that wrong? So if k is wrong, the verifier is going to probably reject, but it's not guaranteed to reject.
So first of all, if the prover does not lie, does not send the wrong value for number phi, The verifier is certainly going to reject, because it's not going to get any quality there. So the prover has to lie. Say if k was 99 but the real value was 100, the prover if it says 100, the verifier's going to reject immediately. So the prover's going to say, well, let's see what the prover can do to make the verifier hopefully accept from the prover's standpoint.
So the prover is going to send 99. Well, the verifier says, OK, 99, fine. Convince me. So the prover-- now one of these two is going to be wrong. Because the two correct values can't add up to the wrong value. So one of these is wrong. So that means the prover had to send the wrong polynomial. Because the correct polynomial would evaluate the correct answers here. So the prover had to send the wrong polynomial. So now when we evaluate it at a random place, chances are this is going to be the wrong-- this is not going to be the same value that the correct polynomial would have given you.
The prover could get lucky. The verifier might have just happened to pick a place where the correct polynomial and the incorrect polynomial agree. In that place, the prover will think, huh, I'm saved. Now I can act like the honest prover from this point on and the verifier will never catch me. It's sort of a little bit analogous to the situation maybe-- I'm trying to see if you really studied the whole course. So I'm giving you an exam by picking sort of random places there. But maybe you just studied a few facts from the course.
You might get lucky. I might happen to ask just about those facts. And then you give the appearance of having studied everything, but you really didn't. So here the prover might send the wrong polynomial, but the verifier just queries that at the place where it happens to agree with the correct polynomial, and the prover just gets lucky. And the verifier is going to accept, in that case. But there are very few of those. So that's why the prover is almost certainly to be caught if it tries to lie. But not guaranteed.
So just tracing this down. If this was a lie, then one of those two has to be a lie. So therefore, the next polynomial has to be a lie. And so we continue. So then the next value is almost certainly going to be a lie. Not guaranteed. And so then one of those two values has to be a lie. At least one has to be a lie. Therefore, the polynomial has to be a lie and so on until-- unless the prover got lucky along the way somewhere, which is very unlikely, even though it has a several opportunities.
We've arranged it so that the chance of getting lucky is tiny at each stage. So even though he has a few chances, there's still going to be a tiny chance that you're going to get lucky somewhere. And so this is wrong, then chances are that's wrong. And so therefore, this is going to be a disagreement. And the verifier at that point when it doesn't agree is going to reject. Unless the prover got lucky somewhere along the way, which is unlikely.
So I don't know if you had-- so that's all I was going to say about this proof. I don't know if you had any questions on it, but let's just see. OK. So do we have any questions I can answer? How the prover gets-- how does a prover get number-- how does the prover get number phi of z?
So you have to-- why is number phi of z have no other variables? You have to go back and look at the definition of number phi of a. Because you add up over all the other variables. So now instead of a, we're plugging a variable for that. But you're still adding up over the other variables. So this is a function in just one variable, because it-- the original thing was a polynomial. This is also going to be polynomial.
I think we're starting to run low on time. So this is our very last check in for the semester here. So of course there's one natural question to ask you all. And for our very last check in, as we're in our last couple of minutes of the course or at least the lectures, does P equal NP? What do you think? Will maybe PB equal NPB solved by a deep learning algorithm? Or maybe we'll never prove it. Give me your best guess. We're kind of running out of time. So let's not think too hard here. Another five seconds.
All right. Ending polling. I'll share that with you. Oh, I did share. So what did we get? D here. We will prove it in somewhere between 20 and 100 years from now. That seems to be the majority opinion. I don't know. I hope it'll be sooner than that, because I'd like to see the answer. But we don't know. Yeah, if you can prove P different from NP, I'll give you an A+. You won't have to take the final. But you better be sure you're right.
All right. So that is our quick review. We finished number set in IP and therefore that coNP is a subset of IP. If you're interested in further pursuit of this material, I got a couple of questions on that. These are some courses you may want to look at. I know I checked with Ryan Williams. He's planning to teach Advanced Complexity fall 2021. So that's going to be the most natural follow-on subject to this one. There's the crypto classes also are kind of make use of some of the same ideas. And there's, of course, also randomness computation that Ronitt Rubinfeld teaches. If I didn't check with her. I'm not sure the next time she's going to be teaching that.
And good luck on the final and best wishes. And I'm going to have office hours. So if you have any questions, happy to answer those. But otherwise, see you all. Good luck. Thank you for the comments. Yeah, I enjoyed having you all as students. It was a fun time. A lot of work, but it was a fun time.
I've always been intrigued by the P versus NP problem, and I proved a kind of a-- I proved the exponential complexity of computing the parity function in a certain weak model of computation. So parity function is obviously very trivial function. But for the parity function, if you can't count, whatever that means, but there is a model you can kind of set up where you can't count. Then parity requires exponential complexity. And surprisingly, not easy to prove. But that's probably the theorem that I'm most known for. Anyway. But that would be a topic for another day.
Another question. Why not include Myhill-Nerode theorem. I don't know. That's a theorem about finite automata and all of those ways of characterizing the regular languages. That seems kind of a technical theorem. I don't see much point in covering it.
And another question that some of my colleagues ask me is why don't I have Rice's theorem, which sort of provides a kind of a machine for proving undecidability. And I don't know. I think that you can use Rice's theorem without understanding how to prove undecidability. It's like checking off a box. Checking some boxes and then you conclude something's undecided. I'd rather have somebody understand it rather than be able to use some powerful tool.
Can we understand that proof about the parity function that I just alluded to? It's super hard. With the knowledge from this class, I think you can. That theorem relies on a certain technique which we didn't cover called the probabilistic method, which is a kind of an amazing method. Not hard to explain, but basically you show that something exists by showing that the probability that a random object has the property you're looking for is more than 0. And so therefore, the thing that you're looking for that has that property has to exist. There are lots of examples of that these days. But it's kind of an amazing method. So we use that method.
Do I think quantum computing can solve useful problems beyond the capability of computers? I have no idea whether one can really build a quantum computer. It seems to be always 20 years off at least to doing one that factors. And I've been literally I remember people 20 years ago saying it's 20 years off. So I don't think it's converging. I'm skeptical that they'll ever build a quantum computer that can factor. I'll go out on a limb and say that. But that's controversial. And whether it can solve other useful problems, I'm not sure what other useful problems are there. Well, I guess they're simulating quantum systems. So maybe that might be possible.
All right. I think I'm going to end this now. But thank you, everybody. Take care. Bye bye.