Episode 378 - Zerocoin to zk-creds: Modern ZK History with Ian Miers

Transcript

[Music] 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. [Music] This week, Nico and I catch up with Ian Meyers, assistant professor of computer science at the University of Maryland.

Ian is one of the co-authors of the OG paper Zerocoin and Zero Cash, the original papers released over 10 years ago that for the first time combined this emerging ZK research with blockchains. Since that point, Ian has worked on trusted setups at Zcash and pioneered influential work like Zexi, ZK Creds, and now ZK promises. Through our conversation, we cover his history and how this is deeply intertwined with the initial batch of research on ZK and blockchains. Research that has in many ways spawned the industry we work in today. There was a lot to cover and we did not get through all of our questions for Ian. So, we hope to have him back on the show in the near future to pick his brain on even more ZK topics. Now, before we kick off, I just wanted to share that we were trying to get some

feedback from you, our listeners. Many years ago, we shared a form with some questions to better understand our listeners and community, but we are very much due for an update. So, we've created a new form for the listeners of this show. It's totally optional and you can leave it anonymous, but if you have a few minutes and want to share some feedback with us, I know we would very much appreciate it. We are trying to understand what you are interested in in 2025, what you like about the show, how you could see us improving, and the types of topics you want to hear us covering. We're adding a link in the show notes and we're going to be sharing this across a few channels. So, if you're up for it, please fill it out.

Also, I just want to be sure you're following our release of the ZK whiteboard sessions. These videos produced by ZK Hack and supported by Bane Capital Crypto feature our hosts Nico and GMO exploring the building blocks of the ZK systems we know and love. We are currently in our third season and we're releasing videos every 2 weeks. These can be found over on the Zero Knowledge Podcast YouTube channel. Subscribe there to be reminded. I've added a link to both the form and the ZK whiteboard sessions. Do check them out. Now, here is our interview with Ian. Today, Nico and I are here with Ian Meyers, assistant professor of computer science at the University of Maryland and someone very well known within the

ZK ecosystem for his contributions to foundational ZK research. Welcome finally to the show, Ian. I feel like this has been a very long time coming. >> Yeah, it's great to be here finally getting around to actually being on podcast and not going, "Oh, that sounds different. I'll put it off till later." >> So, I actually tracked this down. I think the first time I ever approached you to come on the show was actually back in 2019, right after ZK Summit 4. This really is kind of giving us a timeline and I can't believe it hasn't happened until now. like you've been releasing great work. You've been so important for ZK. So anyway, I'm just so happy that now six years later, we are

getting you on the show. We're going to be spending a bit of time early on in this show looking back, doing a bit of a history lesson on early ZK papers, especially where they start to intersect with blockchain. You were very involved in that. It's something we actually haven't talked about recently on the show, so I'm excited to go back into that. I imagine some of your listeners would be surprised to know this stuff goes back to before Ethereum was actually launched or even existed. Right. We've I've been working on this since 2011 roughly. >> Oh wow. >> Um so it's it's been a number of years.

>> A long time. >> Um and we've gone from wait somebody has a podcast on ZK where I'm like that's strange. I I I think I'll pass to oh of course this is this is a this is a thing. I'm happy to do it. Like um >> I think you had actually said yes back then too. I don't think you actually said no, but >> No, but I flaked out because academics flake out on things. That's what and and yeah. >> All right, sounds good. Um, hey Nico, thanks for coming this one. >> Super happy to be here. This is a great start already. >> All right, Ian, let's do some backstory.

I feel like I mean, you just sort of hinted at your time frame when you actually started working on this EK stuff. Were you already involved in a blockchain sort of side of things or were you coming more from cryptography? Yeah, let's go back to that 2011 timeline. >> So, it's 2011. I have just started working in a research lab because I got uh bored of my white collar assembly line job at Microsoft. >> Whoa. >> And there's this Bitcoin thing. >> Mhm. >> And I do some looking into it and it turns out that everything on a blockchain is public. It is uh Twitter for your bank account. And the question is, well, how do we fix this? Right?

There is this line of work dating back to David Ch in the 1980s on e-cash, but ecash requires a trusted bank to hold a signing key. And of course, in a blockchain, you trust nobody. And now it's we got to come up with something else. So, we spend a year or so looking at how to solve this. And the solution we come up with is because Ethereum and smart contracts and stuff don't exist yet. and nor to snarks. Let's build a mix on top of Bitcoin using a different set of zero knowledge proofs. So this is a paper we wrote in 2013 called zerocoin [Music] >> and it conceptually it works but the technology is not quite there. However, the same time in fact literally the same

conference this is aa S&P in San Francisco in 2013 somebody presents a paper on the first implementation of what are now known as snarks. Mhm. >> Who was it? >> This was Brian Parno. Their paper was Pinocchio. There was this arms race between So there's this paper a year or two earlier called quadratic arithmetic programs, something like that, ZK proofs without IOPS. >> And that paper is published. It doesn't have an implementation, but it suggests this new way to do very fast CK proofs.

And then there's a race between two groups. Brian Parno and others then at Microsoft research and Iran Turmer, Ellie bin Sassan, Alisandra Chiaza, Matters of Yuza and I think I'm not short changing any authors on that paper who were at MIT and in Israel to publish the first implementation. >> Um, >> wow. >> And Parno by dent of how confidence work Parno's paper was published first. They have their paper in August at crypto. So top tier works. >> This is 2011 still. >> This No, no, this is 2013 now. This is 2013. Okay. Yeah. So, zerocoin paper writing happens 2011. Yes. You just said that is actually Nico. We have a history. We do a research history and I actually have the wrong date for that. I

have 2013 for that one. I think >> Yeah. 2013 was when the paper was published, right? And you take a year. Yeah. Yeah. It's just you take a year to figure out how to do it and try a bunch of things and nothing works. We come back to the slow solution which is zero knowledge proofs and then it takes a little bit to actually write the paper. You submit that in October 2012 goes around to when it's published. So this is the lag time. >> Okay. So we were all right on our dates. >> Yeah. No, you're right. >> The word like the term snark also as far as as we've understood is defined in a paper that comes out in 2012.

>> This is Aleandro Kiza like and they actually use the term snark at least for the Yeah. For the first time as far as we know. >> Yeah. I think it's some Batansky old paper but I can never remember the time or the sequence of these things. >> Cool. And then so zero coin this is this initial work it's Matt Green yourself and Christina Garmin >> Christina Garmin and Avi Rubin who was a faculty Hopkins >> how like just going back to that first one though Zerocoin like who proposes it how does that come together I've actually been really curious about like that initial paper >> so it's me and my who became my PhD advisor I wasn't PhD student at this point chatting about various interesting problems we had some other stuff we had to do to justify my salary, but that was

boring and it's full of medical records. Um, uh, and we're just sort of playing around with this because it's a very challenging problem, right? It's a setpiece sort of cyberpunk dream to build ecash that academics have tried and have tried to commercialize before and and failed due to personality and and ego conflicts in some versions of it. >> And it's an interesting problem. It's just it's just a nerd snipe like let let's try to do this. And so we're just sort of playing with it until we finally come up with a solution. So it's me and Matt and Christina is one of Matt's actual PhD students at that point. So she gets wrapped roped into it. Avi Rubin is is the senior PI in the lab with the grant. So he ends up on the paper.

>> But the original concept was the usual like me showing up at Matt's office and us throwing various ideas and problems on whiteboard and seeing what sticks. >> So this was at John's Hopkins. >> Yes. >> Okay. Yeah. >> Cool. >> So you you work on the paper. Paper comes out around the same time. You say there's these two camps that are working but I guess are they working mostly on that snark construction or something like like Pinocchio is it just snarks not blockchain >> not blockchains not payments just snarks these are classic I don't want to describe all of them as theorists but there are definitely we have a theoretical vertical tool we will build this primitive with the definitions in this black box >> we don't necessarily care about the applications for the paper and these two things come out and it's basically clear

to us and the people presenting that hey K we should try to do this >> work together. >> Yes. >> Back then those snark papers though they were dense like the things we now understand is like the components that build a snark which we've covered in things like the whiteboard session like the IOPS polomial commitment schemes fry like all those things we've broken down but back then what is this paper like I feel like it's just like a blob and they're like here you go. So, it is a blob. It's a black box that actually I managed to do a bunch of this work without ever figuring out needing to figure out the details of what's in it.

