Episode 403 - Building ZK-Powered AI Guardrails with Wyatt Benno

Transcript

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. This week, Nico and I speak with Wyatt Beno from ICME Labs. We cover how he got into ZK, specifically through the ZK hack Discord and the Justin Thaylor study group. We also discuss how this paved the way for ICME's future projects and the focus of their engineering work.

We discuss how they built Novanet, a network built to coordinate between provers before shifting their focus to bring ZK to AI with their work on ICME pre-flight that is guard rails for agents as well as developing Jolt Atlas, a productionready zero knowledge machine learning framework that allows AI powered applications to be verified or made private with ZK. This episode was a dive into agents, how ZK can lock in, and the opportunities for alternative forms of ZKML to emerge. So, hope you enjoy. Now, Tanya will share a little bit about this week's sponsor.

Today's episode is sponsored by ZK Security. Smart contracts have lost users billions of dollars to bugs. Zero knowledge protocols are next. And in ZK, the bugs are even harder to spot. A silent soundness break can let attackers forge proofs for years before anyone notices. ZK security is the first security firm dedicated entirely to zero knowledge proofs. They've audited the full stack circuits, compilers, ZKVMs, and proof systems for some of the largest projects in the space. They publish open research on ZK vulnerabilities, and they've stepped in on live deployments to rescue over a million dollars from broken trusted setups before attackers could drain them. If you're shipping a ZK protocol,

don't wait to learn what's broken the hard way. Head to zksecurity.xyz to learn more. That's zksecurity.xyz. And now, here's our episode. Today, Nico and I are here with Wyatt Beno, the technical founder of ICME Labs. Welcome to the show, Wyatt. >> Hey, Anna. Thank you for having me. >> Hey, Nico. >> Hello. Hello, >> Wyatt. I'm excited to have you on the show. I feel like I've been tracking your project for quite some time. We interacted quite a lot in the past on the Zika Hack Discord. Uh Novvenet, your project had sponsored a few of our Zika hack hackathons, but yeah, I think this is a great opportunity to understand a

little bit more where you were coming from. Can you share maybe to start a little bit of your background and what led you to work on this? >> Yeah, so I'm actually a serial technical founder. I've done a few companies of my own. Worked with private equity and also venture capital firms before as a technical team member or founder of multiple companies. In 2021, I actually sold one of my companies over summer. It was like an online office space. I was in Japan at the time and people were like, why would you want this online office space? Pandemic happened and all major universities in Japan ended up using it. So the MR was like a a hockey hockey stick and I was acquired actually by a Swedish gamification company that summer and I came back to web 3 in cryptography right after that and I

found the ZK hack discord and all this other cool stuff but actually like what really got me into it was Justin Thaylor and also Yen's groth more directly in a professional setting. So on the discord channel there was a session going on over the book. I would come every week maybe one to two times a week and have these uh very in real life sessions deep very deep deep deep deep diving into his book and also questions that people might have had. Those were all done Eastern time in the US and I asked him if he would be willing to do it in Asian time and he was like, "Yeah, sure. We we'll do some sessions then." I feel bad for it now because he was probably so tired doing these like 3 hours after.

>> Are you getting like oneon-one sessions with him too? >> They always start the same, right? You start with like 30 people and then dwindles down to like three to four people near the end of it. So, it's very very good. >> Study clubs, the study groups. Yes. >> Well, I think it's a lot of people come on not knowing like the the basic stuff and then they have like they watch the videos, whatnot. But it's one of those things at the end it's very it gets pretty personal like there's a very select group of people left. >> Totally. So this is the ZK hack discord study groups that some of you might be familiar with. Theor study group in particular I think was the longest running one. It was like three years or something. He went through his book chapter by chapter week by week three

times. So it's like a pretty dense book as far as I know. And and the people like you just said, we kind of we'd have a big group join at the beginning and then go I mean sometimes I think these would last 6 months, 8 months from what I remember. It was a channel in our Discord. Which do you know which cohort you were? >> I think I was right after the first one. So it was pretty early on. I think he only did the Asian session one time. So I was probably the first and last because it was I think pretty tiresome to be there at like 11:00 at night or whatever it might have been. But from there like I actually my co-founder is actually a professor too at the time. So we actually had this like professor arbitrage where I met him uh indirectly

online like hey we're doing stuff at ZK can we share like our ideas with you that's how kind of this the company kind of started actually off different things that's my technical background with ZK that's kind of how ZK pled but on the other way around the company was actually started off a grant and the grant was actually one person who was on the advisory board of the grant was Yen's Groth I didn't know how important his work was then but now thinking back it's like one of the the main like >> sailor and grot like there as sort of advisers or at least like working with you closely at that at that stage.

That's cool. >> Yeah. So he actually approved that grant. He was at Definity at the time and we ended up building. That's kind of how this company got started was working off that grant directly and from there I learned about folding scheme and I was the first person who implemented supernova folding which is this first NIVC folding scheme and then from them there we keep building this memory efficient space. I would say that we were very different from the beginning though. A lot of people were focused on ZK for scaling blockchains. Yeah, >> we really wanted it for local client side proving memory efficiency and these other type of use cases that I think were being ignored. Another one is privacy. We always wanted privacy >> very early on. So, >> so ZKZK >> Yeah, ZKZK exactly ZK squared. Um, another thing interesting to bring up is

actually the SEI has a monthly session with us. Uh, he comes a lot for folding implementing directly. So he was also very helpful as an adviser but we were able to strictly ask him any questions we have interesting over a 2-year plus period and we still do these sessions monthly and he shows up a lot of the time as well. Um but one final person I call out is Ben I asked him directly at event one time like what are the key things about ZK and he's like this all just polinomial evaluations. Uh so that was pretty impactful. I was like oh okay it's that easy right? It's all just polinomial evaluations we can all do this. But those I would say the four very early people who kind of helped me start >> cool >> doing ZK in a professional setting.

>> Okay. And then ICME Labs and Novanet. What what is the relationship there and kind of how did that happen? Because I really knew I think I really knew you like through the hackathons with this project Novanet. Yes. What is that? >> Yeah. So ISM labs is the company and we have a few different products that we have experimented with it and released and also done papers about Nova itself is based on the idea of having a decentralized prover network that is collaborative. So there's various different proving schemes that exist in space very different hardware settings that exist and maybe these people can come together and work together to have one final result and at the time everyone was doing like proof racing. So we all want to race. Whoever's the

fastest one gets all the money. They they win the proof race. And this is the most efficient way to do all Zate proving. But the way we were actually thinking was slightly different. Like my proving scheme might be specialized for ZKML. It might be specialized for this one thing. And yours might be you might have way better hardware than me. Let's get together and work together and actually have economic incentive to work together. And that's kind of what Novanet was based. uh is this really like sharapply value centric proving scheme for everyone to get together and work together but in terms of like projects in making tokens I feel like it's not a great idea for a lot of people to have tokens right now uh so we put that on pause a little bit over a year ago to focus on the ICM pre-flights

which is our core product now and the Joy paper was last summer is when that paper was released so >> so yeah Novanet for me has always sort of fallen into that category of proof proven marketplace. That was at least how I had sort of understood it at the time. There were a lot of projects that did kind of go live as proven marketplaces and for to you know differing levels of success. >> I think our goal was really about the researchers too like if we incentivize researchers to do research and push through this noven network then like you have kind of a flywheel. You have a researcher come in who might have the best thing for watermarking. You might have one that does the best thing for ZKML and they're actually getting money for doing this research and implementing the code because what you see is like a

