Anna Rose: Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we'll 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. This week, Kobi and I have a conversation about the state of ZK. The last time we did an episode like this was back in January, so it felt like a good time to catch up about what has happened in our ecosystem since then. In this conversation, we highlight some recent ZK applications, new uses for ZK, such as off-chain computation and ID. We chat about recent research breakthroughs, some new trends. We open up the topic of ZK and security, and we have a chance to finally chat about zkpod.ai. But we ran out of time for that last bit. So we'll do another episode dedicated to the zkpod.ai project soon. Now, I doubt we covered everything, and we'd love to hear from you. If you think that we should highlight some other new use cases or new ideas in the ZK space, get in touch on Twitter at @zeroknowledgefm or find us in our Telegram group. We've added the links to these in the show notes. Now, Tanya will share a little bit about this week's sponsors. Tanya: Aleo is a new layer 1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a rollup. If you're interested in building private applications, then check out Aleo's programming language called Leo. Leo enables non-cryptographers to harness the power of ZKPs to deploy decentralized exchanges, hidden information games, regulated stablecoin and more. Visit developer.aleo.org to learn more. Join their Discord at aleo.org/discord. So thanks again, Aleo. Ever feel like developing zero-knowledge proofs is a daunting task? The team at RISC Zero is here to remind you that it doesn't have to be that way. Their out-of-the-box tooling allows developers to access the magic of ZKProofs from any chain without needing to learn custom languages or building custom ZK circuits. Bonsai, RISC Zero’s most anticipated product, is a proving marketplace that enables any protocol or application to leverage fast ZKProofs in languages like Rust, Go, C++. Visit https://r0.link/ZKpodcast to learn more and sign up today for the Bonsai waitlist. And now here's our episode. Anna Rose: So I'm here today with Kobi, my very often co-host. Hey, Kobi. Kobi: Hi. Anna Rose: So today you're not going to be a co-host necessarily. Instead, we're going to do sort of a conversation with an update of the state of ZK and we want to properly introduce for the first time zkpod.ai, which we've teased, but haven't fully dove into. We actually have a lot to get through, so I hope we get to talk a lot about that. So let's kick off. What's new in ZK? What are the ideas of projects that are catching your attention? Kobi: Yeah, I think that a lot of interesting things have happened. So we see both a lot of new use cases being deployed, which is interesting. So, you know, we've seen many first ZK EVMs last year, and now we see other use cases which use very heavy, complex SNARKs being deployed. Things like ZK bridges and storage proofs and so on, which is really cool to see. These are becoming a reality and probably introduce capabilities that people would not have imagined possible a couple of years ago. Anna Rose: Wow. Kobi: Which is cool. Anna Rose: Yeah. Yeah. Kobi: I think like in one of the episodes that I was on before, we were talking about this concept of collaborative SNARKs. I think it was in the episode with Dan actually. Anna Rose: I think so too. What was that again? Kobi: So, collaborative SNARKs is the concept of combining MPC and SNARKs or more correctly making verifiable MPC. Anna Rose: Does this sort of mean like that you'd have like multiple people acting as the prover or the verifier? Would you split one of these roles into multiple roles? Kobi: Yeah, essentially that's what it means, but even more than that. So it's not only to make, let's say splitting the prover for efficiency, but it's also splitting the prover for privacy. So each different prover would hold a different part of the witness, and then you gently do a computation and then you finally get a result like you do in any MPC. But you can also prove the correctness of the computation to a third party, which is a really, really cool concept, and I totally expect to see many more interesting users of it. Anna Rose: What do you think that actually opens up? What would a collaborative SNARK do really? Kobi: Yeah, so for example, one idea that you could think about is that you have all these games that have secret information, so like Dark Forest let's say. And in those games you can imagine two parties having some armies with some properties and these armies fight each other. But you know, you don't want to reveal the entire position of your army perhaps. And you then fight, you get some results, you get the outcome of who won and what happened to the final composition of each of the different armies. Anna Rose: Yeah. Kobi: And then you can update the individual states without exposing any more information. So for example, for secret-information gaming, I think it could be pretty cool. And one other use case that we've seen that actually got deployed or more correctly is in the process of being deployed is around trading or DEXs which I think is what Renegade.fi is working on. Anna Rose: Okay. Kobi: So that seems pretty new. Anna Rose: Nice. This is helpful. I think when we covered it, it was actually very much just on like how it was constructed. Not necessarily what use cases would come out of it, so that's cool to think of. Kobi: Yeah. And I think we're yet to see the most interesting use cases. Like it's just starting. People are getting used to thinking about it even Anna Rose: That combination too, like you just gave a combination of MPC and ZK, which we had heard about for years, but this is kind of like a very unique version of it. I know I pretty recently had Sunscreen on where we were talking about ZK and FHE and I had not actually realized before that point that there's a lot of efforts to try to combine those things to find potentially like lattice-based ZKPs that could work in an FHE system. I guess in that case, and from what I got from the interview, still early days, so I don't know that there's applications that can like count on this yet, but it's really cool to see that development, right? Like, you know, six months ago we were talking about this collaborative SNARKs as an idea, and now you actually start to have people brainstorming on what that means. Kobi: Yeah, exactly. And I think you also make a good point, for example, what Sunscreen is doing is very interesting because, well, when you have FHE by itself, you just have some computation, but, you know, can you trust it was the correct computation? That's a problem. And ZK + FHE I think is super exciting as well when it becomes practical enough I guess. Anna Rose: For sure. I mean, it's funny, I think sort of the way that sometimes ZK is being described now is like, it's the umbrella term. I think we've mentioned this actually on the show before that like ZK is just the buzzword, but it actually includes MPC and Threshold Decryption and like FHE, like it's sort of lumped together even though it's different. I guess, I mean, like, you'll see, I mean we do it too. Like at a ZK conference or a ZK event, you'll also be incorporating these other advanced cryptography pieces. Kobi: Oh yeah, that's a good point. So yeah, I mean maybe if you are looking for a partner on a dating app and you're looking for someone that knows ZK you can also suggest MPC or something like that. Anna Rose: Totally. I kind of want to circle back into research or maybe development. Where are we at with tooling? You know, I want to constantly do check-ins. I feel like ZK Hack Lisbon was a bit of a check-in point, because there we could see like what tools existed that people could build with. But yeah, what are you seeing in terms of tooling? Kobi: Yeah, I think, I think that's a really good topic because developer tooling has made a big leap this year in terms of ZK that is, we see some ZK languages becoming really convenient to use and even deployable. For example, if we're looking at Noir with Aztec 3, they keep adding interesting features. For example, I think they recently added the ZK ECDSA circuit that opens up a whole world of private smart contracts, which were previously very complex to develop. I think the only relevant, maybe convenient tooling that you had for something similar would've been with SnarkyJS. Anna Rose: Okay. I was going to say a Circom there, but yeah. Kobi: Yeah, Circom 4 may maybe if you wanted to deploy it to an L1 or not enjoy something like a recursive proof. But yeah, Noir is maybe 1 level up in ergonomics, which is cool. Like I, I'm glad to see the development. And we are seeing also a lot of new designs for languages. So a few new VMs like Lurk, which, you know, with the use of all the recent techniques that people have been excited about, like folding schemes and efficient recursive proofs, you can create all these very efficient VMs and that opens up a new world in terms of how to analyze security of ZK languages, but also to go back in some sense to previous paradigms of programming and, you know, just writing programs in imperative ways rather than all of these weird circuit-like programming techniques and that improves both security aspects but also convenience. Anna Rose: That's cool. Kobi: So yeah, that, that's really cool. And, and I think we've seen, we've seen the success of this approach even in ZK Hack Lisbon. I think, for example, a lot of people enjoyed working with the RISC Zero tooling, so they were just for trust. And I remember one presentation that I've seen where people even deployed by a mistake to ZK EVM Anna Rose: Oh yeh on mainnet Kobi: And that that's really cool. Like that's, that's a big success because, because it's ZK EVM and it was just emulating everything perfectly. Then they just didn't even know they were working against it. So I think we are seeing some success of adding more and more convenience to developers, which I think will do a lot of good. Anna Rose: It's funny because like the way I sort of see the trajectory of use cases, privacy was the first one identified and it has the longest lifespan we see actually now ZK for privacy used in so many ways. But it, you know, it used to be like ZK for token privacy, but now it's ZK for X, Y, Z privacy here, there ML like it doesn't matter. It sometimes it's off the blockchain. Then we saw the scaling boom, which I guess was like 2019/2020, where people realized it used, used for the scaling. Well now you see it in, you see it happening. That's the thing. Now we see the implementations come live. so that's exciting. But there are these like new interesting spaces. And you've already mentioned collaborative SNARKs, you kind of hinted at the bridges stuff. Yeah, I wanted to bring up an area that like, I still don't know what to call. I had Yi Sun on recently to talk about Axiom. I put them in this, which is ZK+, I don't know exactly what to call these types of tools. And there's a few teams doing this kind of thing. So I know there's Veridise, there's Lagrange Labs, Axiom, and I don't know if you can put RISC Zero in that category. This is something I'm still trying to figure out, but I'll just sort of quote Yi here where he called it a co-processor. So this is like action happening off-chain, which can also interact with other parts of the blockchain in his, in the case of Axiom, it's, it's interacting with the actual consensus layer, bringing information back into smart contracts, which they can't see directly because you can go into history and stuff like that. But yeah. Would you actually, Kobi, this is sort of a question for you, but would you put RISC Zero in the category or do you think of it as something else? Kobi: I think that's a really good question in the sense that maybe you could use RISC Zero for such a thing, but maybe you could also use other techniques as well. So for example, let me make it clear. So with the co-processor stuff, then you rely on all of these data structures that let's say exist on Ethereum, right? Like state roots and such. And then you do some of chain computation and you're able to prove that they were correct because you have the state root and you can link to it from your proof, right? I guess RISC Zero is a piece of tooling that could be optimized towards such a use case definitely. But you know, the basic premise of RISC Zero itself is to allow you to use traditional languages or more correctly anything that targets RISC-V as a compilation target. So I would think that this could be a very interesting avenue for zero developers, but it's probably not limited to that. Anna Rose: And I guess it also might not be like made specifically for this kind, like it might not be the most efficient way to do it. Kobi: Yeah. But it may be very convenient. Anna Rose: Okay. Kobi: So this is a trade off that I think people can play with today, especially with hardware acceleration. So you can definitely start giving up on making the most optimized circuit and just throw it to some powerful hardware to do it for you. Which is good. I think that's healthy and I think that's great. It opens it up to many more developers. And I'm also excited about the, the co-processor stuff. It definitely uses what blockchains already do best, which making everything verifiable, even if you have to run it yourself right now since it's verifiable by people, could also be verifiable by proof. I think that offloading to SNARKs is exactly what they were good for traditionally. So. Anna Rose: Wow. Kobi: I'm very happy to see, to see the development. Anna Rose: That's so nice way you just said that. Like taking what was verifiable by people to make it verifiable by proofs. That's so cool. We still have not named this category, which is the beginning of this question. And I'm so, I don't know what to call these. I mean, so Axiom uses the word co-processor, but I also did hear from Dev Ojha that like, he was like, no, it's the wrong word for what this is. So I like, I'm trying to figure out if there is some category there and what else might be in it. Like do we put the bridges back into this as well? I know that they have some similar characteristics. Kobi: Good question. I'm not sure I would, you know, I think that in the case of bridges, you, you still have some Oracle aspect there. So for example, in storage proofs you have some anchor you can rely on, which is a storage root that you can access from the block header. Anna Rose: Yeah. Kobi: And you have an opcode that can get this for you in the smart contract. But in a bridges case, you still have some kind of entity or some kind of player that needs to tell you this is the latest state in the previous blockchain. In some sense they can always lie, but maybe philosophically you could also say that about, about storage proofs if you're looking at it is a light client because you know, maybe there is someone making an attack on you and you just see some state of the blockchain. So it's hard to decide, I guess Anna Rose: So. But you still don't have a name? We just don't have a name, off-chain something something Kobi: Anchored off-chain computation Anna Rose: Anchored off-chain computation, AOC Kobi: Awkward Anna Rose: Okay. Isn't that like a senator or something? Not senator, whatever congressperson. That's funny. So let's continue on our new use cases, interesting ways that ZK gets used. What are some other kind of areas that you're kind of paying attention to around maybe some use cases or like just interesting ways of using ZK? Kobi: Yeah, so I think you mentioned like very, very rightfully that we've seen a lot of use for token privacy for ZK traditionally and now we are seeing a lot of, let's say non-financial privacy users. And I think this kind of private information retrieval aspect is super interesting. If you abbreviated it's PIR, that is a technique that allows you to, let's say that you hold a database and I want to read something from your database, but I don't want you to see what I'm reading. So that's what this technique gives you. And this has not been extremely practical when you were the cryptographic variants of it. Like when you have a single server that's holding a database because you had variants where they, they had like non-colluding servers and which is maybe not such a realistic assumption, but now you have cryptographic variants where you have a single server holding an entire database and you can already query it privately. And that I think is becoming technique that is both efficient. Like you had a few very interesting papers just the last two years, and we even have things that are live today that you can use. And this opens up use cases such as light client privacy, you know, today is a light client when you let's use a wallet with Metamask or many any other wallet. Then if you're not running your own full node, you are giving away a lot of your activity or at least what you are interested in, even before making a transaction to some other node. Anna Rose: Is it because the node operator can actually see the query? Kobi: Yeah, exactly. Like they can see what you're asking it, right? You just have headers and now you're getting the actual data. So you can verify it, but you actually give away all of your queries and there's a lot of round trips that you make. Like I remember that when I was helping out some wallet product that's valuable, you know, both in the sense of MEV for example, but also in the sense of just privacy. You don't really want people to track what you're doing, even if it's just reading. And this technique can prevent that. Like imagine that if you had the entire state of the blockchain available to you to read without anyone being able to do that, to see what you're doing. That's really cool. Anna Rose: Do you not need to run a full node yourself here then? Kobi: No. Anna Rose: Does does the node operator need to run something special? Kobi: Yes. Not only special. It's very, very expensive. Anna Rose: Okay. Okay. Kobi: It's becoming better. Anna Rose: Yeah. Yeah. Kobi: I don't think it's practical for in the entire state today. Anna Rose: Okay. Kobi: But it's becoming much better. Anna Rose: Cool. Do you think we could start seeing actually like new, if there are new L1s launching, could they start to incorporate this already into their designs? Or do you think we're still trying to figure out what this would look like? Kobi: I definitely think so. I think that there are also variants that are optimized for specific use cases. And I think that new blockchains, for example, those that do private transactions, there you even have something that is crucial for the privacy aspect because you have all of your secret nodes that if you reveal which node you're holding, let's say if it's a mixer, then you, it reveals exactly which was the address that deposited. So you kind of get rid of all the privacy benefits that you already had. So any of those private transaction blockchains or those that includes methods that are similar would do well to include something like that. And I think some of them do or some of them are thinking about it at least. Anna Rose: Yeah. Kobi: So I would love to see more of that being deployed in practice. And there there is some very interesting work on it. There are some groups that are working on it, some companies and it's becoming real, which is again something that we didn't see two years ago. Anna Rose: Nice. I want to kind of go back to that timeline of use cases that I sort of started there with the privacy and the scaling. I know that like really soon after that more and more identity ideas came up, obviously playing into the privacy part of things. And I know at the beginning of the year I was really excited because it was the first time I was starting to see the ZK IDs come into a way that I was very excited, like, I don't know that like I could use already and you wouldn't have to be quite as technical, you wouldn't have to be quite as in the weeds to actually start to get some of the benefits. So what do you think is happening over that on that front? Kobi: What I think is that in contrast to before, you know, I was working on ZK and identity years ago, but back then you didn't have a lot of data sets that you could rely on. Yeah. You didn't have Ethereum in its all of its glory like it is now. Anna Rose: Do you kind of mean like you couldn't do very much, like all it would be would be like addresses that had transacted with some others, but there was no DeFi products. There was no like more nuanced activity? Kobi: Exactly Anna Rose: Okay. Kobi: So like you had that or you had to rely on Web2 entities adopting some kind of cryptographic measure Anna Rose: Yeah. Kobi: Or cryptographic technique to sign data and to attest that the data is correct and authorized by them and then you could rely on it in some proof because the thing about identity is that you need as always some anchor to say this is an authorized set of pieces of data that I can prove something on. And I think you didn't have a lot of that a few years ago and now you do have a lot more of that. And especially something that I think would become, that I hope will become more common is that websites and just organizations will start signing data and attesting the data in a cryptographic manner more and more. Like, I think that would be really useful. And there are even some standards that are thinking about how to do that and how to incorporate it everywhere. Yeah, that will allow you to make proofs about your data without revealing lot like you have to do today. Anna Rose: The thing is, when you start to deal with things like identity, I feel like, and I mean obviously like financial security matters, scaling super matters, the value of these networks, you know, you want the security of these things to be really good when you go into identity. You're talking, I mean you're potentially talking about like the wellbeing of individuals much more fundamentally beyond just like what financial exposure they have, but like actually, you know, are they able to access services they need or what have you. I mean this is where you start to see like, in a way it's so exciting because ZK starts to be so real and so relevant and so important and this is what we've been working on for so long. And so it's great to see it do those things. But also I feel like there comes with that, this feeling of like, are these systems ready? Have they been properly vetted? What are we doing in terms of security? Like do we have to do the DeFi route and the sort of hyper accelerationist adversarial environments where you're just like, break stuff, hackers break stuff, people suffer and then we get better. Or is there like ways to do, I don't know, something preemptive. This is something I'm thinking about a lot. Kobi: Yeah good question. I think in some sense it's very similar to traditional security in the sense that you have to get smarter about it and you have to learn all the techniques on how to hack things, which I think like, that's one of the reasons I was happy that we created ZK Hack, right? Anna Rose: Yeah. Kobi: But there's also something new here that maybe even with the hyper accelerationist route, you have something unique that if you or your system for example, incorporates privacy, then you might not even know there was a hack for a lot of time. So that kind of sucks. But I think that we are getting a lot better at auditing. We have a lot more auditors now. Still not enough. Anna Rose: Yeah. Kobi: Like still the market is very hot for those. If anyone you know, is thinking of a career change Anna Rose: We need auditors over here. Kobi: Yeah. Anna Rose: Pay is good. Kobi: I think you get paid well. Yeah. If you're good. Anna Rose: Yeah. Kobi: But I think auditors are getting better and we even see some educational programs just for auditors. Anna Rose: I loved that. Yeah. I think there is a I think they're calling it like a ZK auditor fellowship. So they're actually trying to, you know, give people the tools to actually be able to audit these systems. Not necessarily like, I guess build them or not the way that other training has gone. It's much more like how to spot the problems and how to break them. How do you teach that though? I mean, other options here would be like bug bounties or like making competitions to break things and stuff like that. Kobi: Yeah, I think that, for example, this general ZK auditing is great, but you also have specific ZK auditing style education. I think I've heard about one of these efforts, for example, for the Polygon ZK EVM. I think, you know, they were teaching a group of people how the code base looks like so that they will audit the whole thing better because it's extremely complex. And I think that would help a lot generally because SNARKs today are very, very complex, especially those that use PLONK. But yeah, I think that beyond what we do at ZK Hack, for example, that we like to maybe focus on some of them, let's say unexpected as aspects of protocols that we, when you solve the puzzle you say this should not even have been possible. I'm now scared of cryptography. There are some other competitions, like other CTFs that do some ZK stuff that show you how to break circuits, that looks like circuits that are in the wild or how to try to spot patterns, which is something that is useful when you are doing things like reverse engineering in the traditional world. So I think that competitions are also becoming different, which helps develop more for security mindset, having all of these efforts. So that's good. Anna Rose: Yeah. One of the things I've been thinking a lot about is just how, what the incentives in general for folks are because I mean, I think there's people who want to get into it professionally because they want to get the career and, and the cash, but I think there's a lot of people who get a kick out of just being kind of like the auditors I've met, I feel like a lot of them, there's a certain like, competitive spirit of like, it's just really fun to be right and to like know stuff that other people don't know, to be smart and like, but like that's awesome. That' like, if that is a motivator beyond money, that's a fantastic motivation. Kobi: That's amazing. Yeah. Anna Rose: So I wonder like, how do you reward that better? And I like, you know, a lot of hackers, especially if you're talking maybe those who like live more in the gray areas, like they're very anon so they can get I guess some cred to their anon, but they also don't necessarily want to be known. Do you know what I mean? Like, there's this funny sense of like, they want to be anonymous, but a lot of the credit I think comes within their peers. But I did wonder like if there's a way to actually reward when it's done really well and when it's, you know, saves people like a ton of pain, I think this should be really rewarded. Kobi: So do you mean like things like bug bounties and such? Anna Rose: Well that's, see, I always find, I mean, bug bounties is one thing. I just know that, like, this is something I'm thinking about. I think I might've even mentioned it already on a show. Like on a previous episode and I'd love to have other people thinking about this and I'd like to start experimenting more. Like I always kind of go to like the, maybe we could do some sort of pool of funds, maybe like something in ZPrize could be used. So I'm actually on the steering committee for that now. And that was something I had suggested, like maybe we could create some sort of way to like reward these things at the same time how do you judge these and how do they compete against one another? Like what's, you know, who wins that pot? Unless you're very, very specific about like the bug you're trying to find. I think that's maybe the challenge. Kobi: Yeah, you know. But what worries me is that even if you solve this question, which is already hard in itself, but maybe, you know, you can develop some algorithm or some criteria to decide, but even if you solve this then, you know, maybe you incentivize people enough to reveal some class of bugs or bugs that are worth an X amount of cash, let's say. But what about the really bad bugs? The ones that if you sit on on them for a year, then you can get a lot of money out. Then in that case you are in a similar boat of the problem with the security argument for things like multisig bridges. What if the incentive for the ones that are managing the multisig are not as big as what the bridge holds? This worries me because the stakes can become really, really big and the bug bounty cannot uncover everything in that manner if you look at it rationally just in terms of money, right. Anna Rose: I would almost also like to hear a report though on the success of the hackers in the really brutal hacks at actually getting their funds fully out. Kobi: That's a good point Anna Rose: Because from what I've heard from some of the more, I mean since last summer or so, I feel like the ones that we've heard about, and if you tracked them over time, there is these recoveries that have happened, people sometimes, like who, if it, especially if there's multiple hackers, some of them just giving it back because they realized all of a sudden they're dealing with funds that are in a way very tainted and potentially traceable. And I think generally like also the systems of enforcement to catch that is potentially getting better. Yeah. So that's why I would love to like offer kind of a ramp to the folks who have this kind of info to just properly share it in order to actually, but still be really rewarded, like to be highlighted, you know, so people understand that they could have done, or there could have been like a much worse thing but they chose this route, which is really ethical. Kobi: Yeah. Anna Rose: I want to get through two more things and then we have to jump into zkpod.ai, which is one of the reasons we wanted to do this episode. One is I want to just give a quick highlight of some research phenomenon. I've actually done a few episodes on this already, just now, just recently. And so that's the kind of work that's been happening on accumulation schemes or folding schemes. Kobi, in prep for this, you gave kind of a good quote that I'm just going to repeat here, but it's that last year was all about lookups and this year is all about, I called it accumulation. I think you call it more folding, but yeah like I don't know if we've actually chatted about this on the air, what do you, are you excited about this? What do you see coming? Kobi: Like I'm very excited about this. I think that, yeah, the year of folding is becoming super interesting, maybe even since you made the last episode. I don't know if that was already out, but there were very recent papers like ProtoStar and others. Anna Rose: Yeah. Kobi: There's a lot of progress happening Anna Rose: For sure. So I just had HyperNova on where we talked about the SpartanNova, SuperNova, HyperNova and I will soon have ProtoStar I hope on the show as well. See I'm trying to cover this because it is really exciting work. Kobi: Yeah. Anna Rose: And it's coming in quick succession. So that sort of shows like I don't know, at least like a circling around a technique. Kobi: Yeah, I'm really excited about this for a few reasons. One is just the fact that it can give you a lot of efficiency where previously we're thinking about things like recursive SNARKs, where you would incur a lot of overhead in making the recursive step each time. And we've already seen this in other forms. Like we've seen this atomic accumulation that you have in Halo 2, we've seen split accumulation. I think I've seen that folding schemes can be cast as split accumulation as well. So those two are really interesting because they defer a lot of the hard computations to the end. So I'm really excited to see how much efficiency they can bring. I think I've heard from some people that it might even rival some of the most efficient techniques that we have today, like STARKs even. So that's really exciting, especially with the paradigms that we are working on today, like ZK EVMs and other protocols that have repeated computation, maybe even ZK ML. So it fits very nicely with what we want to do with the circuit that we want to write and it might bring us a lot of performance benefits. So that's something that I'm really looking forward to seeing. And I think we don't have a lot of those ready to use even. We have a lot of papers, but we don't have a lot of implementations yet. Anna Rose: They're coming fast though. Kobi: Yeah, I hope so. Anna Rose: All right. You just mentioned ZK ML. This leads us into, you know, something we wanted to talk about on the show. I mean, ZK ML it's a topic in and of itself, and back when I think we were first hearing about it, it wasn't necessarily seen as like potentially viable, but there are actually use cases nowadays. There's, I know that there's this library or I don't know what you'd call this tool set, EZKL which people are actually starting to, I mean they use this in hackathon. Kobi: Yes. Anna Rose: They're starting to actually play with this like ZK ML interface. I find the, I always like, I can see it in my mind and when I pronounce it always doesn't match up. EZKL it's E Z K L? Kobi: Yeah. Anna Rose: Let's talk a little bit about some like cool ZK ML interactions. Kobi: Yeh, I maybe it's a preface. I think one model that I have in my mind when I'm thinking about ZK ML in general, why do you use ZK? Right? Like use ZK for efficiency or use ZK for privacy or things like that. Right? And this ML aspect of it is not super special in the ZK-ness of it in the sense that sure, maybe you have some large computation that is coincidentally an ML model that you want to value it with some inputs. So sure you maybe want to do this efficiently, but sometimes you also want to hide the model, for example, like we have with OpenAI and they don't reveal what is the model for GPT4 and that would be a privacy use of ZK ML. But you have some unique challenges when you're thinking about models and such because when you write functions, you can make them public a lot of times and nothing bad will happen. For example, if you just do a computation on storage proofs or Merkle trees or whatever, that's very deterministic. Not nothing can change there. But with ML a lot of things are unexpected. Like, you know, you don't, you don't know what will happen with some of the models. Anna Rose: Yeah. Kobi: Especially with these large ones. And it's hard for you even as the model developer to predict what will be the output. So all of the times you do want to keep these models hidden and because otherwise people can find some special inputs to hack them Anna Rose: And not hack them in the way that we think of hacking this is just like prompt them into saying stupid shit. Right. Or like doing stupid shit Kobi: Or evil shit. Anna Rose: Yeah. Or evil shit. Yeah. Kobi: Maybe. I think that there, there will be use cases where there will be value in hiding those models and just showing that it's fair to use them. So for example, if you're thinking about, you know, you are maybe a portfolio manager for people and you want to show that you've been using some strategy all the time, maybe you use the user, you do not trust the portfolio manager to run the same special ML model for trading that this manager runs for the clients he likes the most. So this is something that you can use such a thing for. I think a lot of the fairness aspects would come into in the real deployment. And I think maybe this is also a bit of a sad thought that this is a lot of what you can get out of it. Like you can get fairness, but maybe you cannot get clarity in the sense that, and I'm thinking like if we keep pulling on this portfolio thread Anna Rose: Yeah, yeah. Kobi: You have all of these people that are online in the non-ZK world that show you how successful they were, they were with some of their portfolios. Right. And then they use this to sell to you their services. Anna Rose: Yeah. Kobi: And it's not only individuals, it's companies as well, it's pension funds and others, but those things are kind of gained, right. Like, because they have hundreds of portfolios and they show you the successful ones. But some other ones were really unsuccessful. So the reason that I'm saying it's kind of sad like that maybe you could game the system in a similar manner here because you cannot provide any clarity about how the model really operates. Like we don't, we can't really explain what the model does. You can output some accuracy measures, you can output some successes, but you cannot gain an overall insight about it. So if you don't reveal the model, then you can only get some partial assurance on its quality. But if you reveal the model, then you are opening yourself to a Anna Rose: It wrecks it Kobi: Maybe. Yeah. Anna Rose: Okay. Okay. And this is where ZK comes in to potentially help? Kobi: No, actually I think that that's the sad thought that ZK doesn't even helped with that Anna Rose: Yeah. Damn Kobi: Yeah. I think ZK would at least assure fairness, which is already good. Anna Rose: Okay. Kobi: I think a lot of us also are in this space because we want fairness. So this is already a big benefit. But in some sense some people would say that, you know, if I trust the accuracy measures that they post, maybe I could also trust them to attest rather than prove. So I think that we might see people trying to do that instead of actually proving the fairness. They would use reputation because they would say it's not a gray area, it's 0 or 1. Either you have full trustlessness or no trustlessness. I guess you have trust, then maybe some people will say, yeah, there is no need for ZK at all. I don't think that's the case. Like I think eventually you do need that. Like you do want to enhance fairness as much as you can. So that kind of one side of it. I think. And another side of it, you know, when, when you have things like private data for users, but models that are more public. So I think that happens in situations when you have trusted hardware to generate inputs that have a specific format or that are not malicious. So for example, like Worldcoin where you have the orb attesting to its readings, Anna Rose: The Orb, I don't like the Orb. The Orb makes me uncomfortable. Kobi: Yeah. Anna Rose: I have reasons, but Kobi: So yeah. But in that case, it is something that can make sure that you cannot hack a model, that you can just provide it with inputs that are of some correct format that allows you to also give users privacy so that they can run things locally and just create proofs that they ran it. Anna Rose: Yeah. Although I think there's other, other issues with that particular project. We wanted to, on this show talk about zkpod.ai, which is not ZK ML per se, although there is a ZK ML experiment that we're going to be running around it. We don't have too much time in the show though, so why don't we just quickly introduce it. And I think we're going to have to hold on this for another part 2 almost, or just like another episode very soon where we go into a bit more detail. But let's talk a little bit about zkpod.ai. Kobi, where did the idea come from? Kobi: So I think I've been holding off on getting into the whole GPT craze for a while. And at some point I've seen some really cool experiments online from this person Yohei. He's been doing really, really cool experiments and I learned about the tool chain called LangChain which is a really cool framework that kind of gives you a very neat path into getting started with doing complex things around LMs. It gives you the methods on how to build a question and answer pipelines, how to use memory, how to use all these embeddings and and such. When I started using it, I said, that could be really cool to apply on zkPodcast but I want to add a special twist to it. Anna Rose: Yeah. Kobi: And the special twist was, wouldn't it be really, really cool if it's kind of like a podcast itself where Anna gives the answers? Anna Rose: Yeah. Kobi: And that's when I started experimenting with voice cloning tools and I started sending you every weekend some recordings Anna Rose: Saying some things and I was getting freaked out very much. Yes and then like I'll just, I'll pick up here because at some point, I think it was beginning of March that you sent me this clip, and actually I wrote a blog post about this, which is pinned on my Twitter, but it was very much just. Kobi was just writing, "I'm sorry" and a link. And the link was zkpod.ai. It wasn't called that yet, but it was sort of the first prototype of it where I saw that I could put in a question, click a button and have my voice answer it. Including though like very technical answers, like this voice, this creation could say things that I wouldn't necessarily be able to say or come up with as quickly. And it was using all of the transcripts from the show. So it was almost like the knowledge of the guests. All of a sudden being channeled through my voice, my very American sounding voice clone. That's the one tell, I don't know if there's anyone who's like, any Canadians might get this, but it's like, there's a few things, like the way it says knowledge, I don't say that it that way. I say knowledge and there's like just these few little things that it seems to get wrong, but still very creepy and totally sounds like me. Kobi: Yeah. And then, yeah, the tool that I'm using is very tuned to American voices. So for example, it works really, really bad for me like Anna Rose: Yeah. Well this is the thank you also for putting your own voice. This is sort of the like, in figuring out how to release it, I was like, put yourself in here too. So it's not just me, but they made you British. It made you British, it made your voice sound British Kobi: Yeah. It sounds really weird. Anna Rose: It's very funny. Yeah.. Kobi: Sounds like yeah, it's real weird. Anna Rose: Okay, so this was, I think, maybe our teaser into the zkpod.ai. Kobi: Yeah. Anna Rose: We have so much we want to share. We have a whole list of topics we wanted to cover, which we didn't get to in this one, but I know we've run out of time. So I say we kind of end our episode here. We've done the catch up on ZK and sort of the quick intro to zkpod.ai. And I want us to do another one. Hopefully next week we can come back with like a more detailed zkpod.ai episode because I think it's like, I think it's a very interesting evolution of this podcast in a way. So I like really want people to know about it. Kobi: Cool. Let's do it. Anna Rose: All right. So thanks Kobi for being on and going through this rundown with me. Kobi: Thank you. It was very fun. Anna Rose: Cool. I want to say a big thank you to the podcast team, Rachel, Henrik and Tanya. And to our listeners, thanks for listening.