>> This is spoiler somewhat regrettable because as a result, the first set of trusted setup ceremonies that were done for Zcash, which I wasn't involved with, were kind of terrible. And then at some point, I actually peer into the black box and find out figure out what these primitives are. And then me and Sean Brow and Ariel Gobinson go and write the actual powers of tow setup that's been used for everything or derivatives thereof. Right? >> But yes, at the time these things are are not very well explained, but they don't need to be because the interface you're using is a circuit, right? We just need to describe some some computation. So there's this fun problem now of which group do we work with, >> right? And we've talked to both of them.

And what happens is we've talked to both them at the conference, right? Or people associated with them. What happens is there's the usual send a follow-up email and it's those groups who email us except one of the groups emails my adviser, Matthew Green, and the other group emails me. If you know anything about academia, you know that professors don't check their email very frequently. >> Oh no. >> And grad students maybe do. And so as a result um we end up working with Aron Tromo on matters and and Alessandro because one of them emailed me and I I can't recall who it was probably Alessandro who was a grad student because again professors don't check or send emails and so that was sort of an accident of history though I think it

was probably the right call not to talk about anything about either of the research groups but the problem is the other group was at Microsoft at the time and so all the IP was owned by Microsoft and I can't imagine Microsoft executive in 2013 or 14 signing off on let's make anonymous money on the internet. >> Wow. >> Yeah. So that that that was probably for the best. >> I mean it sounds sort of like that's how the dice rolled out but actually yeah that point about IP and potential like trying to guard something. I I wonder if that wouldn't have caused some friction anyways.

>> It it would have. >> Yeah. I mean very narrowly we could have run into problems if anyone from the other side had patented their uh ZK stuff because that has happened to subsequent people from some of those institutions with ZK work and there were lawsuits. >> Yeah. and and there are some there's sort of always this push and pull between the open- source folks and then the companies who are contributing and like do they try to create moes and I think for ZK we've been really lucky with like a very kind of from the start open system >> yes >> tons of contribution where I mean I think there was talk at some point of like starkware patenting and they just they chose not to which I think was really good there have been other

technologies like FHE where you are you are seeing a lot more patent Yes. And you're seeing less acceleration over there, too. So, anyway, very interesting. >> Yeah. My my piece of advice if there's anyone who's who's in academia and and listening to this, seriously consider not patenting your work. It'll make sure it gets used more to make sure it gets adopted more. It may or may not make your fundraising story for your seed round trickier. >> Yeah. >> But in my somewhat limited experience, that's not the biggest deal. At least if you have really interesting ideas. Mhm. >> All right. So, let's move on to the next paper that comes out which does combine a lot of this work. Zero cache.

>> So, we have zero cache. This is the combined effort. This is like blockchain and zk combined. >> And I guess is it done in a better way? Like does it solve the problems that zerocoin hadn't been able to? >> Yes. So, zerocoin looks shockingly like tornado cash. In fact, it basically is tornado cash but with >> tornado cash used to snark. So they took the work from Zero Cash for that. But the >> Yeah. Like was it a side chain of Bitcoin with like privacy? >> It was proposed as a let's modify this on top of Bitcoin. >> Oh.

>> Um right because we're academics and somewhat naive. And I remember giving a talk at the Bitcoin conference in 2013 talking about this and people like no we're never going to do this. Peter Peter Todd stands up and and says the Bitcoin developers talked about it and they're never going to do this. And to be fair, >> at the time, given the majority of the technology, that was probably the right choice. >> Um, it is also just sort of amusing because my recollection is that was the same Bitcoin conference Vitalik was at as a reporter going around talking to people about smart contracts and got a similar answer and he went and did Ethereum.

>> So, I might have the year off on that anecdote, but uh it was summer somewhere in there. Might have been a year beforehand. >> Cool. So in in the move to zero cache though I mean zero cache is a standalone blockchain of its own right. >> We had two versions in the paper but yeah the idea was it was going to be a standalone uh blockchain. We we were interested in a protocol which can operate however and that is the core private payments protocol that is used by pretty much every other now at this point every serious privacy reserving payment scheme >> with the exception of maybe Monero which is supposed to move to a thing called full chain membership proofs which are kind of similar. So the idea of course everyone's probably seen this in this podcast is you have a Merkel tree of

notes that have a variable balance on them and you can pay them to other people uh and you do this double spin prevention via what are now called nullifiers. Um that name was not in the paper but it's the same exact technique PRF. >> And so this is the the technique we work out. It's well suited to to snarks because it's it's efficient. The Merkel feed stuff is is nice enough to do >> and you could tweak it. You can use different CK proofs. You can use different PRF constructions and stuff but that's that's the core protocol that we built and then that after we do it turns into via set of security steps Zcash to start.

>> Mhm. Did it have a like renaming process too? >> Yes. Wasn't it sort of like zerocoin paper then zero cash paper then like z well well there's a zcoin project which spins out and then there's is zcash always zcash or is it like yeah just if you can remember the >> that's a good that's actually a good question debates and naming things is always this this contingent stuff and even back when we wrote zero cache there was a discussion of should we call it zcash instead of zero cache the paper and I was like well the previous thing was zero coin and we've gone from single coins you can mix to cash like an actual payment system so I think we should call it zero cash and then that works out but

later the argument of well it's shorter and better when we have to go name the blockchain >> uh it makes that contingent wins I think rightfully and we call it Zcash >> okay >> when that happened I don't recall because actually the actual at the time company now nonprofit that is the paperwork for the LLC that that did all raised the the seed round everything is the electric coin company. >> Yes. >> Mhm. >> Right. Which by the way, I would suggest if anyone is naming a company and you think, "Oh, that's cute and a nice fun thing, don't do that because after you have to say it the 15th time in an interview or talking or with lawyers, you're like, "Oh, this is cringey and we wish we had gone with something else."

>> Um, so there's some iteration of names in there. I think sometime in between when Electric Coin Company happens and there's press about it, somebody takes the old code for zerocoin that we put up with this giant warning of do not use this. that probably have security bugs in it. If it breaks, you own the pieces. They take that code as is and they use it complete with the warning in the repository. And then, spoilers, one of the little tiny ZK proofs in there, not the main one, ancillary one was in fact broken. And somebody used that to steal forge several million dollars worth of tokens at the time. So, yes, if I put for anyone reading this, if you go to my grad students code bases and you're like, "Oh, we'll use this." And there

was a warning on it of warning warning warning. is not audited. Don't use it. I really mean it. And you if somebody shows up and robs you of all of your tokens in the process for academic code with those things on it you were too cheap to pay for an audit for, I will have no sympathy for you. >> Wow. >> And that was Zcoin. >> That was I don't recoup different forks of all these things and I don't remember which one it was. >> I think Zcoin is still around. It renamed and uses a different protocol now. So they're FO and I have I don't know what they're up to, but there was this period where it was Zcash and Zcoin were two companies which were based on similar tech and then there was the Zero Cash and the Zerocoin paper. Anyway, it was just a lot of of funny overlap

there. Yep. >> Naming collisions in a way, but thank you for for teasing that out for us. >> Okay, so you had talked about this trusted setup toxic waste in the zero cache paper. Was that already described? Was that part of the paper or was it just the architecture for Zcash blockchain and then you guys had to create this other thing called the trusted setup? >> We so the paper mentions that you need a setup but it does not describe how to do it. I would have to double check but I think it says you might be able to do a multi-party protocol where a bunch of parties come together and generate it but that would have been like blackbox.

We have multi-party computation so of course you can do this in theory >> and that wasn't targeted at at commercializing this. it was probably targeted at avoiding reviewer number two pointing out that it was a problem. Um, after we write the paper and we comes clear that we are actually going to commercialize this thing because that takes a while. We're kind of hoping someone else runs with it and none of us want to quit our day jobs as academics, right? Uh, I don't want to go try to be a CEO. I I don't necessarily have the skills. I kind of want to stay in research. I figure if I do this myself, there's a pretty good chance that it will fail. And if it succeeds, there's a non-trivial chance I end up in jail. Uh, and so I'm like, okay, I will stay in academia doing research. And we

thankfully find Zuko Wilcox to who wants to go start the company. He does the very hard work of of hiring the right people and setting the team culture and the ethos to get the thing launched, which was an amazing lift. >> And then there's the trusted setup that happens, the sixth person or seven per I mean, and there's there's an entire episode dedicated to that >> um on the radio lab, like not this podcast, but another podcast. And then we we did have Zuko on the show on this show for episode 50 really long ago something like 2018 2019 and I can dig that up as well. I think he he goes over >> that story.

