Episode 369 - Ligero for Memory-Efficient ZK with Muthu

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, GMO and I catch up with Mu from Lehiro. Last year, we had Mu and his co-founder, Carme, on the show to introduce Lehi Hero. This time, we go deeper into some of the characteristics of the system. We talk about how researchers are incorporating some of

these techniques into their own systems. Real world cases where Liharero is being used, how this system can enable client side proving and thus more private applications, the requirements of enterprise, the limitations of current benchmarking efforts and more. It was a lively chat with GMO and Mu at times digging deep into the details. So I hope you like it. Now before we kick off, I just wanted to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your jobs there today.

We've heard great things about teams who found their perfect hire through this platform. So we hope it can help you as well. Find out more at jobsboard.zeronowledge.fm. You can also find a link to this from our website and in the show notes. And now here's our episode with Mu. Today GMO and I are here with Mu from Lihero. Welcome back to the show, Mu. >> Thanks for having me, Anna. It's great to great to be here. I know it's been a while since the last podcast. >> Yeah, it's been a year. And welcome back Yumo.

>> What up? >> It's been a while since I've seen you, too. >> It has. Yeah. >> Well, actually, wait, I have seen you, but we haven't seen you on the show. >> Correct. Right. Yeah. You and I chat every once in a while, but the you know, the show I've been disappeared from. >> I'm glad to have you back on to co-host. Always lovely. >> Very cool. Um, Mu, you were on the show last year with your colleague Carmit and in that episode we did a full background on yourself, on Lee Harrow, on how the research developed, what work had inspired it. I'm going to add the link to that in the show notes. I do recommend people listen to that if they want to hear a little bit more of that full story of Lee Harrow and the company. But for this episode, I want to

understand what's happened with Lee Harrow, the project, since. And I especially wanted to have you on now because I feel like there's been this rediscovery of liarero or liarero techniques. The word liarero like I got really good at pronouncing it. I think in the last episode I kept switching between liar liger but I got it right finally because it just kept coming up on the show. So yeah, it's really great to have you back. I'm very excited to dive into Liaro, what's changed, what's new, why it's getting adopted. Yeah. So welcome.

>> Thanks Anna. Uh and yeah, it's been a while since I feel like a lot has happened since uh the last podcast. Uh but maybe let me just uh for for your listeners, let me introduce myself. Sure. I'm I'm Mu. I'm co-founder of Hero along with three excellent co-founders, Matt, Scott, and Kermit. I am also a professor at Georgetown University. I'm currently on leave, you know, trying to do something with uh uh with Lehiro, >> the company. >> The company. Um so close to our last podcast is when we closed our seed round funding and soon after we went into this marathon sprint of hey we need to build uh a platform we need to build a

platform which is going to make it easy to develop zk applications. So this was our focus from September to January that was the only thing we were doing. >> Cool. Um and in February at Eat Den were we u unveiled our platform and I think the response was amazing. I want to say that from DevCon to eat denware I I could really see the change at Devcon. I went and talked to a lot of people. Hey, like you know if you're focusing on privacy applications from zero knowledge, everyone had already agreed that gro 16 circom you know the that's the only thing you have and everyone was trying to work within the limits of what that could offer

>> and I want to say that's really great tech but when we showed our platform we said that hey like this is no longer a limit you will be able to program really scalable applications that can run on any device and then the response was overwhelming. I want to say not just from people who want to develop applications using zero knowledge but also the community the ZK community at large embracing hey like we should think about privacy and client side proving and you know I can tell more about it but uh I think this has been amazing and and I want to say we unveiled the platform in February and since then I've been resisting myself from like improving the zero knowledge to become faster or better but thinking more about how to make it more useful and usable

and thinking about you know what's the form factor in which this ZK is going to be easy for people to plug and play >> and that's what like from February to now this is what we've been uh focusing on >> and we've seen like we kind of I mentioned in this intro but like we've seen >> visions of Lee Harrow or influence of Liharero actually entering into some consumer focused projects >> but was that happening organically like did that just sort of happen because the research finally reached the ears of enough people or was that something you were actively doing?

>> So I think it's a little bit of a yes and no. uh and maybe specifically if we are talking about the integration of zero knowledge inside Google wallet >> uh which had Lihiro as part of the Ashtag I want to say that I had known this was coming right my Abi is my colleague like we've known for years like you know from our academic circles actually I met Abby at the Google ZK event they had hosted uh last summer where he was talking about implementing ZK for identity but you know we couldn't use Lihiro all the way. We had to combine it with uh GKR in a special way to get the target parameters that we wanted. And I was like, wow, that's

that's nice. And you know, I want to say it's not surprising that Lihiro is performant when you want to think of it uh of being deploy deployed on any device. But it was nice to hear that they arrived at the conclusion independently to use it. And >> nice >> independently as you said. I also think this year we've seen more people understand what is it that Lihiro can provide in the space and take advantage of it. And watching your podcast from before I would say that you know some check in GKR had the moment like probably a year or two back and I think maybe now it's uh it's Lihero >> Lihero you just mentioned that uh that the Google implementation and actually we did an episode thank you by the way for that intro to Abby and Matteo. I'm

I'm going to add a link to that in the show notes as well. That was a really great one. >> I actually thought it was important for even Google's implementation to get the voice out and I thought your show would be a great place for that to happen because uh you know for Google's project to materialize there is still a lot more steps before governments and organizations and vendors are going to going to embrace it and I think getting to the public you know through your podcast and other venues is going to be important. >> Cool. you sort of highlighted already just in your description here the client side proving and then Lee Harrow but I'm just curious like what is that connection and we might have covered this in the last episode but like why are you kind of describing Lee Harrow as

like client sideoriented I think of it as just like a cool proving system but yeah >> yes I think that's a good takeaway it is it is a cool uh proving system I think better way to explain liero than just say client side proving is really minimizing the memory footprint. Now this has implications both for client side proving but also for server side computation. You can think of you know the effort by ETH proofs on real-time block proving it has uh implications across the spectrum. Uh I want to say that what is important when you think of memory footprint is that you have a zk application. you know this is something you want to verify some condition some

you know uh algorithm you can run it on your computer let's say it takes you know a few MBs of RAM now I want to prove that same computation under zero knowledge there is going to be a transformation of this algorithm for example in succinct and risk zero they're going to translate it to a risk 5 program and then eventually into a circuit >> but the proving is often happening on a server there it's not client side >> yeah the prover is happening on a server. But the point I want to actually emphasize here is that this circuit needs to be kept in memory.

>> Now it doesn't matter where you're proving this. And the reason like is that most of these systems are use a polomial commitment scheme let's say based on starks which require the like sort of computing a like an encoding of the entire computation and this is memory intensive. You got to put it in memory to be time efficient. Where Lihiro differs from every system out there is that we don't have to do that. >> We can break the computation into pieces and then we can do sort of the encoding on these pieces. This helps with parallelism but also it helps with space.

That's one feature of it. And actually this has already been used for example in the works of breakdown. They already took advantage of this fact of that you can parallelize this. But the second feature is that the prover needs memory proportional to the underlying computation. And this requires even showing that the constraints in the underlying system can be done in a memory efficient way. And I think this is sort of a key ingredient in I want to say in the liatron system which follows the Lihero blueprint but it provides a compiling technique where the prover doesn't have to uh have enormous space to prove things and >> and this is what brings it client side