lot of papers are done and no one does anything about it. >> You might have more papers, more papers, more papers, but now a lot of stuff is getting pushed live. So really having this incentive to go have researchers, implementers actually do it and make production type systems was kind of the core idea of >> Noanm. I want to move on to sort of the more contemporary projects, but ICME labs. ICME, what does that stand for? I've been really curious about this for a while. >> Yeah, I think everyone is. Some a lot of people just say IMEI. So it's like on these meetings I'm like oh it's me IMEI like no it's ICME and ironically there's like also a group at Stanford called ICME. So it's it's complicated but the naming itself comes from internet computer me. So we're going to make the internet computer easy for people and

there's back in the Ethereum world from way back in 200 whatever the internet computer was a concept. Uh defin jumped on that as well and took the concept. It's internet computer me and we're really the project I would say the first thing we were doing is making like ZK easy for regular people. So my founder was had a legal background and some of the stuff we actually literally wanted to do with legal smart contracts. So we're using ZK with folding schemes to get this like local proving but that's just kind of the backstory like we wanted to get ZK basically running everywhere. >> Nice. Mhm. Yeah. I think one other thing to note that I think is weird to say as well like a lot of projects I feel in Z are focused on like L2s and like the succinctness part of that. We actually

never focused on that at all. We were more focused on the privacy and local proving aspect which I think we're pretty unique and early at. There's a few different companies now that do it but really like we wanted most of our stuff to run on people's devices directly. So I guess that explains the focus on folding schemes and sort of these local techniques or like fast proving techniques. Correct. You could actually use folding seems to pick the step size for your computer as well, which I think is a very interesting trait. So if you didn't want like super fast proving on a gigantic machine, you can choose that step size in folding.

But if you wanted a very small device to run, you should choose a smaller step size at the cost of it takes a little bit more time to run. Uh, but you can actually do this kind of trick where you can choose the step size directly to match the machine specs. And to to this day, I still think it's the best way to kind of deal with that. Um, if you're going to look at this like step-by-step IBC type folding. >> Moving on then to the AI work. I'm actually curious like where and why and when did you like make this shift? Was it like you started to use these AI tools yourself internally for development and then realized there was problem spaces there or was it like strategic shift like Yeah. How did how did that come about?

>> So the Jolt Atlas work itself was quite a while back. We were working on the first version of it. I known about Jolt from the Staylor sessions back in 2022 or whatever it was. I thought just like the just one lookup approach for AI was very fascinating, right? If you have these lookup tables, you can actually do the nonlinear functions very directly. >> And what people were doing before was kind of using Halo 2 and all this other crazy stuff to get these lookup tables work. But really like relu and all these things that come up in the AI world are very well done in lookups and also matt mole itself which is in AI there's this matrix multiplication that happens constantly and actually it's kind of funny the tailor 13 paper had a really good way to go about it and we just

pulled that forward to those 2025 and started using it and it's weird because like people were doing GKR right like GKR from modulus and these other companies who were all using GKR4 AI but there's actually a constant factor overhead for that and you can actually just do this map model directly just with some effect, which I think is a really interesting uh historical fact. Uh performance-wise, it's very very quick. >> I want to dig in here a little bit on the connection between what is it matrix multiplication, something that's useful in the ZK context, but is actually also useful in the AI context like how how is it being used in each of these?

>> A lot of the inference and learning and all this other stuff for the AI is literally just matt. That's why it runs on GPUs. It's just a very basic function that you just run over and over and over. It's actually over 80% of the computation where you ask an AI something that's mostly what it's doing. >> Matrix multiplications. Like that's the math that's happening. >> Mhm. Exactly. And then you throw in some nonlinear functions and that's essentially what modern LLMs are. From the math aspect, it's actually not very interesting what's going on. But I think when it first came out, people were like, "Oh, this is really cool novel architecture, but still kind of like magic, right? Like it's only doing Matt Mall and these nonlinear things, but the output is very usable for everyone, which I think is just amazing." Correct me if I'm wrong here, but wasn't like

the matrix multiplication part of the hardware conversation? This idea of like accelerating ZK when we, you know, back in 2023, 2024, there was a lot of conversations about hardware. Am I am I right here? Was it like >> I think you mean multiscaler multiplication. >> Oh, >> there back in the day was >> when we had elliptic curve commitments like the main operation. >> Okay, so different math. >> Yeah, I think MSMs were a big one. actually did a web GPU implementation of MSMs as well for like local proving it's still useful. So you can still do MSM accelerated on your device. Um but I do think that's like anyone who's using elliptic curves that's one thing you do need to accelerate even today. So >> the MSM not matrixification. Okay.

>> Well, glad I got the clarification. I >> Well, it happens to me all the time deal with MCP and MPC like mixing all these AI words with the ZK words. So >> yeah. So, is Jolt Atlas different from Jolt or is it a variant on it? Is is it your own thing? Can you tell us a bit more about it? >> It's a pretty big variant. We couldn't use Jolt directly because Jolt is based on Risk 5 and we don't want to convert all this AI stuff into Risk 5 to try to run it to be like a even bigger headache and overhead for that. >> But what we can do is say, hey, let's use Onyx rather than risk 5. So, this is the format that AI uses kind of natively. So it's not WASM, it's not risk 5, it's its own special thing

called onyx. And we could run a ZKVM. It's kind of a ZKVM. We just we're just going to say it is because it's easy to say it that way, but it's kind of an onyx based uh zero knowledge virtual machine. >> The core concepts from the paper I would say are a lot of the same, but we do have these other issues that we need to deal with nonlinear functions being one main one. Going back to that connection point though, so I I sorry I got kind of like distracted by the matrix multiplication term, but like are there other things that you're seeing as like a connection point between like even what you had described before where you like the folding somehow is useful in this context like can you express a little more how how these are being maybe used in a new way?

>> I think it's interesting because folding actually did have a gigantic win at the end of the day with a Nova blindfold. So if you want to have privacy in a lot of protocols a day in production in industry or even in papers you just add Nova blindfold okay trick from the hypernova paper back in. So the Jolt team I think not too long ago also did this to their the main Jolt project. They added this Nova blindfold in and now it's ZK meaning like it it's privacy preserving and it's one of the few ZK VMs that are and also with Jolt Atlas we can do the exact same trick. We can add in Nova Blindfold. a very easy way for us to get privacy on top of what we're we're doing. So like for the AI aspect, there's just like really two cool things

that ZK can do that no other technology can do. One is sync verification which is like we can run these gigantic computations but anyone can check in under a second. We use this for guardrails in lab. So the pre-flight project is all about guardrails. We can talk about that a little bit later. The second thing is the privacy right? If you have this process we can run these guardrails but I would need to take 10 minutes for me to run. and it would take you 10 minutes to run. It's not very useful. Moreover, if I have to give you my policy for you to double check it or my my code or whatever it might be, I it destroys the use case for a lot of the ZKML stuff. Most companies don't want to give these policies, guardrail policies or these hidden local data over. So,

there's two things that what I always like want to drive home when I talk about is like sync verification is a superpower. Privacy is also a major superpower of ZK that no other technology can really bring. >> But why for AI? So, sync verification, you just sort of mentioned the guard rails. Let's let's dive into like what that actually means. >> I have so much fun speaking with people in the web 3 AI space currently. Most of them use TES which is fine. >> You mean web two AI? >> No, but web three AI companies. You look at most web three companies like hey what are you guys using? They're like we're using TE which is hardware based type stuff. But it's fun because when you ask them like hey how are you getting that stuff on chain? like how do you get these T proofs these attestation