>> We also have an episode with Mary Miller who worked on these like universal and objectable setups sort of to replace the trusted setup. So that's came later though right from the archives. That was later. Yeah. >> Yeah. So I I'm just on that on that trusted like the initial trusted setup. After that, we have Ariel Gabizon and Shawn Bo who discover that problem, the bug, was the bug in zero cache the paper >> uh >> like or or I know it's not really a bug, it's like a it's like a missed thing, but was it in the paper or was it in the implementation?

>> My recollection and this is a bit of a recollections may vary. So I think it's not in zero cache the paper because zero cache uses sort of blackbox the zk snoring references it the issue was a distinction between the specification of I think it's BCTV 14b but I always confuse these citations the actual snark that Iran Trump matters v Iran Alessand everybody had written the specification of it in appendix whatever of the paper >> and the implementation M >> and the imple my recollection on this is the implementation was correct. The specification however had some extra elements in the CRS that should not have

been there. >> Yeah. >> And in the course of implementing the setup they implemented the spec not the implementation. >> Uh uhhuh. That is my recollection. >> Interesting. I'm going to I'm going to cite one other episode for the listeners who are interested in this history. Episode 76. It's actually one of my favorite episodes of all time on this show. Sean Bo after the fact. So this is like a year and a half after doing sort of a recollection debrief look back on finding this bug talks about the bug and how to correct the bug and like the stress and strain that this team was under because there was it was known to this tiny inner circle in Zcash that there had been a problem in their

system. >> Yeah. if it had been exploited and I mean we still don't entirely know that it hasn't but we assume it hasn't because of some metrics but like if it had been it would have allowed for unlimited printing of funds in the shielded part of Zcash that is the hidden nonvisible part the stuff behind the snarks >> which would have been like a very bad thing for ZK for privacy blockchains I mean it would have just been a total catastrophe >> it would have been yes It's kind of funny though because because this this is a thing that hangs very large over everybody's head. Uh and it definitely is like very legitimate a real problem.

You need to be very make sure you don't do it. On the other hand, now that we've had a sequence of other ZK proof systems and cryptocurrencies and whatever I almost feel like everybody has at least one soundness bug once that can inflate money, right? Like this this happened to Monero which was not a snarkbased system. May have happened more than once, right? It's happened to almost everybody and it is typically not catastrophic because it's not usually exploited yet. >> Okay, >> it has happened >> as far as we know. >> As far as we know, though I should say that like if you had this exploit, you would have cashed out by now for most of these things, right? When we see like >> the the MPM supply chain attacks, right, where someone puts a bug in Node.js JS and then backd doors a bunch of wallets

or whatever it is, those don't stay around for that long because anybody who has the technical competence to land that attack realizes they want to monetize it quickly and move on. >> So, it is a big deal. It really is a big deal. It's just kind of funny to think back to when you did that podcast it was really a big deal versus now I suspect if we asked people the general climate of ZK about how big a deal is a soundness bug, it wouldn't quite be oh that's a Tuesday and it shouldn't be even close to that. But it is depressingly probably closer to that than we'd want to admit. >> Yeah, we do this newsletter called ZK Mesh where we collect links and stuff and we have a vulnerability category. We don't always use it. Sometimes nothing has come out, but often we there is

something >> there's lots of things. I mean often they're found in an audit. They're found by white hats. They're reported. It's disclosed. It's by the found by the team. So it's like but it is it is a common phenomenon. Back then though Zcash was like the only one. It would have been catastrophic that because it was the only one. It was the thing that launched to the highest profile, right? It would it would have been completely catastrophic. I do want to make a comment though because these bugs are are bad. But what a lot of people I think don't understand is they are bugs almost like any other software bug, right? It's like you accidentally disclose something, you accidentally like you did the wrong thing with a hash. Other product projects have had the classic like you can screw up the Merkel tree >> um like and have constraint bugs. These

are software bugs. And the reason I'm emphasizing this is because any piece of cryptography is subject to that kind of risk. >> Yeah. >> And one of the problems we have is there are some frankly charlatans in this space who go off and say, "Oh, RS doesn't use random oracles or ours doesn't use non-falsifiable blackbox assumptions or ours is postquantum secure." And they somehow are implying we don't have this risk that these original snarks that you all heard of at the start have >> and that is from a strictly theoretical point of view. The risk profiles are different. But those that's not the risk you care about. The risk you care about is the actual implementation and audit risk. It's the equivalent of a used car salesman saying, "Oh, you shouldn't trust rubber tires >> on that particular car. You should buy

mine. >> It's bad." >> Yeah. >> Interesting. Okay. So, let's talk about this trusted setup. Nico, you just hinted at this. So, trusted setups, the initial ones were >> small, very >> Yeah. >> challenging to organize there. there. It was dramatic. There was like some fun things about them. People going into the woods burning computers and like taking I don't know radiation like meters to get some randomness into this trusted setup.

>> I don't think I was actually that involved. I don't know if I was involved at all actually at the time of the first trusted setup, but by the second one, I do remember it for Zcash. After that though, we learned about this new or maybe actually it was even around that time there was this paper called Sonics. >> Yeah. >> And Ian, are you an author on that? >> Sonic. No, I'm I'm offering the previous one. >> Okay. So, what tell me about like so Sonics hit our radar in a big way. This was the first time we understood that you could have this universal what you were saying Nico >> like you could create a trusted setup that you would still be able to sort of like upgrade. you'd be able to do things to the underlying system without having to run this entire thing each time.

>> Yeah, there are two things going on here. One of them is this notion of you can do updatable setups. >> Mhm. >> And then the second thing is how do you actually do efficient updates? How do you do a protocol with multiple people turn show up and do the setup ceremony? And so this is the the bit I I I think is actually probably more relevant because I I don't think Sonic got used anywhere. it did lead to a bunch of other interesting proof systems. But the the in terms of setup scenarios systems, what happened is >> the protocol that Zcash ran originally didn't scale because everybody had to communicate with everyone else multiple times, right? And they all have to be online, >> right, for the entire thing. So you could it takes like two days to run and everybody has to secure the laptop the

entire time. And if you go read, Peter Todd has a now deleted blog post about this because he participated and he was very gung-ho about it and then he realized it was lending Credence to Zcash being secure and he he it's a Bitcoin person got upset about it. This was a genius thing on Zo's part to involve Peter Todd in this but like he flew out into like somewhere in Canada like multiple multiple airline tickets as decoys, different rental cars, drove around and then he like sits in this cabin or something. >> No one cared back then. >> Yeah. Nobody cared. And so he sits >> I like that he took all of this precaution. That's so good, >> right? And and he sits in this cabin with like a ninja alarm, which is like a chair propped against the door.

>> And this is the kind of trouble you have to go to because only six people, six or seven people participating in this thing. And that just is if you were going to steal money, that's not the hardest group of people to own, right? And it's more importantly, it's very hard after the fact, this is a lesson we learned, to convince people you should trust those seven, six or seven people. >> Yeah. especially when one of them was anonymous. >> Uh which actually turns out to maybe been better because that person was Edward Snowden. I didn't know this at the time. >> Which is by the way a hilarious idea because if you had to try pick one person whose laptop is certainly compromised by multiple countries intelligence services, it's Edward Snowden, right? Like if the guys at Fort me didn't own his laptop, I want my tax

money back. And the Russians certainly did, right? So like >> wow. amazing. >> It's very hard when you have this protocol like that and it can't scale. You can't add more people. You can't and so everyone's out like why wasn't I included? Okay, so that's the protocol that Zcash launched with. Like two years later, I'm talking to my adviser and going through how that thing works. And I realized that actually we can radically simplify this because the parameters are basically the powers of tow g to the s, g to the s squ, g to the s cubed, etc.

up to the degree limit plus a second version which is like g to the s time alpha plus beta something. I don't do the math off the top of my head. And that has a nice structure we can abuse. So Sean and me and Ariel Gavinson go and make this paper scalable multi-party computation for parameters, right? Which Sean has this lovely name for which he acronyms says like MMO RPGs, massively multiplayer online replaceable parameter generations. >> A I like that. >> Yeah. And so this is the protocol that ends up getting used for the second Zcash setup where anybody can participate, right? and then gets used for all of the other setups for every other project that's using graph 16 or

similar or set set of things or even plon >> um and they're variants of this we write this paper we put it on e-rint we don't bother to really publish it anywhere Mary Mer wrote a follow-up paper that >> changes the the model a little bit and does the formal security proofs and gets it to euro which is great work um it uses the random oracle model which we had avoided because of these used car salesman problems we want anyone like going about it. Okay, so that's the setup thing. Then subsequently there end up being or about the same time there end up being various snarks that don't need this absolutely specialized trusted setup that's specific to circuits.