potentially. uh definitely it definitely brings it to client side and maybe let me talk about client side proving and serverside proving for a minute right >> now almost everyone who is doing 95% of the people that are trying to do privacy applications use something like cro 16 or halo 2 etc and they cannot scale beyond I want to say 1 million or 2 million constraints because they have huge proving keys these proving keys you can't you know imagine putting these proving keys on your cell phone to to run a prover. Now with our system the same things you will need probably 50 to 100 megabytes and now it becomes completely manageable and also it's not that we are restricted with 1 million to

2 million constraints. Technically you can do like an arbitrarily large computation but we have tested it up to a a billion constraints and uh if you don't trust me you can go to our platform you can open a browser and you can run this today. it will run up to a billion uh constraints uh from your browser. So on the client side, you do want a prover whose memory footprint is small otherwise you're not going to be able to scale it on a cell phone uh etc. But at the same time I also want to say I mean I think bringing in the ETH proofs effort for block proving is relevant in this discussion because uh it's not just that people want to prove blocks in very good time and you know succinct has done a great job they

announced in summer they were able to do it but from my understanding you got to use a lot of hardware to do that. Mhm. >> Yeah, I have a hot take about ETH proofs and proving blockchains and EVM stuff. So maybe it's we talking let's let's keep it technical at the moment. We can talk about the juicy stuff later. >> I think what our technology actually this is something we might be able to release this benchmark probably in the coming weeks. We'll show that we can prove blocks from a browser. It might take a while right now, but we have estimates and we have a road map where I think we can prove pretty close to realtime proving from a browser on a decent laptop, right? And >> I think at least from what I understand

from the eat proofs effort, they care about the power it takes to prove and now you want to minimize your hardware. And minimizing hardware requires minimizing footprint and this is where Lehiro comes in. >> Interesting. Waitro now I'm so curious about your hot take. >> So sorry I I wait for what it's worth. Mood it's actually a very technical hot take. This is not like one of those like oh yeah we shouldn't you know here is uh idea number one is first of all why are we you know proving an entire EVM trace like that's already crazy. You could build a blockchain any way you want. Why would you like now construct a system where you have to like build an entire system, emulate the entire system and then afterwards prove that like now middle emulation layer which we already

agree is not good >> even for running on normal computers much less proving a succinct proof thereof >> but you understand why that happened. It was just because of the history of course of course contract developers. There were a lot of people who were used to this. They wanted to redeploy code. >> Naturally there's path dependency but it's like you know we're not building a rocket and then like changing the ship like you know and then being like okay cool we got to launch a new rocket now. It's like we're doing software guys like like this is code that like exists. >> Wow. But it was like worldwide ecosystem stuff. I mean I get >> Yeah. Yeah. I I just like maybe >> I'm missing maybe a larger point. You're asking why are we trying to prove this?

Not in a concrete sense. >> He's like, "Why are you trying to recreate the EVM in the first place given that the EVM is annoying?" >> This is not on you specifically, Mu. I understand why you're doing this specifically. I'm just saying like it is a weird spot we ended up in, right? Like this is crazy. Like we have succinct proofs, we have succinct verifiers, we have all of this stuff, >> but the ideas weren't there like two years ago. >> And that's okay, but they're here now, right? Like that's the thing >> actually. I mean, I agree with you. I also think that I mean this is maybe a direction or effort people need to think about who are doing layer 1 blockchains this includes Ethereum Solana etc. uh they have to refine their smart contracting system if you want wider applicability and I'll tell you this

right like we are engaging with the enterprise and they want to write business logic and they're going to go to to to change probably where the business logic can be easily written and I've heard from them they say well EVM is hard >> this is not going to to do it but at the same time they also accept that EVM is the one that's most battle tested so I do think a lot of effort can go into making this system better for applications rather than ZK. I I think that ZK will work on any system like I think and the amount of people invested in it. I will tell you that the proving speed the the hardware this is going to come down.

>> Lihiro will achieve it but I I will say even in independent of Lihiro the the ecosystem will bring this down. So I think effort should not be driven in terms of hey we need this for ZK. I think the effort would be better if I can if it can be driven to hey for these applications we need to make our smart contracting system better. >> Cool. >> Okay GMA what do you have any other hot takes on ease? >> Yeah I think it's like it's related to the first point here and but but it's like kind of separate. I've been on this rant for for a little bit which is like like we've done this thing where we have taken the abstraction of like a blockchain as an execution environment right and in doing so right you of course have to construct these virtual

machines which run on everyone's computers which can then verify these state transitions and all of that but like I think we've lost the plot on so sorry again this is MU this is like >> kind of a criticism of blockchains >> yeah yeah it's it's like a general blockchain point here which I I think will resonate heavily with MU given you know you've done work on succinct proving systems in fact I would say like some of the best work on succinct proving systems actually is like this is crazy behavior right like we've like taken five layers of abstraction put them on top of each other now right so it's like you take a EVM which is like the thing that like normalizes all these systems and everything below it and like now we're proving all of these things in the middle >> to like finally allow you know a

Raspberry Pi to be able to check everything by rerunning everything but now of course instead of rerunning everything we're just going to rerun a sync proof inside of an EVM which is already crazy >> instead of just you know >> not doing any of that like this is like actually like insane behavior to me anyways the project is very cool I'm curious to see how far we can push the succinct proofs and like ZK to actually you know prove all of these intermediate layers but in some sense like it feels weird that we are doing this as like uh like this is like the you know the flagship project right now not not for Lehera I just mean in general like what I feel for ETH system is like let's prove blocks as they exist today and it's like like we're writing software guys we can re we can change this at any

time it's not like we're like you know 3D printing rockets or something right yeah I mean I I maybe uh my take on that is I mean I think this is how systems evolve like even if you think of operating systems programming languages over like how it evolved yeah you know it started somewhere and sometimes we are stuck with abstractions >> um you can see the constant debate between like you know software and hardware like of chips having certain uh op codes etc like this is not new to the zk space right like I'm saying to to computer science like uh this has always been and >> and we still use JavaScript >> imperfect >> I mean WASM is kind of changing that but yeah yeah we do I mean this this is the

thing and it's like it's very weird to me like I don't know how we ended up in this >> I I think this is part of evolution like I don't think it's about ending up there I think it's a process and you know it uh hopefully the system will you know tune it to to where it has to to go. >> I have a question Muchu on what you described when you talk to the corporate orgs and like EVM maybe not being suitable but like a lot of what we talk about today are like the ZKVMs that are Rust based is Rust actually better for corporates or is that also something like kind of far off for them like what language are they using?

>> I think that's a that's a good very very loaded very loaded question. No, no. I'll tell you why. Right. Because uh one of the first programming languages I learned uh from my dad was Cobalt. >> Oh yeah. >> Oh man. >> And uh a lot of corporate still uses Cobalt, right? Like so they are still in that world. >> In the in the hierarchy where does C or C++ happen? Is it before or after? >> After. >> C++ is after Cobalt. >> Oh C++ for sure. >> Yikes.