proofs which were relatively large to like on a blockchain and sometimes they stutter like I don't know or I need to ask my technical founder but very often they do also need to wrap it in ZK and a process called ZKD decap or something like this where they wrap these T proofs to make them smaller to get on chain we do something similar with AI for guardrails but we're actually taking formal verification proofs >> so we take natural language you say like hey these are my guardrails that I want to run >> and you just give natural language we convert that with a small model to formal logic >> and then this proof is once again like large like I can check it you can check if I give you the policy but the SMT is what we're using it's not lean I'll talk about that in a little bit but it takes

a while for you to check this proof as well so it's a larger proof we wrap that in zk so now anyone can check it the policy is private and you just and fold these together multiple times over and over and over and check in under one second >> so with like a commerce you can imagine it's running a thousand times in like a second even or a a few seconds. The way people are doing it right now is they use heristics or LM guardrails or something called human in the loop. So you literally have to stop a transaction say hey this looks fishy someone check it out stop and make sure it's going okay and for root like a speed this is never going to happen. So what we do is we run these proofs at machine speed and we pull them all together and say hey if

you want to check you can check in under a second and machine can check it a human doesn't have to do it and this sync verification property is kind of amazing for that. I want to actually like explain guardrails a little more clearly because like they're very human. They're like very much user focused from what I understood from the documentation on your site. So yeah, let's explain exactly what these are and then like let's walk backwards how you actually accomplish that. >> Cool. So guardrails very generally are sets of rules you can give your AI agent for things to do and not to do. And one very basic use case we had from way back when we first started doing CML was actually like I don't want my money to be sent to North Korea like prevent that from happening. Don't send my money to

bad actors. Very basic things like >> a limit maybe something like don't spend more than >> only a bit of money to bad actor at any given time. >> Yeah. Exactly that. I think it's interesting because now what people do is like they hardcode a lot of these wallet providers just hardcode rules in and that's like for usability. It's not great. It's like only spend $500, only send to these addresses and if you're an attacker, you can just change your address. So therefore, you're you're just getting out of the system anyway. But with these AI guardrails, you can actually have natural language define these rules and you can defend against >> by natural language, you mean like I don't want to be interacting with a certain product, maybe something like that.

>> So they're factbased checks. So a good example is like an HR document that a company might have. It's like these people will get a raise here. They can take a break whatever times per year. And these are the type of rules that we're defending against. So think of like legal documents, HR or wallet policies. Don't send over this limit per day. Only send to these type of actors. These things, it's just fact-checking in AI essentially based on natural language. >> And it's very like direct like we literally have people just like send random things. And there's this battle testing progress that helps them get it defined clearly before they deploy. >> Okay. Is it for blockchain related projects primarily though? Like do you need to have digital currency? Is it more in that world or is it for like you just described HR and legal which is

like very offchain? >> So our use case specifically is agentic commerce. So it's for the adversarial settings the zk is very important right there's some overhead to it. Um, if you didn't care about like if if it's a chatbot, you don't really care if it goes off the rails a little bit because correct itself or someone could start a new session. But if it's something like, hey, I'm sending money, it's a million dollars, you will be willing to pay a little bit more time uh to wait for the ZK process to go through. So adversarial settings is really where it shines, but there's other ones too. It's not just web 3. You can imagine web 2 companies who have banking, finance, or even like company to company transactions can also use it as well. Hm. Okay. So that's the guardrails. It's text and then you said

like you basically convert that into machine understandable code. >> Yeah. So Vitalic actually had a post not too long ago as well, but he was talking about something called lean which is very popular right now without with before you would have to be an expert to interact with any of these formal verification tools. You would need normally be like a PhD or have a lot of time interacting back and forth with them. One pro way people do this is with lean and this is you interact with your LLM to get these lean proofs out and it's very effective. I think it's much faster than trying to do it by hand before. The bad thing about this is it's interactive. So you're going with this lean and this LLM the questions back and forth doing something called tactics to make these proofs come out the other

end. U but there's other ways of doing the same thing. One is called SMT >> and this is more directed one shot out these like formal proofs. So what we do is we take this natural language and we give it to an AI and it shoots out this SMT file essentially and this is called automated reasoning and this is very well well studied. uh one paper actually from not too long ago as well showed this is 88% effective and you can actually get up to 99 or 100% effective to convert from natural language to this formal logic and when you defend against that it's 100% is very very good right what people were doing before is like heristics and LLM judges and hard coding these at best are like 80ish% uh so you can imagine having money or an airplane even or like anything that's important

you wouldn't want to get on a flight if it crashed >> you don't want 80% >> yeah it's just not what you want so this process we can get to 99%. It's because we're using SMT and these LLMs to produce SMT. With lean, it was actually shown was only like 30% accurate. So, there's still more work to be done there. But another cool fact about this SMT, which is satisfiability module theorem, is that you wrap it in ZK relatively easily, which is difficult to do with a lean kernel for various reasons, but we were able to wrap ZK it with ZK. Now, we have ZK SMT, which makes it succinctly verifiable and privacy preserving. >> Interesting. the paper you just mentioned the one that showed this automated reasoning. Do you can you just share that with us? We'll add it in the show notes.

>> Yeah, it's just called automated actually I think it's neuros symbolic something very long title find it for us and we'll add it in the show notes to the links. >> So just to summarize we have a policy guardrails gets converted by an LLM into like an SMT instance and then you have an SMT proof that gets verified in ZK. Is that right? Exactly that. Okay. And so then do we have to trust the LLM that converted the policy into the SMT? And how much trust is that? I know you said like 99% but how do I know that you ran a good model to do this? So this is what I think is interesting about the binding aspect of ZK more generally, right? You can run actually an SLM and do the same

process yourself and it's a smaller model so you can run like on your device or whatever you might want to do. So with these large models that with automated reason now it normally runs on a cloud provider. You might not trust the cloud provider. uh you might want to share these proof with third parties who also don't trust the cloud provider and this is the case in agent commerce more generally but you can bind the result of your local s to the larger result they're both formal logic or they're both proving formal logic uh and you can actually share the S&T as well if you wanted to do that so a good example is like hey that gigantic LLM did 1 plus 1 2 my local also said 1 plus 1 we match the answers and we binded them together so we have kind of this trust

composibility but yeah I would say the trust there is if you trust the cloud provider who's running the larger models or you can run it locally to do the exact same thing if you want to and kind of bind those two results together. >> Also, if you're an expert, you can verify the SMT yourself just like check it before you deploy into production. And that's something we have to do, right? Like in production systems, we do do this battle testing where we have humans make sure their intent matches the formal verification files. Uh which is just a different literature aspect altogether. Like how do you match intent with formal proofs? And we do still need humans to come back in and say, "Hey, I sign off on this guardrail. this is what I wanted it to do. And then you can start using it for production use cases

and that's when you can have it run a thousand times a second. We don't say like hey just do it and not battle test it. We say hey do it and then battle test. >> What does that battle testing look like? Is that actually like a back and forth? Is it sort of like here's my guardrails? You send that off. It does it it turns it into like this formal verified proof. It tests it sends you back. Is this what you wanted me to do? And then you say yes or no. Like I'm trying to picture like how you even check that. That's also super I posted recently on Twitter and it was pretty funny is people who are like experts in the space like that's there's so much like you're you're overlooking in this one aspect you can do it like this this and this

