 speaker. So now I'm going to talk about some strengthening of what Joffra just described. So this is John's work with Randall's Blum and Daniel Wicks. So I'm going to look back at what Joffra talked about before. So pretty much what we built is a distinctive reference on music. So just to take a step back, we have a prover on the verifier, but now summer is approaching so they remove their hat unshaved, so that's how they're looking now. Pretty much so there's a series in the sky, and given this year as the prover using a witness for a statement, can send a proof to the verifier, and then the verifier using some special verification key can decide to accept another proof. So what I'll be mainly interested in during this part is the setup assumption that we make. In particular, the setup assumption that we make is that there's a magical entity that both publishes a series in the sky, but also gives this secret key to the verifier. So in particular, the setup is kind of complex in the sense that the trusted party has to interact with every verifier that participates in the protocol, and in particular if there's many pairs of say prover verifier that wants to participate, then the trusted setup has to talk to every verifier. So a natural question is to relax this trust setup assumption and to have something that is much simpler, and in particular it would be nice if we could make something work by using simply the setup of a music. So what do I mean by that? So that actually defines someone naturally, the notion of a mainly choose designate verifier in a music, where the setup is really just a series. So there's a magical throttle entity that publishes a series in the sky, and after that it can go offline. After that, any verifier can just look at this series and pick himself a secret key. So that will be his verification key. But now in some sense, the proof produced by the prover has to depend in some sense to this verification key. So what the verifier does is he also picks a public key that depends on this verification key and put that in the sky. So now given this series and this public key, any prover looking at both can publish a proof, so generate a proof pi, and now the verifier depending on this verification key can decide whether to accept or reject the proof. So in particular, the only change we make is really in the setup phase in some sense. So the protocol still has a strong flavor designated verifier in music, in the sense that, for instance, the proof are privately verifiable, and they're still hoped that this will be easier to construct than in music. But at the same time, we don't want to shift the trust of the trusted party to the verifier. In particular, the verifier could be malicious for, you know. So what we want is really to ensure that whenever the verifier is malicious, then security holds, so in this case, zero knowledge. And in particular, the verifier can pick his pair of keys maliciously. But actually, from the point of view of the prover, it's not even clear there's even any secret key associated. So what we really want is that the zero knowledge property holds given arbitrarily maliciously generated public keys. And in that sense, the security that we get is much closer to the music and also the setup in the sense that the only thing we trust is really that a magical entity put a serious in the sky. Just a quick remark. So this is the notion of a malicious-designative verifier in music, or MDV in music. And if I just reword the arrow, another way you can look at that is read that we have some kind of two-round zero-knowledge protocol. But what makes it really interesting is that the first message is reusable, so that really what gives this non-interactivity flavor. OK, so now the natural question is how do we build that? So the run map will follow pretty much closely what Jofa talked about. So Jofa just showed that if we start with a VPRG, you get music. And if you start with a designated verifier version of PRG, you get a different music. So naturally, what I focus here onwards is to focus on the malicious version of that and show that pretty much that surface is for music and how to build MDV PRG. So we call how do we use a DVPRG to implement the music engine? So here, the prover will choose a seed. The seed, along with the seros, will define many, many random beats. And the prover will also have generate proofs that beats are generated correctly. So now to implement the hidden beats, the prover will simply send a short commitment to the seed, along with hidden beats, and local proofs that those beats are generated honestly. So this will translate directly into the malicious flavor where the verifier now picks himself his key and gives publishers of a public industry. OK, so now the only thing that changes is if the verifier is honest, everything is the same as before. The only thing that changes is when the verifier is malicious. And what we used to argue zero knowledge of the designated verifier in music in the end is really that when the prover gives a local opening to some beats, the other beats still remain hidden. That's really what makes the hidden beats zero knowledge go through. So we want that naturally to hold given maliciously generated public use. And it's not too hard to show that pretty much this syntactical thing didn't change the proof, and malicious dvprg implies a malicious dvnyzics. So now we reduce the problem of constructing mdvnyzics to the problem of constructing malicious mdvprgs. So the natural step is, well, how do we construct that? So let me recall briefly the concept, you know, like slightly rephrase the construction of Jopho. And a natural question is to check whether the construction we gave before naturally satisfies the property we want. So again, you have a seed, like a commitment to a seed that will just be a group element. And S will be the seed that is chosen by the prover. And this is the same as A in JofaStalk. So in the CRS, there's a lot of different group elements, Jofa code that G2DBI. And pretty much we define those hidden beats to simply be those group elements in the CRS raised 2DS. So now there's also another part in the CRS that allows you to check whether those beats have been generated correctly. And in particular, you have some group elements that help you prove that pretty much S1 and G have the same discrete look, in some sense. So JofaStalk talked about the 2DS check. Another way to see it is that we actually have a designated verifier, nizics, for a kind of DDS language. And that's exactly chroma-shoot. So that's just another way to look at it. So now we can directly change the syntax to handle a verifier that picks the public key. And that will be the part that allows them to prove whether the beats are correct. And now what we want is that some kind of resilience whenever those group elements are generated maliciously. So say the verifier wants to attack the first hidden beats. Well, another thing to do, so in particular, he won't get the proof for the first beat. But the very easy thing to do is to simply rewire. So in particular, given the CRS, he can just set the last element of his public key to be the same element as the first bit of the CRS. Now, given how the proof works, actually just receiving the proof directly reveals the first beat. So it seems like very easy, and we broke it pretty easy. So is our hope lost? Well, it turns out we can fix that somewhat easily. And how do we fix that? We'll simply make all the hidden beats depend on many more group elements. So what do I mean by that? Now we'll have many, many more group elements that the number of hidden beats that we want in hand. And what we'll do is simply to pick some random graph. And now every hidden beat will depend on many random different base group elements. So also, to check the proofs, now we need to give the appropriate group elements CRS2DS. So how does it help us? Well, now suppose, again, that the verifier wants to learn something about the first hidden beat. Now, with high probability over the graph, well, so first, he has to actually recover if we break just some of your favorite hardcore beats. He has to recover all those group elements CRS2DS if he wants to do anything meaningful. And in particular, over the randomness of the graph, there's at least some group elements that does not appear anywhere in the other hidden beats that the verifier has to learn if he wants to learn anything about the hidden beat. So in particular, for the simple mix and match attacks that I described before, you can also argue that for a sufficiently high number of group-based group elements, that also happened. So if the verifier manages to do anything meaningful with the first hidden beat, he can actually compute some H2DS like by itself. So that sounds remade progress. But again, that's simply for a very restricted class of attacks. So what we show is that, actually, if we pick this random graph in a slightly careful way, you can actually prove security against any adversarial strategy for any malicious verifier. Under a slightly stronger assumption, let's go to one more CDH assumption. So it's like one more version of CDH. And that will directly give malicious-designated verifier on music from one more CDH. So next, Shu is going to talk about compact preprocessing music. So yes.