Anna Rose (00:00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

(00:00:27):
This week, Kobi and I talk with Dan Boneh, professor of Computer Science at Stanford, and the Director of the Stanford Center for Blockchain Research. We cover his most recent work in ZK Tech, both in education and in research, and then we walk through innovative use cases that he and his students have been working on since our last episode. It was great to have Dan back on the show, and I hope these ideas inspire listeners to jump into the research or maybe build some of these concepts into new products. Now, before we start in, I wanna invite you to ZK HACK III, a virtual event happening right now and running until December 13th. It's all online so you can join from wherever you are. ZK HACK consists of a multi-week series of workshops from the best teams working in zk teams like Aztec, RISC Zero, Aleo, Anoma, Scroll, Mina, Sismo, and EF's Privacy and Scaling Exploration Group.

(00:01:15):
These workshops are designed to onboard and show developers how they can start working with ZK DSLs platforms, tooling and tech. Each workshop is different, so have a look at our schedule and sign up for the events that you're most interested in. In tandem with this, we are running three puzzle competitions. With this, you are meant to find a bug in the ZK protocol and exploit it as fast as possible. We release one every week, and the winners of these will get prizes, spotlights, and lots of credit within the community. I also wanna highlight that the zkJobs Fair is happening as part of ZK HACK, and it's happening this week on December 1st. The workshop hosts, the teams I mentioned before will be there to meet with potential hires. The event is held in gather.town. It's a virtual space. You get a customized avatar you can run from booth to booth, getting to know different hiring teams.

(00:02:01):
This is a great way to get to know the teams before you actually go through the formal application process or just come to hang out with other participants from ZK HACK and see what kind of jobs are out there. So if you wanna attend, be sure to join our event on December 1st. This is the ZK HACK Sessions 4 with Aztec. At the end of that event, we're gonna be sharing links to the zkJobs Fair, or if you're already signed up for the ZK HACK Newsletter, we'll also be sharing the links there. So yeah, hope to see you at the job fair. Now Tanya will share a little bit about this week's sponsor.

Tanya (00:02:33):
Today's episode is sponsored by Mina Protocol. The need for private trustless solutions has never been more clear. A new era of ZK power decentralized applications is coming, and Mina is the place to build them. Introducing Mina zkSpark Cohort 0, where developers do tutorials and build zero knowledge applications or ZK apps and get rewarded. There are a quarter of a million Mina tokens up for grabs for zkSpark Cohort 0 participants. Mina's ZK apps are written in type scripts, so developers can easily get started without learning a custom programming language like other ZK protocols. To sign up for zkSpark Cohort 0 head to minaprotocol.com/zkpodcast. And if you're not tuning into the podcast live, no worries, Mina will be launching additional ZK Spark cohorts. Just visit minaprotocol.com to check out the best way to get involved. So thanks again, Mina Protocol. And now here's our episode.

Anna Rose (00:03:31):
Today, Kobi and I are here with Dan Boneh. He's a professor of computer science at Stanford, and he's the director of the Stanford Center for Blockchain Research. Welcome to the show, Dan.

Dan Boneh (00:03:40):
Yeah, and I excited to be here.

Anna Rose (00:03:41):
I should actually say welcome back to the show. You are on episode 100 many years ago, and it's very great to have you back for this episode, which I think should be episode 256. I wanted to pick a special one.

Dan Boneh (00:03:54):
Wow. I get the best numbers.

Anna Rose (00:03:56):
Definitely. And hi, Kobi.

Kobi (00:03:58):
Hello. Good to be here.

Anna Rose (00:04:01):
So Dan, I wanna ask you, in the last three years, it's been three years since you've been on, I mean, I feel like there's so much we can cover. Do you wanna share maybe some of the highlights, maybe shifting work or focus from the last time you've been on?

Dan Boneh (00:04:15):
Yeah, it's been, my God, it's been a while, right? Over three years and so much has happened. I think the zero knowledge world has changed quite a bit in the last three years. So we're seeing things now that honestly, even three years ago seemed, seemed quite far away there. There are lots of changes that have happened, if I can kind of go through the high points very quickly, I think the whole developments of ZK EVM and the progress that's been made towards making that real, you know, that's something that three years ago seemed, seemed very far, and yet, you know, now we're almost there, right? I mean, we already have some available ZK EVMs working at decent speeds, which is really, really quite impressive. The rollout of zkRollups has been very impressive.

(00:05:00):
You know, they're now live and very supportive. I think we're gonna be seeing in the near future ZK based bridges, so trustless that are made possible by the use of these succinct and efficient proofs. So in that sense, things have been moving really at quite a remarkable speed. I think we also, maybe even last time when I was on the show, we talked about using zero knowledge for compliance, and that has actually become even more important these days. So maybe we'll touch on that like later in the episode. So, yeah. So ZK has kind of become even more central and more of an enabling tool for the blockchain ecosystem than it was three years ago. It's really quite remarkable to see.

Anna Rose (00:05:42):
Definitely. I wanna just touch on something before we jump into some of the topics and new works. And that's the, like three years ago when we had our interview, soon after that, you and I started a planning of a course, the ZK course. Now, this ZK course I teased on the show, and like, I don't know if everyone realizes how far we got, like, we actually recorded a lot of stuff, but then the pandemic hit and it put everything on freeze and one of the challenges with research like this and, and topics like this, as much as we tried at the time to make what we were making, like atemporal, so it would last forever, time went on, and actually, some of it at least became somewhat obsolete. We weren't able to use it but this year I was so happy because in a way, we got to accomplish at least part of what we had set out to do. You hosted three modules of the zkWhiteboard sessions. This is something that our listeners might be familiar with. I often tease it in the intros. So this is like these three modules that act as like an onboarding, a mini course into ZK Tech. So yeah, I just wanted to sort of mention that because yeah, that was a project I was really bummed we didn't get to do, and I'm really glad we got to do something this year.

Dan Boneh (00:06:56):
Yeah, actually, we did get quite far along and then, yeah and then the pandemic hit, everything froze, and that kind of messed up our schedule somewhat. So yeah. Anna, thank you so much for doing the zkWhiteboards. I think that was a wonderful way to kind of make this happen. And now it's deployed. I was very happy to record the first three sessions. Basically the first three sessions are kind of an intro to zero knowledge, right? It's kind of going through

Anna Rose (00:07:20):
Totally

Dan Boneh (00:07:20):
What zero knowledge is and how it's constructed. It's even breaking it up into the components of you know commitment schemes and IOPS and then we construct each one of those in the session. So, yeah, so those three sessions take you basically from zero to PLONK and so good overview. And then of course, the rest of the zkWhiteboard sessions are amazing. They kind of go through everything that's been happening in the space.

Anna Rose (00:07:44):
Totally. And I think there might be more of these in the works. I'd love to do more with you at some point in the future too. I do wanna mention something that our audience may not be aware of, but there is this like mystery never aired interview of you, me and Vitalik back in 2019 or 2020, early 2020, talking about the future of ZK and all the use cases. And it's never aired. And I was just realizing this in prep for this interview that it would be, maybe it would be really fun to kind of dig that out if we can find it

Dan Boneh (00:08:17):
Yeah, yeah, you should, we should definitely post it. yeah, I know you should definitely post it on wherever you think is appropriate. Yeah, I remember we discussed applications of obfuscation and kind of advanced crypto to blockchain. So it's, yeah, it was a fun interview and I think it's a lot of parts of it, many parts of it are still very, very relevant. So it'd be great if we can post it.

Anna Rose (00:08:38):
We had this, I think we had a different way of categorizing how we thought about ZK so even that change might be fascinating, but yeah, I just wanted to throw it out there. If we find this, we'll definitely try to put it up on the podcast YouTube channel or something like that for people to see. Just, I wanted to also give people people context if we do find it. This is years old, so it's kind of like a from the archives. Yeah. Never aired.

Kobi (00:09:04):
It's interesting to see if you predicted the amount of PLONK variants that came out.

Dan Boneh (00:09:08):
Oh boy. Did we know

Anna Rose (00:09:09):
Was PLONK a thing then? I don't think PLONK

Dan Boneh (00:09:12):
PLONK just came out, yeah.

Anna Rose (00:09:14):
Wow.

Dan Boneh (00:09:14):
PLONK was just starting out its journey.

Kobi (00:09:16):
Yes.

Anna Rose (00:09:16):
Yeah. It's crazy. I don't know if we covered it, actually. I don't think we did or at least not in depth at the time. So a lot has changed. I wanna talk a little bit more about general ecosystem stuff though, because do you feel nowadays there is just like more resources, education? Like are you doing more education around ZK in general as well?

Dan Boneh (00:09:36):
Yeah, absolutely. In our regular course, in all of our courses on cryptography now, we we dive much more deeper into ZK than we did before. I have to say, what's happened is kind of interesting, you know, the idea for using proof systems to outsource computation, which is kind of what's happening here is is old, right? This dates back to the early 1990s. You know, there's this paper that I like to cite, actually, I like to quote, it's called the BFLS paper. The quote goes something like a single laptop can verify the computation of a herd of super computers. Yeah. This is like the vision back in the early 1990s and I think what's been holding the field back a little bit since then is the fact that, you know, computers got really fast.

(00:10:19):
So, you know, our iPhones now are like basically supercomputers and so we were missing an example of a slow and expensive computer that would then be used to verify the computation of very fast computers, right? Because computers just got generally so fast that it was difficult to justify outsourcing computation in a verifiable way. And now all of a sudden we got our example of a slow and expensive computer, right? It's basically a Layer 1 blockchain.

Anna Rose (00:10:46):
Amazing.

Dan Boneh (00:10:46):
Yeah. So because a Layer 1 blockchain is so expensive, and, you know, not particularly a fast computer, it actually now makes a lot of sense to outsource computation to a GPU and have the GPU prove to the blockchain that what it did is correct. And that's literally the kind of the reason why zk-rollups and zk-bridges and all that have taken off. It's really just examples of outsourcing computation. So it's really quite fascinating and beautiful to see that the vision from 30 years ago has kind of come now to fruition in the blockchain space because of what blockchains are. So, you know it's just wonderful to see.

Anna Rose (00:11:23):
So let's hear a little bit about some of the recent work you've been doing in the ZK space. Maybe we can talk about some of the use cases that you've been exploring.

Dan Boneh (00:11:30):
Oh, yeah. Great. Yeah. So there's actually a lot going on. Maybe I should say that like, the one thing that's really important to stress is that the blockchain community is building, kind of developing the technology of zero knowledge and, you know, advancing it by leaps and bounds. But what's interesting is it's like similar to the Apollo program, right? I mean, they were going to the moon and but in the course of going to the moon, they developed all these other technologies that were useful in other industries. So, cool and what's interesting is the same thing is happening in the world of zero knowledge, right? It's being driven by blockchain applications. The blockchain industry is the one that's kind of developing and commercializing these kind of systems. But because these things have now become so easy to use, you know, we have lots of frameworks that are quite easy for people to program in that now they're all, all of a sudden applications for ZK that are outside of the blockchain space altogether.

(00:12:20):
And I wanna give you one example. Like this is kind of a fun thing that we recently did. This is with one of my students Trisha Datta. And it has to do with using zero knowledge to fight this information. So let me tell you the story. So the problem is this. So as you know, when you read a newspaper, there's a picture usually that comes with a news article, and the picture is kind of related to what the news article is discussing. The problem is how do you know that the picture that you're looking at is really a picture that was taken at the place and time that the news article is discussing, right? So maybe you're reading an article about a war zone. Well, how do you know that the picture that you're seeing is really from that particular war zone?

(00:12:57):
Maybe it was taken somewhere else at a different time. And this is not like a, a hypothetical threat. This is really happening, and it's happening so much that if you just search for disinformation through images, you'll find many, many hits of ways to try to combat this, ways to educate the public about how to tell if an image is authentic or not. And so the media, the media industry was kind of aware of this problem. Generally, the news industry is aware of this problem, and they put together this interesting standard. Yeah, the standard is called the C2PA standard. It stands for content providence and authenticity. And let me tell you, let me tell you about the, your listeners might be interested in the standard in general and that what it does is it embeds signing keys inside of cameras.

(00:13:41):
Yeah. So, like, Sony has a camera that literally just came out this summer where the camera has a signature key in embedded in the camera, supposedly embedded in such a way that it's hard to extract the secret key from the camera. And then every time the camera takes a picture, it basically signs the data of the picture and it signs the metadata associated with it. Yeah, so it produces one signature that binds the picture to the location, the time, and other metadata that's associated with the with the image. Yeah. So now all of a sudden we have a signed photo that anyone can verify and see when and where the photo was taken. Okay, so newspapers in principle could embed those photos in the articles, and now people can verify that really the image they're looking at really did come from one of these authorized cameras.

(00:14:29):
Now, I have to say, there are lots of issues with this design. So maybe even your listeners are starting to think about all sorts of interesting challenges with this design. But one challenge is that what comes out of a camera typically is a very large image. Yeah. These fancy cameras, they used to like 30 megapixel cameras. So they produce very, very large images and newspapers don't need to send to their readers such large files. So what they do is they resize the images, they downsize them, maybe they crop them, you know, maybe they grayscale them. They do these standard operations on these images before they embed it in a news article and then they send this edited image to the reader. The problem is, once you've edited the image, the reader can no longer verify the signature. Right? You need the original signature, you need the original image in order to verify the signature.

Anna Rose (00:15:15):
Oh.

Dan Boneh (00:15:15):
So what do we do? Yeah. So C2PA had some mechanism proposed in the standard that is not quite secure. The correct solution is zero knowledge proofs. Yeah and let me explain why, how do zero knowledge proofs come in here? Come to the rescue here. So imagine you run your editing software and it resizes the image. What you'd like to do is then replace the signature on the edited image with a zero knowledge proof that says this edited image is the result of a properly signed image that all we did to it was just resize it. Yeah, so the secret witness in the zero knowledge proof is the written original image and the original signature and the statement we're proving, a) the original image was properly signed, and b) if you apply resizing to the original image, you end up with the image that was actually sent to the browser.