>> Is what 77? I actually yeah maybe whenever the kerning and pike book came is probably for me when C was there but >> okay >> but I don't think enterprise I want to say uh cares about the specific programming language uh they want something that they can write their logic in a clean way and probably to be audited right so I'm sure Rust is fine I'm sure any of these uh are fine EVM you know it's a challenge like because if it gets compiled down to that it's a it's a challenge uh for them but look that hasn't stopped people from embracing it right we saw the big announcement of Robin Hood on arbitum which I think was huge uh uh in the space right so people still do trust

ethereum and you know I think uh hopefully these are things that will get uh resolved along the way >> nice I think something that differentiated Lee Harrow also when we talked about it last year from a lot of the other projects that I speak with is a focus on enterprise In the past there were like the blockchain kind of projects maybe the L1's who were focused on enterprise corporate but then there was this like in ZK that didn't really happen. It's definitely we were starting very much like kind of in that independent researchy area but yeah your focus has been to speak with those customers. I'm just curious like what else are you

hearing from them? So, we've just talked a little bit about like the the need for an easy way to deploy the business logic, but yeah. Are they is there interest in ZK? Do they see opportunities with ZK or systems like yours? >> Yeah. No, I maybe this is also a good uh maybe a little bit of a segue here in terms of I want to say what's been our vision or at least how do I want to frame what Lihiro's vision is, right? I think a big blocker in blockchains to me u it's not speed it's not composability it's actually compliance >> I think a lot of the zk industry has been focusing on privacy zk is helpful for privacy but in our mind as much as

we are a zk company zk is a tool and I would also go to an extent and say privacy is a feature programmable privacy a lot of chains are focusing on this it's great But programmable compliance with privacy I think is the missing link. >> Like compliance is what is going to connect blockchains to the real world. We should be able to go and stand up in a courtroom and say, "Hey, I was compliant and I didn't leak information." And that should hold. >> And this is what we want to focus on, right? I mean, ZK is a great tech, but if we don't provide some compliance and I call it programmable compliance in a easy way, it's going to be hard for

adoption. M >> and since I want to say that you know uh since we started we pivoted from you know doing our multi-party computation protocols to zero knowledge this has been our singular focus we want to think about infrastructure that you know enterprise can use so that it will remain compliant and and private and I want to say this is not going to be easy but this is something that resonates with enterprise and again I don't I'm not making any judgments it's not like privacy before compliance it is compliance And privacy because of compliance.

>> Yeah. Or as part of compliance almost if you look at something like GDPR where it you actually have to provide privacy but you have to comply with the law. I mean it's it's an offshoot example here but like ZK could be an amazing tool for something like that if done correctly. >> Absolutely. It's not an offshoot. It is it is precisely it. I'll also go all the way back to bank secrecy act that uh asks these banks to uh enforce certain privacy uh policies and I ZK is going to be the tool to do it but I think the product is more about compliance than privacy directly >> interesting it's actually like looking at especially this year the amount of tradi you know big bank interest in the

space I sort of wonder if like they haven't fully realized yet that the wallets that they use will eventually get identified and if not already and will be mapped and that will change so many of the dynamics um investment strategies like I'm assuming this is being communicated to like some of those players but I just wonder if they realize to the extent of which this is going to change their business. This is where I also wonder if like what you just described of like private compliant but the private part of the compliant will also start to matter. Like we've been I feel like we've been talking about the privacy and how great it would be for business for years since this show started really and before I'm sure

people were talking about it before that but like the businesses didn't use this blockchain stuff anyway. So we were trying to introduce blockchain plus this private version of it and I think that was too much of an offering. But if they're already going to be doing blockchain, I just wonder if now's that moment that like the privacy problem will become super super visible to everybody. >> I'll say that I mean this is top of mind for enterprise, right? I mean privacy as part of compliance is top of their minds and it's not just enterprise, it's also stable coin providers >> because right now they're not everything's public, right? There's no like they're sort of opaque because some of the action and you know especially if it's one of these like stable coins that is like offchain stable coin issuer but

at the moment all those transactions everything is public like it's every cash payment every bank transaction you're making if you're thinking of it like a bank will be somewhere out in the open. It'll be synonymous for a while. People won't necessarily know it's you but they will eventually figure it out. No indeed for stable coins to be adopted. I mean these are things probably everyone is saying but it's worth mentioning like you know if you want to imagine banks on chain if you want to imagine salaries being paid on chain and even crossber payments uh privacy is going to be important maybe we don't care about if I went to uh you know Khan and I you know bought coffee at Starbucks maybe it's fine that this is on chain but if I am a small business and I have my vendors across the globe

people wouldn't want to reveal who their vendors are and how much they they transact with them. So for stable coins which again you know are trying to achieve these goals uh without easy to use and compliant solution it's not going to go to the next stage and this is I want to say at least the primary focus of Lihiro in terms of when we are thinking of product design using zero knowledge >> is there any interest among that community also for things being open source like do they fair like that ver the thing that a lot of people in our community care about the verifiability the fact that you can look at you know

how how code is created and everything like does that also factor in or I mean because I feel like a lot of what they use is actually closed source tech >> I think they care about it indirectly >> okay >> now you can see that at least uh historically um enterprise let's say even financial institutions haven't invested in cryptography or cryptographic techniques and they won't they actually would go for vendors to provide this service. But to trust vendors to provide this service, they're going to require these be battle tested or standardized. And to get to that place, the best way is to be open sourced. So even if they don't, I mean, at the end of the day, they probably

don't care whether it's open sourced or closed sourced, but >> from a product and using the product standpoint, I think that is the the path. But that being said, I should tell you all these institutions even though they are not themselves investing in building cryptographic techniques, almost every institution has a digital asset wing, a research wing that is exploring all these techniques. And for them, I mean, when we talk to them, hey, can I try your code, right? Like, you know, going to everyone, hey, can you sign an NDA? I mean, that doesn't, you know, bode well. So, for them, having it open source is good. You know, we are very excited. We released our code open source just a couple of weeks back and uh please go and you know try our tech you know we'd like your feedback. We'd

like more developers coming. >> Do you want them to try to break it? >> Please. I am. Yes. Please try to break it. >> 12 to CK hackers out there. Yeah. Um I want to switch gear a little bit and talk about kind of what prompted this this interview and that is the techniques of Leharo popping up in all sorts of other projects and systems and research papers and GMO I think it was in our conversations I think like you found an interest in Lehi Harrow you kind of started to highlight this to me and then I started to see it in other places like maybe not by name but like the technique that was highlighted or was kind of introduced by Lehi Hero we start to seeing things like Samaritan and Mercury work that came out of your

group Germo over at Bank Capital Crypto also releasing Lehi based things and like I actually forget like was ver was uh the accidental computer did that have any leero? >> Yeah. Yeah. Yeah. Of course. Absolutely. Essentially everything like like the way I would put it is like Mu I don't know how you did it but like Lehiro is like God's given protocol. Like this is like the way I would put it. I know this is like a very strong term and this is rare to say in academic circles but I'm gonna like go out and say it which is like there is one protocol for essentially almost everything and it is the hero and then everything else is like very downstream of that. I know people look at it the opposite way and it's like we we need to hire GMO as our PR.