>> Ah, >> so now we're talking about universal setups. >> Universal Yeah. Universal protocols come in. >> Okay. >> Right. And the idea there is you don't have to redo the setup for every single new circuit you make. Yeah. >> So Plon has this property, Marlin has this property, >> pretty much most of the things that come after. >> Yes. And the reason for that is because the parameters are just for a polinomial commitment typically. >> Interesting. Okay, I see the distinction here. So there was like two steps. One was allowing more people to participate not having to be on online at all at the same time. And then the second were and it almost sounds like also like Sonic and Plonc these are proving systems like it's not just the trusted setup. It's just they can use >> trusted setups in different ways almost

and and open it up open up the design space. Hm. >> And to be fair, Sonic did have this notion of people could update the setups as they go, but the protocol and and origins for that is not that paper. It's Sean and I and then Mary's uh work following up and putting that on on slightly more formal ground. So, the two different things. It's universal setup is you can reuse it. >> The setup ceremonies are how do you get a bunch of people to participate and can get trust. And this is actually really fun because the the real effect of this is if somebody on the internet is a naysayers going I don't trust you about this you can just say well why didn't you participate right yeah it it's it's it's a social thing that the cryptography enables by having it scale you can just make anyone put their money

where their mouth is and as a result they have to shut up about it and so the net result of this is at this point now in 2025 nobody complains about trusted setups >> I mean we're even avoiding them completely right we Yeah, actually now there's systems that don't need them. >> There are um but I don't think that's the marketing. I mean, there is a bit of marketing on that, but it's not like they're competing on trusted setup with universal stuff or or whatever. It's like other domains, postquantum speed, VMs. >> Well, there's a couple like other steps. I mean, so I worked with Kobe on the Plum setup there. It was like parallelization. Yes.

>> So doing that was kind of a bit of an advent, a bit of a change. >> Yeah. there a bunch of sequence of improvements on like every major project who has done this has done a tweak to it when they're like oh we can do this better and I don't mean to short change any of those I just don't have that list of projects in my head and what they've done so yeah parallelization is one >> perpetual trusted setups is another where it goes on forever >> yes that's kind of easy if you have a universal setup system the if you're using graph 16 right you have to after you get the powers of tower you have to do the second phase and that fixes it but actually I think at this point that maybe these sort of perpetual soup ones where people reuse the first parameters

from various projects and they added to them. >> Totally. >> Howard Woo at Alio had this trick for making it easier to check the transcript where you only had to check one element of the powers of at the end. There's been some people who have do done guarantees about whether you can get excluded or not, whether you use a blockchain to do fairness. That was a paper. I don't know if that was ever used. I don't know if it was worth it, but there have been a huge number of tweaks of this this core idea of of replaceable participants. Yeah. >> Um, and I don't even know. Actually, it' be kind of funny to figure out what the what is the sum state of the art if we take all the because I figure it's probably branched 50 times and there's like a bunch of different things on

various sides where you should unify them. >> Yeah, I remember for the Alio one there was also like there was like four different ones. So, they broke up their circuit into all these different pieces. Like they did there was a moment where they were talking about doing four cuz I also worked on that one. >> Uh, four distinct trust setup. >> Yes. And alo had different curves too when you have to do them. You can break them up. There are ways to parallelize it. There are ways to have potentially different parties participate in different parts of it. >> Um these are all interesting ideas because at some point you do hit the scalability limit of in a browser. Oh, and somebody I don't know who this was did the hard work of like making this run in a browser where you could just like visit and and go.

>> I think the tornado cache one was like in a browser. That might have been I mean Aztec did >> I don't think they ended up using it in the end but this is like a really long time ago but they or they used it for was it called Aztec connect they used it for some product that is now defunct but they had used docker like it was like easier but it wasn't quite browser it was like somewhere on the way towards a browser >> and and the cool thing is at some point so I I made it an absolute rule that I would not participate in these things >> because one I didn't want anyone to claim that I had my finger on the button to like Zcash, right? Very like when they were doing that, I was like, I do not want to be involved. I do not want

to be one of the people who's like trust comes down to you because one, people might think I break broke it and two, people might think I have those parameters on my laptop and can commit billions of of anonymous dollars. >> And so I had a sort of personal rule of refusing to participate on these things, including for Alio, including for anything else up to at some point I think somebody asked me to do it for something Miston was doing. I don't even remember what it was. And I'm like, all right, there are enough people participating at this point. whatever it it's not on me. >> So, it's nice that we've scaled to that point where it's no longer an OBSC risk to to be in one of these things. >> Totally. We just talked about Alio and Zexi.

>> That's another project that you I think were involved. You you're involved in that or and actually maybe to to wrap on the Zcash story a little bit like you were part of were you part of the founding team? >> Yes. >> What did that mean like to be part I've always wondered about that because there's like a lot of co-founders. >> Yes. >> I wondered like what did you do? Ah, so so this is this is a good good question and the answer is at the the very start not as much. It was like they needed to get the Bitcoin bits of it working and like I gave them some pointers on how to work through the Bitcoin codebase but they're professional engineers and I'm not. It was a bit of like seminal engineering stuff for Libnark because the original Zcash actually used Libark

which is the code that matters visa primarily wrote and then where it really became involved was like trusted setup the first one that was my co-founders not me um on the academic side figuring that out. I did the second version and then the second version of Zcash Sapling which was Sean actually flew out. It's amazing how things work. Sean at the time was like still very budget contest. He booked a Spirit Airlines flight from Denver to Baltimore to come talk to me and Matt and we worked out the core of of of the basics for Sapling and then then Darra Strad and and Sean and every writing out that whole spec and adding some other features and stuff. So it was it was high level technical advice. um uh and then the protocol design >> and then you got involved with Alo as

well like were you kind of juggling all of these things or do you did you sort of phase out at some point? >> Yeah. Uh so what happens is like I'm an academic I do research and at some point you end up at the edge of not needing new new protocols especially for applied cryptography right you can do better snarks I don't do better snarks I use better snarks and so it's like okay Zcash is mostly done I had some bunch of involvement trying to get them to deploy stable coins but that's not a technical thing >> so we've published zero cache what's the next thing you do so as academics we're like okay well there's this Ethereum thing and literally at this point right when we were writing zerocache ethereum didn't exist and then it starts and so like Oh well, Twitter for your bank

accounts for payments. Clearly, we need to go do privacy for smart contracts, right? And there had been one paper before this that Andrew Miller did called Hawk, which took Zcash and generalize it to instead of doing a basic accounting balance, let's run an arbitrary function. >> But that isn't a smart contract system, right? That's not an operating system with different mutually distrusting programs that can talk to each other and how do you have a state model for this and how do you do privacy? And so Aleandro Tza, myself, Sean, Howard, I think Patmish was on that paper. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

>> End up working on this paper known as zero knowledge execution. >> Yes. >> Uh and this is actually like 2016, 2017. Paper took a while to to get published. >> Yeah. Cuz I remember it later. I remember more like 2019, 2020. >> Right. So this is that we start early, right? It takes a while to do these things. I think it took us like a year and a half to do the paper and then it it did the rounds getting rejected. nature of academia. And so we're working out this fundamentals of how to do privacy preserving smart contract systems, >> right? And this is the this is the model that Alio built off because at some point Howard Woo the one of the authors who was a master student in Jesus lab and also running decrypt which was this >> blockchain fund out of blockchain at

Berkeley if I recall correctly he ends up deciding to commercialize Zexi >> and that becomes Alo and so we were involved in in advising him for that. Meanwhile, a bunch of other projects actually run with the same exact state model, though I think they try to do something else first and then come back to it. So, Aztec actually uses the same model. Uh, different proofs. They've done a bunch of innovation on top of it, right? There's a whole bunch of stuff that you have to do. Same for Alio. >> And they're an L2, not an L1. So, Alio launch as a standalone >> and yes, and Alio launches, right, as a as a standalone L1, right? It's now live. Aztec is in beta still.

>> It's I think test nets are out. I think there is there is like a like an end in sight which is exciting because they're a long time coming. >> Shipping is hard, right? Shipping for zero Zcash was hard, right? That took forever. Alio took forever, right? These are like seriously hard things to do >> and it's very easy to get nerd sniped by the next thing and so it takes discipline >> and then of course you have the changing regulatory environment which causes other problems. So that core idea of how do you build private smart contracts with private state where they can communicate with each other is what we were building in in Zaxi and that has a whole there's a whole formalism in there and then there's a whole bunch of things that aren't formalized like there's an intent