(00:16:10):
Yeah. So now the browser basically will get the, the down sampled image along with the ZK proof. The reader can just click on that image, the browser will verify the proof, and, and the reader will know, oh yeah, this image really is taken at, at this place and at this time.

Anna Rose (00:16:24):
That's fascinating.

Dan Boneh (00:16:25):
And so we did a lot of experiments on how to actually, how well this works in practice. And it turns out it works really well. Like the tools for zero knowledge have come so far that actually, even though the picture is huge, it's 33 megabytes of data. Right, it's a huge huge amount of data that needs to be processed here. We can actually do cropping and resizing and gray scaling and basically proof generation is under a second. Yeah and so we end up with a very short proof.

(00:16:54):
The proof is like 400 bytes that gets attached to the edited image that gets sent to the browser. The browser can verify that the only thing that was done to the image was just, you know a resizing of the image to make it smaller and nothing else was changed. Right. Maybe the image was gray scaled, but nothing else was changed. Verifying the proof is like blindingly fast, right? This is like milliseconds in the browser. So, yeah, so it works quite well yeah. So now I'm hoping that we can actually demonstrate this to the you know, to the associated press. If any of your readers happens to be affiliated with any news organization, please reach out to us. It'd be great to actually have this deployed and used in the real world, because it works. It literally just works.

Kobi (00:17:35):
So this is really, this is really interesting because in that use case that you just described, like resizing this, you use zero knowledge proofs for succinctness, basically. So theoretically you could still send the image and have interested users downloaded and verify all the transformations themselves. But it actually can be even more interesting because you can also apply blurring and transformations of that sort that where you would actually also use the ZK properties of this proofs.

Anna Rose (00:18:05):
Wow.

Kobi (00:18:05):
Which could be really, really interesting.

Dan Boneh (00:18:07):
Yeah, yeah. No, that's very true. So the, the reason they resize the image is because they wanna save bandwidths.

Kobi (00:18:12):
Yeah.