>> We have to have to >> he's your hype man >> like 100%. Dude, this is like like I don't know how you came up. I know there's like a history of it and stuff at some point. And I I need to like I don't know if you drink, but I would love to like grab a beer with you and ask you the questions. But >> you can, but you don't need to. Like, you know, I I think I'm kind of the same uh both ways. Uh I I don't hear too much gossip, so you can't hear gossip from me. But uh are there any papers? Are there any actually works that I missed here? You also mentioned the Google work, the actual research that they created also using Leh Harrow, but is there anything else that I missed? I mean there's a lot a lot of stuff I

think is fundamentally based on this. There is like BCG20, there is like breakdown, there is um uh Blaze essentially uses stuff like this too. I mean in some sense it is like the simplest possible protocol you could think of that actually works and it works like beautifully well, right? And this is why it's like it's funny cuz you kind of see some rediscoveries of it in some weird sense, but but in reality it's it's like the thing that you would expect works. Um >> the uh I mean one of the things I don't know if I mentioned it in the last podcast, but u also just want to bring my you know my 5-year-old daughter, right? Like we watch kung fu panda and you know they say what's the secret

ingredient and there is no secret ingredient and really I mean as much as like I want to talk as well as gear more about liro >> um >> there isn't a secret ingredient in lihiro it is based on techniques that we have known since the 80s wow >> right like this MPC in the head the MPC we use is not something like really new that we have done we have definitely tightened the screws to the best way possible to extract as much efficiency from it. But the underlying techniques uses nothing more than secret sharing which we have known for a very very long time. But just to u maybe trace out >> Lihiro and the ZK space since blockchains right we published our paper

in 2017 actually this was before start and in fact uh when we were talking to Ellie and Ellie formed the company he was like hey like you know we want to benchmark Lihero and he said the first system they built was Lehiro and if you look at their first paper either I don't know if it was start or Aurora they actually benchmarked and you will see that Leihiro has a faster prover than air system. >> So the fact that Lihiro can give a fast prover I think I mean for people who have developed it it is obvious why it gives a fast prover but this has already been uh with people but here is where I want to kind of maybe distinguish Lehiro and Starks right what Starks and I mean Ellie has done like an amazing thing with the you know uh with making this

really the space it is today >> for sure Starks being adopted throughout like Starks and Snarks blurring together into a single thing. I think there's very few snark systems that don't have some Stark somewhere. Yeah. Or >> tech. Ellie is also an OG in the sense of like a lot of the results that we use even nowadays were like Ellie's results. Like Ellie himself like derived a lot of these like error correcting code results that are like very non-trivial. Him swastiki >> swastik and I went to school together and I ate medas. So I >> Yeah. I mean naturally, right? It's like it's all the same soup, right? It's like it's got to happen.

So the thing that is there in starks is what I call is succinct verification which lihiro doesn't have this is something wait for an announcement in a month and a half liro will have succinct verification but >> succinct verification is important and I also want to say that one of the focuses of starkware has been verifiable computing they come from this view of verifiable computing and we are coming from privacy and making it more verifiable compute and in blockchains you want sustain verification you want to verify on a smart contract. this is you need you know succent verification and this I mean there's been a lot of work refining starkware starks to uh get this property on the other hand I want

to say hasn't found that much at least since we've started you know from 2017 hasn't found its place in blockchains because of the lack of succinct verification it's still viewed as a web to thing hey like I can send it and you know you and you can verify it. And I can see Gear Mo laughing here because he's going to talk about Ligorito next. And uh um but here is the uh thing I want to say, right? We've built something that is ZK. Now we we know the wealth of how to make it succinct uh verification. This is going to come next. And I think now we're going to get sort of a best of both worlds with uh with Lihiro.

>> Cool. >> Yeah, it's interesting. I so I think like I want to go back a little bit to something you said which is like the techniques that have been known for a long time and like yeah yeah of course like the techniques have been known for a long time in like what do you do you take error correcting codes which have been known since like whatever it's like the 40s and you take random linear combinations of refined fields which says like okay yeah like that's the natural thing to do right I I think that's all true in this like general soir secret sharing which is like what 50ome 60s something but but it's it's the combination of the stuff that's very very nice what's interesting is like Mu I I I think you come from like a like an OG MPC background, right? And so this is

like why the NPC point is like so specific like oh we took NPC in the head and made it and tightened the proofs. Whereas for me it's actually completely the opposite for me it's like the NPC in the head is now like almost like a discovery method but the like natural thing is the like error correcting code version from which like the NPC view is a consequence thereof rather than a cause, right? And so anyways, I I just I I loved this is what was very fun reading the transcript of the previous episode. >> We were talking NPC in the Head. >> Yeah. Which I to for what it's worth, I still don't actually understand and I I probably will never I will die not understanding NPC in the Head, but that that's fine. That's fine. I mean, like I don't think it's a particularly pen,

glass of beer. I'll explain. That's okay. >> Let's do it. Okay. One of these days we will like absolutely do it. It's going to be great. And I will ask you a crap ton of questions about all of this. >> Maybe over a whiteboard. >> Maybe over a white Oh, that'd be fun, too. Yeah. Yeah, that's right. No, I let me say this uh about your comment gear mode. The thing is that u now we have better abstractions. Polomial commitment scheme is the abstraction that everyone uses. So MPC in the head can be viewed as a polomial commitment scheme. I think from even from an efficiency standpoint and even a perspective standpoint I think where Lihiro differs from other polomial commitment scheme with the matrix and encoding is that people who have come from the complexity like you know Ellie uh where he did

probabilistically checkable proofs etc the perspective has been that when I make a query into this oracle it's an element it's either a bit or a field element it's small but if you think of a query in the system it's actually a column of elements It's a field of elements and in the complexity world they want a small alphabet. this is really what they call it right and for optimizing things they need it to be a single element or a single bit but we come from the space where hey that is no longer a restriction and so the lio space really explores that and I want to say that that's one of the aspects that actually a lot of the systems today that

are trying to use lio is taking advantage of right like we no longer have to think of these probabistically checkable proofs etc or even uh IOP proofs where these elements elements are small, we can think of them as uh big elements. Yeah, I I will tell you that like I've never thought of anything as proistic struggle proof or even an IOP like yes implicitly it's somewhere in there but like I come from like you know cloud optimization and linear algebra and for me it's like dude this thing is a matrix your query in let's say columns now cuz we're in the column space version querying some columns of it asking some questions about it and out of it you get some hypotheses that you can test right and that's what the verifier is doing anyways this is like maybe for a deeper discussion on on some

other point but it it's so interesting just seeing we have like what now I would say like four different perspectives just like error correcting codes ogs which I would put like Ron is kind of that >> right like Ron Roslam um >> he's a cryptographer >> yeah but like you know it's really like >> we did an episode with him on error correct that's how I know him too >> I mean cryptographers are experts in error correcting codes excluding me but you know >> yeah I I am trying to nerd snipe Mary wooters has been like my one goal of like truly like an error correcting code person to just like try to do some of the stuff >> then there's like you know MPC people and there's like Ellie who comes from the PCP world and actually so does um I believe Justin Thaylor was doing

complexity stuff on circuits right >> complexity and again I I I things are changing I do have a complaint in this word is because they put zero knowledge secondary so this is a complaint for me but again this is changing I want to say since we announced like in Denver etc now a lot more companies I think including start where I see their announcements they want to do client side proving I I mean this is great for the community and we've seen it throughout this ecosystem client side is back kind of what I want to say here is that um I'm also looking forward when they can put zero knowledge back into Starks right I they're working on this this also you know we invited their people to ZK proof they're doing it but that's I'm I'm really looking forward to seeing when they are able to do that