model in there. I didn't even know what intents were. Yeah, >> it's not called such and I didn't even know what intents were. I didn't notice this until Zachmanian couple of years later when we put up the paper e maybe after that points out by the way page three is like a dex >> and you have intents built in >> and I'm like oh I guess yeah you're right right and there's like these these notions of of of instance identifiers a bunch of other stuff that's in there but not formalized and then actually people forgot about including us embarrassingly and then like all the projects have to reinvent this stuff um that was sexy and then that's how we got involved in alio because Howard who was one of the authors went and did Alio launched it >> interesting I mean, this is so cool to

hear your through story, your history through these projects that are so familiar to us. >> I want to make sure we leave time because there's two papers, two works that we really want to cover. >> Yeah. >> We may end up on a different podcast episode, I guess. Um, >> we can work them in because So, those are the two thing and unless there's something major in the middle that we're missing here, but it's ZK Creds, >> which Nico has been championing in almost every episode that he can. Yeah, people are sick of hearing me talk about ZK creds at this point, but we have the man himself.

>> So, I'll be back >> before we dive into this, which is what we wanted to talk about, but like is there any other work post ZXY prezks that you think we should mention? >> Uh, technically no by that definition, but there is a paper we wrote immediately after Zerocoin before Zcash. >> Oh, okay. What's >> called decentralized anonymous credentials in 2014? >> Totally hear about now. >> Exactly. Nobody has ever read of this. I I'll check it. It it does not have the largest number of citations. >> Okay. But that term is now used all the time.

>> Exactly. And there there were literally this is even in academia. This was a top tier it was in India says the top tier security conference >> but like nobody like paid attention to it. And so like we've had I've reviewed papers where someone like we were the first people to propose decentralized anonymous credentials. And my comment and I'm going to out myself as reviewer number two here is essentially have you tried googling that exact phrase? So, so we wrote this idea of let's do credentials on a blockchain and it's it's a very simple idea of like zerocoin had tokens. What if we use the tokens as a single bearer credential? So, we wanted to but the proof systems were limited. It it it it worked but >> it wasn't usable at the time.

>> It was not for some reason that idea didn't seem to have taken off right then. >> I mean I just recently had the team now called Billions and Pado used to be Iden 3. So they're coming out in 2018, >> but that's also post your work it sounds like. And they are the sort of a team that starts to work on that space. >> Yeah. >> But so it almost sounds like I mean if it was 2012 2013 that you're talking that you released that what was the date actually of that paper? >> The paper was published at NDSS in February 2014.

>> Okay. 2014. So yeah, there's like a there's like a three-year period there where or four year period where there's no pickup. And even when it is picked up, I don't know if it's that that's picked up. >> It is not that as far as I know, but I don't know that. I don't know that project. So, um, >> yeah, interesting. >> This is, by the way, I would just say this explicitly. At this point, when I'm telling the story, I'm getting into a site problem where there are a bunch of ZK identity things. The names all sound together because talk about name collisions and partial blame here too. There are only so many permutations of ID pass ZK Z whatever that you can do and I can't even keep them straight. So, 2014, we do this and it's a it's a proof of concept. Again, very primitive. no

snarks. So we wanted to come back to this and do it right because now we have better snarks and also effectively and this is the thing that I think everyone's missing and and Nico's big motive >> the ZK identity systems are an application of a smart contract in fact you have a mutable state >> that you can use to maintain your self-s sovereign local credential the entire thing that the sequence of papers from zerocoin zero cache and zexi on have been building is how do you use snarks to maintain mutable state because a standard snark is just a proof of something you can prove you have passport. You can prove you have a balance, but you can't update the balance because you double spin. You can't like >> adjust an entry in a in a table because there's no state. There's no point to prevent you from forking it. And so we

have these tools now to do this. And so we look at this in 222 is when the paper goes up. Obviously, again, we're doing this with about a year and a half lead time. 2021 co >> but there's a lot of ZK at this point. There's a lot out there. So there's a lot of rules to play with, techniques that have been discovered. Oh, that's so cool. >> Right. And actually we're playing with graph 16 still. So, and we're using arc works that that Patricia Mishra wrote and we look at this how do you do this right right we have the zk primitives we know how to do the state the state mutations how do you build this model and the model is you have various identity signals that come in you can verify a passport we do I think what might be the first zk proof for a

passport timing the first one I know >> using the NFC and all that >> using the NFC I make my grad student actually he has to get a phone from somebody to do it and writes this proof that does the parsing this is again when we wrote this and put it up on 2022 and I think the first one I know of that comes after that is some of the people who later became self put one up at ETHCC in Paris in May whenever that was uh 2023. >> Yeah, that sounds right. >> That's my understanding of the timeline here. >> Interesting. >> They didn't steal the idea from us. I want to be very clear that the foreclo we can do as ek proof about a passport have been around for a long time, >> right? And we actually it was an afterthought. The paper was like what we

want is various identity signals come in. We're going to build this up and like, hey, we know this forkclaw idea. You can do a passport proof. We might use it as a signal to put in data. >> Yeah. >> And then we realize, okay, we have this actually, we can do reuse these proofs. We could rerandomize them. So, you're still anonymous. And that idea, by the way, is underutilized. I think that's a thing. That and the parsing these things into a shared state are two ideas that nobody else, I think, still ran with. Randomizable. And the fact that you can link them >> and you can link them. Yes. >> Okay. This is all under the ZK creds work for anyone listening. This is what we're talking about. So this >> is so that earlier work 2014 that sort of goes quiet. New tools have emerged

and then you've been working on the ZK cred paper. Is it just called ZKreds? >> It's just called ZKreds. It's like ZK creds flexible anonymous credentials from ZK Snarks and existing identity infrastructure. >> Great. And it sounds like what ZK I mean we now kind of informally call this like ZK ID. There's a team called ZKID. There's teams like Raro, Self, >> Pado. I mean, it's just so funny because I'm like doing a series by by accident this year on these teams. Like almost once a month, we've been having someone on who speaks about this. I think actually the episode right before this one is Pado Billions, which is coming from the Iden 3 team. So, it's like, yeah, there's and there's EK Passport.

Yep. That's still sort of potentially upcoming. And there's a bunch of teams that have been doing this ID work. Do you get cited a lot? Do you know? >> We uh No, not that much actually. >> You know, I've actually interacted with a lot of these teams and was the first one to mention ZK to them like they were discovering that paper >> even though they were also building the same stuff, right? So, >> oh wow. >> There's this notion like yeah like you were saying Ian this folklore idea of like we can scan a passport and give us your knowledge proof of it >> but then no one want to go and check like what can you do next? And that's sort of the important part of ZK creds in my opinion.

>> And and yeah, I I should say like you should read this paper and I don't mean this in this you should cite this. I I I do occasionally tell people that, but I kind of hate to be that person. Don't >> review it too. >> Yeah. Don't don't I mean I'll do an academic context but otherwise right like you should read it because I actually I think legitimately there are a couple of ideas in there of what do you do next past the obvious folklore idea >> that a lot of these projects haven't done yet. So like I was talking to the self people. They've done a huge amount of nice work productizing this getting actually like not janky code using a bunch of different inputs for for identity but they hadn't had the idea of what if we parsed the passport once and

then use an intermediate format they were doing updates to as our own thing. >> That wasn't on their system right I don't think anyone knows the randomization stuff and then and this is not our stuff we we implemented but there were no ideas. There's a whole bunch of work from academics on anonymous credentials of things like rate limiting and deanonymizing people have to go over rate limits and a bunch of other tools that if you're building one of these systems you probably want to include because they're actually useful. But that was nonzk. This was just >> this was back. Yeah. This was >> this is older >> like structure preserving signatures, analis PSIs, these kind of things.

Analism sky original work. >> Is this like cryptologology like more like the breaking? Is this all the ways that it can break? >> No, no. This is just this is just standard cryptography but not the smart people. The actual academics like you did like >> if you know pairing original pairing based cryptography, IBE various signatures. These are like classic Euro crypto people who did a lot of hard work formalizing this stuff. >> Yeah. uh and figuring out features and snarks I think provide a better framework for flexibly program this but those features and ideas you probably want to use >> and if you go read our paper we have oh we can do all of these things literally a grab bag of them or watch there's a talk at real world crypto whichever was two years ago where we give this and that has the paper has the sites to