Dan Boneh (00:18:12):
So having readers download the original image basically would kind of nullify that. But you're absolutely right, cropping and blurring would actually be now be utilizing the ZK property. So that's absolutely right. So good, good application. What's interesting to me is that this is like I don't, it's a fairly important application of ZK it's got nothing to do with the blockchain. Yeah, because it is just basically verifying images. But the reason this is possible, right? The reason, the only reason this is possible is because ZK technology is advanced so much that we can generate proofs on huge statements. These are 30 megabyte statements. Yeah and we can generate them in, in a reasonable amount of time, you know, quite quickly. And the only reason this is possible is because the blockchain community has kind of developed ZK proofs to the point where they're this fast. So I think it's a kind of exciting story

Anna Rose (00:19:00):
Wow.

Dan Boneh (00:19:00):
Of how blockchain technology is bleeding into other areas of society.

Anna Rose (00:19:05):
I love hearing about stuff like this. I feel like there's a desire for more and more use cases, more and more ideas. I have never heard this one. So I think that's really exciting. And I feel like what you just described also potentially opens it up to other kinds of mediums too, like that the one you just referred to is image, but maybe it could be audio, maybe it could be something else. So that's really cool

Dan Boneh (00:19:29):
So actually I'll mention like an open problem for your listeners. So if somebody wants to jump in and help, we can now do this for these large images, but we'd also like to do this for video, right? Because video also gets downsized and edited and readers would like to verify that the video is valid. Video files could easily be gigabytes long, right? And so the question is how do we generate ZK proofs on such large amounts of data as a video? And so, yeah, this is a good challenge for your listeners if anybody wants to work on that. This is a good thing to try.

Kobi (00:20:00):
I'm actually curious if the standards already refer to how to sign videos as well, or is it just for images?

Dan Boneh (00:20:06):
Yeah so they focused on images because they were interested in the news application.

Kobi (00:20:11):
So it's also part of the innovation that could be by the, the listeners. So that's nice. Cool, cool.

Dan Boneh (00:20:16):
Yeah. How to sign a video. But more importantly, if you just do minimal editing to the video, like, I don't know, like let's say you just wanna zoom in on one particular character in the video and only publish that. How do you do a zero knowledge proof that that's the only thing you did? The only thing you did in the video is it zoomed in. And so yeah, proved that the resulting video came from a properly signed larger video.

Kobi (00:20:40):
Yep.

Dan Boneh (00:20:40):
Yeah, it's good. It's a good challenge. Maybe with enough GPUs we can do it, but right now this, this is beyond what we can do on a single laptop.

Kobi (00:20:48):
Yeah. Okay. Maybe, we'll have to wait for ASICs. We'll see.

Dan Boneh (00:20:52):
Yeah

Anna Rose (00:20:53):
Quick question, Dan, about that. Do you need to have the underlying file in its fullest form, or can you actually do things to like, already kind of compress it just for the proving part of it? Like, don't you just need sort of the proof of validity in a way? You're proving that it existed the way you say it existed, but when you put it into that proof, could you have already like, compressed it down a lot?

Dan Boneh (00:21:14):
Yeah, so the original signature, of course, is on the raw data. So you would need the initial, original raw data to prove that the original signature is valid.

Anna Rose (00:21:24):
Wow.

Dan Boneh (00:21:24):
And then once you verify that the initial signature is valid, then of course you can compress and do transformations and prove that the only thing you did is those transformations. By the way, there's a list of authorized, of allowed transformations. And basically what this proof does is prove that the only thing you did to the image is these is authorized transformations.

Anna Rose (00:21:45):
So Dan, I feel like there's a lot of use cases we could touch on. Tell us another one. What else are you working on?

Dan Boneh (00:21:50):
Yeah, so another application of of ZK that's that's come up recently is one that has to do with trusted setup. Yeah let's talk about how to do, how to do setups. Again, many of your listeners probably know that some examples of zero knowledge constructions, they do require a trusted setup, right? So this is where one entity generates what's often called the powers of Tau. And then Tau is this is this random secret value that that entity has to forget. Yeah. It has to erase. And, you know, often that's done with some interesting ceremonies where people go and break the machines that the power of Tau was generated on, or they do it in airplanes and they throw the machines off the airplane

Kobi (00:22:30):
Or they take like nuclear waste readings from Chernobyl, that also happened. Yeah.

Dan Boneh (00:22:34):
Right, right, right, right. So there are all sorts of interesting ceremonies that people do to generate these powers of Tau, but it's really kind of crucial that once the trust is set up is finished, it's really crucial that the secret data is removed. You probably know the, the Ethereum Foundation is actually working on powers of Tau ceremony. This is a super, super interesting ceremony that they're doing because it's gonna involve a very, very large number of people.

Anna Rose (00:22:58):
Oh,

Dan Boneh (00:22:59):
Yeah and so very interesting project, and I'm really happy to see them do this, this is probably the powers of Tau that they're building is probably gonna be useful for many other projects beyond just what the Ethereum Foundation needs.

Anna Rose (00:23:10):
Is this the perpetual powers of Tau that they've been running for many years? Or is it something else?

Kobi (00:23:15):
So it's a smaller one. It's the danksharding one.

Anna Rose (00:23:17):
Oh.

Kobi (00:23:18):
And that's gonna be very core in Ethereum. So that's really interesting. Agree.

Anna Rose (00:23:22):
Cool.

Dan Boneh (00:23:22):
Yeah. Yeah. So it's a very important ceremony that's about to take place and it's supposedly will involve, it's the largest ever, ever done. Yeah. It's supposed to involve like hundreds of thousands of users. So this is a paper that we submitted recently. This is joint work with Valeria Nikolaenko, who actually deserves a lot of credit for this idea is Sam Ragsdale, who deserves huge amounts of credit for the implementation and with Joseph Bonneau, who's also fantastic. And the idea there is basically to try to do this work on a blockchain rather than just do it as a standalone application. So we might ask, well, why do we need to do a trusted set up on a blockchain? The interesting motivation is that blockchains have anti censorship capabilities, right? So if somebody tries to block you from writing to the blockchain, well, the whole point of a blockchain is it's designed to make it possible for you to write.

(00:24:14):
So the interesting application here is if you try to run a trusted setup, maybe there is some network attacker that's trying to prevent an honest participant from participating in the setup, right? So maybe there's like a bunch of people who are in the setup, but if the honest participants can be prevented from participating, then we have a problem. So it's interesting to run the setup on a blockchain because we use the natural anti censorship properties of a blockchain to make sure that all the honest participants can actually go in and participate in the setup and this turned out to be kind of an interesting question. So now there's all these issues with how do you run a setup on a blockchain? And so basically the blockchain, what it would have to do is have to verify that every time a participant comes in and randomizes the current state of the setup, the blockchain has to verify that the participant really did its job correctly.

(00:25:08):
That it didn't mess up the setup. Yeah, it actually really did participate and contributed randomness as opposed to overriding everybody else's randomness or just submitting junk altogether.

Kobi (00:25:18):
So the blockchain replaces the coordinator part here, right?

Dan Boneh (00:25:20):
Exactly. Exactly. Exactly. And it turns out, there're kind of a couple of models here. So the two that, that are interesting is you can imagine putting the entire powers of Tau on the blockchain. Yeah. And then basically the chain will just verify that every update is done correctly. So that's one approach that works for small setups, right? Where like in danksharding, you know, the amount of data that's generated is not that high. So you can imagine storing all of that on, on the blockchain. So the question is, what happens if you would like to actually not store this data on the chain, and instead you'd like to store it off chain, in which case what you could do is you can just store commitment to the data on chain.

(00:25:59):
Right? And so you have a commitment to the power of Tau that's stored on chain and now when someone updates the powers of Tau, what you would do is they would update the commitment that's stored on chain. So they would upload a new commitment on chain and then provide a proof that the new commitment is a valid update of the powers of towel relative to the old commitment. Yeah. That would be the zero knowledge proof. Now this is kind of starting to be kind of interesting.

Kobi (00:26:24):
Yeah.

Dan Boneh (00:26:24):
How do you do that proof? That's basically kind of what's worked out in the, in the paper. One interesting question is now you have a data availability issue, which is somebody has to store these powers of Tau. Yeah. So presumably we have to use one of the data availability services.