>> for sure I think part of that by the way that reintroduction of ZK as ZK like not the royal ZK but the real ZK uh ZK for privacy this the private part of it. I think there was this like ZK was exciting. It had all these interesting characteristics. Then people focused on privacy. Then there was the push back against privacy with a couple of like tornado and other team like there was like this scaring off of a lot of teams from focusing on the privacy part of their systems. So I think they just put it on ice. They didn't like walk away.

it just sort of they went on hold on that part and they focused on these other optimizations that were like definitely less controversial in the last 6 months 8 months maybe a little bit longer but like around like really recently it's this full resurgence of just like yeah we're going to do privacy we're going to do it smart it's more sophisticated this time around too I think you talked about this compliance like I think it's like a little bit less big hammer privacy and a little more like fine screwdriver I don't know if that's a very good analogy but it's like it's definitely more thoughtful the way the privacy wants to be used. Now I think >> I I think there's like yeah there's a bit of a convergent and divergent thing happening here too where it's like yeah like the TC stuff happened and that's

fine. I think what also happened is like a lot of focus went into making the proof systems fast and small >> right and that came in spite of the privacy because it turns out like >> you know uh MU is like okay like we should have the ZK part in ZK >> uh but certainly it's much easier to reason about a lot of these systems without the ZK part and then add the ZK in and so I think what happens >> the quality that they were looking for was that sort of compression like those rollups proofs being one one prime example right if you're focused underneath proofs like the ZK part is very cool but it is otherwise like an overhead because fundamentally you're just checking stuff that's already public.

>> So anyways but but now it's like okay cool like now we have really fast things that are really really cool and really quick to prove locally and don't require that much memory and are verifiable cool like what do we do now? And it's like well like we better go back to adding some privacy to this stuff man I don't know like we called it ZK like we called it ZK for a reason. So I think that's also partially where the like you know we're not kind of converging back to the the point here where like you know these histories merge. >> Maybe one maybe controversial statement I will make is probably that it's not easy to put ZK back in. Like I'll just say that >> and if you don't trust me go watch uh you know ZK proof uh event on how to put

ZK into Starks. You'll get a flavor of what I'm trying to uh say. But that doesn't mean they can't do it. I'm sure they can do it. But I want to say you want you have to seriously deliberately think about it. And one of the things just going back to MPC in the head is that you get privacy for free. If you started thinking from MPC in the head, secret sharing rather than error correction because secret sharing has privacy inbuilt in it. Then you know what follows is you get these properties automatically when you are building uh the ZK system. And for us at least again Kermit and me what drove us to this is about the privacy and verifiable compute I think now there's been so much

progress we can we have been good in taking all the techniques from others and putting it into our system and I'll just give you a couple right like uh lookups again lookups were known since the 80s9s by Manuel Blum but you know using it in zero knowledge we know how to do this now in Lihiro >> I mean lookups have been also in our I mean we went through what is Flook up. >> Yeah. >> CQ >> log up. >> Call log up. Like yeah, there was this whole chain of lookup work. Did you use that or was it did you go back to the original sources on lookups and reimplement?

>> Once you abstract it away like you know it's one and the same. Okay. Like you understand how you you know how to do the memory checking and then you can use it. In fact we have a couple of papers which uh you will see it coming along. I can tell you a little bit more. This is about pre-ompiles. You know DSL versus ZKBM debate. I can tell you a bit more but I wanted to go back to this point that you said of you know the OGs of privacy Zcash and also like the notoriety of tornado cashache etc. The missing as you pointed out is compliance if these things already had compliance baked in and I maybe here I want to tell you rail gun is one such privacy pool on uh on Ethereum L1 that is trying to take this that's trying to take this path.

Now I want to tie this back down to client side proving because you want compliance. You want something that is gated. You want to do private transactions. You want to do it gated. Today with Groth 16, with circom you can only get to some amount of things that you can prove. But what you can do with Lihero is now I can prove a lot more using the ZK. So every transaction it's faster but also I can prove a lot more compliance. >> For example, you take the Google identity what they have proved. I can use that and say look I'm going to use a pool only for people who have a valid driver's license. I can also talk about hey like I am not part of an OFAC list etc. Like these are things that you can bake into the ZK system and listen to

our announcements. We are going to show all the different compliance KYC AML regulations including say even livveness check which you have to do can be done from uh from client side and I think this is going to change the narrative of how we bring bring privacy to to blockchains and you're right Anna like I mean tornado cashache etc has kind of >> well it chilled it for a period. Yeah. And now people want this tech and like you know we want to deliver something that people can use offtheshelf and like you know and give the necessary tools so that they can comply with regulation you know to operate on a chain.

>> It's interesting there is this you know we're talking about the nuance of privacy and these different kinds of privacies kind of going back to the scaling side like we are getting things like benchmarking very clear ways to compare teams. Is there a way to compare teams on the privacy front? Like is there any effort to do that? I wonder could that be coming? >> I think this could be coming. Uh and I'll say that when it comes to benchmarks, uh really the one that everyone's using right now is uh proving a block of transactions of of Ethereum. I think that's a that's a great great benchmark. But also it has focused all the efforts in for example pre-ompiles for this pre-ompiles for that.

And that doesn't quite tell you how well are you going to do when you have to do compliance of I don't know recognition etc. It doesn't tell you how you can extrapolate the results for that. But also when it comes to privacy here maybe I will I will lay it down >> 100 million constraints on a browser on a laptop of your choosing >> right pick some application that will yield that many constraints and uh you know show your performance on uh on a browser. And I want to say that this doesn't mean just for privacy or client side proving. I think this will hold even for serverside computations. If you can achieve memory footprint etc on these I will bet you if anyone does this like us

>> even the server side computation will become extremely faster on smaller hardware like if you think about it and I want to say like Ron Rothblum and succinct what he had initially two papers and actually our paper lietron followed that he had two papers on space efficient snarks but he used public key assumptions no one's going to or at least no one has tried to implement that because it's going to be pretty uh pretty expensive but that made us think about the question of can we design actually this memory efficiency I would I would tell you it's actually falls under the bracket of something called complexity preserving ZK >> okay >> complexity preserving proofs and let me explain what if you think of ZK like initially at least after you know uh the

advent of blockchains and using Zcash etc people focused on improving the time complexity and there were about you know uh I want to get quasy linear I want to get linear time you know linear time and codable codes. There was a lot of works trying to optimize this. And what were they really trying to optimize? Hey, if my original computation took teps, my prover should take roughly, you know, some constant times teps, right? So the overhead is this constant in in time. Now when you think of a computation, time is not the only metric. There is space, there is parallelism, etc. And now theoretically this has been understood what you can do in terms of overheads. Practically let me say that I have a computation that on I don't know eight cores and so much memory I can do

this computation now the overhead of this when I want to prove it how many cores do I need and how much space do I need and complexity preserving says that hell the overhead on every dimension should be a constant and what we did was for time and space can we get good overheads and this is what liron did really we said that if the original computation had you teps and used memory of some size S then the prover will also require roughly the the same overhead and I mean thinking of the question this way actually will help you at least target the benchmarks that you want for uh scalability