there's a bunch of different ways to do it but the way we do it directly is actually just give you back scenarios anything that's ambiguous >> okay like the edge cases >> exactly that so if there's anything that wasn't clean that's ambiguous or there's duplicates so there might be two variables that are the same thing we'll send you back scenarios and you basically just thumbs up or thumbs down and you do this over a few iterations in norm It takes most people like a minute or two and it'll keep going back. Hey, now we're 88%, we're 94%, now we're 100%. And that's when you know you're good to go. So, it's not just satisfiable, it's also valid. And these two results together are like this is the policy guardrail that's ready to run >> once that's accepted by the creator of the agent. Does your technology then

generate this final proof of some kind? Like I'm kind of curious what that last step looks like and where does it go? Yeah, you can actually run the verifier yourself because it's just like an open source jolt verifier for this stuff. >> Okay. >> But we do create a proof on each guardrail run. So every time you're running the guardrail, say like an agent has an action, it's running on your computer, it's like, hey, I'm about to run this file, open it up and do this thing or edit it or what whatever it might be doing. We stop it there and say, hey, wait one second. We're going to run this guardrail. And after that clears yes or no is when you get the Zate proof back. You might not need that directly yourself, but if you have an auditor later down the road who's might

be collecting thousands of these together, what people do now is log everything because they're afraid that their agent might go haywire and someone has to go back and look through all these logs once again. But the magical thing with the ZK guardrails is say, "Hey, you don't need to log everything. Only when the guardrail hits, log something." And someone can literally just go back and succinly verify the proof ran and also if there was a need for it, go back and see which thing actually ran and passed the guardrail. For us though, it was money, right? So, it's a little bit different. It's like, hey, my agent needs to send money or my agent needs to do something that's adversarial. And that's when you really want this cryptographic guarantee.

>> How do you stop the agent? Like, how are you attached to this agent? >> Every agent has its own way to stop it, which is kind of irritating. So, we're unopinated about that, but they all have their different things, right? I think like with cloud code, there's something called Hookify. And what Hookify does today is it uses Reax, and it's like a coding file on your computer. And if I was an attacker, like I could just change that coding file and kind of get past this. >> Not safe. Not the best agent control. >> Not not the best, but it works really well for a lot of people, right? It runs locally. It's fast enough. They could compose it whatever they want, which is fine for like nonadversarial settings.

Once again, uh, but for anything that would be adversarial, you use hookify and you just plug us in right at that middleware layer and it runs each time. Interesting. Another thing you could do is actually use a V Z V Z V Z V Z V Z V Z V Z V Z V Z V Z V ZBM like bind the action with literally another proof if you want to >> or TE like you have the actions running in your agent might be on your computer but the actions are actually running on trusted hardware somewhere else. Uh so there's various different ways you could do it. >> You just mentioned the clawed code example, but what are the other systems like? >> Open claw is another good one. There was an incident where there's a skill that like evolves your claw code agent over time. So it's like literally evolving

step by step with you to make it better. But the it was poisoned essentially with send this data to a server in China. So this is an example of like hey you can use these skill files for whatever but a lot of them might have things that break guard rails >> that that still would have broken the guardrails. >> Depends on how you would run it, right? Like if you would use a skill file, we would be vulnerable to the same attack. If you're saying with a skill like hey use the guardrails every time. But if you actually sandbox your agent away and then you have these guardrails running as a middleware somewhere else, you would have that protection now.

>> Okay, you'd be going through it. Um, what about like any of the other agent stacks? I don't even know what to call them but >> there's so many agent stacks. It's ridiculous. There's Hermes. There's so many. There's so many more. >> Do you have to do integrations with each one? Like you basically they come out, you're like, "Okay, how do we stop these agents when we need to? you have to find the mechanism to halt it and then you somehow have to lock your guardrails into that. Is that sort of the work you're doing? >> We let the agents do that or the the customers do that a lot. So, everyone has their own way of doing it and they already have their way of doing it now which is interesting, right? So, it's like, oh, we have this way of doing it.

It's only 88% accurate. We're just flipping that over to add the cryptography in where it's essential. And what I would say about that is like it's we're unopinionated. In the paper that we have coming out on this topic specifically, it very clearly defines how you should do this, but we don't say like this is the only way you can do it. It's one of many different ways you can go about it. >> But versus people already doing things in production and versus what they're doing. I would say it's kind of a superpower to have a ZK plugged in, have the proofs coming out of it. But all these agent data, it's like the wild west right now with agents just generally speaking. You see all these protocols going out, they're mostly like reputation based and reputation is fine.

like you trust Visa, you trust whatever until it breaks. It's like, oh, I trusted that agent for this thing. It lied to me this one time. It stole my money. It's like go reputation. Um, so that's like really approaching these companies and these people who are using it has been pretty fun in a lot of different aspects. >> By the way, do you still consider this like ZK powered guard rails to be ZKML or is that something different? cuz I think people were using the term ZKML to say like, "Oh, I'm going to prove, you know, inference or proof training maybe." But this is very different, right? You actually don't even prove what the LM is doing.

>> We're actually really weird people from the very beginning. We were into folding schemes for local proving and my opinion on ZKML always was we should do what's practical first and not try to do like the biggest and greatest LLM. So, a lot of the teams I was speaking to initially were like, we want to do chat GPT, the fastest thing ever. It was always like, hey, let's do classification models. Let's do like SLM that run on people's machines. these smaller models that actually you do need trust for, right? A good example is like if you have a model running on your phone that does an iris scan. I think this is also from the world community well from from from the past. You want that to be done on your local device. It has nothing to do with LLM. Like you want a ZKML that runs

locally. It does this proof and you prove to third party I ran this model correctly and you can hand that up. So these type of use cases that are like local running with trust is where I was always more excited about. And in this case, we are doing some LLM, but they're just smaller so called SLM small language models instead of the the larger language models. >> Right? So maybe I've misunderstood, but the guardrails is only for small local models. It's not like for I'm using some cloud-based large model. >> So the guardrail itself uses Jolt to run the actual guardrail. So it has no ZKL. The transformation process from natural language to the SMT is where you have some Z. This is where you're binding the local SLM to the larger model.

>> Got you. Yeah. Yeah. So this is we have a little bit of everything in there and there is a paper coming out relatively soon. You might be able to get early access if you ask Ali for it, but it's with a major cloud provider and it's how like they had a system before that was doing this without the ZK and it's just making it much much better by adding in the ZK for various different reasons as I mentioned like logging. One good example log is like Coinbase was paying Data Dog $65 million just to log information which I think is insane right and they freaked out about like hey we should do this in-house and eventually they made a deal with Data Dog to do it but really like most of the cloud providers are saying you should log everything right now and I think

from the cryptographer perspective is like you're going to log all this stuff something bad's going to happen and you're going to have to go in and like find where it happened it didn't protect you anyway because it's very reactive cryptography more generally though is very proactive right we're setting rules upfront for what these agents are able ble to do or not able to do. I think the proactive approach is very good. >> Interesting. You mentioned your customers. You sort of said like our customers, but who are your customers? Like are you you also mentioned sort of your customers would implement these things? So are your customers OpenAI and the agent creators? Are you is it anthropic or is your customer a wallet or are they the the users the end user?