these things and you should use those ideas and again I want to be clear those are not our ideas but it's a good summary of here's where they these are because this paper is what's next from the call. Okay, we have a passport. Let's parse it. And then you realize it's parsing is expensive. So you at least cash the parsing on cash the signature verification. Let's do that. Th this paper tells you what to do past the forklor. We have a passport. We're going to parse it and verify the signature. And then you realize the signature verification is expensive in a ZK proof. So you actually go verify that once on chain and then you redo proofs later.

>> Uh and we go beyond that, right? Also we avoid if you want you can avoid having to um parse the verify the signature >> in the proof system because the disconnect between issuance and usage of the credential happens after that with this proof that you're in a Merkel tree or assigned element and so this is a much more efficient way to go about doing this and flexible you can bind in other identity signals you could do device binding you could do other things in there so you should read the paper >> that's cool I mean I wonder some of the teams we've had on I feel like if they were here they may say, "Oh, no. We are doing some of those things." I don't like I can't I can't totally make that connection point, but yeah, >> I I would I would suspect they are every

one of these teams is probably doing some of them. Maybe some of them have done all of them, right? This is not again a read the paper to please cite us like you're not writing academic publication. It's just like we thought through all of these ideas and put them down in one place. >> Yeah. One of the things that that there's a whole question of what the value of of academia is precisely particularly for ZK snark applications research given how much funding and momentum in in industry there is but one of the things that academia does well is you have to communicate your ideas clearly on what do you have what is the framework what comes next >> and so this enumerates all these things so you should at least read the paper to check you know all those ideas are things you're building on if you caught

up with all of them great that that's awesome if you had more than those. That's great. Awesome. Actually, you should when you write your blog post say we have all these ideas and we have these extra ones. And that's by the way the one thing I would say about when like reviewers are about site us. The actual reason that you should do that >> is it helps everyone else know what's new in your blog post. If you do these whisbang marketing posts where you claim all of the ideas under the sun are yours and new >> and people who know the area are reading and go, "No, well, those four are not." They're not going to find the two that actually are new >> and you deserve credit for. It's much clearer to say we have the fandoms for things. If you don't want to site me,

fine, don't do it. And we have these two new innovations. And that's how we actually get progress as as an industry is when everyone says here's the actual new contribution we had. We built on existing stuff. Even if you don't want to credit your competitors with what the existing stuff is, it is rhetorically useful to say existing stuff. If you're going to be a jackass about it, don't cite them. Nude thing. Because that's how you get credit. versus if you write all these blog posts that be like a pitch deck where it's like we have all this new stuff >> anyone who's Yeah. none none of it becomes new. Yeah. >> Yeah. And it doesn't propagate. >> If it's listing everything is their own, then it's it's just trying to educate maybe someone who doesn't know anything about the space, right?

>> Yeah. It sounds like making that distinction would be useful. >> It's very useful for for again even for people in industry working on this stuff. Now all of a sudden I'm like, "Oh, I wish we had like an ETH proofs pie chart for like the ETH proofs or this effort for scaling where it's like different characteristics you have to achieve or like they did the same thing for the ZK EVM >> L2 scale like is it what level of L2 it is >> but something like that for a lot of these ID systems like which of these can you check can you say you've done maybe someone's doing it actually it could also just be a table. I I would I would love to because the only way I know to do it is to go make my grad students dig through the code and they come back with

answers but they're it's timeconuming and they're not sure >> and it might not be up to date. You'd almost need the teams to sort of say what they're like doing and how and where it is and how close to open source it is or something. >> Actually, it would be a good thing to to organize like a ZK like feature competition or something. >> Yeah. I mean there's now enough of it's really quite amazing how many of these there are. There's also and I wonder maybe I don't know if you're as familiar with things like ZK email or the we work on ZK login. They're not exactly ID but they're like touching this, right?

>> They actually are. So you can use them as a as as an identity signal and I believe you mentioned this in the ZK credits paper. It's like you're going to say I have a passport, I have this, I have that. >> Right? Like and they are in fact signals, right? You can take all the ZKTLS stuff and and use it as inputs. And that is a thing that I believe a couple of projects are actually doing to some degree. There's some dicey questions of the privacy models there, but >> yeah, I'm not sure if they're actually aggregating it into a credential. You know, I I know everyone is capturing these signals and I don't know if they're creating a credential out of it, which is why I keep saying read ZKRS. >> There was another work that came out right around maybe around the same time,

Deco. Is that at all in the same kind of realm as ZK creds? >> It is. Deco is a ZKLS system. Yeah. So, it's again a signal. >> Yeah. The history of there goes, there's the TLS notary guys back in 2014. Talk about ideas that are older than you thought. And then that kind of worked and kind of didn't and it didn't have a ZK proof in it. And then the Deco guys come back and sort of redo that. Um I don't think they entirely realized they were redoing a bunch of the TLS folks. And then they add the contribution of we will do a ZK proof to show data. They want to just get data on chain >> um for sort of enterprise applications.

in fact and they don't quite realize that this could be used for other things other than like your Accenture and you want to get some legacy data on. >> Yeah. >> Um and they write that for TLS12 and it almost works but nobody there's some bugs but TLS13 is a thing everyone uses and then there's this huge race to actually formalize ZKTLS schemes that work for TLS13 and the state of that is still open. There are protocols that work but we would the state-of-the-art is evolving on a on a some timeline at least a year. Um, and those are all identity signals. And there are projects actually doing this. I think self maybe has some notions of this. The ZK like I'm going to stop naming projects. I'm going to get confused.

>> Ethereum has the ZK ID project as well looking at the European Union's requirements for their ID solution. We've we've had a lot of these on. So, we're going to have links to this in the show notes if people want to dig in. >> But some of them are doing the take ZKTLS as an input signal, I think. And certainly that is a thing you should do, right? That's one of the things that we were like in Zeke get >> cred. Cool. Nice. So, there's one more work that we haven't gotten to. There's lots more topics though, >> man. This is We're catching up on like six years at least since we started >> this attempt to have you on. And >> Aaron, we have over 10 years of research already.

>> 13 years of research. >> So, we may need to do another one. >> Yeah, we could just do another one on this one. Yeah. >> Although, let's let's at least summarize them. Maybe we go deeper on another one, but ZK promises, is this >> a totally different direction? Is it sounds quite different from what you've described just before >> or does it use ZK creds? And let's define what ZK promises are. >> So ZK promises is two things. One, it's how do you build an anonymous programmable reputation system where I can interact with you. Let's say you're Wikipedia. I prove I'm authorized. I make an edit. you later find out I rick rolled everybody and you want to ban me but I'm anonymous. So what ZK promises does is let you do that or downvote me

by having what are called anonymous callbacks, hence the promise. And so this is not that separate one because it's an idea around identity. Two, it's a stateful privacy preserving smart contract actually that's how we're doing this either on a blockchain or on a centralized server. So it's still this idea through line back to zerocoin through zc zeroccast of state and it lets you build these systems. It also lets you build just privacy preserving smart contract systems with callbacks which also gets you if you squint at it a really actually usable privacy preserving account model with full actual privacy where you kind of can like sequence your own messages people are sending to you because the guarantee

we give is if I hand you this call back it's a random number and you post it later with your arguments I have to I have to apply say ban or down vote by five later the next time I do an update or however you've written the program I have to scan through and process all of the call backs that have been sent to me, all the random numbers that are mine. I know this cuz I've saved them in my state. >> Process them that are on chain or on some server and apply them. And so that's a sequencing issue. Basically, I'm sequencing other people's callbacks back to me. So this is an observation that actually I missed originally when we were writing the paper and Patric Mishra who was on my grad students uh PhD defense observed this and it's a a point we we included in the paper uh

that you can do sequencing with it effectively. >> Right. And so ZK promises forces you to process these callbacks correctly and publish that. >> Well, it doesn't force you to publish them. It forces you to process them and apply them to your private state. Right? So the entire model here for for Aztec, Alo Zaxi is you have a commitment to we call it a ZK object. Think of it as literally an object that's running on your computer. And of course the premise is we don't trust you. So we need to make sure you don't modify that object in ways you're not programmed to. That's the ZK proof. And we need to make sure that even if you if you have an object, you can't fork it, right? You can't do a double spin, right? And so those are the two complication two things in that