>> yeah I'm wondering do you think that like in the move towards more client side focused things does the hardware question become because I mean there was last year two in the last two years AS6 and FPGAAS and this idea of optimizing hardware has been the focus. Does this sort of like walk that back? Does this sort of like make that less important? >> Okay, controversial statement number two, I guess. Um I I think for us we've been thinking about hardware of course for a long time but here is sort of at least my take on it is if GPUs even commodity GPUs on the laptop browser can come within 2x speed of A6 or FPGAs like there's no point in

going it and I also want to say in today's system and I'm sure most people will agree like doing this encoding or entity that is not the bottleneck. It is witness generation and these hardware or at least what people are focusing on is improving the encoding time using this hardware but really you want to if you don't improve your witness generation it's not going to matter so we haven't quite actively pursued using hardware for this reason because the GPU has delivered us and in fact even in our current system the the encoding is probably less than 5% of the time that we we spend in generating uh the proof.

Wow. Wow. That is controversial. The first time I've heard that. >> Okay. So, maybe maybe this is the only segment. Maybe I'm going to tell something a little more technical just for the people who care about it. >> Go for it. >> Is that again as much as I loved all the research that came into linear time and codable codes and all these things. I want to say at the end of the day, we don't need to think beyond read Solomon codes. Okay. And here is my take on this. And also maybe a side remark here like I I didn't have I didn't do a course on error correcting code. So I don't know beyond read Solomon code. So you know take take what I'm saying with a with a grain of salt. So here is the thing now when you think of doing uh

error correcting codes now how much time does it take to do it? Now let's say that you have any amount of parallelism that you want. And the point is that any code you need what are called linear codes meaning codes that you can add homorphically like this is at least needed in most systems even if you had infinite parallelism you need at least what is called login time to do encoding of a length n >> okay like we don't know error correcting codes in nc0 that's the technical uh you know at least additively homorphic let's linear error correcting codes in uh in nc0 so read solomman codes if you give parallelism you can do it in login time.

So even if you had linear time encodable codes like if you think of it with enough parallelism you can't do better than login. So maybe let me explain this in a different way. >> What does mean I have actually have no idea what that means as somebody who like kind of knows error correcting codes like >> good let's say that I want to encode something of length n. >> Okay. >> Okay. A linear time encodable code says that I can do this in time order n. >> Great. But what it doesn't say is if I give you enough parallelism what is that time and the point is it cannot go below order login. >> Oh sure yeah yeah that I believe absolutely good and read solomon also you can get order login with enough parallelism on the GPU if we do encoding we get it in order login time. So why do

you want to go beyond read solomon codes when it's nice >> the the problem actually doesn't come from the login factor although I agree with the theory here. The problem actually comes from the fact that like read Solomon codes absolutely trash your cache unless you're like really careful about it, right? So like now it's actually like the big O constants matter a lot and in some linear time encodable codes this is very good. Uh I would say like um the like RAA codes of Blaze are actually fairly good although the permutation stuff actually becomes a little bit complicated because you you end up moving a lot of data around in different ways. That's because you are still in the stark kind of thinking where I need to encode a long thing, but when you think you're encoding something small, the cache is not the problem

because it's like square root size. >> No, no, I I agree. Yeah. Yeah. Like when you're encoding square root, I I think that's true. I I actually have an argument for why you do not want to do square root. Uh and this is maybe gets to Liharita if we do want to talk about that, but that's fine. I think like what is really gets really really difficult here when you are restricted to read Solomon codes although it actually turns out to be a little bit different in the case of like binary fields versus like fields that are smooth or whatever is in smooth fields actually do have a lot of this weird switching that happens and you you have some lower bounds actually some friend worked on lower bounds for IO for how much you like actually need to do IO to be able to do these read

solvent codes uh versus like binary fields which are a little bit nicer on the cache but not super nice. So I I don't know it's it's kind of hard right like like asmmptoically read solment codes have a lot of very nice properties practically linear time encodable codes also have a lot of nice properties so I actually like I don't know I don't make as strong of claims either way I just think it's like cool that we have things that can encompass both and at some point we'll figure out which is better maybe it's read solment codes in the end and like you know it's the the midweight curve where it's like you know everyone who's in the really complicated codes is in the middle or something. No, I'm saying like it's the same u I I would apply the same logic, right? Like if linear time and codable codes are not

going to give me like more than five or 10x performance, why go there? >> Mhm. >> Right. Like I mean if it gives you more than 5 to 10x like I would switch to a like an FPGA on ASIC, but I haven't seen this happen yet, right? So you know definitely more research has to go. I you know I'm I'm proponent of research that people should study linear time encodable codes. I just want to say that in case of like implementing the ZK and in fact if you look at the breakdown paper that did do linear time and codable codes they had a version with read Solomon which was called shockwave which was faster than the linear time and codable codes but you know that that doesn't seem yeah no I agree I agree I mean like I think you can get read Solomon codes can be very fast and and

in fact actually we have a specific demo of it being very very fast in fact we did it in Julia and anyways uh we can get to that uh if if that's of interest but yeah yeah like I'm with you I just like it feels like we've been stuck in this world of read solvent for a long time of like here are a bunch of nice properties that this thing has and we're going to like decompose it. But it turns out like for pretty good performance systems, you actually don't need like the structure of read solment codes at all. I just need like a linear code that's like quick to encode. And so and that's a surprising thing that feels like it's like a weird like feeling thing that I don't really know how to describe like and maybe that freedom is completely hard one and for no reason,

right? Or maybe it's actually really useful. I don't know. >> Maybe I will say that differently. I don't think that's where the bottleneck is there today, but maybe as we approach it, that could become the bottleneck, but I think we are far from that being the bottleneck. >> Fair enough. Yeah. >> So, we don't have too much time, but I wanted to highlight two talks from the recent ZK summit 13 that happened in Toronto back in May. Both relevant to this conversation. One, GMO you just mentioned was about, and I'm not going to say this right. I'm so sorry. like the same way. It took me a while to get liarero but liorito >> it's liarito it's like liarero butto >> liero but it's got a different liarita

um but yeah so there was a talk >> by Kobe but actually like prepared slightly by GMO all about Liherito so we should talk a little bit about that and then Mu you did a talk all about I mean it was it was such a cool talk I actually also rewatched that recently before this episode and you talked about ZKDSLs you mapped ZKD DSLs to like old programming languages to say where we were. You talked about vibe coding. There's like some cool stuff in there. And so I wanted to touch on both of those talks. Let's start on leorto.

Anyway, >> it's great. You're killing it. I think it's like it's it's a cute version of >> very cute. It just takes me a while. But yeah, do you want to just explain what that is, GMO? Also, how it relates to the original system? Like is it a variation on it? It's smaller I guess. >> Yeah. Mu how would you describe it? I don't know. >> I I I'll describe it. So >> as I said right like I mean Liuhiro just like snarks I mean they don't get very short proofs like snors do right. They're not a few bytes they are a few hundred uh kilobytes and how they scale with circuit size again it it you know Starks and Lehiro change uh differently.