So the way we've been going about more recently is we want anchor customers and these are normally large providers of these services to third parties already. So a cloud provider might have a million customers using some guardrails that they implemented and we just want to make that much better and secure. So stable coin providers is a good example. Stable coin price or some of our public companies. They need to to know for a fact the agents aren't going off the rails and sending money to North Korea or doing these other bad things. And they have hardcoded ways of doing this, but we give them a cryptographic way to verify it as well. But there's already customers who are doing other things that have nothing to do with web 3.

They're using these existing guardrails that are you have to trust the cloud provider and you can't audit very easily and we just uh come in and kind of upgrade that system for them and then they're able to distribute these millions of customers that they already have. >> Would you be like a tool within the the cloud providers tool set potentially? >> Yeah, we would be in the marketplace and also like directly integrated in and for like our type of company most people don't know what ZK is. Most people don't know what SMD is and like going person to person trying to explain that would be very difficult. But if you have a a joint paper and people are using a product and there's just a better version of it, they're very keen to just upgrade to the better version with better capabilities.

>> The proof that you're actually the proving system that you're using to do the all of these proofs I'm guessing is the Jolt Atlas ZKVM ZK ML engine. I think you've called it both those things. They're the same thing, right? >> So there's two. We we did our own version of of Jolt. So we're using Jolt for some things and we're using Jolt Ellis for for other things. And Jolt Ellis is the ZKML variant >> of Jolt. One cool thing about this is A6Z backs Jolt. So they're indirectly we always like the joke. They're indirectly funding us by doing this really cool developing by maintaining and doing all this other stuff. So like GPUs is one thing we want to do this year as well.

So there's one goal that we have to have one GPU proving one CPU core in real time for the GAML which would be real-time proving in a sense right and there also have a similar goal. So we have now this like collaboration effort to get there and one way we're thinking about doing is actually directly with lattises rather than using elliptic curves. >> I'm glad you brought it up. I was going to ask I remember seeing you guys being involved in porting Juel to latises. So this is a great uh great segue into that. >> Yeah definitely. I think one cool thing that people often overlook about EC and lises is the homorphism >> and with all these folding scheme like that was the one thing you needed to make them efficient at folding together.

You would have this homoism trait. Uh a lot of the hashbased stuff essentially had to like find strange workarounds to make the stuff memory efficient and make the proofs succinct. But there's a few traits of lattises that are very very cool and one is homorphism. >> How do you add lises to Jolt though? How do you like what's it replacing? >> You're taking out the elliptic curve in the PCS. So commitment scheme. Uh I some people use Dory there, some use Hyax for for the drilled versions and you're taking that out and replacing it with a lattice based PCS.

>> And which one what would that be? Is it like this Neo or something like is it the work of like Shrenath? These systems are now being kind of like put in in the place of Dory. >> So we're taking something shin for the ZK aspect of it. So lettucees themselves aren't privacy preserving and we want to make them privacy preserving. So the trick from the Nova blindfold paper or the Nova blindfold trick. We're trying to make that applied to the lettuce setting and we have some notes coming out out on that relatively soon. But making this up ZK we did pull some tricks from folding scheme more generally. But other works on our team as well. There's one called ABBA which is just making all the stuff more efficient. Nico might actually know more about fine details there than I do, but

it's very deep in the weeds on the maths of lises to make it more efficient. >> It is. Is there a presentation at ZK Summit as well >> or remember? >> Uh there was the other one >> or ZK. >> Yeah. >> Oh, you did ABBA at ZK Proofs. You did Jolt Atlas I think at ZK Summit. We'll link to all of these videos. >> Mhm. >> Cuz we have those up now. >> So I think I understood how you're adding the the lattises. One of the cool things they fit in size GPUs natively. So with these lettucees you actually have smaller field sizes. So I mentioned that we did like web GPU in the past for these MSMs. And what we would have to do is convert from the CPU to the GPU and there's this gigantic overhead when you're moving the data back and forth.

But potentially with Lattises, you can just run these things directly on the GPU removing this overhead time. And then you could have like I mentioned one GPU proving one CPU kind of in real time. Just another cool thing about small fields and things uh that lettuce can do >> including on like small devices or like local I guess devices. >> It should work pretty well on most devices with GPUs directly because the field size is the same no matter what, right? >> Obviously like if you have a gigantic gigantic GPU, it's going to be faster on that in any case. But >> I want to go back to the folding itself.

So we've covered folding a number of times on this show. I think most people are familiar with it and I think you may have already explained where you're using it maybe 20 minutes ago when we were kind of going through the steps of the guardrails, but I'm still like not exactly clear on like why does folding matter here? Like is it you like are you yourself batching like all sorts of guardrail instructions together using folding or are you sharing with other people? I'm assuming not but like non-client side like on some server you're folding everything together like yeah maybe you can just explain where the folding is happening. Yeah. So, Jolt actually there was in the Jolt community, I wouldn't even call it a

community in the Jolt Telegram group, there was two different ways about going about space efficient proving for Jolt. One was like a streaming prover that the Jolt team went for and they actually implemented and the other was like folding these Jolt proofs together and we've always been a fan of that one for a few different reasons. >> But what we can do now is say you're running your guard rail and it might run a thousand times per whatever minute. If you have to check all these proofs, it's still pretty cumbersome. But what you can do since they're all similar proofs is just fold them one by one by one and have one succinct thing at the end to check that everything would well. >> Would it be like like at some time limit it would like produce this final proof?

>> You could just keep going and stop anywhere. That's what the IVC like inical verifiable compute thing is. You can just stop it whenever you want check it and then continue the progress going forward. And for an auditor like we were talking about logs earlier like if you're an auditor and you know this rule is like has been checked off by a human. It has these very specific facts. So it's factecking these agents of very specific things and you check the proof at the end. It's just much easier than going back and trying to go like a thousand different proofs, check each one over and over and over again or check the logs in a similar fashion. >> Is it creating a proof per log though? Like you you were sort of saying like you don't need to create as many logs only when it hits the guardrail, but

like what you fold in is it is it all of the logs still like are you some are they hitting somewhere or is it only the guardrail hits? And then you kind of compress those into a I know you're not supposed to use the word compressed, but like you basically like fold those into a single proof. >> So logging in the AI world is literally like the back and forth from the user to what the agent said. So you can like ask a question and somewhere in the world a chatb server is like logging that so someone can check at a later date. And there's a lot of text. It's a bunch of text based data. >> And if you do this it it quickly explodes. Like people talk to their agents constantly in very long sessions for a bunch of different things. What we

argue though for these adversarial settings is that you don't really need to do this if you have a cryptographic way of handling it. So at the end of the day you say hey there might have been something that we want to check. It only happened when the guardrail broke and we logged that one interaction with the user. Uh send my money to XYZ. We blocked it for this reason and we logged those textual things. And also here's a proof that you can just run in a verifier and also check that all these guardrails before it ran correctly. >> But again like is it just so is it just the when it hit the guardrail is like what actually ends up in this proof and it's not every time it hits a guardrail but like a collection of these hits of guardrails that would be then put

together into one proof. I'm sort of thinking of it like batching but I don't know if I'm maybe >> it's kind of like batching, right? at each guard say or unsatisfiable was like you might want to check then right like for whatever reason the agent is doing something bad is sending money to someone you might want to stop it right there and make sure the transaction doesn't go through and you might want to record why at that point rather than recording all the ones are okay >> how is that flagged for the the customer the consumer or the user of this like does your technology trigger something like an alert or something.