(00:26:40):
You know, there are many of those that are now forming. That's where the powers of Tau will actually be stored. The chain itself is really just used for anti-censorship, and all it does is it just updates commitments, you know, from updater to updater. So it seems to be like a good use of the properties of a blockchain. Of course, it'd be nice if we had a chain where gas costs were lower. So actually, you know, more people can participate without having to pay the gas costs associated with each update, you know, but hopefully that's coming in the next couple years. So anyhow, I thought this was kind of an acute application of ZK connected to to something that's stored on the blockchain.

Kobi (00:27:21):
Yeah. And I do agree that it's really cool because in all the setups that I've seen and that I've participated or ran, and basically you have to rely on social layers to enforce that on that censorship presents this property because you would post on Twitter or then you would cast some doubt maybe on the coordinator that censored you and not having to rely on that is exactly why I invented blockchains and that's that's really good use, yeah.

Dan Boneh (00:27:49):
Yeah. Right, right. Yeah. So we'll see. So maybe even something like that can become commercial and used in real systems.

Kobi (00:27:58):
Yeah

Anna Rose (00:27:59):
Quick question about that Dan. When you actually produce, so like you've, you've talked sort of through the process of producing this, I sort of imagine this happening on an L2 cheaper than an Ethereum ideally, but the outcome of that, does it go directly into the smart contract that activates the ZKP or would it still have to do something like outside before you, like I just, I always think of the trusted setup as like, this thing you have to do in order to start the SNARK or to start the process. See, I wonder is it all on chain or is it just this part?

Dan Boneh (00:28:31):
No, that's a very good question. So actually the proofs that participants contribute to prove that they updated the setup correctly, of course that has to be done with what's called a transparent SNARK. Yeah. So one that actually doesn't require trusted set, so it's kind of interesting that we're using, we're using a transparent SNARK to bootstrap a SNARK that does require a trusted setup. Yeah. And that's, what happens is the randomization process and the proof generation of course happens off chain and then what the party that did this work, what it would do is it would actually write this data on chain in the chain, which is verify proofs. Yeah. So the chain basically does what it does best, which is update commitments and verify that the update was done correctly by verifying a short proof.

Kobi (00:29:20):
 I think Anna, you were kind of asking whether we can use this directly, like let's say in some let's say ZK EVM or something, right? Like that's kind of what you were getting at?

Anna Rose (00:29:29):
Exactly. Yeah. Like, it's almost like some deployed SNARK on the, like, and this is where, even though I've done a number of episodes on the trusted setup, I don't know if I'm completely aware of like the moment that the, what is it the SRS actually gets activated or gets used? Like can, I think the question here is does it go the full process? Like, can you do this generation and then it sort of like falls right into an on chain zk-SNARK and makes it private?

Dan Boneh (00:29:57):
That's actually a great question. So it and the answer is yes.

Anna Rose (00:30:00):
Okay.

Dan Boneh (00:30:00):
It does, right. Because what happens is the, you know, what we call the verifier parameters, right? The parameters that the verifier uses to check proofs, you know, those live on chain all the time. They just get updated every time the SRS is refreshed. But those do live on chain. And then, you know, any contract that wants to use them can just read them and use them to verify proofs.

Anna Rose (00:30:21):
Okay.

Dan Boneh (00:30:22):
Yeah. It's a great question actually and that actually is completely supported.

Anna Rose (00:30:25):
Cool.

Kobi (00:30:26):
Yeah. But although I think that actually you might have a problem when you're talking about deploying circuits because when you have PLONK and let's say other universal SNARKs usually have to go through this indexing step, and that's going to be hard to do on chain

Dan Boneh (00:30:42):
That would be done off chain. Yeah. Yeah. So the setup, the pre-processing setup would be done, would be done off chain but that's because you just, there's no reason for the blockchain to actually do the indexing itself.

Kobi (00:30:52):
Yeah. But you would've a hard time verifying that basically this was derived from the parameter that we're on chain. So you would still have this semi-trust on the off chain process to deploy the contract. Right?

Dan Boneh (00:31:07):
Well, I mean, so that's interesting. If the wrong parameters were used in pre-processing and then you are in the indexing part of that phase, and then you try to generate a proof using the wrong parameters. Yeah. The verify will fail.

Kobi (00:31:20):
Yeah, that's fair. That's fair. You would verify

Dan Boneh (00:31:23):
You'll end up producing wrong proofs. Right. So that's not very helpful to anybody. Yeah and then the on chain contract would just reject those proofs.

Kobi (00:31:31):
Yeah. I'm more thinking about in the context of let's say the dream of updateable SNARKs where you, you would have a SNARK that always updates and that you can keep using an up to date version whenever a new participant contributes more randomness. But I think maybe this indexing part a bit hurts that dream.

Dan Boneh (00:31:51):
You know that, no, that's again, an interesting point in that every time you go through a series of updates, you can imagine like a batch of updates that happen. Yeah. You would have to rerun the indexing algorithm, but the indexing algorithm is, is deterministic. Right.

Kobi (00:32:06):
Yes

Dan Boneh (00:32:06):
Anyone can check that it was done correctly. So there's no trust assumption there and so you would just, somebody you would have to off chain would have to rerun the indexing algorithm.

Kobi (00:32:14):
Yeah.

Dan Boneh (00:32:14):
Yeah and then push the results of indexing, you know, the verifier parameters on chain and then the contracts on chain would use it.

Kobi (00:32:23):
Yeah. Okay. That's fair.

Dan Boneh (00:32:24):
A lot of people contributed to the secret randomness and the point of course is that no one was prevented from contributing to the secret randomness.

Kobi (00:32:30):
Yes, definitely.

Dan Boneh (00:32:30):
Because of anti-censorship.

Kobi (00:32:31):
Cool. Yeah. Amazing.

Dan Boneh (00:32:33):
So, yeah, I don't know. I hope this will some projects will actually end up using this kind of mechanism. Although I have to say that what the Ethereum Foundation is doing is super, super interesting. So that project, I really can't wait to see it take place. And I'm really looking forward to seeing the huge number of participants that contribute randomness there. So yeah. Lots of things happening in the space.

Anna Rose (00:32:56):
Yeah. So, going from trusted setups, are there any other kind of spaces in the blockchain world, maybe kind of areas that we're trying to tackle or add ZK stuff into?

Dan Boneh (00:33:08):
Yeah, the list is really long at this point. Maybe I can mention one more, one more example. Sure, sure. So one thing that we were interested in is this question of how to run a DAO with a private treasury. Again, this is work with one my former students Griffin Deneuve. And the question basically is, if you run a DAO today on chain, you know, everyone can see what the treasury of your DAO is. Right? And this causes a problem where, say, when a DAO wants to participate in an auction, right. If you participate in an auction and everybody can see what your treasury is, you know, everybody knows exactly what your maximum bids can be and this is not hypothetical is, you know, this is exactly what happened with the constitution DAO, right? Where you know, the participants knew exactly what is the biggest or the largest bids that the DAO can issue, and then somebody just issued a larger bid and outbid them.

Kobi (00:34:00):
Yeah.

Dan Boneh (00:34:01):
Right? So the question is basically how, so a) you can, you can take this in two different ways. You can say from a game theoretic point of view, what is the correct auction mechanism where you have participants where some of them who have private state, you know, humans basically have private state, and some of them have public state where everybody can read their minds. Yeah. How do you design auction mechanism in that sort of environment?

Kobi (00:34:24):
Yeah.

Dan Boneh (00:34:24):
That's kind of a game theory question or a mechanism design question that should probably be solved, actually. I mean, I'm a little, it's kind of important for auction houses to change the way they do auctions because DAOs participate and everybody can read the mind of the DAO and see exactly what their treasury is.

Kobi (00:34:41):
Yep.

Dan Boneh (00:34:41):
The other way to go to take this question is to say, well, you know, can we actually design a DAO they can participate in an auction and keep its treasury secret?