Lehiro scales square root uh in this. Now there is an obvious way of reducing the size. You use recursive composition. Okay. Like most people as you know today they use starks composed with growth 16 and they get you know the best of both worlds fast prover and success proofs. You can do the same with uh liro as well right? I mean once we get success verification you can start with lehero and end with uh with grot 16. But someone can ask hey can I have the original lehiro system itself with smaller proofs? Why should it be square root? Now you have to play with some trade-offs to get something smaller than square root size. And again here I want to say one can recursively compose liu with itself in like sort of the most

naive way. The naive way will require is what people do today with sharding like you know sustain risk zero they have different shards and they compose two proofs into one and make it smaller. You can do the same but there is another way of compressing which I want to call is something called blackbox compressing. And what is blackbox is that when I want to compress the proofs in the second part of the proof I don't want to prove something cryptographic I don't want to prove the inverse of a hash function etc and under this category I would say leher 2 falls under and maybe here there is a plugin to my academic work there was a work called lihiro++ where we did reduce the proof size but we reduced a different aspect of liero in lio there

are two competing factors that makes it square root one is the query symbol size which is of size square root and the other is this random linear combination for you know proximity test and you know linear test etc which is also square root the++ shows how to reduce the other which is the query complexity smaller and leherito shows that you can uh I mean you can do the other which is the row or columns again you know row and columns config but the random linear combination uh you can recurse into that but maybe before GMO can maybe I should take a hot take on this so that GMO can answer on this as well please. Now uh I want to say that when we think of designing our

system I mean you know we would love to implement anything is it were stir liarto like any of these things if it makes sense in our system we will definitely pursue this the optimization that I want to say we are focusing on currently is not proof length but verification complexity at the moment I'm not convinced that the verification complexity is going to help us in this composition but that being said a the name is super awesome and B the work is also awesome. So thanks. >> All right. Okay. So like very quickly I'll I'll like reexlain the the thing that Mutu said but in like our own words. The way to think about liarito is what happens when you recurse liarero into itself without the annoying parts >> right? Like if you recurse liarero in

the standard sense like you prove that you have you essentially put a verifier inside of like verifier inside of lia you end up with a bunch of extra terms >> like you need to prove like said all of this construction about your you've done your hashing correctly you have like put the right elements you've done your openings correctly and that's very weird and kind of silly >> there's two observations but the main one is the actual most expensive part of alihero proof is surprisingly not opening the rows, but it's in fact the verifying that like you have correctly encoded a vector and if you make that vector very very large, you can make the rows in turn very very small, right? So you can like you take this like matrix which is your witness,

you stretch it out, you can make these rows very small and then you make this one vector that you receive in liarero very very large. But the observation now is that that thing that you now had this big object you now have you can put back into liarero to prove that you have opened it correctly right and then if you can just recursively do that like now we've just like created a complete and you can do this by combining with some check in like a weird way that requires not just breakdown sum check but indeed like this log randomness stuff that only happened later in 2023 via diamond and poses. So, it's like there's a bunch of like little tidbits of stuff that kind of like people didn't seem to have picked up at the time and then we just kind of like put it all

together into one simple system that says like you actually can recursively harrow into itself. The observation that makes two things I think true. Number one is actually it's pretty easy to add ZK is my hot take and number two is you actually do have succinct verification is twofold. Number one is it is very cheap in this setting to evaluate things which are tensor products of each other. And the reason why is because these things decompose in exactly the same way as the witness decomposes whenever you do these recursive steps. So the verification is actually succinct at the end of the day. And number two and the zk part is here's like a very dumb observation of liarito is once you add one more column to this matrix it's

uniformly random. Everything downstream of that is also uniformly random. >> That's masking. We do that in Lihero. That's the masking. >> But I'm just saying like now you the things that you're opening are also themselves very small and you're opening a very few of them. So the amount of bits to reveal is actually relatively small and now you only need to do a mask in this like sum check way that people do it in a standard way for this very very first layer which is very very short. And the overhead is roughly constant. Right? Now I don't mean constant in the like times n I mean in the constant in the plus n sense, right? because it's only masking for the first subject. So I I actually like we we don't state this because like you know we wrote a note it's like we're probably

never going to publish it anywhere because it's like just a bunch of silly observations. >> Uh Jakamo and Remco have pointed out that like some parts of the stuff they were kind of uh you know independently developing and is like in some GitHub repo and some PR which is like worth checking out. Uh, so I I'm it's it's like not a thing about like the mechanics of the protocol. Like it's just kind of like look man, we threw five observations together and in doing so got something kind of interesting including a super fast prover that we wrote in like Julia. It's like 300 lines of code where we wrote all of the libraries. You know, there's no dependencies on anything like if you just run it.

>> Can I just maybe qualify that? Like you only wrote a polomial commitment, not an application. >> I only wrote the polinomial commitment. >> That's not a full ZK, not a product. I just want to >> Yeah. Yeah. No, sorry. To be 100% clear, this is not a full ZK system by any stretch of the imagination. This is >> not It's not a complaint. It's not a complaint. I I actually have two maybe specific comments to what you're saying. And and I want to say that >> Oh, sorry. Before you get to that, I I really want to give a shout out to to Andrea who was my co-author on that paper. He's a he's an absolute monster and like he's the reason why that thing exists in in a not shitty way.

>> Uh it's for sure. Andrea's great. >> Yeah. Anyway, sorry Mu, go ahead. I want to say that you use some check on reducing this column random linear combination column. Uh we had the observation of recursing with Lihero itself on doing that. We have some internal numbers in terms of what the proof length will be uh uh if we did it. Again we need to understand what would be the growth 16 complexity of recursing this finally uh to do it to understand whether that's useful. But the second point I kind of want to tell you is that you're making these matrices skinnier so that you can leverage more out of this.

And I'll tell you where that can pay. It can pay in memory efficiency. And the reason is that because when you make the row when you make the columns bigger, you need memory proportional to the column. So you will have to if you do care about memory efficiency, memory footprint on these. >> You can't make it too skinny because then you're going to pay the price there. So the two competing factors and I also want to say that we haven't used sumche for this reason. Some as it is is not memory efficient and Talor and other Justin and others they're doing work in making this more but some or even GKR you know they move from output to input which requires all your computation roughly to be uh in memory and we have

religiously focused on saying look I don't want to do anything that will remove this portability from our system and we're trying to work within the confines which might be a stupid thing to do, but we want to keep it as long as we can. Like I don't want to adopt something that will let go of this memory efficiency. And even if we were going going to do this ETH proofs with real time proving, we're going to have it memory efficient and hopefully running it from a browser. So yeah. Yeah. So uh one statement on that which is funny is actually in page 20 we we this I I don't know of another paper that does this and the reason why is because we were also a little bit obsessed with this is we actually have in page 20 of the paper we have a table

that gives the actual complete prover allocated memory like over the entire time period not the maximum allocated memory but the entire thing and it is like only like a constant of the witness a very small constant of the witness >> but liatron is smaller than the witness. >> Yes. Yeah. Yeah. Right. Because you you do specific columns which we could do here. So here we have total pro allocated memory over all things. But like you said a natural thing to do is you could just take column by column. But >> I I have a my one argument here is um witnesses often fit in RAM. >> Um maybe not for like ethofroof but you're not going to be proving ethroof on a phone, right? You're going to be provess video recognition compliance on your phone. like that's going to be I look I'm not saying it's going to be billions