>> Yeah. So, in the AI world, there's something called observability. And this is I actually went to SF and talked to a bunch of AI labs. I'm like, what do you guys do now? And like we have these observability dashboards where a human like looks at it all day and make sure the agents aren't doing crazy stuff. So, they're observing their agents and there's companies that are doing this and building like making millions of dollars, even hundreds of millions. There's also companies that are doing guard rails based off observability. One was acquired last year for $500 million. And in my opinion, these are all just shittier ways of doing what we're doing. Uh, and it's interesting. It's like human in the loop for commerce will never work because really these agents are moving at speeds we can't even comprehend. And you could have my agent

interacting with your agent and we're going to go like buy an airplane ticket or do something like this. And to check all these third party integrations, not everyone's going to integrate one thing in. Uh so you do want to have like this is synchro for your own guardrails like hey this is my intent in my my natural language and my agent did protect against my my personal intent for that. I'm not a big fan of observability but yes you can absolutely see on a dashboard like hey this guardrail failed. Here's a log why why it failed. And then is there a way for these systems to recover from a fail? Like okay my agent has a guardrail. I now have proof that I was protected by my guardrails. Is that the end of the interaction or can MEN keep going and doing its thing?

>> That's where the whole reputation comes in. Right. So in the Ethereum situation, there's like ERC 80002 I believe is what it's called. And at that point, the agent would be like not trustable anymore. The identity of the agent is now known as a bad actor. And you would have to like clear the context memory and make a new agent. And the whole like point of that ERC is like, hey, these agents are running over a long time. So this should always have good reputation. And if not, we should stop that agent like we shouldn't use it. And the weird thing about that is like most agents who first made have no reputation. So you're just trusting something that has no reputation anyway. But in the the ideal world, you like clear the context and you'd reboot the agent to where it should have been in the first place. And

you can do that with like memory or these other tricks. But all agents, they're they're probabilistic. So they're always have a probability of having an issue no matter what. And we're really bringing in the the mathematics to make that more cryptographic uh rather than the probabilistic. You just mentioned that there are other companies building guard rails. How are they doing it? Why is your way better? >> Oh man, it's it's horrible. It's it's pretty crazy out there. So, one really interesting but one not so great way of doing it is something called LLM judges. So, you have your LLM that you want to defend and then you have a third party LLM look at it and say, "Hey, is this thing going crazy? Is it sending money to bad actors? What?" So you have like rather than having a human do this, you have the LLM kind of judge in but

there's something called a prompt injection attack which basically is like I'm going to trick your agent by sending it some funny text >> and it's going to send the money no matter what. Uh so this be like hidden hidden in a file. It could be direct like I could just be sending it like text or it could be hidden like emails and other very tricky ways of doing it. If you have an LLM judging an LLM, you can just do the same thing at the top top level red. So, it's just like passing the ball up and saying, "Hey, I hope we're okay this time because there's another LLM judge protecting against us." And in many real world examples, these just fail directly. Uh, they're just as gameable as the the first LLM.

>> That sort of like LLM org chart with the judges and the managers and checkers. That sort of reminds me of this episode I did last year with David Wong from CK Security who Nico works with. um where he had built out sort of this agent or chart, but of course running like owning it all. So there's ideally no malicious actor in there. Um in this case, these judges like who who's running them? Like where where are they? You would run your own. >> You could run your own. Yeah, you could run it wherever you want or you can have a third party run it for you or you can like have an SLM on your like phone even do it. There's a bunch of different ways of doing this judging process. But I think the key about that is just like very easy to go to market with that,

right? It's easy to do. You can build this project maybe using AI vibe coding tools and get it out there very quickly. I feel it's very similar to like having tees in the web 3 space. It's very easy to run a lot of stuff on TE. So most companies are using TE's. So most companies since it was easy to deploy, they're doing this LLM judge type thing. For the deep tech though, like having cryptography or something that's a little bit more protective, it takes more time to develop it and deploy it. So most of these companies aren't even aware of cryptography yet. Go to the AI lab and say like, "Hey, who are the cryptographers? Like where are they at?" And they always have a fun time answering like we have none or we don't really know what ZK FHE or any of the stuff is. It's always fun to kind of add

that back into the mix with those conversations. >> Okay. What else differentiates what you're building from these other guardrails? Like do you have a privacy aspect or not given that there's the ZK there? >> Yeah. All these people assume that you're interacting with the service provider or the guardrail provider and you trust them. Uh so it might be a cloud provider that you're on their platform and you trust them directly. >> In Agentic Commerce, you might want to show to a third party that you ran this guardrail and they don't trust this cloud provider. They don't trust this third party whatsoever. And to do this now, you'd have to hand over the policy and have them run the same process over again like this guard ran for this reason, did this facteing ABC down the list, and then they could start trusting

it. But you might not want to share your policy as a company. You might want to say like these are my rules. One example is the the North Korea example. These are the addresses we're avoiding the moment you make that public. Like they're obviously just going to use a different address. >> So what we can do with ZK is hide the policy saying, "Hey, you don't need to trust the cloud provider that they're using or the service provider of the guardrails, but you can verify this proof as a third party at the end of the day. we know for a fact it didn't go to some bad addresses or we know for a fact that the specific guard rails were without exposing all the policy. So if you're a bank is another good example as well. You're not going to like expose your customers private balances or these

other things. But with the current systems you would have to do that. You have to take these logs and show them to an auditor and the auditor would have to go check and make sure the balances are correct and this type of stuff. So the privacy from the ZK aspect there is hey the policy itself or the data that's put into the the inference is private but yeah ZKL is interesting because privacy is actually one of the most essential things for it >> and without the privacy it's not as useful as it would be otherwise. >> Are there plans to use Jolt Atlas and the stuff you guys are building in other places than in guardrails?

>> So there's actually researchers who have started using it in various universities around the world. Um, it's been pretty interesting because ZML has three separate powers, right? You can hide the inference input and make that private. So, this is like your private bank account data, your policy, whatever it might be. But you can also hide the weights. >> Um, companies spend millions of dollars training their AI and you might want to hide the weights after spending all this time and money. Um, but you can also hide the model as well. So, there's three different things that you can do with it. And hiding the model is important because you might be like chatg or open AAI cloud, whatever the company's called. uh you might spend tons of money like insane amount of money in compute and you don't want to expose that to third parties or you can

have like your own personal AI running on your own device that you fine-tuned yourself and it has private data in there and you don't want to expose that model or that data to third parties. So this SL interrupt I think has been very interesting in terms of CK. I always imagine like Apple or another big company using this stuff as well because they do have even currently AI running on your own device private data and they actually use FHE to interact with a larger LLM elsewhere. But you can imagine this for like biometrics or other things that might run on device that you want to hide the inference or the model or the weights themselves. >> In the case of your ZKML engine, what are you hiding?

>> We can actually do all three. So, we're in the upcoming paper. We're able to do all three. And there's a very cool trick that lets us do the the the model. I think it was open in the literature actually. There's one team that claimed they were able to hide the model a little bit over a year ago, but then they removed the paper, which was unfortunate because we're like, "This is a really cool trick. We want to use it." But they probably found a bug or an issue. But now we're able to hide the the model as well. So, you can do it for all three. The weights I I would say one thing is like ZKML is not for training AI. Uh so, you're never going to be like ZKML training. If you hear that, it's probably something way way way in the