model. And then to this, we add callbacks, which is a third party who doesn't know who you are, who can't track you, can be given an anonymous call back that they can then later use to force you to do the modifications. >> Mhm. >> Where ZK creds it like you create this setup and then we see it being used now in these ID systems. Yes. >> ZK promises, what's it for? like you've described a little bit of like what it can do, but let's define what ZK promises are. >> So, one thing is that you want to do anonymous reputation for like a social media system. If you want to do, I don't know, Wikipedia. The way I originally got to it was we have this problem with privacydriven cryptocurrency and people stealing funds, nation state linked hacking groups stealing funds, right?

This is what caused tornado cash problems. >> And one of the things you want for defenses for this is a notion of reputation and the ability to ban addresses, but you don't want to harm people's privacy. Mhm. And you want to go kind of beyond like they constantly just use the OFAC list and you're like that's stupid because they're not tracking every hacker on there. There's lots of bad actors that are like not on that list that you would want banned from a system. So this sounds like you need something a little more like Yeah, >> you needed to be programmable and updatable. Basically, you need what is called in if you've ever sat through a bad MBA talk or a not very good cryptocurrency executive pretending they know how to do strategy, they may have told you this thing called an udal loop.

Observe orient decide act. >> Um, kind of eccentrical of a consulting thing. >> Consultant. Yeah, >> it is. But actually, it originally comes from the air force of all places and fighter pilots, which is you have an adversary. you two are fighting and you need to look at what they're doing, decide to do something, react, they're going to counter and then the person who wins, the person who can do that loop faster, who can adapt. >> Okay? And >> so this is why we need programmable like moneyaunder prevention and reputation tools. So the point of this >> is it needs to catch up. Yeah. You can't just rely on these fixed like very slow to change lists.

>> Yeah. If you if you I have been in uh Chatam House rules roundtables where somebody stood up and pitched one of these static ZK proof you were I don't know effect list and somebody in the counter threat finance side of treasury is sitting next to me and Snickers because of course this doesn't work right like like you just like this is not reality on how people actually deal with real bad actors on real attacks right you you need to be able to adapt >> so sorry could you illustrate how ZK promises helps in this case I don't think I I followed completely >> so it's It's ambitious, but the idea is you can define various reputational signals that you have like because it's programming, you can do whatever you want and you can have people say rate addresses based on did this become stolen funds? Did it land up being

suspicious? And you don't even know who the address is, >> who owns it, right? You don't know who the account, you may not even know the address. You may just know you interacted with them. And that gives you some degree of a rating ability. And the other thing is because this is a smart contract system, it's programmable. So you can just program change the rules of what how the reputation works, what factors in this thing you wait together, what features you reveal. Right? So this is sort of a cross between ZK promises and generally a pitch for why you need privacy preserving smart contracts for compliance purposes >> and a pitch for some other papers that we may may have online in a couple of weeks >> of in general you want programmable and adaptable systems.

>> Yeah. >> Um and when you end up programming and adapting those things you are going to want callbacks. It's not the case that ZK promises is the only thing you need. It's not the tool that solves all this, but it is one of the tools you need. And that's originally how I figured out to to build it was thinking through that that >> udaloop. I mean, that idea though of like crowds voting on addresses. >> I also think about like cuz you know there's there's like the addresses that are tracked that are kind of known bad actors in the ecosystem. >> But then there's also like >> the gray zones like the market makers who might have contracts. Maybe they're supposed to do this behavior and but like from the outside it looks real sketchy and people could like the crowd >> could potentially like decimate these

things which might be good. Like maybe that's what's needed. I mean a lot of that stuff is gray zone. It's grayzone cuz it's like grreyzone. It's not really good. It's not healthy. >> And you could also get attacks like one brand that people don't like or one person has said something bad and they know the address and you could get like this reputation bomb on them. >> Yes. No, no, this is definitely like it's not clear how you should program this thing, what the reputation rules should be, who should be able to make these >> rules because they're both like attackers can get around it. There are attacks that can happen to the system. There's certainly a risk that this could become a locked down closed sort of authoritarian ecosystem under the wrong hands. And so just because this thing is secure and ZK does not mean it's a thing

you want, >> right? >> This being whatever thing you build using these tools, right? And so this is the thing to keep in mind in general when we start talking about privacy preserving smart contract systems. And just because you used a privacy preserving smart contract system, whether it's Alia or Aztec when it launches or polygon miner when it launches or whatever, just because you used one of those to build something doesn't mean that thing, even though it's ZK and nominally private, is a good idea. >> Same thing of just because you used Amazon to do something doesn't mean it's a good idea. Right? Like tools do not mean that the thing you built with a tool is a good idea or meet certain sets of values or is ethical. Yeah, >> I've seen this a lot in the identity space where people tend to forget like,

oh, my credential is anonymous, sure, but we can still use that to discriminate against you, right? We can still ask you to prove gender and discriminates against that, right? So, the the tools versus the actual use of it, >> right? So, so popping all the way up to the real world, right? So, when we wrote ZKreds, we had this case study of proving on you're over 18 to website, which at the time we thought was a hypothetical that was a bit cringy and we nearly removed it. And now of course >> like super relevant >> right there to the UK. Yeah. >> Requirements to do this. Even if you do this in a privacy way, it's not clear it's a thing. It's quite controversial for very good reasons, right? Because you can use it to gate access to content, right? Sure, you don't want extremist terrorist content maybe. But

what constitutes extremist, right? Does like antivax stuff count? Does whatever. These all are very good questions and none of them are answered by our credentials are anonymous by the way even assumes they actually are anonymous which as you just alluded to is a very open question even for some of the more private versions of these >> crazy this problem space I feel like is so exciting and I feel like we're just scratching the surface and at the same time you do have I mean you have teams that are looking to build products and they want to get to market and they they have to find customers and so it's it's interesting you're seeing research really exploring out all of these spaces. you have companies popping up but usually focused on pretty narrow

problems like yeah I'm really curious to see how some of these ideas start to permeate like other systems but yeah reputation generally like I feel like it's been talked about for a long time and there's been attempts to create you know reputation systems for for a long super long time but given AI given the lack of trust given all this stuff I feel like it's way more urgent right now to figure this stuff out and I love the idea that ZK is helping. I know it's not the only thing like like you said ZK promises it targets like a small portion of the reputation >> concept, right? You need other tools as well.

>> Yeah. I mean I guess there's I'll say one other thing. There's a whole question of how do we fund this kind of research because so I'm an academic by day like normally my research is nominally funded off of NSF funds but the National Science Foundation. there isn't that much of it to go around these days. And uh you can have companies do this, but they tend to do siloed things where they're trying to market the stuff and and doing the basic idea and then exploring the product. And I think here we need much better just like here's a set of tools, here are new tools so that you can solve these problems and we don't end up on some of the darker versions of this world where it's like utterly controlled, maybe not private to everybody problems like this.

>> And then it comes back to like how to fund public goods. >> Yes. And I don't know, it's tricky. There were moments of I don't know how to describe it. Like there's little sparks where you're like maybe it will be Gitcoin and the public community or it'll be Kickstarter like even before that it'll be communityf funded. People will know the value and they're going to put their dollars towards it and they do for a little while and then those things seem to peter out. Like I don't know if we found the right model. We had ICOs which were kind of doing that too and for some things like look at like what Nosis has built like safe and all of these really important components of Ethereum funded by an ICO built public goods but that

was like the choice of that team you know what I mean it wasn't like >> that's not a guarantee it's also yeah it's not a guarantee that the builders will be good in their case I think they are quite good >> there's a lot of things that were funded by ICOs and the the people disappeared with the money and that was it >> exactly most of them ended up being scams I don't I think that's a perfect model. But yeah, there's definitely a lot of work to do there. >> Yep. >> Seems like a topic for another day though, >> like ICOs and public goods funding. Nico, I know you had a few other topics we talked a little bit about before the show started. We don't have much time left in this episode, but do you want to just like >> Sounds like we're going to have to have

Ian on the show again. >> Yeah, I mean, we'd love to have you back, but why don't you just like throw out some of those like just the little ideas so we can think about it before then? Well, one question I actually wanted to ask you is your line of work, ZK credit, ZK promises, seems to point towards like how do we have usable systems where people can remain anonymous, but also we don't like get flooded by spam and nonsense. So is problems like civil resistance things you're also looking at? >> Yes. And in fact, that's that we have ongoing work on exactly how do you apply these techniques to that? Uh and again you know the the straw man version here which we alluded to into ZK creds and there's a couple people have maybe have deployments is you take various identity signals using ZKTLS protocols and you