of constraints but 50 to 100 million is reasonable right like to do 50 to 100 million constraints in like you know 5 to 6 seconds in a Safari on an iPhone you have 1 GB of RAM >> I think for two to what is a 16 million we have 600 megabytes that that fits on RAM >> 16 million I was saying 50 million >> oh 50 to 100 I was telling yeah >> okay yeah I I'm it's it's like not that far off I guess is my You know, like if you just half it or But yeah, I'm with you. I'm with you. We should totally do that. And nobody is doing this. I like literally not one person is doing this thing, which is like very interesting.

>> Absolutely. >> So, I'm going to add a link to the video. Yes. Of Kobe presenting it and that paper. People can look at page 20 if they want to see that chart. I also want to talk about this other ZK Summit talk that you gave Mu where you talked about the ZK DSLs. You talked about I mean it was such a cool talk like the history of also what your dad was working on and you sort of at some point though talked about vibe coding ZK but I I was kind of confused like were you vibe coding on liotone or in li like was it like you're vibe coding then you just add zk proving at the as the last step and and actually can do it. I'm just curious about your experiences there.

Maybe we can talk about it. I'll say in again I want to tell this in probably in all honesty like I gave the title before knowing what I wanted to present in that talk. Um I mean I had wipe coded I wipe coded ZK but I didn't know what will like what is the entire talk about right but I really love the way it it came out like you know uh a little bit of homage to my dad uh in the presentation but let me say this right like since Eat Denver when we unveiled the platform what we have been thinking is how to make it more useful more easy for people to develop we are not going to imagine regulators people to learn ZK to learn circuits to learn DSL they're going to program in familiar languages it even in that like we are not going to imagine

them writing algorithms right so how do you make it more easier well we have LLM that do wipe coding today so I was like let's try these applications that I've showcased on our platform can chat GPT produce that application so to answer your question Anna what we are trying to do is how do we code a zk application using wipe coding the zk part is under the hood no one to know even what's happening there right so I want to prove I have a driver's license my age is over 18 these are the applications we're thinking of so go to chat GPT say I want to verify this of a certain you know piece of data this is how it is

authenticated it should produce this code you take it you copy paste it into our platform and you have a zk application for it >> right now as a cryptographer I should also tell you please don't do this without uh you or supervision because you're talking about privacy etc. Yeah. >> But that being said, I will say that there is a way that these systems can selfch check >> and I'll just give a simple thing is that in our in fact none of the systems today you can mark an input as private because none of them is zk but if you go to our platform and you do it you have to mark which inputs to your application are private. This means that when I verify it, all those inputs are not provided to the verifier. Now, if you're

worried about if your code is going to leak some of this input, there is a semi- way of checking this. I won't say it's foolproof is that I run my prover on this and then if I can verify it without using that data, then my application at least is protecting the privacy of my sensitive input. So, even if I use wipe coding, there is some amount of safety you can do. But I recently saw Dan Bonet give a talk and he was like look probably in in within the next 50 years it's not just that LLMs or these AI models can generate code it can also generate a lean proof that the code is fine.

>> Wow. >> So you know this is uh I mean I don't think this is sort of impossible within I would say even within uh my my lifetime. So the wipe coding part as much as it was maybe a little bit a cheesy title it was more that we want to make it easier for people to develop applications and I think I think we've done significant uh strides in that but it's still not close enough like it has to be even more easier to like drag and drop and do these things uh to build zk that's the only way people are going to adopt it >> you may be curious what is the actual language that it is writing in like I know you're You're just vibe coding saying what you want but like what is liatron actually reading or interfacing

with? >> So liatron reads web assembly files. This is what our prover does. So instead of we don't do risk f we do web assembly. >> Interesting. >> And you you need a whole separate podcast. I need to explain versus risk. >> We covered a lot like a long time ago but I don't know if we've ever done a comparison. Huh. Actually, Vai in one of the ZK summits actually compared Risk 5 versus Web Assembly. I think it was ZK summit 11 or 10. I remember watching this >> London. >> Yeah. >> Yeah. >> One random tidbit on the lean prover stuff. So, I I've been going down a little bit of this rabbit hole of like type systems as proofs and like what it means. So I actually think it's possible to like construct type systems for which

essentially like the properties that you get of this privacy like public private divide how you actually operate on these things uh can certifiably at the end prove that no no part of your data has been leaked or if not like what parts of the data have been leaked at what points because like there you know there's like this obvious one of the things that I don't see yet which we probably will see at some point is like it's weird that we like think of ZK proofs as like separate from like mathematical proofs, but we know mathematical proofs could be represented as like types in like a type system, right? And like Rust or like Julia as you know we did or whatever, right? And so one of the things that I I just like I think would be so fascinating especially in the age of IP

coding and and AI and LLMs is can you construct systems for which like once you write a piece of code the output of that piece of code much like lean code gives you guarantees about the truthiness of a theorem this thing gives you guarantees about the security or the privacy of like a particular underlying system right by composing certain pieces. So one of the things that you know it's like right now we have the Dan Bonet which is like oh we have the code and then we have like a lean proof that shows that the code is true but like why not combine those two? Why can the code itself not be its own proof of its own correctness?

>> Right? Because it compiles and type checks. Anyways this is just like just throwing it out there for everybody to you but also the audience. >> No let me actually I have a response to that and >> oh great amazing. Okay. So first I want to tell you you probably want to I mean what if in this direction you should look at a lot of work that is done in MPC in this space and I I >> I'm not strong in programming languages and you know but I have imagined exactly what you said which is mostly that I want to define like a type system and such that any program you do in that you have a simulator in zero knowledge which I've seen in most ZK places they don't talk about a simulator it's something is private because there is a simulator but

I think there is this theorem you can prove in this system that if it is type safe then there exists a simulator if there exists a simulator it is private okay now I want to say that since I've come full-time at the company and taken a leave from Georgetown I want to say one of the things I'm losing is these citations right like you know when you write a paper I know what citations like which year and now you were telling me when is hamming when is this like I was like I have to search through my brain like what these I will tell you a year back I would have been able to quote it like you know just directly from >> it'll come back more too >> I know it will but the point I want to tell you like maybe one paper that I

remember in this space is something called wisteria you should look at it it's an MPC paper which is related to programming >> lististeria w e r i wisteria >> it's anc paper and u I also remember there's some work of ela shei that was also related uh to doing programming language and proving security uh interesting this way. So I I'll I'll send you the references of >> Yeah, that'd be great. I would love that. >> Maybe we'll add that too in the show notes in case people are curious. Very nice folks. Thank you so much for this amazing episode. Wow. It was really fun to explore all these different sides of Lehiro, the variations, the the history, the compliance, the privacy, and also

like we did a few detours along the way, but it was really nice to to get a chance to catch up. Super fun. >> No, thank thanks really for for having me and I really enjoy coming to this. >> Cool. I wanted to say one more thing, Mu. Thank you so much for these great guest recommendations you've been sending our way. I try to sort of do shout outs when you do that, but it's been really great. >> I mean, cryptographer contacts, you have anyone, let me know. I'm happy to I'm happy to introduce like, you know, in the cryptography space. I mean, if they're willing to listen to my email, then you get the contact. So, but yes. >> Yeah.

>> Very cool. I want to say a big thank you to the podcast team, Rachel, Henrik, Tanya, and Kai. And to our listeners, thanks for listening. [Music]