(00:34:49):
And that's again where ZK comes in. Yeah. And so the private DAO design, it was kind of a fun design to to work on, it's basically where we build what's called a DAO platform. Yeah. So it's one contract that will service many, many different DAOs. Yeah. So Juice Box is an example of such a platform, right? Where it's one, literally it's one contract on Ethereum that many different DAOs use. And this one contract basically makes it so that the treasury of all these DAOs is all combined together. So I know somebody looks at the treasury of this one contract, all they'll see is the aggregate treasury of a large number of DAOs, but they wouldn't know the treasury of a particular DAO. And so to make that possible, it's very important that when someone sends funds to the DAO, they don't reveal to the public, which DAO is the recipient of those funds.

(00:35:43):
So in some sense, you need to be able to send funds to the DAO in secret, that is you're sending funds to the platform, but the world, the public doesn't see which DAO on the platform is the recipient of the funds. Yeah and you can see that that's kind of where ZK techniques start start to come in so now the DAO basically has a, has a list of deposits that were, or rather the platform has a list of deposits that were sent to it. You know, some deposits were meant for one DAO and some deposits were meant for another DAO and now the, the, the manager of one particular DAO on this platform would actually have a secret key. It could use the secret key to then say, you know, these 15 deposits are mine, and here's a proof that they're mine because I have a secret key that proves that these were actually meant for me.

(00:36:29):
And then the DAO contract will say, sure, these 15 deposits really are for you, and therefore you can, if you decide you can go ahead and send them to the auction house to participate in the auction. Yeah and so it turns out that doing this, this is again, where, SNARKs turned out to be super, super useful because imagine you have one particular DAO that received a large number of donations, let's say, I dunno, 20,000 donations. Well, if you had to do a separate proof for every one of those donations, the DAO manager would have to prove this donation is mine, this donation is mine, that donation is mine. They would've to repeat that 20,000 times, and the chain would have to verify those 20,000 proofs separately. Instead, you know, we can use SNARK batching techniques where we can take a bunch of proofs and squish them into a single proof, and then just present that single proof over to the contract.

(00:37:23):
And the contract can just now verify this one single proof that says, yes, all these, you know, 20,000 donations belong to this one, that were sent to this one DAO and therefore the DAO manager can direct those funds to the auction house, yeah so

Anna Rose (00:37:38):
Cool.

Dan Boneh (00:37:39):
And I have to say, this is something that still needs to be built commercially. Like it works. It is a prototype that shows this is very practical. It actually works. It doesn't cost that much and yeah, I dunno, you know, I'm hoping again, one of, hopefully some of your listeners participate in DAO platforms and maybe we can take, we can take that design and make it real. It'd be, I think it'd be something that DAOs would really benefit from.

Kobi (00:38:05):
Well, what kind of batching technique have you used here to make this efficient?

Dan Boneh (00:38:08):
Yeah, so actually it turns out the basic proof is what we use is it's sufficient to use a very simple sigma protocol. So it's sufficient to use just kind of a proof of discreet log. So the same type of proof to go into Schnorr signatures were actually sufficient. And so the batching, the naive batching is to just use the same aggregation technique or same batching techniques that apply to verifying Schnorr signatures.

Kobi (00:38:32):
Yeah.

Dan Boneh (00:38:33):
So, you know, if you need to verify a large number of Schnorr signatures, there's a way in which you can actually save some work there and so that was like the simple design, but that doesn't bring it down all the way. Ideally, you know, the right thing to do is to actually use a SNARK to prove that, you know, these 20,000 deposits are all mine produce a single proof that the contract can verify and that would kind of make on chain work minimized. So there's still a need for a SNARK here.

Kobi (00:39:01):
Yeah.

Dan Boneh (00:39:01):
That's used primarily for speeding things up.

Kobi (00:39:04):
I'm also curious if the design included some measures for compliance or traceability that, for example, the DAO could show to, you know, someone that wants to look more deeply into their finances, that everything is fine.

Dan Boneh (00:39:17):
Yeah. So that's again a fantastic question. So compliance, yeah. We should definitely switch gears and talk about ZK for compliance too. So the basic design actually was just focused on the privacy of the treasury, but of course, now you're absolutely right. Everything that as we learned, you know, you know, these systems do need to provide some compliance capabilities and so that, yeah. That remains for the DAO application that does remain to be done. And so, but that actually suggests maybe we should switch topics

Anna Rose (00:39:47):
Sure.

Dan Boneh (00:39:47):
And talk a little bit about another area where compliances might be useful, which is for mixers.

Anna Rose (00:39:55):
Yeah. So we are recording this right now, just the week after this whole FTX thing has gone down. And we also, this summer went through the Tornado Cash OFAC sanctions. I've done a few episodes on that just sort of showcasing like the impact and what it's done. But I think it had a really, like both of these things are, I think are gonna have a pretty profound impact on ZK research and use case development. Like on one side, can ZK actually be used to help mitigate some of these problems in the future? So yeah, tell me, are you doing any work in that direction?

Dan Boneh (00:40:29):
Yeah, yeah, absolutely. I mean, so I'm actually glad to see how you framed it, Anna, that ZK could be used for privacy, and ZK can also be used for compliance. Yeah and in fact, there are a couple of companies out there that are using ZK for compliance. I mean, one example of course is Espresso Systems. That's kind of one of the things that they promote. So in the context of Tornado, there is a way to approach this from a technical point of view, which is to ask how could have Tornado been designed, you know, to maybe reduce the risk of you know, the sanctions being applied to it. Yeah, so that's a tech, we can approach this from a technical point of view. Of course, you know, policy makers would approach this from a policy point of view, which is, you know, what's allowed, what's not allowed and so on. But, you know, we're computer scientists, we like to think about technical questions. And so, you know, there's this interesting

Anna Rose (00:41:18):
An experiment?

Dan Boneh (00:41:19):
Yeah. It's an experiment. Exactly. No, I like how you say that it is an experiment, which is, if we had to start over and we could redesign Tornado, is there a way to design Tornado in such a way that still provides strong privacy but is compliant with, or maybe I would just say deter bad actors from using the service. Right. Because really that's kind of the ultimate goal, just we want bad actors to not use the service. So let me kind of summarize these kind of three approaches. These have been discussed separately in a number of places. But let me just describe these three approaches that might help. Here again, I'm not a lawyer. I mean, none of us are lawyers. We have no idea if this would actually satisfy the sanctions folks.

(00:42:00):
But, you know, just as a intellectual exercise, yeah. Let's just think about how, what might have helped here. And by the way, I should say this is something that we've written about this is written about this with Joe Brosen and Michele Krover. And so let me kind of summarize three different avenues that we could, we could try to go down. The first one is actually, it's actually somewhat weak, but let me say it anyhow. This is what we would call deposit screening, right? So deposit screening means that when someone tries to move into the contract, say into Tornado, the Tornado contract would actually check is the source address on the current sanctioned list. Yeah and you know, there are a bunch of companies that provide a sanctioned list. It's actually these it's kind of interesting. So Chainalysis provides one, Elliptic provides one, these are kind of very simple contracts that you can look them up on chain.

(00:42:48):
And these contracts literally have a function called 'is Sanctioned'. Yeah and you called, you say, 'is sanctioned address', and then the contract returns true or false if the address is currently sanctioned or not. Yeah. So there are a bunch of these contracts available online. Last time I looked, there aren't that many addresses on that on that list. So I dunno, maybe they'll update more, aggressively in the coming years but that's what's available today. So this is called deposit screening, where when you try to deposit it into a Tornado, basically Tornado will check if the address is currently sanctioned, and if so, it will just reject the deposit. Yeah, makes sense? That's a simple solution. The, the problem is this doesn't really work. Yeah. The reason it doesn't work is because, you know, if a hack happens and somebody moves the funds into Tornado, right?

(00:43:36):
The hack would happen and within minutes the funds would move into Tornado and there's no way the sanctioned list would update within minutes. Yeah and so by the time the sanctioned list has been updated to block that address, it's too late. Now the funds are already inside of the mixer.

Kobi (00:43:50):
Yeah.

Dan Boneh (00:43:50):
Yeah. So it's a good thing to do, but it doesn't quite solve the problem we wanna solve. So the next idea is to use what we call withdrawal screen. Yeah. So as you know with mixers, once you move your funds into the mix, you have to wait, you have to, the funds have to sit there for a while because if you just move them in and immediately move them out, you didn't mix it all. Right? You get no benefit from from the mixers. So the funds have to sit there for a while.