composite them into a credential. There are some questions there about how is that dynamic? What are the security properties? How do you do this safely? >> Um because you can get into some some dicey questions there. But yeah, that that is one very clear thing that we want to do you want to look at and you don't want a system where everybody is locked into some biometric hardware, be it an iPhone or a world coin orb. >> So you're not advocating for scanning eyeballs. >> Uh it seems like it doesn't work very well. The eyeball scanning hardware could be great though you are trusting that it's it's a closed it's a permissioned ecosystem. You have to trust the the root of trust in the chip.

The privacy might work. There are credible claims about how that you could do this with ZK. I don't know if they implement it correctly, but it would work. >> The larger problem is you're not going to be able to do this by scanning someone's eyeball once because you can sell that account and in fact people do. >> And that's not a viable civil resistance mechanism. So you need something that is dynamic and ongoing. And that starts to become a challenge for World Coins model because they aren't going to have an orb for everybody, right? You're not going to go get rescanned every month. There aren't enough orbs. That doesn't scale for World Coin or anything else to work. you need some ongoing measurements and updates >> and they could pivot to that and then you've got some hardware you got to trust and then maybe it matters more

that it's permissioned and you have to trust the or I don't know >> okay >> but as is the scan your eyeball once model just is not a model to to protect against civils at any reasonable scale >> another point that takes us a little bit off this this will be like the quickfire question point but uh quantum security are you working on that cuz like there is talk about like some snarks being safer or Starks like hashbased you know are more quantum resistant what is it postquantum yeah resistant I'm not saying that right >> postquantum secure >> postquantum secure >> yeah do you have many lines of work happening at the same time is this a topic that you're looking at at all >> so this is a topic we're tracking

because the we build solutions for real world applications we have multiple projects going on some of them are how to securely program these systems some of them are how to actually build new capabilities some about how to do applications be it civil resistance, money laundering. One of the things I unfortunately have to track is this question about hey, what snarks are better, right? Which ones should we adapt to? And then because certain entities like the Europeans have requirements on like they want postquantum this or that, you need to track what's going on. This is somewhat amusing because for example, the European identity requirements had had issues about postquantum security and this is a problem both for some of the Stark schemes because the Stark schemes are not by default ZK. So they're not anonymous credential and the traditional analyism skaya yan cameish anonymous

credentials which are not PQ secure either. So here's the reason this is a little weird. So the the worry in general for postquantum security is a couple of years from now, couple of years might be five, it's more likely 30 or 50. Um timelines are debated. Someone might come up with a postquantum quantum computer that can break classical cryptography and therefore they could do two things. One they could forge identity system proofs now and then for certain classes of systems like encrypted messaging if it was a postconu they could decrypt stuff in the past. Right? This is called a harvest now decrypt later attack.

>> Wow. And so it's a little weird for the case of anonymous credentials particularly ZK ones particularly for the European Union for example that were worried about this because the harvest now decrypt attack doesn't apply if you're using something like even graph 16 because although graph 16 is not sound in a word with postquantum computers it is still zero knowledge it's statistically you can't break it and I don't think given the cost of a quantum computer that it's really something some 16-year-old is going to use to access violent or adult content in the European Union. So, it's a little weird occasionally when regulators say, "For proving you're over 18 online today, we need to worry about quantum computers in 50 years." Right? If you're a defense department or a department of war or whatever we've named it, you might worry about your adversary getting

a a system and 100 years later going back and reading your mail. >> But for a lot of these applic or or Zcash or Ethereum and you're worried about 50 years from now, can someone fake money? >> Right? Those are worries where you have to start sort of ask yourself what timeline do we have to react but on other things for like identity applications it's not as clear and there are very real like trade-offs like starks are postquantum sound right they would be postquantum zk if the practical implementations were zero knowledge but that's a debatable costly thing that >> nobody's done yet for reasons that are somewhat nebulous I accidentally kicked off a hornets nest on Twitter a week ago just asking about this and I was literally just asking I wasn't even like >> that was lovely to watch the threat Yeah,

>> you should find the thread cuz I was literally just like had coffee with someone. I was like, "Hey, this is an interest." And then everyone's going back and forth and I'm like, "All right, apparently this is more of a question than I thought." Right? So Starks are not ZK. And then the other premise is Starks Starks or any other hashbased proof system. I don't mean to single out Starks here specifically because that's not the case are large enough that to fit them on chain, people usually wrap them with graph 16. That's not postquantum sound. >> Yeah. Yeah. >> But it does solve your not ZK problem, which is why the ZK bit doesn't actually matter because graph 16 is ZK. In fact, it's pronounced quantum ZK. So, there's this weird This is on audio, so you don't have I don't have a good verbal

notion of shoulder shrug, but there's this weird loop of like it's not clear what's driving this and what do you want. >> Yeah. >> And what applications it matters for >> despite clearly for some it doesn't matter. Like postquantum privacy for statistically sounds ecosystem is fine. We do not need to worry about somebody with access to a quantum computer using it to access over 18 content when they're 16. >> Yeah. >> Right. And it would be too crazy to use those resources for such a silly use case. Yeah. >> Right. On the other hand, we probably do need to worry about soundness long-term for payment systems or scaling systems if you don't think you can ship stuff quickly enough to do updates. And some cryptocurrencies have enough cadence that I wouldn't worry about that of a

problem if you you'll get some warning on on especially attackers getting a quantum computer, right? Like we're not talking about the NSA gets or the GCHQ or the Russians or the Chinese get a quantum computer and keep it in the vault and tell no one about it because they're using it to spy on each other. We're talking about somebody has it to actually steal money >> and that you'll get some notice on. But if you need to design things you don't think you can deploy new technology on a 20-year timeline, you may need to worry about that. >> Legitimately >> passports still use RSA signatures, so not postquantum secure. >> That's the hilarious one for all the identity stuff. all the classical identity documents they're trying to deal with are all signed classically and there's basically no reason they're going to update that because for example

for passports you have to fit the signature in an RFID chip and that would be somewhat challenging with the state-of-the-art postquantum signatures and I'm not going to say it's impossible someone's going to like add a comment of well actually the existing standard this many bits if you spend twi three times as much on your RFID chip on your passport you could do it and they'll probably be right and it will probably still be shot down in budget reasons for they don't want to up the cost of the passport by that much and get it to be backwards compatible with their readers. >> But even the pace of updating passports, you know, like getting a whole population to change their passports is is going to take much longer than >> changing our proofs for ZKD, right?

>> Yeah. Yeah. So like the these are these are kind of funny. >> And by the way, I should also mention in the hashbased proofs, there is one that has ZK deployed. It is Lihero. >> Yes. and Google have been using that and that's you know an interesting call back to previous episodes as well. >> Yes. And that's in fact why Google did that. Oh interesting I don't know if you did you guys have the Google folks on >> we had Matteo and Abby on the show and we also had Mu come on after that. We had Liharero last year and then we had kind of an update because it's been permeating lots of different systems. So it's cool.

>> Yeah but is exciting right? It's it is EK. you can go run it in a browser like debatable apparently if the proofs are small enough that you can effectively wrap them or not. But MU has some interesting thoughts on we can do itai hashing and maybe get it to work. So >> so cool. >> I'm excited. >> Ian, we actually have even more things listed on our on our questions list, but I think we are running out of time for this one. Thank you so much for coming on the show and wow, what a journey. Like your journey through ZK, it's so colorful. you're touching so many different like key foundational things.

Yeah, thanks for sharing that with us and I can't wait to see what comes out soon too because it just sounds like you're on the cutting edge of Yeah. where ZK is kind of expanding out past payments and sort of the things we were just talking about like a decade ago that was like the main focus. Now it's going into ID and reputation and yeah, it's so cool. >> Yep. It it's been very interesting to do this full arc from ZK started for privacy for payments. Yeah. And we are now coming back of I've worked out enough tools and people have built enough battery proof systems and software you can start using it to solve more traditional larger scale computer security cable resistance reputation theft prevention problems that as an academic was actually somewhat

unsatisfying that you know this whole line of work I did that that kicked off payment to ZK and blockchain line didn't really cross-pollinate back to traditional security problems. So now we >> back then, yeah, >> we have tools. >> Cool. And now it can cross-pollinate. And actually, I think a lot of those teams and groups are learning about ZK, which is so cool. >> All right. Thanks, Ian. >> Thanks. >> Thanks, Nico. >> Thank you very much. >> I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Hector, and to our listeners. Thanks for listening.

[Music]