future. I can imagine u because like training is very computationally heavy compared to inference. So we're mostly speaking about inference and the models and weights that are involved with that >> and small modules for now but maybe bigger models one day >> very soon bigger models like if you had the compute now we could do it like it's always people were always very bearish on everything. Two years ago people were like real time proving of Ethereum blocks. That's insane. Now it's down like 4 seconds. I think Z came on the same trajectory. People were still stuck two years ago. So when I talk to people like, "Oh, it's going to take you 5 minutes to run that, right?" I'm like, "No, we're not using this older technology. We have this brand new deck and it's actually down like 4 seconds for a lot of these use cases."

>> So for this real-time proving like if you had 64 GPUs and it was an SM, you can do real time proving today with a lot of compute. >> But more realistically, like you could probably do LLMs. I think there's already teams that are doing this for government contracts that are are not us. they're already doing this gigantic compute to do LM and they already have demonstrated like this is possible right now uh if you have the compute and it's just a matter of getting that compute down a few orders of magnitude to make it more practical for most people. >> Yeah, if we have a bit of time I I'm still curious to dig into the technicals of Jolt Atlas. So you said Jolt architecture we have this like one lookup pretty much the commitment scheme is still moving between elliptic curves as it is now and latises coming soon.

How does that compare to I know a lot of people were like doing GKR and they were saying GKR is the way to go for latises. You mentioned that earlier and you mentioned there was a downside. Could you tell us a bit more about it? So I think a lot of people are attracted to GKFR ML because there's you don't have to commit to the layers in between as you can imagine like a starting point and like a web graph of different connections at the end you have the output and this commitment cost reduction is what I'm pretty sure a lot of people found attractive about it. But there's actually a constant factor overhead for this whole process. And if you're doing mat, like your biggest claim is like, hey, we want to do matrix multiplication really quickly using GKR, you still have this constant factor

overhead. But if you just go back even further in time to failor 13, you have a different way of doing it that doesn't have that same issue. And we were able to do that. I think most teams actually converted from GKR to doing this like batched sum check type approach. >> So people are still using GKR for certain things, but I think most people have now format all come to the conclusion that this batch sum check is the way to go. What we all disagree on still is like nonlinear functions and flo floating point numbers and this type of stuff projects vary a lot on these details in the academic literature people still use ekl and halo 2 >> which is I think just an artifact if you go to the github has like a million likes which is a very well-known repo and more recently people started using

rsoft in in the literature as well and you'll probably see it referenced a lot more but yeah GKR was the way a lot of people started I think modulus was one of the first times since I heard about it maybe in 2022 and they actually acquired like super quickly which I thought was pretty interesting. Um so they built like ZML and they were acquired by worldcoin but yeah batch sums jacket seems to be the way to go recently. >> Okay. And no folding except for ZK. >> Yeah. So the that's a fun trait as well right nova blindfold is now like the de facto standard for adding privacy back in. And you do have folding if you want to aggregate proofs. It's a very effective way to aggregate these proofs together. In Jolt Atlas itself, we don't use it other than adding in privacy. And

this is an artifact from the Jolt team themselves also doing streaming proving rather than doing folding proving. So we already have like space efficient Jolt Alice by streaming if we want that. But what I can imagine later on is that we could fold some of these things together as well. There's so many tricks in the ZKO land that everything ends up being used at the end of the day. Even both from the ZK world and also the AI world. There's just a ridiculous amount of tricks and tools that are still uh vastly unexplored. >> I think you probably already did this earlier in the episode, but I'm blanking on exactly what's the difference between Jolt and Jolt Atlas.

Sorry to go back to start here. We totally talked about this difference where they are in the stack, but like I just realized I'm like, wait, what is the difference again? So, what is the difference? >> Jolt is a ZKBM based on risk 5. So a lot of people who are scaling Ethereum love risk 5. They are making a bunch of different ZKVM for risk 5 proving and jolt was one variation of that like let's use this one lookup table to very efficiently prove risk 5 via a zkm and this is sum checks very much Justin Taylor sum checks MSM lookup tables and all this great stuff right uh sparity aware is another good thing okay but Alice itself is like hey we can't use

risk 5 for AI or ML operations it's not the lingua frana there. It's completely irrelevant. What we use in the AI space is something called Onyx. >> Oh, this is where we were talking about Onyx. Okay, got it. >> This is where Onyx comes in. So, we're not using Wisk 5. We're using Onyx as the trace proving. And this is how we get the from the beginning to the end in the ZKVM world kind of as a jolt variant. And we couldn't just like change Jolt obviously because it's very risk five. We had to make our own version essentially with a lot of the same stuff. So, we have the Jolt I would say engine powering it, but we have a lot of stuff on top of it. That's the uh ZKML specific work that we do.

>> And that work that A16Z is doing is are they also working on this Jolt Atlas or are they doing something else? >> Definitely. No, they're working on a lot of stuff that's just like very I would say helps us out a lot. So adding privacy back in was one of those recent. >> Okay. But all on Jolt like the focus of their work is the Jolt sort of underlying libraries. Okay. >> Yep. They're Yeah. They're not doing third party stuff for free. So >> Got it. >> Actually, this is a good point. How do you separate risk 5 from jolt? Right? Because jolt is this one lookup and it's built specifically for risk 5. Like how do you do one lookup for onyx?

>> So it's actually not one lookup for >> onx and jolt is also not one lookup right but it's you know simplifying making a bit of a sketch. >> So really what we do is like there's a bunch of functions. We'll just call them op codes to make it easy for people who understand zik fams. In on there's a bunch of op codes and there are either linear functions or nonlinear functions that you have to run over and over in various LLMs. Each one of those we have a lookup table for and these are run and batched together in a very similar fashion that the main Jolt work is done in. But I would say each one of these is its own thing. Actually at one ZK summit I think someone was talking about ZKML more generally and I I spiked in the conversation about Jolt having this

decomposability trait which is just really good for these type of lookup tables. But more more generally speaking like I think there's also work on floating point that needs to be done. Most people we take floating point and we make it fix point for ZKML and we're still doing this but potentially with this lookup ccentric architecture you could actually do some floating point directly as well. I believe there's one paper on that last summer as well just using like jolt directly for floating point but I'm not sure how practical it is today. But in terms of like quality of the agents themselves, like most people actually use these uh fixed points rather than the floating points for like local SOM and stuff like this.

So >> cool. >> Yeah. So is there still a lot to be figured out on that front? >> I would actually say from the AI land, we have a few other people who who work with us. So neural transport teleportation is a word that doesn't exist in ZK at all, but now it might via via this podcast. But that's just a trick like you can actually take these very large lookup tables and actually make them very small and still preserve accuracy. And this is something from the AI world that they use for pushing these stuff into production on smaller servers. And we just took that and we moved it to the Z case saying, "Hey, this gigantic table would take a really long time for us to run. Let's use neural teleportation, make it smaller, preserve the accuracy, and actually be able to improve on it much more

efficiently." Um, >> teleportation is the word. That's >> Yeah, pretty sure. Unless I'm making >> and it's for lookup tables >> now. Now it's for lookup tables. Now it's applied to lookup tables. But the person we actually first met was actually also at Imperial who was doing that research and we're like, "Hey, that's really cool. Let's take that and apply it to ZK because we actually use this like making the tables smaller thing directly in the ZK world." But there's a lot of tricks that are coming from both directions. I think for us, we're looking at making latticees ZK and then we're going to make them succinctly verifiable as well and then hopefully have GPU powered. But another thing we're looking to do more recently is isogynies, which I think are just trending in cryptography.