(00:44:16):
In fact, the recommendation is they sit there for a few days before you take them out so that, you know, they get mixed with the rest of the traffic. Yeah and so well, by the time you try, you, the bad actor try to withdraw the funds. Hopefully by then the sanction list has already been updated and now your source address, the address from which the funds came actually are now blocked

Anna Rose (00:44:38):
or flagged. Yeah.

Dan Boneh (00:44:39):
Oh yeah, yeah, exactly. Your source address is blocked or flagged. No, that's exactly right. So withdrawal screening basically says that at the time that you tried to withdraw from the contract basically you have to prove that the source of the funds is not currently on the sanction list.

Anna Rose (00:44:56):
Oh

Dan Boneh (00:44:57):
And so yeah, this is what we call withdrawal screening and what's interesting here is what's the technical tool that's needed for this is what's called an exclusion proof.

(00:45:06):
Yeah. So it's a very small change to the Tornado contract, at least a Tornado Classic. It's a very small change that at the time that you're withdrawing, you proven your knowledge, again, what's called an exclusion proof to say that the source address of the funds is not on the current sanctioned list.

Anna Rose (00:45:25):
Wow.

Dan Boneh (00:45:25):
Technically, this is like, we know how to do this. It's quite simple, it's quite efficient. You know, exclusion proofs, if your listeners don't know about exclusion, proofs, go read about them. It's quite easy to do exclusion proofs using Merkle trees. Yeah. There's a very simple trick that lets you do exclusion proofs using Merkle trees, and you can prove that your address is not on the list as opposed to is on the list. What's interesting about this is if you are a bad actor and you move funds into the contract, and then at the time you want to withdraw, your funds have been, sorry, your source address has been added to the to the block list, then basically your funds get trapped in the contract.

(00:46:04):
You can never withdraw them and so that's interesting because that actually discourages bad actors from moving into this contract to begin with. Right, so maybe they'll just, you know, they'll stay away altogether.

Kobi (00:46:14):
Yeah.

Dan Boneh (00:46:15):
And so maybe that's a way to help the design. Now, by the way, this, this only applies to Tornado Classic. When you look at more complicated designs where you can do transfers inside of the contract, things get a bit more complicated. One can even think through how to do withdrawal screening even in that setup. So that's kind of the second approach. Yeah, does that make sense? So basically verify that you are not flagged during, at withdrawal time. And if you are flagged, well, sorry, your funds are trapped.

Kobi (00:46:47):
It's interesting though because Tornado itself did include this offline compliance mechanism, right? Where you could reveal enough details to someone that wanted to verify that where the fines came from and so on. But this would make this on chain verifiable which seems like big improvement.

Dan Boneh (00:47:08):
Andthe compliance tool you're referring to was voluntary. Right so, you know,

Kobi (00:47:12):
Exactly.

Dan Boneh (00:47:13):
Most likely a bad actor would just not go through that through that process.

Kobi (00:47:17):
Exactly. Like it would help an honest actor to show that their funds are okay. But a dishonest actor would just ignore it. Yeah.

Dan Boneh (00:47:25):
Yeah. Exactly. I should say that this withdrawal screen method, there are lots and and lots and lots of variations of it that you can imagine.

Kobi (00:47:31):
Yeah.

Dan Boneh (00:47:32):
But one takeaway from that is that hopefully, you know, because of the threat of your funds getting locked in the contract, that will just keep bad actors away. But more importantly, you realize it doesn't hurt the privacy of good actors. Yes. Right. So good actors, you know, remain, you know, you're not able to eavesdrop and or peek into what they're doing. We should keep this tool in our pockets to remember there is a way to try and discourage bad actors from using the system without actually hurting the privacy of good actors. The third approach which is I think a little bit more problematic from a privacy point of view, is what are called viewing keys.

(00:48:08):
Right. So viewing keys is probably something you discussed at length in the, on your, on your podcast, Anna?

Anna Rose (00:48:14):
Yeah.

Dan Boneh (00:48:14):
Right, so viewing keys is basically where the depositor has to encrypt the source address under some authorities public key, which authority is not clear. you know, who owns the secret key is not clear. So viewing keys are in some sense kind of, it's basically a back door, right? It's a back door,

Kobi (00:48:31):
Yeah.

Dan Boneh (00:48:31):
To the privacy of people transacting with the system and all the issues with back doors come up in this, in this environment as well. So viewing keys definitely are a way to go. And in fact, it's interesting our many people in our community, in the blockchain community that you talk to, and they want to implement compliance, viewing keys are sort of the first solution that they go to.

Kobi (00:48:51):
Yes.

Dan Boneh (00:48:51):
And I just wanna make sure you discussed on a viewing keys at length, Anna, I imagine in other podcasts so I don't know that we need to talk about them too much

Anna Rose (00:48:58):
Well, I don't know if I've talked about them at length. They've come up, but actually in this comparison that you just made, like listing those three approaches, it does seem like a very kind of, it's like the big hammer one, but you actually open the door to a data leakage of all sorts. What if the wrong person gets a hold of those and then can see all of the data and leaks, all the information. So there's lots of problems associated with that.

Dan Boneh (00:49:23):
Yeah, yeah, exactly. Those are all the questions. I mean, you're asking exactly the right questions. These are all the questions that come up generally with with back doors. And I guess that's the term that they're called, and in the industry who gets access to the back door. What if the back door is stolen? What if it's lost? Yeah. There are all, all sorts of administrative and management questions that come up with that. So what's interesting is I just wanted to kind of contrast the fact that viewing keys is kind of where people naturally go to when they need to deal with compliance. But I just wanted to mention also this withdrawal screening, at least in the context of Tornado Classic.

Kobi (00:49:58):
Yeah.

Dan Boneh (00:49:59):
That is another tool in our toolbox. Again, we don't know if this will satisfy regulators. I mean, we have no idea if this will actually satisfy the requirements, but I think it's a good tool to remember and keep in our pockets if we need to design compliance systems.

Anna Rose (00:50:13):
That was interesting.

Dan Boneh (00:50:15):
Yeah and by the way, the open question there is, it does get more challenging if you can do user to user transfers inside the contract. There are multiple sources for funds when you withdraw those funds and then all that would have to be kept track of, and then it becomes harder to do this proof during withdrawal. So there are also interesting kind of questions to think about in terms of how to design this for more complicated systems.

Anna Rose (00:50:41):
It would be more complicated if there was a swap, if there was any like DEX in there, any sort of action.

Dan Boneh (00:50:48):
No, no, that's exactly right. Yeah. That's exactly right. Things would get more complicated if the source of the funds could actually be multiple accounts. And now you would have to do a proof that none of the accounts that contributed to the account from which we're withdrawing is currently on the block list. Yeah and that's a more complicated thing to do.

Kobi (00:51:08):
Yeah. I think, I think the situation is even worse because you yourself in that anonymity pool, you yourself don't even know the source of funds after a few transfers. So it's even harder.

Dan Boneh (00:51:19):
Yeah. Yeah. That's right. That's right. So actually there's an interesting design problem here, right? So it turns out there are actually ways to design this, but now there's a trade off between privacy and compliance. So I, I'd say again, there's an interesting design question there on, on, on how to do this in these more complicated systems.

Anna Rose (00:51:37):
Cool. So let's kind of continue on this line though, where we can actually use like elements of zero knowledge or ZK proofs to actually help prevent any sort of financial malfeasance. I mean, here I'm obviously talking about what happened with FTX. Small caveat here. FTX was a centralized exchange. I think anyone who listens to this show knows the difference, where it was more like a bank than actually like anything on chain. But I know that it's been floated this idea of like proof of reserve through ZK, this idea that you could use ZKPs to prove that there is some sort of funds backing the activity that's happening. So yeah, I'm curious if you've been working on that, if that's like a topic in your group.

Dan Boneh (00:52:22):
Yeah, so funny you should mention this, Anna, because this is actually something that I guess we worked on many years ago. And again, I should say this is joint work with Dagger, Benedikt Bünz, Joseph Bonneau, Clark, and myself on a system called Provisions. I think it dates back to 2015 or 14. I'm not exactly sure.

Anna Rose (00:52:42):
Oh, wow.

Dan Boneh (00:52:43):
But this was in response to Mt. Gox. Yeah. So FTX is not the first exchange to fail, as many of your listeners know. Yeah. We've had these, these problems actually for quite a while now, although maybe not to the same extent. And so the question was basically how can an exchange prove that it's solvent and do it in zero knowledge? So what does it mean to prove that it's solvent, right? It needs to prove that its obligations are less than its assets, right?

(00:53:14):
And so exchanges generally are kind of, might be nervous about doing this because they might not wanna reveal how many assets they have. They might not wanna reveal what their customer's obligations are. You know, how many customers they have, what their customers have in their accounts. So this is a perfect application for zero knowledge, right? The way this works is the exchange, there are two parts to it. The exchange basically commits to its assets, so it will give us zero knowledge proof that it has so many assets on chain and then it commits to its obligations. Yeah. So it proves in, it basically computes a commitment to its total set of obligations to its customers. And the interesting thing is every customer can log into the exchange. You know, when they use their wallets to log in, they can automatically check that their balance in the exchange was included in the commitment to the obligations.

(00:54:04):
Yeah. so the customers sort of inherently as they interact with the exchange, they basically check that their accounts were included in the obligations that the exchange committed to. Yeah and so over time, you know, if enough customers do this, the commitment to the obligations is trustworthy. We know that this commitment really does represent the obligations that the exchange has to its customers. And then the only thing that's left is a zero knowledge proof that the value in the committed assets is greater than or equal to the value in the committed obligations. Yeah, so this is something that in principle exchange, they could have done seven or eight years ago. Right? So if the funds, if basically the exchange loses the funds, it will not be able to do these proofs anymore. Yeah and so I guess, you know, in the case of, I'll go back to history since I don't wanna talk about recent events.

(00:54:56):
But you know, in the case of Mt. Gox, basically as soon as the funds

Anna Rose (00:55:00):
Since we don't know everything yet

Dan Boneh (00:55:01):
Yeah, yeah, exactly.

Anna Rose (00:55:02):
Yeah.

Dan Boneh (00:55:02):
As soon as the funds were extracted from Mt. Gov, they would no longer be able to produce these solvency proofs and you can imagine the solvency proofs would be created once every 24 hours. So immediately when bad things happen, they can't produce solvency proofs anymore and the issue would be detected. Now, again, there are lots of caveats to this. If you start to think about this, there are many ways in which exchanges can still complete the solvency proofs, even though they might not control the funds. For example, they can take a loan, a temporary loan in order to do the solvency proof and then pay the loan back.

Anna Rose (00:55:33):
Yeah.

Dan Boneh (00:55:34):
Just as an example. Yeah. So there's still, you know, funny games they can play with. But you know, the hope is that if this is deployed, you know, they have to produce this proof every 24 hours. You know, it makes people think twice. You know, if we take action X, we won't be able to produce a proof. Maybe that will prevent them, that will just make them, it's a mental block to say, well, maybe we shouldn't be taking action X to begin with. Yeah because that would cause the proof to fail so it's another, you know, it's not a full proof solution, but it's another you know, kind of the defense in depth mechanism. So it's one of these things that, you know, we back in 2015/16/17, we tried to get exchanges to implement this.

(00:56:16):
Yeah. This would've been, it seems like a kind of a pretty natural thing to, for exchanges to use, you know, exchanges had other priorities. This does require some development work. And so what I'd like to suggest that maybe to your listeners is folks are interested, maybe we should kick off a standardization process around this, right? Why don't we have like a committee or you know, a a standards body that decides on what is zero knowledge proof of solvency. You know, we'll have a standard that says, here are the formats that here's what we're committing to, here's what the proof proves all these things will be standardized. Then companies will actually be able to implement the standard in such a way that it'll be very easy for exchanges to integrate well easy in quotes. It'll be easier for exchanges to incorporate this into their workflow. And then boom, every 24 hours they'll generate a proof. And similarly, wallets could integrate this into their into their processes and kind of the proofs will be checked sort of automatically by lots of customers. Yeah so if we have a standards for this, you know, it could go, it could go a long way. Again, it's not a foolproof solution, but it's kind of one of these defense in depth mechanisms that might, you know, in some cases might prevent this from happening again.

Anna Rose (00:57:31):
What's amazing about what we just covered is like, so many of these examples I feel like are great for listeners to hear and start brainstorming around and now that there's some proof of concepts or some papers written up about this, like you can start to think about this in different contexts, and then hopefully we can start to see like all these new use cases.

Dan Boneh (00:57:53):
Honestly, the reason all these use cases are possible, you know, we have to acknowledge the fact it's only possible because of the development of frameworks to do zero knowledge proofs very efficiently in a way that's easy for developers to use. Yeah, this has only happened because, you know, the blockchain community needs these zero knowledge proofs. So there's been a massive effort in developing this technology. Otherwise, none of this would be possible. So I think we should acknowledge, you know, give credit where credit is due

Anna Rose (00:58:23):
Definitely. Is it in the, do you think it's in the languages or in the libraries? Like is it the fact that things have become more efficient or is it because there's now like tools to engage with it without needing to be kind of in the circuit? Like using it more as like a black box?

Dan Boneh (00:58:39):
Yeah. Yeah. Definitely. I totally, totally agree with you Anna. What's interesting and kind of remarkable is the fact that now we can actually have developers work on zero knowledge proofs without actually knowing the details of how they work. Right. They can interact with the frameworks and make those things work without having to spend two years understanding all the nitty gritty details. 10 years ago, you know, Kobi, you know this very well. 10 years ago, if you wanted to develop a, or use a zero knowledge proof in your system, you basically would've had to hire a team of cryptographers to go and understand all the different proof systems and then implement everything yourself. These days, I can tell you that even in our course we have a SNARK project where the students develop, like within a week they're able to do inclusion proofs and Merkel trees. Basically we do, right now we do it in circom, but we're probably gonna move to one of the other, one of the newer frameworks within a week. Someone can go from zero to building like prover and a verifier without too much effort. That's only possible because of the development that's happened over the last decade.

Kobi (00:59:47):
Yeah. I mean, you don't even have to go 10 years ago, like even six years ago, I remember working with lips SNARK you already have to work for a month just to support fixed point arithmetic or negative numbers. And now you have this out of the box and you can verify it on Ethereum directly. It's amazing. Yeah, I agree with you

Dan Boneh (01:00:04):
Yeah and look, the proof is the fact, again, we can do this in one week, students can go from zero to writing software that generates proofs

Kobi (01:00:14):
Yeah, so then one of the more interesting works that I've seen coming from your group recently was the collaborative SNARKs paper where you could have multiple people collaborate on the different secret parts inside the SNARK and produce a proof and I was curious to, to hear about what were the applications that you had in mind for this and like, what it is and so on. So I think it would be interesting.

Dan Boneh (01:00:39):
Oh yeah, thanks Kobi. Yeah so this is something that worked on with Alex Ozdemir, who you know very well. I think he's been on the podcast a couple times.

Anna Rose (01:00:48):
Totally.

Dan Boneh (01:00:48):
And so the question was basically what do you do when you need to generate a proof, but the witness for the proof is actually distributed across multiple parties, right? Traditionally, when we think about zero knoweldge proofs, the secret witness is only held by a single party. So what do you do when this witness is itself distributed across multiple parties? And this comes up actually naturally in a lot of different situations, right? So we were thinking of like in the banking system, if you need to produce a proof on the transaction, on the global transaction graph, you know, well, every bank only sees its view of the transaction graph.

(01:01:25):
Nobody really sees the global transaction graph, and yet somehow they want to produce a proof on the global transaction graph. So that's an example where the witness is split between multiple parties. There's another nice example actually I think Pratyush brought this up where imagine you are a weak device and you wanna produce a proof. What you can do is you can take your witness and break it up into multiple pieces, give the pieces each piece to a large server and now neither one of the servers will know your witness because it's secret. But together they can now work together to produce a proof overall the pieces. Yeah and presumably that actually gives speed up over doing the proof on this weak device yeah. So there are lots of situations where these collaborative proofs actually come up when you have to produce a proof using a witness that's distributed across multiple parties.