>> But maybe like folding, we'll come back into that a little bit later as well. But these are the two things in terms of like the hardcore tech in the back end that we're looking for for the next 10x in performance uh speed. But a lot of these other things are just engineering and also from the AI world rather than the ZK world. >> Who and like what kind of group are working on the isogyny stuff? This is actually like me asking you for maybe recommendations for future podcast guests, but like yeah, what where do I even look for this? >> My lab says Alberto, who Nico also knows, he actually went to Okinawa recently for a big summit, which I think was fun. I'm like, where are you at? Is like went all the way around the world to to Okinawa and there's a summit of

all the isogyny experts. But I think the the thing there is like there's still a bunch of unresolved issues. So I would say it's like they made a version not too long ago and it's broken. >> Yeah, we know that. And I think I we covered that on the show before it was broken. >> So like that's where they're at now. But the cool like you have elliptic curves, right? Everyone's afraid that they're not postquantum secure. But then you have isogynes that are plausibly post quantum secure like yeah but they probably are, right? And the thing is like they're just very hard to prove like there takes a lot of time to do this proving. But what you might be able to do is have the fast stuff run on lises and then port over when you want succinctness to isogynes. So have kind of this back and forth between the two

things for the various traits of the two systems and both are plausibly postquantum obscure. So at the end of the day you'd have these elliptic curves finally used for PQ systems as well. But or you could just do it directly with isogynes which I think would be cool. >> What kind of math is underlying isogynes? Like isn't it completely totally different right? I I we covered it many many years ago. I don't really remember. Wasn't there like these two spaces and they're interacting across a Okay. >> Yeah. So there's two elliptic curves and I think you're finding similarities between between the two curves essentially in two different spaces.

>> But I like to mention that when we're like elliptic curves are dead. I always just like say no. Isogynes might come back and save everything. >> Wow. >> Cool. So right a few months ago we had an episode on is ZK dead and we talked a bit about ZKML and Tun was very bearish on the case for ZKML and following that you very promptly tweeted Tarun let me prove you wrong. So I'm glad we have you here actually to to do that. I'm wondering is not on here but is not on. We we need around three but yeah have we covered sort of all the exciting ideas that you think make a bullish case for ZKML. I the way I like to argue it is that the vintage of ZK is

ripe or ripening now like you might have had these things processing over many years and you're seeing them being used in real world use cases just more recently. So a good example is like when open AI started it was 200 whatever 7 years before it took them seven years to make the base tech to finally release chat GBT and with ZK a lot of the early focus was on hey let's scale blockchains it's all about scalability we don't really care about privacy or local proving uh things were went from very slow to very fast over a short amount of time and that thesis for investors was kind of like hey we're all going to have tokens they're all going to be L2s and in that sense like that there was a lot of money put in and the results were not as great as a lot of people wanted. Uh,

but for the real world use cases now like guardrails and Google using it for things people are using directly. These actually are arguably more powerful than the original vintage was. If you're doing this guardrails, you're protecting hundreds of millions of dollars of transactions that people already using worse guardrails. Uh, so I think ZK has come of age and it's right now is probably the most interesting time to actually come back in as someone investing or looking in the space just more generally. >> I mean, I love to hear this. And I also really like your metaphor of ripening and now I'm thinking like fermentation and wine and you just mentioned the vintage. This is lovely. I really like that. We'll try to we'll try to push that forward. Yeah, it's funny as you

mentioned these different use cases. I mean this there was just an announcement about I think OpenAI is now doing watermarking. As far as I know not using ZK at least I nothing in their public announcements mention it, but we did an episode on ZK for for watermarking as well. Like there's these really interesting interaction spaces for ZK in the world, but also ZK with LLM ZK. Like I I'm really excited that you just presented this one for me. That's kind of a new one. The guardrails. >> I didn't actually have that in my mind before. So yeah, thanks for sharing that with us.

>> Yeah, I I think it's super no like it's pretty novel. So even with the people we talked to who are like doing this professionally, like this is like [ __ ] really cool. Like how did you come up with that? And I think another thing is like just the pressure of having Jolt Atlas like out. What's a good way to say it? It's like everyone's doing scalability and we're always focused on this like local proving type stuff and then we happen to find like this arc paper and like we should make that ZK. Uh but there was definitely a flash of genius involved with that. It wasn't like most people were were able to just like find it randomly. So but I think anything like that like if you're just a person who's into ZK who might be in the community finding these type of

use cases like hey could this benefit from having success sync verification? could this benefit for privacy and that's kind of where you can connect the dots. Most domain experts in CK don't know about AI or they don't know about these other things and vice versa. So you can actually have this mixing and matching of skills as well. Yeah. >> So if you're someone who's looking to make a company, you can find a founder that might be a lawyer or something else and have this mixing and matching that gets these kind of novel ideas brewing. Going back to your origin story, at least in from our context in the ZK hack discord, what you're making me think of is like maybe future ZK hack hackathons should really be ZK hack X, other technology, other, you know, industry because >> maybe that's where we're at at this

point. It's not purely like ZK experiment using ZK libraries. It would be something like bringing what we've learned to something that is >> yeah is a very developed space in its own right. invite to run when you do an AI one because the the triangle is like upside down like AI has all the money and then there's like cryptography somewhere at the bottom of the pyramid like the upside down pyramid and quantum is somewhere down at the bottom too but it's like the if you flip it around then you'll have a bunch of investors show up and people are building things the investors and everyone has a fun time that way as well and one thing he mentioned to me as well like I went to this event I don't remember which one there's no other investor besides me like well you're a technical investor

like you're into the cryptography that's probably why you're here but I Just more generally speaking, like if you do that type of event, it benefits a lot of people because you do have this crossing over of different fields. Montreal part two. >> Totally. Yeah. Your amazing t-shirt. So the Novanet t-shirt, we actually checked I checked this before starting the the interview, but that's like a legendary image for me. It was Gaylord's sort of hockey theme sticker with the Novanet wording. It's very like Montreal Canadians colors as far as I remember.

And that was our kind of a t-shirt that was given out at CK Hack Montreal. >> Yeah, definitely. The prompt for that was from Gaylord and then we went out and printed it and brought to the event. I still see some today, but it's definitely vintage and awesome. >> Nice. Why is there any other projects you're working on today? Because it sounds like I mean ICM Labs is like building all of these things and you've spun out a few things. Yeah. Is what's next? >> So, we're in the distribution phase. We're have this technology that we've been working on the papers out. We're writing one more other big paper but very much about getting this out into the world via real distribution. And one reason for that is like we do believe it's the best way to have these guard rails. We already spoke about a lot of

the fine details there. Um but making agent of commerce secure or there's not going to be agent to commerce unless it's secure and we feel the distribution the the main job there to do right now. >> Cool. Thank you, Wyatt, for coming on the show, sharing with us your kind of journey into ZK, all of the work that ICM Labs is doing. I really like this pitch that you just shared at the end, this pitch to sort of find that intersection for your ZK project and yeah, hopefully we get to see more projects like that emerge. >> Thank you. It's been awesome.

>> Yeah, thank you both for a super fun interview. It's nice to be able to dig into as well the technicals of Jolt Atlas. It's fun. I think a lot more people should go and look at it now. >> Cool. Thanks again, Wyatt, Nico. I want to say thank you to the podcast team, Henrik, Rachel, Tanya, and Hector. And to our listeners, thanks for listening.