(01:02:16):
So the question then is how do you do it? And from a theoretical point of view, this is immediate. The way you do it is you basically run the proving algorithm as an NPC among the parties that hold the witness. Yeah so I hope your listeners know about multi-party computation, right?

Anna Rose (01:02:33):
Definitely

Dan Boneh (01:02:33):
Multi-party computation lets you compute on shared data. Yeah, well here we have a shared data, right? We have a witness that's shared across multiple parties. They can run a multi-party computation and generate the proof using, the shared witness. So to do that, what it means is we have to design a SNARK where the proving algorithm is MPC friendly. The proving algorithm has to be efficiently implementable inside of an MPC protocol. So how do we do that? Well, it turns out you can actually take some of the existing SNARKs and massage them somewhat and they become MPC friendly.

(01:03:08):
Yeah, so you can actually run them very efficiently inside of an MPC. To me, by the way, this is interesting because it's kind of a new criteria for SNARKs, right? We have all these demands from SNARKs, right? We want fast provers, we want no trusted setup. Maybe we want quantum resistance. This is kind of a new demand from a SNARK. Not only does, it has to satisfy all the existing properties, also the prover has to be MPC friendly. Yeah, so how do we build snarks that that are MPC friendly? And you know, for example, it turns out we can take our friend PLONK and massage it a little bit and how it works, and lo and behold it becomes MPC friendly so we can actually run the prover in an MPC. Now, the amazing thing that happened, this is something that hardly ever happens in the world of MPC but the amazing thing that happened is that it turns out that when the, you know, SNARK proof generation is so heavyweight that in fact, even when you run the prover inside of the MPC, most of the work is done on a local computation to compute the actual SNARK.

(01:04:08):
Yeah. So the overhead of the MPC is minimal. It's like at most a factor of two. Yeah. This is like unheard of. Usually when you take a computation and you convert it to an MPC, things slow down by a factor of a thousand. Yeah, but SNARK proof generation is already so hard that the overhead of the MPC is really not that high. It's quite, quite negligible. So the lesson here, and again, this is something again your listeners might should probably know about the lesson is it's actually not that hard to generate a collaborative proof. It's really not much harder than just generating a regular proof. Yeah, the overhead of MPC, if you do the SNARK correctly, you know, if you implement the SNARK correctly, then the overhead of MPC is almost negligible. It's kind of doesn't add much complexity. This, by the way, I think the experiment went up to like 30 provers or so. So it's MPC across 30 parties and even then the overhead was was not that high. There are graphs in the paper that show this and so, yeah, I thought it was kind of a bizarre situation because like again, in the world of MPC, usually MPC introduces huge overheads and here it's almost for free.

Kobi (01:05:17):
Yeah, the overheads are so huge already and look, like the final proof that you get is it looks very similar to an existing proof. So you can basically expect the same verifier efficiency, which is really appealing as well. So basically people can use it in existing environments, which is really cool.

Dan Boneh (01:05:36):
Yeah, that's exactly right. By the way, there's one subtlety that I wanted to point out, which is, you know, when the witnesses distributed across multiple parties, the threat model now becomes a little bit different, right? Because now let's say there are three provers trying to work together, prover number one might actually try to be malicious so it could extract, prover number two's witness, right? And so that, that's kind of what the MPC protects against. However, there are some things that the MPC cannot protect against, right? In particular, prover number one can cook up a fake witness and see whether the MPC protocol results in a final correct proof. Yeah, and in doing that, inherently unavoidably prover number one learns something about prove number two's witness in the sense that it knows, oh, my cooked up witness actually combined with prove number two's and three's witnesses results in a, in a valid proof.

(01:06:29):
Yeah. So that inherently leaks something about prover number two's and three's witnesses. So just, I think it is important to keep in mind when you use collaborative proofs, it's perfectly fine to do, there's one subtlety you have to remember in that inherently you have to leak some information about your witnesses to the other provers. Yeah, in particular, just the fact that you have a piece of a valid witness that actually will leak to the other provers. So there's one subtlety I just wanna make sure people are aware of. So nobody falls into this into this trap door.

Anna Rose (01:06:59):
So you just chatted about like the MPC ZK combination sort of in a way we're not used to bdcause MPCs are usually seen as like the trusted setup part of a ZKP but I wanna sort of finish off with a topic, I don't know if we talked about it last time, we might have, but it is the ZK FHE combination and I'm curious if you're keeping tabs on that, if you've been paying attention to, because FHE, when we met, I think you were the one who actually introduced it to me potentially on our last episode, this idea that you could have this place where you could do like private computation. Have you been following that? Does any, does your group ever touch on that? Or yeah, what do you think of it? Do you think we're still a ways off?

Dan Boneh (01:07:38):
Well, I mean, no, that's a fantastic question, Anna. I mean, FHE is kind of one of the most amazing things that happen in crypto, right? I mean, the fact that we can compute arbitrarily on Ciphertexts is mind blowing. Yeah, what's I guess the space of FHE is also advancing quickly, right? There are a couple of companies working in the space and so that technology is maturing quite rapidly as well. So there some connections between FHE and blockchains as well. Yeah, so there's kind of two touch points between ZK and and FHE so one touchpoint is where ZK can help FHE in that the FHE model is right now in some, in some sense what we call honest but curious where you kind of assume that the person that's computing on Ciphertext is computing the right function.

(01:08:27):
Well, what if you don't trust that person and you'd like them to prove that they computed the right function? Well then that's where you can kind of use your knowledge to say, you know, hey, Mr. Computer, you computed on Ciphertext, but please also include a proof that you computed the right function and so that's an application of ZK to FHE there's also an application of FHE to ZK maybe I won't get into that, but it turns out there are actually constructions that we can do using it, using FHE that are, that are beneficial to ZK but maybe we can leave that

Anna Rose (01:08:55):
for a future episode?

Dan Boneh (01:08:56):
to another time.

Anna Rose (01:08:58):
Sounds good. Dan, thank you so much for sharing all of this work. I feel like I'm gonna use this episode probably towards like any future hackathon that we do. I'm gonna send people to listen to this one because I think they're gonna get a lot of really great ideas that they could potentially then use for creating products actually with a lot of this stuff. So yeah, thanks so much for that rundown.

Dan Boneh (01:09:22):
This is great, Anna, by the way, just to show you the wealth of the space. We didn't even get to everything that we could have talked about.

Anna Rose (01:09:29):
True.

Dan Boneh (01:09:30):
It would've been fun to also talk about hyper-PLONK and how hyper-PLONK works. It would've been fun to talk about generalizations of IOPS to things like F-IOPS. but we can leave that to another episode. I think what it shows is just how broad the space is and how much activity is going on in this area. So Anna, thank you so much for running this podcast series. I think it's really a fantastic tool for the community.

Anna Rose (01:09:56):
Yeah. Thanks for being on. I do want to say one thing before we sign off, and that's that we do, I think as this airs we're in the midst of ZK HACK, which are like month long multi-session workshops and puzzle hacking. And Dan, one of your students actually helped us with one of our puzzles this time around. So I wanted to say big thank you. I think by the time this airs, that puzzle should have been released into the wild. So if anyone's listening and wants to find out more about that kind of thing, check out ZK HACK. I'll add the links in the show notes to that. Yeah and thanks so much for the education work you do in this space, because I do feel like a lot of the people who are coming into cryptography and computer science, like you are their first impression of what is going on in the ZK world and I think it's been really fun working with you on these videos. And yeah, I hope we get to do more.

Dan Boneh (01:10:44):
Fantastic. Likewise. Thank you, Anna. Thank you, Kobi.

Anna Rose (01:10:46):
Cool. Cool.

Kobi (01:10:47):
Thank you. It was fascinating.

Anna Rose (01:10:48):
All right. I wanna say a big thank you to the podcast team, Tanya, Henrik and Rachel. And to our listeners, thanks for listening.