zkSummit13 - Livestream

Transcript

Hello folks. As you're arriving, please make your way to the front. We have some seats up here and I'd love to see you. I'd love to see your faces. All right. So I think it's a good time to get started. Agy, are we good to go? Okay, cool. So welcome everyone to the Zero Knowledge Summit 13. How are you feeling this morning? Good. You excited to be here? Very nice. So the Zero Knowledge Summit, as you may know, is presented by the Zero Knowledge podcast. Um, we have done 360 episodes and

counting. Last year I took a short break, but we came back in February and we've been running strong since then. This is the team behind the podcast. Uh, this year we actually merged the ZK hack team and the podcast team together, so we have a bigger group. And I have my wonderful co-hosts, two of which are here today. I still have not had all four of them in the single room, but I'm on a mission to make it happen. So, every summit I share our top episodes. These change slightly. Um, this year or actually for

this edition we have quantum engineering with Yolena Vokovich and the founding of zero knowledge systems with Austin Hill. Um, we've been doing a small series on quantum as well as like a history series on this really cool Canadian tech company called Zero Knowledge Systems that existed in the late 90s. This was the third in that in that series. Uh, do check it out if you haven't already heard of it. I have it's it's kind of crazy but I have this very unexpected connection to this company that I talk about in that series. We've also been covering Latises recently. Uh I think we just had two

episodes come out on that. So do check them out. So all videos for this event and all of our podcast and all of our study clubs and all of the videos that we create are over on our YouTube channel. You can see last editions like the last summit's videos there and the live stream I think is there already. So yeah uh if you know anyone who wants to follow along from home please share this with them if you're not. So oh actually are you are any of you listeners to the podcast? Maybe some of you good. Okay if you aren't go check out all our episodes over here. Uh there's lots of great content for you.

So now I'm going to talk about a sister project called ZK Hack. So I sort of mentioned this at the beginning. ZK Hack was originally kind of a separate project. We've since merged the teams, but ZK hack is the spot to go if you want to like learn some of the basics of ZK. We have study groups. We do content there which is a little bit more for beginners. Um, we do live events and actually our next live event is ZK Hack Berlin, uh, full-fledged hackathon focused on ZK tools and tech. So, if you're learning about cool stuff here today, but you want to actually try building with it, head over to zkhack.dev and sign up, register for the

Berlin event. This is something I actually have never mentioned on this stage, but we also do a monthly newsletter called ZK Mesh. And Makira and I, where are you maker? Yeah, we started this back in 2020. Um, since then, it's been folded into the ZK hack project. It comes out every month. I think we have a rollup with that QR code. And also, you can always find ZK mesh and ZK hack. I think we're the only ones. Just Google us. This year we released the second season of the ZK whiteboard sessions. Uh I think we wrapped up in January. Have any of you seen the ZK whiteboard sessions? Okay, some of you have you

seen the second season of the ZK whiteboard sessions? Oh yes, so sort of less. Um the first season came out in 2022. It was really amazing to you like I think a lot of people used it to learn about ZK kind of for the first time. We followed up last year with season 2 and we are currently producing season 3. So you can expect some more whiteboard sessions. Cool. Okay, let's talk about this event. You're here for ZKS Summit 13. So ZK Summit 13. We've been running ZK Summit since 2018. We've hosted this in Berlin, San Francisco, online, Amsterdam Lisbon London Athens and now Toronto.

So these stages have hosted speakers that present cutting edge CK systems protocols. People save up their research to present for the first time here. It's very exciting to bring it to Toronto. Here's a few pictures from previous events. Let's see. We got six online. Eight 11 4 12. Has anyone been to a ZK summit before? Yeah. Let's make some noise if you've been to a summit before. All right. There was Has anyone been to one of the old ZK summits? This is this I wonder like pre 2020. Okay. Oh, we do have some people who are at the old ones. Cool.

Yeah. So, those were always held in Berlin. We have two two pictures from those. There's ZK Summit, what is it? Three, ZK Summit 2. That's 10, 9, 2, and ZK Summit 7. So this time we are here at heart house at the University of Toronto. Fun fact, I actually went to the University of Toronto for one year many years ago. I will not say when. It's so long ago and being back here is kind of cool. Like I'm walking around vaguely remembering I think that was my cafeteria. I think I was in that building. One interesting thing is so I I don't know if you know this. I never formally studied computer science or cryptography except I did one class at U

of the intro to CS CS 101 and in that I believe we did have an introduction to cryptography like just the very very beginner stuff but it's kind of cool to be here doing ZK Summit 13. Okay, a little bit about this venue actually. What do you think of this venue? Is this hall amazing or what? Crazy. So, we are currently in the main stage. There's a side stage, breakout room, workshop, and a chill out area. We do have maps kind of I think they're placed around the venue. The main stage is very easy to find. The breakout is just over there, so you should see it as well. Now, for

the second floor, you actually go up the stairs and you go on the other side of the courtyard. If you look up here, that's actually a restaurant, which I think you can go in, but it's not really part of our event. So, when you go up the stairs, you actually kind of go to the other side of the building. There you find sidestage, workshop, and chill out room. Oh, yeah. I want to say thank there's we have these wonderful snacks by a great Montreal bakery. Was anyone at ZK Hack Montreal? Yeah. So, you guys know these snacks. So, we brought them again here in uh Toronto. So, Lou and I, uh, it's vegan, gluten-free, lactoseree.

Uh, it is created in a facility that might have nuts, I think. So, if you have an allergy, make sure you check the labels and just be aware. Um, this will be found just outside here where we're also serving food. Uh, that's where the lunch will be as well. And we have this very exciting other snack thing happening. So, this is from Boundless from the Risk Zero team. They have a smoothie bar that they've put together for us. This is only running in the morning. It's upstairs in the chill out room. So, right there. And if you're interested in trying out their verified bar smoothies, which I definitely am, be sure to head there in the break, like

this morning break. And yeah, they close up at 12, so just be aware. Cool. Okay, here's our program. You should have this on your lanyards. One small change, uh, at 12:00 our speaker was not able to make it, but we are still going to try to have the talk, but with a replacement speaker. Vigny is going to do both of those talks. Yeah, thank you, Vigny. Also, as you can see on your lanyard, we've moved Ying Tong's talk from 5:30 to 4.

Yeah. And maybe just one other note, break the breakout. So we have three workshops on the workshop stage and then at what is it at 3:30 we're doing a workshop in the breakout stage. That's kind of why it's designed that way. So that's a full hour. We have stage ho wonderful stage hosts. So on this stage we have Alex and Nico. On the side stage we have Henrik and Rachel. On the breakout, we have Jeff and Rachel again. So, Rachel, any of the speakers, do find your breakout host. Rachel's going to be basically moving between those two. And I think you've all been in touch with Rachel.

So, if you have any questions, she's your go-to person. Yes. Wi-Fi. So, in your pouch, you have a code. The way it works in this building is we've had to do individual Wi-Fi codes. So, yeah, if you have any issues, go to registration. I think they have some more. All right. Now, I need to say a massive thank you to our sponsors. Risk Zero and Alo return sponsors. I mean, these events really only happen because teams like Risk Zero and Alo come and support us. They bring extra things. They bring their swag.

They bring their smoothie bars. Um, I want to say a massive thank you to these two teams for joining us. This time around for silver sponsors, we have returned sponsor Polygon and first time sponsor Stafle Labs, a local Toronto company. Thank you [Applause] guys. and our community sponsors for this edition. We have Tetsa, Tatso, Novanet Rayabs Aztec Celestia Maiden, and Horizon. Thank you to all of

the sponsors for coming together with us for ZK Summit 13. This is the team that made it happen. We have Rachel, Hanya, Agny, me, Henrik. We have our programming team, Nico, Philip, Kobe, and Gaylord. Thank you everyone who made this thing possible. Let's give them a massive round of applause. Also, thank you Agy for finding this location. Uh, you visited Toronto, went to a bunch of spots, and you came back being like, "It's a bit smaller than we usually do, but I think it'll be worth it." And I'm so happy you did. It's awesome. All right, please follow along.

Please ping us, tweet at us, tag us. Uh if you're not in the Telegram group, we're going to be sharing a little bit in there as well. Um that's our our ex Twitter account. If you want to share this live stream, I think we've posted it there as well. And now we've gotten to the point of this presentation that I always love sharing. Every time we do this, we ask people on the application form a question. And this time around we asked how would you explain proximity proofs to a friend. We get fantastic answers, hundreds of answers. And the committee who also helps to program this went through that list painstakingly and

pulled out some very good answers from all of you. So let me say it again. How would you explain proximity proofs to a friend? It's a tool used in ZK proof ZK proofs based on linear codes. Rather than checking if an input is exactly valid, a proximity proof allows you to verify that the input is close to the valid value within some tolerance factor. This is good. Approximate proxies for proofs of proximate properties. I have no idea if this is correct, but we liked it. All right. How would you explain proximity proofs to a friend? I'd start by saying this is

going to hurt. Then proceed to ask them, how much do you know about univariate polomials? A proximity proof is a way to prove that a function or data is close to having certain properties like being a valid polomial without having to check every single part of it. I don't need to read every page of the book to know it's probably not a cookbook if every tenth page talks about dragons. Now, this was a bit of a mixup, though. We we had a lot of answers that talked about like sampling, which I don't think is exactly proximity proofs, but we still liked this answer. How do you explain proximity proofs to a friend? A friend doesn't need a proof for our proximity.

Okay Google's furiously. There was lots of I don't knows, I don't knows as well. There's also a lot of chatbt answers. We see trends. How would you explain proximity proofs to a friend? This is Nico's favorite, I think. A way to quickly get a lowfidelity answer. Is some input close to correct? This is one of the sadder ones. If I had friends, I would tell them to check out Dan Bonet explain it instead. Um, Dan actually uh did modules for our whiteboard session. If you're not familiar with his work, you can check it out there. He is a very good explainer.

All right. Thank you all for those wonderful answers. Um, yeah. So, now I'm going to invite Nico to the stage. I don't know how much time do I have. How am I doing? Five minutes. Okay, we're gonna have to do this quick then. So last time around uh last for the last edition of the summit I did a run through like a history of ZK research and then I did a history of ZK applications. After doing that I learned I I had some gaps in my research. Um also I feel like as time goes on when you look back in time you notice papers that maybe hadn't really hit your radar start to become more important. And so we're doing kind of a revamped version

of ZK research from the year 2012 to today. All right. 2012 the term ZK snarks is defined for the first time. The concepts had existed before but this is the first time we see snark. In 2013 we have Pinocchio. In 2015 we have GKR. Mhm. And so here we have sort of the first trend of like can we make snarks and how small can we make them? And in this case are trusted setups already a thing? I think so.

Yeah. By the time you get to Pinocchio you already have um knowledge assumptions, pairings and trusted setups. In 2016 we have the very famous groth 16. Um just a note to anyone who's here who's maybe not as familiar with ZK, you will hear the term Groth 16 often. It's I think the most implemented proving system. Lots of teams are using it somewhere and that obviously came out in 2016 with a trusted setup. It is also sort of the culmination of that line of research like this is the tiniest proof we knew and it was sort of proven in the model in which it operates. That's the smallest you can get.

In 2017 we had Fry and Lee Harrow presented for the first time. Lee Harrow I thought was from 2022 but it turns out it is older. 2018 we have Starks and bulletproofs. So what's the change here? So here we're saying let's get rid of the trusted setup. Let's get rid of fancy cryptography as much as we can. So forget about pairings in some cases for bulletproofs. Forget about elliptic curves altogether um at the expense of maybe a different model random oracles uh or bigger proofs.

Nope. Also, yeah, this is Fry Leh hero is the sort of no trusted setups, no pairings, no curves. 2019, there was an explosion of research. Uh ma ma, where are you again? Yes, there also coined the statement snarktember. There was snarktober. Snarkvember. It just kept going. 2019, especially near the end of the year, had Sonics Plonc Aurora Spartan Marlin and Redshift. Obviously, plonk really stands out here is like you'll see variations of this continue on. We thought, wow, there's so much research, but little did we know what's coming.

Well, it kind of stays the same and then it gets crazy. But also interesting trend here. A lot of these are based on polomials, univaried polomials. And we have this one work Spartan that's saying uh multilinear polinomials could be interesting and let's see how this pans out in the next few years. 2020 Fractal Halo Halo 2 Plopup so this is kind of the first time we're seeing lookups quarks it well in this context quarks and plunky one which the team behind plunky has said not really worth mentioning but the name plunky becomes a thing so we put it in this list you also have uh the idea of recursion for the first time fractal is a proof of a proof um Halo and Halo 2 is another way of

doing similar things sort of for maybe a bit cheaper. 2021 we have faflanc other types of plon we have nova obviously a major kind of shift change with IVC I don't know if it's defined already as IVC but it's present it's kind of it is yeah emerging for the first time we have breakdown and snark pack yeah so nova is kind of the culmination of this proof of proof ideas uh breakdown is sort of liarero coming back in a different form um yeah I think that's it for for these guys. 2021 2022 and now we have Plunky 2. Very important proving system. We have Hyperplunk. We have Supernova. We learned that people

constantly use the word hyper and super a lot. We have Gemini. We have logup, plonkup, flookup, culk, culk plus and cq. And so you have a lot of lookup stuff happening here. Yeah, everything on the right hand side and logup is lookups. We do have a multilinear polinomials coming back with hyperplon gemini. Um, yeah, I think nice year. Cool. Okay, again with the proto. Proto becomes a name. Okay. Hypernova, hypernova, protostar, proto galaxy, goblin, plon. That's that's new.

Sangria, one of your works. We have binius lasso jolt basefold logup plus GKR, and Labrador. This is sort of the lattice work first starting to make an appearance in our world. And uh actually I think this wasn't on the slide last time because lattises hadn't hit at least my radar. So now that's going to be highlighter for 2023. Yeah. So the left hand side is sort of all these variations of Nova and this proof of proof idea pushed to the extreme. Um and then in the end of 2023 we we see a different trend starting to emerge is better hashbased proofs. So like binyas basefold um and then last year so this has also

changed a fair bit since I presented this last time in October. So we have Plunky 3 in 2024, Stack Proof, Circle Starks, Blaze, Breaking Base, Garuda and Pari, Poly Polymath, Greyhound, Lattis Fold, Stir, and Worse. Some of these presented actually on these stages, some that we're actually going to hear about today. Yep. And a mixed bag of ideas now, like you get folding and lattises, sort of these two ideas merging together. Um, what else do we have with Blaze and Breaking Base? We have ideas from uh Liaro and ideas from Fry sort of merging as well. Cool. Um super interesting. Oh, and the return of small proofs. Garuda and Perry and Polymath or

back to the sort of growth 16 trusted setup per circuit setup but tiny proofs and 2025 highlights. This is a big question mark. It's hard to predict now. Although we're in May, we're a few months in, but it's hard to really predict which of these will stand the test of time. But we have a number of them presenting today. So if you're curious to follow some of these threads, this is a great place to do it. We have Mercury Samaritan Zinc Ligorto Ligorito, Twist and Shout, Neo, Lattis Fold Plus, Micronova, and Warp. More merging of ideas, right? More Latis folding. Uh you have the sort of blaze-like ideas making their way into elliptic curve world with Mercury and

Samaritan. And then you have warp which combines linear prover all these multi-linear polomials hash schemes and folding. So like yeah very cool everything is merging. Yeah and I'm thinking like today we're also going to be checking out a lot of talks. It's possible we want to add to this right after um obviously as time goes on we learn about things we learn about things that even maybe came out in previous years that start to kind of become relevant. So, this is a changing, evolving list. And I think that wraps up our highlights of ZK research. Kind of by accident, I picked the dates 2012 to 2025, not realizing that's the last 13 years of ZK research presented here at ZK Summit 13. It's a good little

coincidence. Um, very cursed coincidence in a church. Thank you, Nico. Yeah, thank you, Nico, for that. Cheers. All right, we got a wrap. So, I think we're at time. All info of the event will be at zksummit.com. That is actually the most up-to-date uh schedule as well. We really tried to keep those printouts in your lanyard up to date, but we had some very last minute changes. Um, you can see some of them. Uh, I want to just highlight that there's some side events happening kind of all week. So, if you go to the website zksummit.com, there's a link to our wonderful partners side events.

Tomorrow, there's two events. There's something on the 14th and on the 16th if you want to check them out. Uh here again is the program. And so coming up on this stage we have we die presenting the onchain privacy trillemma. Very excited to hear that. The side stage we actually have a hold until 11 and we're going to be opening up that stage. Then on the breakout we have openbanking.nr kind of an application of ZK. And on the workshop we have EC Plonish. So I think starting now we're going to give everyone two minutes to basically pick your stage to settle in.

Um and then we can get started. We'll be sharing more about the program as we go. We have nice long breaks at this event. This is how we always do it. So we have big halfhour breaks. So if we are running over in any way, we always catch up. That's also a great time for you to meet with people, talk with people. And as the program gets later in the day, we actually start to shut down stages. So if you want to workshop, brainstorm, there's the chill out area. There's desks around. Yeah, please feel free to to start building the next generation of ZK stuff here. Cool. I think that's the end of my presentation. Thank you all.

Very excited to have you. Can't wait for the day. Very cool. All right. So I think yeah take take a few minutes pick your stage and we're gonna start up again with way dai on this stage shortly. Thank you. Also if you what stay here if you're interested in privacy oh yeah if you're interested in privacy you should stay here says way die. Also if you don't mind coming if you do want to stay please come up a bit closer so the speaker can see you. Thank you. Hey everyone, we will be starting very

shortly. Please, if you're at the back, come sit forward. It'll be a lot nicer for yourselves and for the speaker. Yes. All right, please take your seats and help me welcome to the stage our first speaker, Way Dai, who's going to be talking about the privacy trma. This is for you.

[Applause] All right. See, still see people settling in. Um, let me just say that it's my third time at TK Summit. Um, and the first time I was at the side stage and the second time I was in main stage and this time, you know, I'm I guess I'm opening for for for for the main stage and it's my honor to be here uh to talk to you all about privacy. Um, let's see if I can get this going. Okay. Technical difficulties. What should I point at?

Okay. Well, I have to say this is probably one of the, you know, better venues. There's no no better place to talk about privacy than like in this, you know, church-like setting. Um, okay. Two minutes. Okay. Yeah, it's a very private privacy presentation. Great. There we are.

All right. Okay. So, let's get started. And we are at a zero knowledge cryptography conference. And okay, this is still not working. Let let me We'll give you another minute to sort this out. Okay, there we go. All right, let's get started. So, privacy, let me first make a disclaimer. I think whenever we talk about privacy, we need to uh mention what type of privacy we're talking about. So in this talk I'm not going to be talking about privacy of information of communication.

I'm going to be talking about privacy of assets of financial privacy and in particular onchain privacy. So we're at a zero knowledge cryptography conference. So let me open up with a quote on cryptography by Phil Rockway. Cryptography rearranges power. It configures who can do what from what. Although cryptography is a technical field, it has deep and far-reaching consequences in society. And in recent years, there is a growing tension at the intersection of privacy and blockchains. And I think there's a true ethical dilemma at the core. And the

best way I found to distill this conflict is in the following technical trma between the following three properties. maximum usefulness, self sovereign privacy and assets and threat resistance. Any onchain privacy system can only have two properties but never three. And for those of you familiar with some of the privacy protocols, this is roughly how the landscape look uh from a selection of them. There's many many more protocols out there. Roughly speaking, we'll have on the top left the idealized protocols which leverages ZK to build shorted pools for maximum amount of privacy

possible and on the bottom we'll have things that are similar to for example Zcash Monero but adds certain um velocity restrictions on asset movement therefore making it more threat resistant and I'll define what that mean in detail later on. And then we have the top right category which sometimes you may not even associate them with onchain privacy solutions. In fact a centralized exchange can be leveraged to get onchain privacy. And there are also solutions leveraging for example multi-party computation FG and uh which is fully home of encryption as well as trusted execution environments. And I will

expand on this dark one in more detail this talk. and and here's the rough outline that um that we'll go through for the next 25 minutes. First, we'll go into detailed definitions of these real these real properties and why we need them. Then, we'll look at a more technical treatment of the trlemma and get to the core of where this conflict is and I'll talk about the land about solutions and how to expand the trade-off space and finally takeaways and uh call to action. So let's let us get started.

First of all, why do we need self-s sovereign assets and privacy? Here's two articles from the universal declaration of human rights published by the United Nations in 1948. There's article 12 which is often referred to as the right to privacy and article 17 which is often referred to as the right to own property. In some sense, privacy and asset ownership are fundamental human rights as defined by United Nations. So therefore, why shouldn't we have them in our onchain privacy protocol? And what do we mean exactly by self sovereign privacy? So in order to get a sense of this, let me uh read the

following excerpt from the cypher punk manifesto by Eric Hughes, which was published back in 1993. He says that we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. An anonymous transaction system is not a secret transaction system. An anonymous transaction system empowers individuals to reveal their identity when desired and only when desired.

So by self sovereign privacy we mean that exact property which is your transactions should stay private on chain unless you or any other party involved in that transaction explicitly decide to reveal them. So let's go into a little bit more detail of how these onchain transactions um what they actually encode. For a typical transaction on chain with a sender and receiver, we have the notion of anonymity which hides the identity of the sender and or the receiver as well as confidentiality which asks for the privacy of the content of the transaction. And there's are transactions that interact with DeFi

protocols which we also have the notion of anonymity which hides identity of the sender confidentiality which hides the content of the transaction and also function privacy which hides which application you might be interacting with. And by self- sovereign privacy we mean that the system should have the following property. When private transactions are posted on chain, the only way to reveal their content is if an involved party explicitly decides to reveal that transaction. And to wrap up, self-s sovereign assets and privacy means that empower the individual to own and to own their assets information and

there should be no one else that can take that away from them. And um question of the hands, how many people think that we should have soft sovereign assets and privacy for alter protocols? Great. So this is not that u cypher pong off notion, right? It's it's part of the declaration of human rights. I would say let's move on to the next property. This one is a lot easier and it's a notion of maximal usefulness. Onchain protocols today move an immense amount of value. So here's a chart of the weekly stable coin um payment amounts relative to Visa and AC.

We're currently we currently have exceeded the amount of money movements that Visa facilitates and more than half of that of a payments or AC transfers and onchain protocols today are very easy to use and they uh and we want to preserve that property. So what do we mean? A maximal use useful protocol on chain should have at least the following properties. Anyone should be able to transact freely. Making arbitrary transfers, making arbitrary DeFi uh transactions.

They should be able to generate new addresses to to to to get better anonymity. And there should be no limits on how fast transaction can happen or how fast money can move around. Okay, so that's roughly what we mean by maximum usefulness. By show of hands, how many of you think that we should build protocols that is maximally useful on chain? Okay, last hands. Interesting. Um, my agreement is we we don't want to replicate and want to make onchain finance as accessible and useful as possible. So therefore, for this purpose of this talk, we're going to consider uh systems that wants to achieve maximum usefulness.

Finally, let's move on to threat resistance. This is perhaps the one one property of the three that's more subjective where sometimes you could maybe refer to this as interubjective, right? What is a hack? We have a common notion of what hack is today and here's a graph of all the onchain hacks that have happened over the past decade. um there's no signs of them slowing down and in fact there's simply more and more hacks that that are happening as more and more finance uh move move on chain and just recently about 3 months ago there was the largest hack ever um on a

bad bit wallets totaling $1.4 4 billion. And let's take a look at what happens during these hacks. So, so here's a stat statistic of the by bid hack after two months um of the hack. Roughly 69% of the assets are still traceable. Meaning we have a list of addresses across different chains that are possibly belonging to the original attacker. And roughly 28% of the funds have gone dark. Meaning we don't know where the address is holding these funds. It could be any address that have been that have received funds over the past right 3 months. And roughly 4% have been frozen. Meaning they were probably

traceable and that counterparty that attacker used uh was actually collaborative in freezing the funds. And during this process, the attacker extensively leveraged for example crosschain swaps which are traceable exchanges which are also traceable but only if the exchanges cooperate and mixers on both Bitcoin and Ethereum. So this is what we mean by threat resistance where this is one example of how protocols can be threat resistant. We want these major hacks to be traceable. We want the number of uh the amount of traceable assets to be as large as possible so that we we can have

uh you know the third number there amount assets to be uh frozen to be also as large as possible. We don't want asset to go dark and and so that is what I mean by threat resistance. We want hacks to be traceable and note that this does not actually require us to build in protocol freezing uh methods. So the we simply need to reveal the content of transaction. We don't actually need to take the assets away from the attacker and this is actually how all the transparent onchain protocols work today, right? Um we simply need a blade to track and so it's not really asking for that much. It's really right reveing the

content but not uh explicitly taking away self- sovereignty of assets. And show of hands, how many of you think that we should build protocols that are threat resistant? Great. Okay, more hands than the usefulness one. Um, so great. So this means that we have a true uh problem here because I claim we cannot get all three at the same time. So the perfect onchain privacy protocol does not exist. And let us see why. The strategy will be as follows. We'll assume I promise this is kind of the only technical part of the talk. Uh we will assume that a system is both maximally useful and soft sovereign and

we're going to show that it will not be threat resistant meaning if there's a hack that happens there will not be a way to trace a transaction graph. And we'll do so in three steps. First in order to set up the the proof uh we we'll first argue that we must have a system that deal with raw public keys and one one of the responses that uh you know to to this problem is what if we get an identity system. So the first step is to claim we cannot have a global identity system if we aim if we want maximum usefulness and the second step we'll set up the uh we will model privacy preserving on transaction systems and the notion of threat resistance more formally then we'll do

this um final implication which will be obvious once we set everything up okay so the first first argument if you look at current blockchain protocols today there's only the addresses which can be derived from public keys of signature schemes or code uh for example for smart contract wallets and addresses have no inherent notion of an owner and addresses can be created on any device on the fly anywhere in the world.

On the other hand, an identity system, if we were to actually enforce something like that, would need to effectively map every single possible address that's ever used or will be used to a real world identity. And that real identity could either be a human or could be a company or any entity. Um, and so you can see that it would be quite hard to achieve such an identity system. And in fact, we simply do not have the identity system today. And so for the sake of maximum usefulness, I'm going to assume that systems will need to work with raw public keys or raw addresses. Okay, so that's step number one. Now let's

actually set up the uh more formal model of the system. And we'll have the notion of addresses. So these are arbitrary bit strings. And we have the notion of transactions which have sender, receiver, and an asset and amount. And with that in mind, it's really easy to define what a ledger is. A ledger is simply an ordered list of transactions. And here I'm going to block out the text to denote that that transaction is fully private.

And due to self sovereign privacy it means that if a party involved in a transaction want to reveal that transaction then they can decide to do so and we will denote on on on the diagram by unblocking the content and when transactions are added to the ledger we will assume that they're added onto ledger by default fully privately. Okay. And so these can be realized using um combination of geological cryptography and other tools. But this model is kind of the core of what's what's happening semantically on a private transaction system. So now let us move to setting up defining threat resistance more

formally. And formally we we're going to define a game between an adversary and an environment. And we're we're going to have the notion of a malicious set which initially will be empty. And this set will be keeping track of all the public accepted malicious addresses. The adversary um will can at some given time any chosen time t uh pick an uh pick an address a to be malicious. So this uh if you connect to the previous example of onchain hacks.

So this effectively could be a is modeling like a real world hack where when a hack happens that fund is marked as m malicious with the address marked as malicious. However there's a delay. In practice, when this happens, there's a social consensus that need it should be reached on that that it's an actual hack and and that oftentimes could be hours, days. And so we're going to formally model that as the time delay d. So what happens is that at any at some point in this in this in this game, the adversary can pick an address, mark it as malicious, and after some time delay D, that address is is then added to the set. the public's at M. Okay, so that's

uh point number one. And at any time the adversary can create new addresses and the adversary can submit arbitrary transactions to the ledger. And at the end, we'll say that the adversary wins this game if a is not fully traceable. So the the address picked by the adversary it have spent um have done transfers that are not revealed on chain. Okay. So this is some something I guess more complicated to set or something very simple. It's simply saying um if the adversary picks an address and um that that models a hack, can can the average get away with

it? And we'll have this notion of a public set M that keeps track of all the accepted malicious addresses. And so the first point um is if we want any form of traceability for the malicious address then the following must happen. We must modify our ledger protocol so that if a transaction is coming in that's fully private, we cannot fully we're not cannot commit a transaction unless the sender is not part of the malicious set right because if we commit that transaction what happens is that due to self-s sovereign assets and privacy that can never be

revealed. So we cannot let malicious addresses spend their funds spend their funds fully privately. And so we must do the following at any given time. If um an if an address is in a malicious set then any transaction from that asset uh from that address must be done transparently. And so we can enforce this for example using zero knowledge proofs. And we're going to to restrict ourselves to the set of protocols that do this. And now this kind of the final step to to see the contradiction.

Um recall the time delay d that we have. The claim is is the following. If the ledger commits any uh fully private transaction before the time deid then the system cannot be threat resistant and the and the reason is the following. Consider the following scenario. Suppose that the ledger have committed a transaction here is the the transaction a sends to a prime. If the transaction is committed in a fully private manner, what would happen is that the adversary can simply sample new new addresses, new public keys and send from the original malicious address to

the new addresses. And because of soft sovereign access and privacy property, any uh any transaction following um this transaction can be spent and the transaction a sends to a prime will safely private. And so that means that effectively the entire graph is not traceable. And this is if the system commits that transaction before the delay D. And on the other hand, if we actually wait for this delay D to commit transactions, then I claim that actually the entire thing can be fully traceable and threat resistance for this malicious address. And it's easy to see that

because if we wait for delay D then we we we we can simply keep track of of the original malicious address as well as all the all the transactions originating from it. Okay. So, so this concludes the proof of the contradiction, the proof of the tramma. Um, because we have shown that if a system is maximally useful and self sovereign, then it cannot be threat resistant, meaning there's a hack that can go through the system without being uh traceable. Okay, so now let's actually explore this trade-off space a little bit.

Um the dilemma really signals that we cannot get all three properties perfectly and in the real world I think there's effectively three class of protocols that start with two properties and try to get the third property as much as possible even though we cannot really fully get there and on we have first idealized privacy protocols these protocols typically have the notion of uh full sovereign full self- sovereign privacy as well as maximum usefulness and however it's really hard to add threat resistance and the second category is what I call programmatic privacy

protocols so these are similar to category A but they add movement controls so sometimes uh for example by disabling payments from within a protocol and adding deposit delays we're going to effectively become threat resistant And there's more recent works showing that if you can actually encode the transaction graph with every single transaction, then we can potentially also uh we can actually allow payments and faster movements without sacrificing threat resistance. Meaning we can make the protocol as useful as possible while retaining self-sign privacy and um threat resistance. And finally there's this category which I call privacy with

information custodian using a trusted custodian. It's um it's somewhat of easy solution and there's ways to make this less trusted meaning we can use multi-party computation protocols. We can use trusted execution environments to custody the information that then need to be decrypted. So in that way we could actually offer better privacy for individuals even though it's it cannot be fully self- sovereign. And let me um end uh the talk with some more forward-looking points. And really the the landscape is is just a landscape of trade-offs. We

cannot get the best of of all three properties. And the field is still wide open in terms of pushing the trade-off space outwards. And it specifically in pragmatic privacy protocols, how do we get more usefulness out of these things? How do we lower the restrictions while still getting threat resistance? and in um privacy protocols with programmable disclosure. How do we leverage multi-party computation trust execution environments to to be able to make protocols uh threat resistant but offer max amount of self-s sovereign privacy? And for those of you that

really think we need full self-s sovereign privacy, here's another way to think about it. Um it turns out because onchain privacy protocols work with a notion of anonymity sets, the inability to disassociate oneself from an attacker is actually can be seen as a problem. And so so instead of thinking about self-s server privacy, we can also think of think think of offering freedom of dissociation to people right? And let me end the talk with the following quote um by by Helen Nismb. Privacy in a sense of contextual

integrity demands that information gathering and dissemination be appropriate to specific contexts. Privacy as a technical pursuit is something that we as cryptographers as uh protocol designers think about all the time. We should enlarge the space of trade-offs of privacy protocols. However, doing that is not enough. The larger challenge is to have social consensus on what type of privacy we actually need for onchain transactions. And that I think is the largest challenge that we have today.

Technically I think um we have very very good construction of privac privacy protocols but we have very little social consensus um relative to how much these onchain protocols are used and I truly believe we can build protocols that maximally achieve the three properties despite we cannot really reach it 100%. So that is the end of my talk. Thanks for your attention. [Applause] Thank you very much. Wade, do we have any questions?

I'll just give you the mic for the first property. I forget what you call it. Uh the privacy one. Um why is it that you define it in such a way that either of the parties can reveal the entire transaction? Yeah. So that's a it is defined that way. It is defined that either the sender or receiver. Yes. But why? Yeah. So it's a simplification. So for sure. Yeah. There's going to be there could be two two notions, right? Maybe maybe this receiver cannot uh can only reveal itself but not the sender.

But really it's not um uh the same the same trul. So I I just you know use the the simpler definition of that to um you know for the talk. But like it it doesn't really matter kind of like uh who could provide more privacy and and the the property will still hold. Do we have any other questions? So in the assessment of the threat resistance at one point there's going to be a a determination to make on whether

the threat is in the onchain or offchain and whether an actor is malicious deemed malicious onchain or offchain. So onchain I think that determination is a little bit more intuitive but in your vision how do you see uh dealing with a mixed reality where the threat can come from you know the real world and how do you uh bake that in? Yeah. So this um is kind of baked into how how the model is defined. So um sometimes this onchain can just looks like a normal transfer but still there's a social consensus that hey there's a key loss on a on an address right and this is in fact what happens with a bad bit hack and um I

think really there's actually not one globally accepted list which is malicious right chain anal chain analysis maintains a list and you know there's a list if you were maybe to survey uh different crypto companies um and that can you know be larger or smaller. So some protocols do maintain se different lists right like you can have like this parallel list of different malicious addresses and in fact that's what privacy pools does right you have this notion of anonymity set um provider so I think fundamentally there is in some sense a minimal uh list that we can all agree on because there's certain things that we call hacks and certain things that we don't call hacks right and so um yeah it's definitely open question

thank you very much we'll thank our speaker once again. Thank you. Great. Thanks. Our next speaker is Binyu Chen from Stanford University who's going to present Latis Plus. By take it away. Okay. Yeah. Thanks, Nico, for the introduction. Uh let's wait for slice. It's okay. Okay. Cool. Cool. Yeah. Hello

everyone. My name is Bing Chen. I'm a researcher at Stanford. Today I'll present Lassfold Plus which is an upgrade version of Lassfold that enables fast and memory efficient proof system for large scale computation and this is a joint work with professor Damonet. Okay. So in the snark world we have three main approaches to build efficient proof system. The first one is this ellip curve based ones such as grossing or plunk. So they have really small proof sizes and very fast verification time and it's also much very simple to build a phoning scheme out of its such as nova and protostar and hypernova. Unfortunately this kind

of scheme rely on this discrete log assumption that is um vulnerable to quantum attacks such as sher attack and moreover the prover time is slightly less efficient because of the use of large arithmetics over ellip curves. Now in the postcontent world we have two other categories. We have hashbased uh proof system that's widely used in practice and pretty popular now because of this fast verification and efficient uh fast proving time and efficient verification. Unfortunately when it comes to build a recursive proof system or folding scheme even though we've witnessed great progress recently is still very challenging to build a concrete efficient scheme because of the really large recursive verified circuit.

Finally, we have this last space range proof uh last space based snarks which can potentially achieve even better proof sizes than hashbased ones because they rely on this more structured algebraic lattice assumptions. However, the downside of this kind of scheme is that verification usually is much slower. This limits it usage in blockchain space. But today I want to mention that lattice is actually great fit and great tool for building folding schemes and leads to a really fast folding scheme such as last 4 plus I mentioned today and also it's possibly postcon secure as well as a motivation I want to mention why one very interesting exciting application of

last plus which is a beam chain so beam chain is a proposal by ethereum ethereum for long-term security against a quantum attacks and also scalable consensus. So the idea is that after proposing a block in consensus there will be a bunch of validators who will ver read verify and design these blocks using some postcom signatures such as the standardized latispace signatures and then will be aggregator who collect these signatures and build a succinct proof showing that these signatures are valid are correctly verified. Okay. And after publishing this short proof, this blog can be

confirmed. So this boils down to this research question of of building a much more efficient proof system that's able to fold many signature verification statements into much smaller one and finally compress the statement into much smaller snark proof. And I claim that lat space folding is a great fit for such application. For example, as plus exactly address this problem for two main reasons. First is a fast and postconquing scheme and second it natively supports proving algebraic lice operations. So B basically this constraint system is particularly fit for just proving lice operation. You don't have to do this arithmetization to translate this lattice ring operation into some uh constraints in R1CS over

snuck friendly field. So this makes a great fit for doing um like for this kind of application where you want to verify stuff such as um signature verification for latises or uh verifiable FH. Beyond that I believe there are can be more advanced application as well such as ZKVM, ZK machine learning and data provenence. All these kind of advanced application involve proving large scale computation and our goal is to achieve that using small of amounts of time as well as small amounts of memory. So to do that I think like the the direction could be using lastbased folding combined with hashbased narc. And then I want to mention that

for last plus it has three really nice features here. The first is that the system itself the proving complexity is not much more complicated than just committing to the weakness and this is like a great features for uh folding scheme in lefth words such as nova and second the commitment scheme itself is highly parallel hardware friendly and supports more field arithmetics this something that can be even better than this pattern commitments and finally is plausibly postcom secure as well compared to the predecessor called last fold. We believe it can achieve much faster approver as well as much shorter and simpler verified circuits which is uh affecting the folding

statement size which also indirectly apply um affect prover time. So we really believe that this can be a promising direction and hope that can be more and more research onto the last space proof system and fing scheme and this won't be the last scheme I think there will be more uh advancements in the future I hope. Okay. So in the following I will quickly go around like go with go through some quick background about phoning scheme and let's see how last 4 plus will work. Okay. So in the literature we have one generic approach to build memory efficient and fast proof system for large scale computation. The idea is simple and this is also uh this called PMIN snark and also known as IVC or PCD.

The idea is to like you have some computation you want to prove and you just split these large computation statements into many small chunks and then you stream the proving of each chunk statements and combine them together or fold them together into much smaller statements and further compress it into a small proof and this small proof will serve as a snark for this large scale computation. So the key research question is then how to fold these statements efficiently. And this is where fing schemes come into play. But before that I want to mention a more general notion called reduction knowledge. And reduction knowledge is a protocol that allows you to reduce the checking of some input statements in some relation R1 into the checking of

some output statements like update statements in output relation R2. where R2 is usually much much simpler to check than the input relation. So you can reduce some harder problem to some simple problem and snarks exactly one such example where output relation is just this trivial language which always output one and fing scheme is another special example. So in fing scheme the input consists of two statements. The one is this online chunk statement you want to absorb. The other one is this accumulated statement you want to keep absorbing this online statement and finally get one statement for it. So the following protocol basically what he does is to combine these two statements into one updated merge statements in

this accumulated relation and you can keep absorbing these online chunk statements one by one and finally you can absorb all their online chunk statements and you finally just need to compute or prove this final smaller statement. So as you can see this operation is no longer trivial even though it's still simple it's no longer trivial. So the task for folding protocol is slightly more easier. Okay. And that that is the reason why usually folding scheme is much more lightweight and more efficient than monolithic snarks. For example, according to PSC's benchmark, Nova is like 100 times faster than this elliptic curve counterparting snark word like Halo 2 or PL 2. On the other hand, they are also powerful enough to support this piece meal proof

system as I mentioned before by combining with snarks in the end that's like pro a much smaller statement. So in this landscape folding scheme we also have similar categories. First we have this like classical elliptic curve based folding scheme such as protoar and nova and hypernova. They're pretty simple, pretty elegant and leads to some uh really simple verified circuits and proving time is also not much more complicated than just committing to witness using pedest commitments. Unfortunately, the they're not um postcont secure and also the commitments is slightly less efficient because of the large field arithmetics over ellip curves. Now in the postcontum world we

also have hashbased and lastbased folding scheme such as arc and lastfold. They have much faster commitments. They are also possibly postconom secure. However, the end to end system now is much more complicated than just committing to the witness and just do some random combination of commitments and witness. This ma make this kind of scheme finally like less concretely efficient than this ellip curve based folio schemes. So in this work we want to strike a balance and achieve the best of both world. We want to inherit the fast commitments and postcom security.

But also we want this proving proving system to be not much more complicated than just committing to weakness and randomly combine the corresponding commitments and for that I would need to um provide a quick framework describe quick framework for building lattice space folding schemes. This is already inspired by hypernova and also already implicitly described in lzfold but I think it's nice to have this generic framework so you can have the high level picture and after that I will touch upon the core technical part which is a new ranch proof in the algebraic lab setting okay so our starting point is hypernova which is a phone scheme that's uh uses homorphic nearly homorphic

commitments and sam check the idea is that you start by convert this high degree committed MP relation into some linear relation that only checks some linear statements and then you randomly combine two linear statement into one by just using some randomly combination of the homorphic commitments and the witness and also sometimes you need some sack proc out of it. So this is pretty simple and they instantiate using pattern commitments. Unfortunately, as I mentioned before, pass commitments is vulnerable to quantum attacks and also is slightly less efficient because of this ellip curve operations. So, we instead use less space commitments or at hashing functions instead. Uh is actually very

elegant and simple scheme and there are also some variant of it that's much more comp u much more uh optimized and efficient than that. So but at a high level the idea is as follows. To commit a long weakness vector what you do is just to left multiply a random matrix which is a narrow and long and then you get a narrow column which serve as short commitments. And a nice feature about this is that this matrix A which is public parameter can be generated on the fly. You don't have to store it in the memory when you commit it. You can just generate locally every entry using PRG or PRF. And this makes it extremely hardware friendly and GPU friendly. Uh and also we have some variant of this kind of scheme using polinomial ring or

module that leads to much more efficient scheme. And according to Nethermine's benchmark even on a single threaded CPU this can be much faster like three times faster than pattern hashes for committing to the same amount of data. And I hope that this kind of gap and the advantage can be even larger if you use GPU or hardware. And other on the other hand is also plausibly postquantum secure because it relies on this well-known shortest integer solution assumption that's widely believed to be quantum secure. But there's a trade-off. There's no free launch. The trade-off here is that we require this witness to be no norm. Otherwise, this assumption will be broken. It will longer be true and the security will be broken. So that implies

that every element of this witness should have a relatively small absolute values and that also means when we do the folding when we do the random combination we always need to control this norm to never exceed some fixed threshold otherwise you can no longer fold afterwards and you won't have security. So to address this issue uh we adapt this u relation we want to fold to include this nom check statements which further check that indeed this witness are indeed no norm which is parameterized by this integer bound B here and then after converting this uh highderee committed MP relation into a linear relation we define this accumulate relation as a product two

statements which is our two linear statements that parameterized by this integer bound B prime and B prime is globally fixed uh parameter that never changes. We always want to make sure that we never increase this kind of non bound. And now we have three input statements and we can do something similar but the different here is that we use some no norm polomial ring scaler to com to combine the three statements into a new statement where the witness now is slightly larger. The norm is slightly larger but not much larger. But as we said before I need to correct norm right but this is easy to do we just split these statements into two using the so-called decomposition technique basically when you have a number when

integer you can decompose into two integer where the two values become smaller and this is some technique used last fold but why is special about last fold plus is that in last plus we only do this once uh in decomposition and we only split one statement into two while in last uh let's fold for some technical reason we have to decompose them into many small decomposed commitments which makes the efficiency of the phone scheme much worse. Okay, so all this sounds pretty natural and uh uh simple and also quite nice. But there's one challenge here in the sense that you also need to further prove that in this folding step this input statement are indeed having no nom witness. So in some sense you

have to provide a proof of knowledge that these inputs witness are no norm and this is always the hardest part for building a last falling scheme and that's why it's like no notoriously hard to build a very efficient last space proof system of folding schemes and this is where our key contributions comes in. we obtain a much more efficient range proof that is fits into this algebraic latch setting uh and which I think is of independent interest. So to illustrate the idea our first step is to uh represent a range statements as as an algebraic operation.

Why do we want to do that? Because algebraic operation or statements much easier to prove because we can use this polinomial and all kinds of tricks related to polinomial and algebra. And what you would do typically is that suppose you have this statement about proving a is inside half minus half d and half d. What you do is b decompose this value into a binary vector. Prove this binary vector is consistent with this value and prove that binary vector is indeed binary. That leads to um many different zq multiplication. Basically prove that ai * a i minus one equals zero modulo q. So in some sense given a one ranch statement you translate into multiple algebraic statements over ZQ and this kind of kind of laws we don't

want to do this we want to translate one ranch check of this form to a single algebraic operation and the nice thing about lspace folding is that we work instead of a zq we work over polomial ring and this is RQ here which we want to exploit. So pretty simply very simply uh the every elements of RQ is just a polinomial of degree less than D. So you can add two polomial polomials and you can also multiply two polinomials and modul this polinomial x to the d + one to obtain another polomial of degree less than d. So in some sense it is a ring that supports addition and multiplication. And another nice feature here is that you can also shift the

coefficients of the polinomial onto the constant term by multiplying this x to the a monomial monomials uh here which is is a great feature because we can now do shifting very efficiently to the coefficients. So this is where we want to exploit and our goal to represent the ranch into just a single ring multiplication. The idea is following. First, we define this table polinomial TX which embeds the value of this range inside coefficients of this polinomial to the corresponding uh different monomial terms. And then we introduce some heer values which is this delta a which looks like some x to the a monomial term even though um like more formally it is not

exactly like that but let's just assume for simplicity is uh almost x to the a and now we are ready to represent the ranch check statement just as one multiplication. The idea is just to check that the constant term of data a times multiply this tx equals a. Why is it work? Because essentially this delta a is working as to shift the value you want to check onto the constant term. You can basically extract this terms this coefficient onto the constant by multiply x to the a or something x to the minus a. And then if the constant term equals a that means a is inside the table right because like is is equal to some value inside this table. So this is

why we can represent a ring uh a ranch check as a ring multiplication. And this idea easily extends to arbitrary table lookup or even larger ranges by just embedding different values in this table polinomial and using this decomposition technique from lasso or something uh like that. So this is a high level idea. We're now ready to represent uh ranch check as some algebra operations. Um and now let's come to our main tech me task. We want to prove knowledge of opening vector such that this opening vector is opening to the commitments and moreover every elements of this integer vector is within the range. So as I said before given this insights it's basically just checking

that this vector f uh element wise is equal to the constant terms of tx scalar multiply this delta vector right so basically we want to prove knowledge of t and delta such this equation host this basically a headmar check and for some reason we want to transform this into a single multiplication check using the shrmma let f tilda and delta tilda to be the margin extension of this vector and and let R to be a random sampled uh point over ZQ to log N. Now it suffice to just check that F_sub_R equals to the constant term of TX times delta to the R. Okay, like this we can preserve the soundness using shripy polma and this is high level idea. Basically we convert

this kind of a ranch check for long ve vector into a ring multiplication. But proof more formally this leads to the following reduction knowledge protocol where the prover just send this helper commitments which consists of commitment to this delta vector which consists of many monomials. Okay, which is lifting the values to the x to the a from a and the verifier will after receiving this sample is this random challenge and the prover will give the corresponding clam evaluation and the verify assume this valuation is only computed just check this single remation and if it holds true then after that it is suffice to just check that we know the some relaxed opening of f and delta to the these two

commitments such that the corresponding evaluation claim holds. I want to highlight here that this relaxed commitum opening relation is much easier to prove. It's basically very similar to a statement to be proven in hypernova which requires no strict ranch check as we said before and is much easier to fold using randomly combination. So this protocol kind of work as a ranch proof for uh as a reduction knowledge for this uh vector f here. And also you can see this scheme is extremely lightweight. The prover needs to commit these monomial vectors.

And because this monomial vector is really sparse, right? And also very structured. When you instantiate the ring based at commitments, this can be really efficiently computed. It leads to just linear number of ring additions for example rather than ring application which is much more expensive. So this is pretty good and and the verify is also pretty simple. It just sample a single challenge and check one application. So the corresponding verified circuit will hope that can also be really small. However, I'm cheating a little bit here. Okay. Uh this works when the prover is honest. But what if prover is malicious? What if he send some commitment that is not monomial vectors?

Why you send some arbitrary polinomials instead and f verify? So we need to further enforce that the malicious approver is always committing to some monomial vectors so that these previous algebraic statements will will make sense. Okay, but fortunately we can do that and we do this very efficiently. We come up with a new monomial set proof which is a proof of knowledge of this uh monomial vector under the line commitments which is super efficient. Uh I don't have time to cover this here but I think it's really cute technique and catch me offline if you're interested but one thing I want to highlight is that the underlying protocol is just a sum check over field rather than RQ. So the sum check is actually pretty

efficient and insignificant compared to committing to this ring vector. Okay. So for now we know how to prove knowledge of committed integer vector which is within the range. But in practice for efficiency usually we are directly proving relation over lice based rings like algebraic polomial rings and that means the weakness we have is actually some ring elements or polomials. So it's a vector polinomials rather than a vector of integers. So actually what want to want to uh prove is to prove a knowledge that all the coefficients of these polinomials are within the range. So that leads to a much harder problem which is to prove d different integer vector are within the range. But naively you can just run this

ranch check protocol we had before for integer vector for d times in parallel. Right? And the prover time is not too bad. The monomial vector commitment is pretty efficient. And this monomial set proof can also be batched using randomly combination. So it's not big deal. But there are some other subtleties in the sense that communication will increase a lot. Okay. And the prover has to send more more and more commitments one per commitments per vector. And as you know that we need folding verify circuit to be really small. But when you instantiate you need to do fe shamir to sample this random challenge which needs to take all this input as input to generate this random challenge. If it's too large, fear shamia circuit can be quite large. And our approach to dealing

with it is to use so-called double commitments which allows us to compress a matrix of n by d into much smaller commitments rather than d commitments. The idea is simple. So after getting this d different commitments, we just decompose it as a as a scaler. Deco compose it and we should attend a long slightly longer vector. And now we can use this at hash function I mentioned before again to obtain a much smaller commitments. So as you can see we can compress a one megabytes commitments into a 10 kilobyt commitments and much shorter and the verifier will only receive this double commitments before example this random challenge. So f shamir will be much more efficient after that. But this there's still one subtle

challenge here is in that after doing the reduction knowledge we obtain some statements that's related to double commitments. But double commitment is not linearly homorphic. So we cannot easily using randomly combination of the commitments to fold the statements. So that's why we need one more technique to translate a statement relating to a double commitment into a statement related to this folded version of lattice space commitments. And this is also of independent interest. And after that we can continue folding without problem. Okay. So that's basically the idea of ranch track protocol. In summary we have three main components. The first one is this table polinomic extraction technique plus this monomial proof that makes the prover much faster than before

because we remove the need of computing many decomposed uh vector commitments using attack commitments. And second, we use this rand uh double commitment trick to compress the folding proof so that we can have a much smaller F shamia verified circuit which makes the uh folding statements slight um much smaller. And finally we use this commitment transform trick to translate double commitments into linear commitments which allows us to do polomial unbounded unfolding afterwards. So you can fold many many online statement as you want and if you plug in this ranch checker protocol into the framework I mentioned before this leads to a much more efficient Lbased proof system uh or folding schemes because

this ranch checker protocol itself is no longer a bottleneck of efficiency. So we claim that the actual complexity will become uh like a bottleneck will become just to committing this witness ring vectors. Okay. So that's basically I want to cover. Uh how many minutes I do I have? Okay. So I go quickly. Uh one thing I want to convey here is that this lises is uh like mathematically it's a really deep topic. It's really interesting and it involves a lot of deep mathematics but I don't think it's that scary. It's not that fancy. Also I saw Craig here which is like OG in the in the last word. Um and I hope that more people can use it because it's really powerful and helpful to use for example in folding schemes. And

according to Netman's rough estimates, we believe that Lasso Plus can even beat the state-of-the-art of ellip curve for scheme such as a hypernova even just on a single strate CPU. And we believe this advantage can be even higher if we use GPUs or hardwares. And moreover, it's possible postcon secure. And one thing I want to mention here is that also it can natively support proving lattice operations without like diving into like some indirect translation into RNCS constraint over fields. This all makes is a great feed for those applications that you need to prove lice operations such as beam chan or verifiable FHE. Uh I think I'll just stop here and like

there's many open question but one thing I'm think most relevant for investors and company engineers is whether you can have faster software and hardware implementation for the monomial vector commitment I mentioned before. If you can do that you can accelerate this last even further and you can get get even better uh performance. Okay I think stop here and thanks for listening and I'm taking more questions now. Thank you very much, Biny. Um, we'll take one question and then I think the rest we'll take offline. Um, because Oh, sorry. Go for it.

Thank you for the talk. It's super awesome and interesting work. Thank you. Um, with folding scheme more generally, what you have is great memory efficiency. So, you can choose the step size to match machines. Uh, so if you have a bigger machine, you can run bigger step sizes, smaller screen, smaller step sizes. But in the hyperver paper they actually added folding for zk as in you can fold something and add privacy to it. I thought that was a very interesting technique. Do you know in the lattice space setting if you can add privacy via folding in the same way? That's a good question. So you your question is so can we add CK or privacy property for these kind of schemes. I don't see a inherent obstacle. Um but we haven't thought much about it. I I think it should be possible. For example, I

think in the in the li curve setting, we do have some kind of rel this kind of work. But in the last setting, maybe you can also do that, but probably we need to have some rejection sampling stuff which is more complicated in last word. But I haven't thought about this. I think it's a very interesting questions. Yeah, thank you. Thank you very much, Vinnie. We now have a break and we'll resume here at 12. See you in a bit. Hello folks. I think we're going to get

started on the main stage pretty soon. So, if you want to take your seat and do come up to the front, we have lots of space up here. That would be great. I think we actually do need to start right now. So hopefully you can sit down. Thank you. All right, let's

resume the morning's talks. If you could please take your seats. So for this next talk, we have something a bit special in that Hadas unfortunately couldn't make it. Uh but her co-author Biny has uh very bravely decided to give the talk. Um disclaimer, Biny has not seen the slides before giving the talk. So this is a bit of a slide karaoke situation. Um but I'm sure we'll learn a lot from it. Thank you very much, Beny. Yeah. Thanks, Nico. So yeah, sadly had cannot make it. I heard that there's a flat tile in this flight and the flight

got cancelled. So I have to um replace as a replacement. I will need to present it. And I haven't even read these slides in full yet. So I want to like started the slides and see how Hadas thought about this work together with you guys. So this is blaze. What is blaze? Blaze is a fast snark built from interled ra code. So TLDDR uh blaze is a scheme that is a hashbased polomial commitment that gives snarks over binary fields with like strictly linear time prover time and poly logarithm verified cost. So before this work theoretically what we

know how to do it but concretely we don't have a really efficient concrete um system like concrete efficient proof system that achieved this both properties. We either have uh point logarithmic verified cost but cost proving time or linear time but uh uh super logarithmic verified cost like lego or breakdown and this is the first one that achieved this concretely with concrete efficiency and also further supports binary fields. So that's the reason why even I'm doing karaoke style presentation. I really want to this this kind of work to be heard.

Okay. So I'll give some backgrounds and I'll also give some background about polomial commitment scheme and how to construct it. And finally I want to mention this so-called RA codes which is new type of codes that is really useful and really efficient. Um and I think they could be very interesting to be used in the snark world to pretend a very efficient prover for hashbased proof systems. Okay. So generally when we build a snark we follow this generic framework. Well we start by designing some information theoretical interact proofs and compile it into snark using some crypto primitive. And what is the interact

proof? In an interact proof the prover wants to convince the verifier about some statements in MP. And he does this by sending some messages in multi runs. And every runs the verify will reply with some public coin challenges like RD to R0. And finally according to the answer according to the me message it received your accept or reject the statement. And more generally we also can have interact oracle proof. In this case this message being sent by the prover is not really in full is not really in entirety by the verifi.

Instead of verify only to check a small subset of entry of this oracle in order to verify the proof and later we can instantiate this as a snark by using Merkel Merkel proof or vector commitments and even more uh I guess it's more generally or more special is that we can also have this kind of so-called polinomial interact oracle proofs while further um this oracle being sent now becomes polinomials Like for example, universe polinomials and the verified query no longer is is no longer this entry query but evaluate this polinomial as some uh the man of this polinomial and according to the

answer and evaluation of that the verifier will decides accept or reject and you can compile with polinomial commitments with it to pretend a snark as it said here. So that what is colonial commitments? It is a primitive that allows us to replace these oracles and this and instantiate them in practice in an efficient way. And more generally the it has follow syntax where the prover given some polinomial will commit this polinomial into a short string and send to the verifier and the verifier will decide some kind of evaluation query and the prover will give the evaluation and also prove that this evaluation is correct with respect to this committed polinomial.

Uh so in the in the landscape of building snark we have this generic uh paradigm for building snarks which combines a polinomial IOP with polinomial commitments uh to to obtain some arguments and then usually uh at this point we still have some interactive arguments because the challenge is still sent by the prover and then we can make it inter non-interactive using this standard femir based transform uh that's by proposed by kilian and uh uh Silva Macaui in 2001. Okay. So um okay I haven't saw this before but let me see um so what is polomical proof and our goal here is to translate a

circuit into circuit sizability into polomical proof right the idea is to just interpolate the the uh the weakness into some polinomials and embed them into the evaluation points the evaluation of these polinomials like in this case you can embed this while values as the evaluation polinomial at different points like x1, x2 to x7 and basically we can translate this circuit sizability problem into a so-called zero check basically checking that evaluation of this corresponding polinomial evalu to zero everywhere in this uh demand that we embedded the values uh witness values in. Okay, so we have this uh and this leads to this uh um and therefore it

means that finally we need to obtain a polinomial commitments that um prove some evaluation statement about this uh polinomial I said before okay so in the literature we have many polomial commitment construction in the lip curve based ones we have kg we have PST uh and we have this pedison based commitment uh PCS such as bulletproof Hyrox Dory uh they have really fast verification efficient batching and uh is also pretty efficient in terms of proof sizes uh and cons of them is that they have slower prover and there sometimes requires trusty setup which is not very good and they rely on some public key

crypto on the other hand we also have this hashbased proof system or PCS that's a resol based or codebased that's can support small field arithmetics and has really fast prover and also in the last space we also had some candidates for that uh they obtain really good proof size as well but as I mentioned in the last talk the verification is a bad a bit bad and today our focus will be the hashbased polinomial construction a polinomial commitment schemes and we can see this kind of a really fancy map that u had make there are many very cool constructions there uh And our focus today is a scheme which

can support three things which are really popular in practice. First is binary fields binary or power of binary fields which has uh really inst like create hardware instantiation for this. For example, you can see this beanas or fry binas which are really cool work that's uh have really fast prover in the in the binary field setting and the nice thing about binary field is that can native support is 32-bit integer armatics or something like that. Um so that's why we care about binary fields and second we care about Martin polinomial commitments. The reasoning is that we have kind of switched from univer PCS or universe NX into the Martin setting given the rise of this u um uh Spartan like or hyperplunk like

proof system which has near time proving time proving. Yeah. Oh, I see. Okay, I'll tell about that and thanks for the correction. Yeah, cool. Uh yes and uh um yeah so as said Lgerero and breakdown they uh breakdown also supports it like binius is a binary field version of breakdown which also supports binary field um but all of them are super logarithmic verifile. So we want to have uh super logarithmic uh logarithmic poly logarithmic variable complexity and want to support Martin polinomial and finally we want to have

this linear time prover which is achieved by breakdown and also legarrow also have near time prover I guess yeah but uh we want to go one step further we want to make the verifi verification and proof sizes much much smaller and this is where uh blaze comes down so astoically we have a commitment scheme that's extremely concrete efficient because of the use of this new code so-called RA code. It has a commitment um like commitment complexity is only exactly eight n additions for for a witness of the size approximately n and one miracle tree commitments and the evashion proof is also pretty efficient

is basically dominated by addition of binary fuse and 5nm multiplications and finally compared to breakdown and the goal we have po logarithmic proof sizes and the verification time. Okay, I think I'll speed this and uh I want to mention that uh blaze is really shines really performance where we when we are dealing with some really large martiners Martin polinomials that's really large witness if this relative small I think based proof system is already sufficient but if you comes to some witness size of 2 to 30 blaze can this asytoic advantage will finally emerge and you can have much more efficient schemes uh using blaze

For example, if you have a witness length of 2 to the 28, this is more than 10 10 times faster than martini based uh fry uh schemes. And in terms of prover time compared to breakdown is slightly slower uh but it is much smaller like the proof size and verification is much more efficient and smaller compared to breakdown. Okay. And this all number are just for 60 bits field elements. And if you if you initially if the witness itself is already binary we can even get more advantages by this packing technique from beas which can have more um performance optimization uh via this advertisation

technique. Okay. So why binary fields I think I mentioned this already before but I want to quickly uh record this here. Why binary field is uh because first in a binary field the addition is almost for free just xore and it's extremely efficient and the multiplication is slightly more complicated because we need to do this modular reduction over some polinomials but the nice thing about blaze is that you don't have to do multiplication over binary fields a lot and I think also why m Martinian polinomials is because there are many proof system which rely on uh martinial based polinomial. So we need a Martin polinomial commitments. Okay.

So uhhuh. Yeah. So in the literature uh in the hashbased literature we have a generic way to build a pawn hashbased PCS using this so-called interactive oracle proof of approximity like fry. Okay. And those kind of scheme are using error correcting code or uh linear linear codes. And linear error correcting code is basically just a a kdimensional sub space of fn. So the k like well k is smaller than n. So f to the k corresponds to message space and f to the n correspond to this code code war space. So that means there for different code words they will have some distance

between them and and the minimum distance is called this minimum hamming distance. And proximate proof is basically asking that given some oracle access to some uh symbols like a strings. We want to check that in this this string is close to some code word in this code word space and uh we have many way to do that such as uh fries and uh uh and some like I think Ron also has some other approach approaches in the past.

And we will do this a slightly different way. Basically we want to combine different two different approaches together to achieve the best of both worlds. So on the one hand we have this resol based uh OPP that has really concretely efficient verification and proof sizes. On the other hand, we also have this breakdown the garlike um uh idea for for doing by combining multiple uh strings into one using random combination and check this smaller code words. So we want to combine these two.

So basically we have a uh code words which looks like matrix here. So uh this matrix corresponding to code word and uh uh we split them into multiple rows and then we can use the idea from lego or breakdown to just randomly combine them and instead of checking this matrix is close to a code word we can reduce the checking that the combined rows is close to code words and this uh and we rely on this so-called correlated agreement lama to achieve that. So now our resulting task is to prove that this combined inter like this randomly combined rows of this green matrix is indeed a uh a a code word in some really efficiently

computable uh code such as RA code but RA code doesn't have a really efficient OOP okay doesn't have a really verified efficient ILOP so we'll do some code switching technique from RR and his colleagues in 20120 20 to translate the the code in RA code into the same code uh in resolment code that underlying underlying message are the same and we can translate after that we can just work on our IOP for resolment code and usually this code switching uh is not that concrete efficient. It depends on what kind of code we work on. And nice thing here about it is this. Oh, I think I mentioned this. I can skip

this. Uh, yeah. Okay. Yeah. So, usually we don't have a really efficient code switching for arbitrary code. But nice thing here is that we RAA code is such a super simple and fast code and that makes code switching now concretely efficient. So, let me quickly recap what RA code means. Uh, yeah. So RA code is a linear code while the generate matrix is a composition of several operations. The first operation is just repeat your message for R times. Okay. And then you just random permutes this message into another vector and after that you accumulate this message. What does mean

by accumulate? It just means the like prefix sum. Basically perfect sum in the in the uh binary field case. For example, the I entry now is the sum of the first I entry of the original vector and you do this by more two and then you permute again and and accumulate again. We just do it twice. Okay. So basically these are all very simple operations like permute accumulation repeat and turns out this kind of relation is easily to prove using sum check. Okay, you basically what you need is just prove some relation this matrix vector multiplication relation. Uh and this can be done is very similar to just a snarks where you prove some headmar check. Now

you just prove some matrix vector multiplication. It's basically just same task and we have really efficient um arguments for all these kind of task like permutation arguments. We can use uh hyperplank which is a very which is inspired and used that technique from clocks and you can have really efficient permutation arguments and accumulation is even even simpler. We just uh uh invent our earn but I think it's kind of folklore uh it's pretty easy and simple. Okay. So we just just run this permutation arguments and pro after proving the three permutation arguments reduce some statements related to uh a committed a code word that's encoded by ra codes into some statements related to

martinia polinomial that's committed using resolment code and also this message because we use this interle this message itself is much smaller than before like before is like length n now it's ns n by t where t is this interl living factor. So it's fine to use cosine linear time algorithm now because cosine linear over n / t is still could be linear over n. So this leads to some really nice uh schemes which have linear time prover and poor logarithmic verify. Okay. So finally I want to mention a little bit more about ra code which I think is the one of the main contribution of this paper. uh this involves a lot of really complex coding

theory stuff which I really appreciate even though I don't know too much about I've learned a lot from it from the our co-authors who work on coding theory but I can give you some kind of intuition on why it works okay so as you see here we do like what we do is that we do repeat permutes and do some pre sum and permute again and accumulate and when it comes to the this analyze a code words or a coding scheme. The first thing you want to analyze is its rate and the and also its minima distance and that reduced to checking that every code words has a relatively large minimal uh hamming weight. Okay.

So why is this code has good hamming weights? This one the intuition is the following. So suppose suppose for contradiction we have some messages that our code word as a really sparse in the beginning that has really small um hamming weight and but if you they they are quite sparse they distribute quite u in like uniformly after accumulation you can get a lot of one from zero you can flip a lot of zero to one and that's why you can get a much more higher weight of code words afterwards and that's why accumulation is you is useful here. But if this these words are quite close to

each other, they might cancel out that this one might becomes zero. So you you really have to make sure that before accumulation, you want this kind of uh uh distribution of the one to be as sparse as possible. And that's why we need to do this random permutation beforehand before we commute accumulate. So that's the kind of intuition um uh why it is it is uh has high high heming weights and we provide some more fine grand analysis of this compared to prior work and that's I think that's one of the main contribution on giving more confidences of using RA code so even though we didn't have uh okay so okay before I mention that I want to

um like describe this analog analogy by our co also run which I think is a really nice one and you may ask why why do we do two twice for repeat and accumulate and permute right why not just do once permute and accumulate the reason is that if you if you do repeat the weight of the the message of this sparse message lowe message will slightly increasing and then if you do one time of permute accumulates then will be more and more once there will be more and more weight which is of the level of square root uh size well n is the length of the witness. So if you want to have better distance what you do is accumulate once another times and turns out after

another time of permute accumulates the distance of this will be much better it's at level of linear size o n of that so it's kind of approaching GV bond but of course you can accumulate permute accumulate more and more times which gives you better rate uh like distance and rate bound but that's kind of marginal okay so even though you get some tiny gain on term in terms of uh rate and distance you also increase the cost for computing and encoding these messages. So we find it like we think that's a hot spot like a sweet spot here to do it twice and uh after doing that we can like approximately approaching this GV bound which is like an ex ext

existential upper bound of uh of coding scheme and it's nice uh nice question on how can we exactly achieve GV bound okay also you know that RA code is some random example code we actually don't know like basically this random permutation is sampled random example we actually don't have a way to efficiently check that this RA code is indeed having a large minimal uh distance so this is kind of a issue but we have some idea to give add some confidence on that after this randation we have some uh really there will be really tiny probability which is like uh smaller than getting a

lottery uh like uh like getting a lottery for that uh for that and uh the error probability will be concretely really small. However, uh the downside here is that this probability is still not negligible. So if it's a cryptographer, you won't be happy with it. But I hope that in practice you can be happy with it. But of course this is a open question whether we can prove that ra code uh can be uh checked so that the error probability can become negligible. This is a very interesting open problem for those coding uh serist okay I think how many t uh minutes okay so um yeah so there are some open questions I think I'll stop here there's

some open questions first is that can we improve the error probability to negligible as I mentioned before and second is that our uh scheme actually only supports binary uh extension fields so we there's no analysis for our RA code over large alphabets other than F2. So when we want to use large ext large fields what we do is we do extension field of F2 and work on it and also in this resoppp we cannot directly use fry but instead we use like fry binius which is a variant of base fold that can easily support binary uh extension field. So on the one hand it's good to use binary extension field. On the other hand it's not that good that we can only support

binary extension field. So it' be nice you can also support large alphabets or arbitrary prime modulus. Okay, so that's it. Uh that's my understanding of the the slides by Hadas when I read it. So hopefully it can be somewhat helpful and uh yeah, I'm happy to take more questions. Thank you very much, Biny. Um do we have any questions? Wow, no questions. Um, I have a question. Given, so you're saying we'd like to get the error probability of the RA code to be negligible, not just constant. Yeah.

Given a fixed permutation that's been sampled, can I check what its error is? Uh, then you have to enumerate all possible messages. Okay, like you can check it in exponential time, but it's not clear how to check it in polinomial time. But we have some uh like tricks to to like boost boost the the approach to make sure that we can make sure that this error probability is as small as 2 to the minus 4D by uh do some computation in one day or something like that. And in practice I think this is not big problem because we can run some long computation and make sure this complexity this varability is as small as 2 to the minus 80 or something and uh you should be fine to use it. Yeah. Uh

probably. Yeah. Thanks. No remorse. Questionwise. If I wanted to generate like a bad code like and I wasn't adversarially setting up the system, I would do the same thing or is it is there a faster way to maliciously sample a code? Yeah, that's a very good question. I think it's hard. It's actually very hard coding theory problem whether you can generate u actually because this actually um I'm not fully sure but if it's random I think it's pretty hard to to treat it because all these setup are transparent when you use in practice you basically just the randomness you choose is just

like for example the beacon value of blockchain for next hours and it's fully transparent and from that per from that we generates a globally agreed permutation Okay. So in that case this kind of attacking scenario is not relevant there. I think uh so that's why we think is still kind of confident that in practice this application is not a big deal if we make sure the permutation is public and is generating using some transparent and uh random setup. Yeah. Thanks very much Vign once again. Thanks for doing this so last minute.

Thanks a lot. Our next speaker is Leam Megan who's going to be talking about Mercury um and hopefully slightly related to Blaze actually. Okay, thank you. That do I like this? I see. Okay, thank you. Um yeah I'm going to talk about Mercury um which is a new um KZGbased multilinear polomial commitment scheme joint work with Ariel. Um yeah so let's get into it. Um so yeah talk about why why you should care about this what what we

accomplished um and then kind of some background context. I expect people here are probably familiar with the sumche protocol. Um and you know like why we should care about this and then kind of like the existing landscape of KZG MLPCS. um you kind of have these constant size MLPCS that require linear sized FFTs and you have linear time I I so I will say time but uh all of this is KZG based so over elliptic curves so in some sense is technically not linear time but just for convenience to avoid adding

that caveat every time I talk about it uh what I mean by that is like a linear sized uh MSM And those those MLPCS are are log size. So that would be like Gemini um which is what Aztec uses. And Mercury is able to kind of get the best of both worlds. It's constant size uh meaning it has a constant verifier complexity and also linear time. So yeah, the the sum check protocol has over the last you know few years become extremely popular in uh like high performance snark protocols for a couple of reasons. It uh so it it replaces linear or univariat polomials

which things like plon were used or used um with multilinear polomials because we can avoid um f ofts. So if you know how plunk works um you have to do basically a product of univariat polomials and uh division and that requires extending to domains and so FFT algorithms take quasylinear time and some check allows us to avoid this. Um uh subtle point about that is that um the benefit often isn't really the time it's like the memory to do an FFT.

So sum check is also useful on constrained proving environments like phones and whatnot. So if we replace our univariate um polomials in the IOP with multilinear polomials we need a different kind of polomial commitment scheme. Polinomial commitment scheme is just a way to prove that you evaluated a polinomial correctly. Um so this makes sense. uh there are really nice univariat polinomial commitment schemes like KCG um but multilinear is less more complicated so that's why we care about multilinear polinomial

commitment schemes yeah so like I was saying before the existing MLPCS um require a trade-off and maybe maybe just like also to say for motivation um uh we care about the um elliptic curve setting because they yield concretely smaller proofs and they can be efficiently checked onchain. Um so that that's another maybe caveat but yeah so the the two ways you could do a multilinear polinomial commitment scheme with kcg are with a product basically uh which gives you o of one proof size but um like I said before requires an fft in

order to compute a quotient or as in gemini you can do a kind of it it's it is itself reminiscent of the sum check protocol um there a bunch of different snarks that have this kind of pattern where you shrink something down by factors of two log time. Uh and this this allows us to do linear MSM work. Um it is like I said not technically linear but mercury we can get both. Um also it's it's interesting to note that Mercury does like less overall prover work than existing linear uh time MLPCS like Gemini. um we do 2 n scalar multiplications instead of just uh 3N

for Gemini. Um and this is with the standard KZG pairings. Um if you were to use an additional pairing, you could actually get it to the same asmtoically as KCG, which is pretty cool. Um yeah, so just some definitions to when we talk about sum check. um multilinear function f has a degree one in each variable. So that means that the terms of f will look like one and x1 x1 * x2 and so on. Uh there are two two to the n terms um or two to the k. Multilinear extension is the unique multilinear function like polinomial

that uh interpolates some values. So we we usually talk about the domain like 01 of boolean hyper cube when talking about multilinear extensions. Um the sort of process of multilinear interpolation has a very nice structure. It uses these EQ functions which are kind of like the lrangee functions in univariat and they decompose as a product like this which will be important for how the MLPCS works and in fact is important for how other MLPCS work as well.

Um yeah, so this function, if you kind of stare at it for a while, probably convince yourself that when you evaluate it uh with the x's being all zero or one and the y's being all zero or one, you get one if the two inputs are the same and zero if they are different. Uh and to see why like imagine they're different at some position then you'll have like in the first term 0 * 1 or 1 * 0 and in the second term you'll have the opposite and so one of the factors will vanish uh and so by interpolation we mean we can write everything as like a linear combination of the values of the MLE by

the EQ functions. So yeah, this is all pretty standard some check stuff. So what is an MLPCS? It allows uh you know prover to convince a verifier that some committed multilinear extension when you evaluate it at any point u gives you a value v. Um there are lots of different types. Um uh so if you've heard of IPA or bulletproofs uh that yields essentially a multilinear polinomial commitment scheme basefold is explicitly multilinear polinomial commitment scheme based on fry gemini linear time kcgbased etc. Um some of them have like a natural

kind of MLPCS like I said before right there's this way in which a lot of snarks fold things by half uh and like randomly combine the halves and this is very similar to what sum does and so like um if you want to do an MLPCS for bulletproofs it turns out to be like extremely natural or fries it's also very natural this is not the case for KZG G. So we have this trade-off. Mercury does sort of both things, right? Okay. So we'll talk about the two existing ways that people do it because Mercury sort of combines both of them. The constant size multilinear

polinomial commitment schemes um work uh by reduction to a univariate sum check basically. So like I said we have our uh MLE fhat and we can write the evaluation claim itself as a sum of products. So that is a sum check. In this case it's written over the boolean hyper cube. But you can imagine that the eqs and the fhat are actually given as vectors. So there are generic like there are other types of sum check protocols like in the beginning I said multilinear sumche but sumche can be defined for univariate polinomials as well. Uh this is like people call the aurora sum check

where you evaluate at zero. Um in fact it can be defined for polomials over like uh kind of arbitrary kind of shaped hyper cubes. Um so to get a constant size KZG MLPCS once we write it like this as a sum of products we can use like an inner product protocol or uh you just could interpolate the two vectors with polomials multiply them and then do a sum check lots of different ways you could do this we have a protocol in the paper that I think is interesting uh it's like compared to existing inner product protocols. It it

commits to like half as many values um using an interesting symmetry of you know the identity but won't get into it here. If you if you look at the paper it's there. Um also so the encoding that we use is pretty simple to describe. It's on the next slide. Um you you take your values and sort of imagine them as a vector and you multiply each one by a subsequent power monomial. Um so the the boolean hyper cube right it's bit strings it has a sort of canonical ordering you know as integers and so if you do this it has lots of nice properties and in particular when you encode the eq function like this it factors this is

the trick that like halo used and it's ubiquitous in these kinds of protocols um so that's what I mean by you can avoid committing to the eqs okay so that's the constant size MLPCS. The linear time MLPCS uh work like I said kind of similarly to sum. Um there are sort of two I think that that we think about Gemini and also Zeromorph um that fairly similar um for technical reasons Aztec uses a variant of Gemini.

Um, so again, we start with MLE and evaluation claim. And this is the encoding that I was talking about before where you take all of your evaluations and you sort of order them according to the canonical binary hyper cube uh ordering and you multiply each one by a subsequent power of x. Same encoding. So we want to relate like this encoded univariat to some kind of structure for the MLE. So I write f for the univariant and fhat for the MLE. We have the same evaluation claim as before but just written out

explicitly. Um we define a sequence of partial evaluations of the MLE. So notice that when you partially evaluate an MLE, you get a new MLE of like a domain of half the size. So you just plug in some use. You have the remaining variables. Then we can define a univariate for each of these smaller MLEs. Notice the not having a hat. So this is the identity. I don't I don't work out all the algebra in the slides, but this is sort of the Gemini identity. And I I don't I think that's the first place I saw it, but you um can take the even coefficients of each univariat and the odd coefficients

of each univariat. And this is the same thing as specializing the original MLE to zero or one. So if we take a linear combination of those, there's a slight error. I think it should say FI + one of X. Well, I guess it depends how you define it maybe. But in any case, you take the linear combination of the even and the odd coefficients and it's the same thing as specializing the first variable. So this allows us to relate the univariats like fi to fi plus one in the same way that we've related by evaluating in the first variable. So this is like a folding operation. And the reason this is this

is useful is because we have a univariate MLP piece or a univariate PCS. So if we had a commitment to FI, we could evaluate FI even from evaluations of FI. And so we can relate evaluations of each of the folded univariates uh in this way. In particular, we can link FIR and FI negative R with FI + 1 R 2. So this is this is essentially hit what Gemini does. Um from here it's not too hard to work out the rest of the protocol. You have these like subsequent folds and you want to check them all at different points and there's you know subtleties but proceeds

naturally. So this is the idea of mercury. Gemini were always folding by a factor of two. And you see here I say like fi r and fi negative r. You imagine that the prover sends evaluations for these to the verifier. So Gemini folds by a factor of two. It folds log times and it sends two values each time. So the transcript is log sized. Um if we could fold by a factor larger than two, we could use fewer rounds, right? If we could fold by a factor of three, we would send three values each time. we folded by a factor of square root n we'd send like square root n values in one time maybe um but like so for concretely if you

were to do this you might use flunk which is as is a way to decompose a polomial into sort of pieces in like this sort of FFT decomposition um but you'd send one value per each piece so if you fold by a factor of k you'd send k values Um so if we wanted super like constant folding factors you would increase the proof size like like I said if you folded by a factor of square root n the proof size would then become square root n. So in in building a constant size mlpcs we don't want this.

Um the main trick I think that Mercury does is we can fold by a factor of K and only send O of one information like prover only sends a single or O of one commitments to polomials instead of setting K values and we can prove like construct this proof in linear time. Um, if we had that primitive, which we do, then we could fold once by a factor of square root n and then use the slow like FFTbased MLPCS to check that the folded thing like relates properly. Um, so even though you know

we're doing something that's n login, you're applying it to a vector of length square root n and it doesn't affect the overall running time. It's interesting to note that like we pick square root n because it's optimal for our use case, but you could fold by a factor as small as login and still get a linear time prover. Yeah. Yeah. Exactly. So um yeah and and yeah but but in our case you know it's square root n so it makes sense.

Uh okay. So, the way that we do this is is uh not not so complicated. Um, I think this slide might be missing like one line. So, sorry if that's confusing, but we instead of sending K evaluations. So, we need to back up a little bit. In the the Gemini case, we're send two evaluations at R and negative R, which you can think of as a co-et of the degree 2 roots of unity like one and negative 1. This generalizes in flunk to a co-et of the k roots of unity. So you'd send like an evaluation at r an evaluation at r * omega and r * omega 2 up through k. If you think like some some simple

like algebra um sending a bunch of evaluations is the same as sending like a polomial reduced mod a polomial whose roots are the points evaluations that you care about and the polomial whose roots are the k like the k root of unity coset of r is x the k minus r the k like if you plug in omega * r into this equation it'll vanish. So instead of sending evaluations we can send the reduction mod this polomial and then from that you can evaluate it to the points that you care about because the modulus vanishes and so this is what we do. Um we have f we decompose it and this is

the piece I'm missing. These f sub iis are like the interleved k order coefficients of f. Um in the case of k= 2, f0 would be like the even coefficients and f1 would be the odd coefficient. Um and so if you reduce mod x to the k minus r the k you replace all the x to the ks with rs to the k's and you get a polinomial of degree k minus one as g. So if we could check this congruence of polomials then uh we would be able to check that we sort of folded f by evaluating each piece at an element of the k coset

determined by r. Um that might sound more complicated than it actually is. And we can compute all of this in like well yeah we so uh another like technical point is in flunk you need to use r to be a kth residue uh this is not the case for mercury you can be any value in the field um and so yeah that's just the identity I was describing before if you multiply r with power of k through root of unity um each of the so implicitly here you have this like a quotient which is multiplying the vanishing polomial and

you also have g and in order for the overall protocol to be linear time we have to show that you can compute both of these quantities in linear time and it turns out that you can um the intuition is if you take each of the interleaf chunks each of the f subis and you want To construct a quotient, it's sufficient to consider it as a polomial of degree n over k and compute the quotient as you normally would and then interle the quotients. So it's done. Not so bad.

That that would take n over k time and then times k is n time. So this is the the overall protocol sketch of mercury. I I've found in the past trying to describe it in words confuses people more than just writing it down first. So hopefully this this is clearer than it would have been. Um we have the same public input as before. We have like our commitment to f our evaluation point u and our uh evaluated result v. And we let b be squar n. Um this is written sort of parametrically. Like I said, you could let B be lo or any value from login up to N / login. So that's our FFT decomposition I

was talking about. You split F into um B pieces and each one will be of degree N overB. This is the like Gemini style univariate encoding of our MLE. Then you take the evaluation point and split it in half. U prime and U prime prime which are like the first log B coefficients and the second N over log B or log of N over B coefficients. If B is square<unk> N, U prime is just the first half and U prime prime is the second half. So we commit to the result of the first folding. So a linear combination

of the pieces by the EQ functions then pick a random challenge and commit to the folding of f by that random challenge. So we have two sort of uh you could think of it kind of like a commutativity diagram or something. You like go in one way where we fold by the eqs and then you go in the other way where we fold by alpha. And we want to check that those two things agree. So if we take the folded polomial g and we do an inner product with the eq functions this should be the same as if we take h and evaluate it at alpha and

this is because if you were to so suppose we evaluate h at alpha we get each fi to be at alpha time eq and if you look at the definition of folding by alpha replaces the x to the b by alpha and then doing an inner product takes the inner product of those values. So it should be the same. This lets us check that h was correctly constructed and it runs in time like um square n log square n or something. Then once we once we've checked h is correctly constructed we can do another inner product with the rest of the coefficients. This also runs in square root and time. So these final two steps are both sublinear and the only linear step is

actually the folding. Um concretely uh committing to Q and then committing to an evaluation of F in order to like reduce all these polomial identities to a single um KZG check are the most expensive parts of the protocol and that's where we get the factor of 2N like in the overall work that prover has to do. Um, everything else is basically like square root sized, so it's all very cheap.

Um, yeah. See, I think I think that's basically it. Um, it's worth mentioning there's uh another work that came out like a few days after Mercury called Samaritan, which is like essentially the same um construction presented a little differently. And there is a way in which you can sort of think about this like a bariate sum check. um it's maybe not exactly the same but I think it's an interesting thing to think about and uh kind of expand upon but um yeah I think if you if you're using a

multilinear polinomial commitment scheme that's based on KCG like Gemini or Zeromorph you should probably uh consider or just switch to to Mercury or Samaritan because um the provers simpler the verifiers is simpler. Um, it's constant size, less randomness. Yeah. So, that's it. Any [Applause] questions? Thank you very much, Liam. Do we have any questions?

Okay, I'll start with one. Um, you mentioned sum has some nice memory efficiency properties. Are they preserved here with the commitment scheme? I think so. Um, so the sum check like memory efficiency properties that I was talking about come from not needing to compute a quotient. Um, I'm not sure. I'd have to think about it more. I would I would assume probably, but I think there's usually a trade-off, especially in like the very low memory some check protocols of like increasing time so you like would reconstruct the witness. If you did that, I think I think this would definitely be compatible with that.

Thanks. Yeah. Yeah. Any other questions? No. In which case, thank you very much, Liam. We will now break for lunch and we'll be back here at two for the rest of the talks. Thank you. Hey, what's up

All right, everybody. As you're filtering in here, please find a seat. Uh, hello. I'm Alex and I will be your host for this afternoon for the main stage here. Um, so you'll see me for the rest of the day. And our first talk for the afternoon is instruction set architectures for MPC. Uh and this is um from Mara and she'll be presenting from Stofl Labs and Hashcloak. With that, please give Mara a warm welcome as she comes to the stage to present. Make sure this works. Put the right place. Yeah. Give it a click. Make sure it works.

Perfect. Great. Okay. Hello. Um yeah, it's great to be here. I think I've been to two in the past and at one of them we actually presented Stufflele when it was like internal at Hashglo but now we've like spun it out into a separate company and we've been like building it out for quite some time now so it's like super great to be here. Um so yeah today I'll cover you know what kind of need to think about when um you want to build ISAs and VMs for MPC. Um so I'll just like set some background first. Um so today like there's sort of two major things going on in computing um in general like distributed systems. Um we've kind of like settled on different kinds of architectures and approaches.

Um whilst like this new thing called like programmable privacy is like you know coming to the forefront. Um right so like what is the state of distributed community today? We have like the basic client server model um serviceoriented models blockchains etc. Um but they come with like a lot of uh limitations um around like trust boundaries, privacy um centralization risk and then while that's ongoing we have you know programmable privacy that like kinds of kind of solves a lot of the problems that we saw in the previous slide. Um and the sort of programmable privacy isn't just like one thing. There's like a bunch of different tools that exist to sort of solve it. Right? So I think most people here know what ZK is. um has the

most advanced tooling but it sort of limits what you can do with you know private data. Uh t tooling is probably also like getting there um as well. Um but there are a lot of concerns around you know hardware risk um supply chain attacks um and so some people don't feel comfortable storing all of their private data within TES for those reasons. um this FH that's also like very popular um but it's still very slow um a lot of companies have popped up to just like invent new hardware to like run FH compute um whereas but we have this thing called NPC um that sort of gives you a lot of the same properties as FH um but is bit bit more practical and so

today we'll talk more about you know MPC is like a programmable privacy primitive today and then just a state of like computers in general like how we've and sort of you know building hardware for computers. Um right so you know most people have a computer in their phone um and it's usually just on a single device right uh most of it is like based on some form of like x86 architecture um but then there's like newer architectures um that are coming out like risk 5 and then there's even GPUs that are still just like a singular device um and then there's some that are sort of optimized for distributed compute like beam has anybody like heard of like Erlang or beam um that's like optimized to like run on um a single

runtime but like multiple nodes and then there's some that are even optimized for um certain forms of cryptography like encryption um HSM like banks use these um but none of these really capture both distributed systems and programmable privacy um and so today we're going to talk about like how this works in NPC so just as like a really high level overview of NPC we'll go into like more details Um it's a way to basically um computer a function as a group without like trusting some external party. Um so you see staffle here, who's the real stafle?

Um the function is to determine like who's the imposttor. Um or who's the real staff. Um and it's commonly used in settings where like everybody distrusts each other. Um and what that means sort of depends on the setting which you're deploying it in. Um, this is very vague, but I'll go into like more details later about what exactly we mean by those terms. Um, but just to like set the stage of like if you want to use NPC today, what you know, you're kind of forced to deal with. Um, as a developer, um, you might like read some papers, you might encounter the word circuits, but you know, you're not really writing circuit programs for the most part. If you use like a regular general purpose language, you're most likely dealing with like random access machines. Um but then once you like you know go further and really

look at um what's available to you today you'll see APIs you'll see DSLs and then you're like faced with you know the decision to go even further and then you'll see after that's all academic software to like use more interesting MPC stuff um and so like the state of using NPC is still like very early even though this academic software has been existing for a long time it is deployed in and like to production to uh a certain extent um for all of this because like there's a huge demand but you know nothing exists really to alleviate that demand. Um and so like how can you reconcile the way people

program today, right? Like any programming language that you use today is based on like this rap model of computation and not circuits. Um but there's like a lot of you know optimizations that you get from running circuits and and speed and how do you sort of reconcile that um in this like MPC environment. Um, and the goal of today's talk is to sort of start at like like not as close to the hardware but as close to the hardware as possible like instruction sets architecture but that are designed to work with NPC um and to start sort of thinking about how can we make you know MPC more accessible and performant for uh developers.

Um yeah so quickly what's an ISA? Um, if you know like a little bit of computer science, it's like the actual like set of instructions that your hardware actually uh runs. In this case, it's all going to be software. Um, maybe hopefully in the future we'll get hardware optimized for MPC, but right now it's all software. Um, and then the VM is what actually like implements um on top of a ISA like implements the actual like instructions and how their process takes in a program etc. Um so like the main distinction is like one is the specification and one's the implementation. So in more technical terms so I gave like a very high level

overview of MPC before um but this is a bit more specific. Um so you have a set of end parties that want to comput a function um over some input X um but X is not known to any of the parties. Um and the nice thing that you want out of this is that from each other um you get privacy right. Um so concretely in this example we have three staffles. Which one is the real stafle? Um every every staffle has a set of um inputs that you know they have as proof that they're the real stuff. Um but they don't want to reveal that information to each other because like what if you reveal some information to the fake stafle and now

he can like pretend to be the real staff. Um and the way that's done there's like you know these different kinds of like security notions um for like how to build these sort of kind of uh fake stuffful protocols um right so there's sort of two angles over which we define security in MPC um and this defines uh sort of how you actually um do the operations for computing f ofx and it does affect sort of what considerations you want to uh take into account when design designing running ISAs for NPC. Um so quickly passive um just means that like one of the stopples here can just like observe you know everybody going through the protocol but

doesn't actively do anything to to stop the protocol from running um or some other like malicious behavior. Um active just means that you know one of the stalles actively tries to like you know mess with the operation of you know trying to determine who the role stopple is. And then covert is um which this is not like a great example to show but you know maybe one of the stopw if if one of them gets caught. Um and then there's like over how many you know what proportion of the the parties are you know being honest versus being

dishonest. Um and that affects like how you design these protocols. So in this case it's only three. Um so you can design a protocol for determining who stallel is um either by assuming like two out of the three are honest or by assuming just like one of them is honest. So the main ways to represent MPC computation um in literature is via circuits. Um so arithmetic circuits I'm sure everybody is very familiar with this um binary and garbled circuits and then mix circuits where you kind of combine both. So very quickly arithmetic circuits represent uh polomials. You get two operations addition and multiplication um and you mainly operate over like rings and fields. Um and you

can like sort of represent any reasonable like polomial approximation using this and it's really great for like linear comp computation um addition subtraction stuff like this. Um binary garbled circuits um are more closely like modeled after your regular circuits that you'll see in computers. Um and instead of having bits you have like each bit is encrypted. Um you can do like the regular operations like exor and and these are really nice for nonlinear computation um like doing conditional assignments um and stuff like that. Um and then there's like this nice thing in MPC that we called mix circuits that combine both. Um so you can have MPC

programs that um are really highly optimized for linear computation but then when you need to like do some nonlinear computation you can switch to binary circuits and when you need to go back to linear computation you can like switch back to arithmetic circuits. Um it has like a really high overhead. So it's a heavily use case dependent. Um but for those use cases it tends to be quite performant compared to just like using a polomial approximation for you know an if statement for example. So fundamentally the nature of MPC computation is such that um you're basically operating over either shares or doing oblivious transfers. Um, and these are like inherently distributed

objects um that you pass around to other people um in your your network. Um, and like these objects have specific properties for shares um and for like encrypted bits for garbling. Um, addition is free and by that we just mean that you don't need to send some somebody else something in order to like do a plus b. Um, which is nice. That means like if in your program you need to do an addition, you can just do it yourself and you don't need to like rely on somebody else. Um but when it comes to multiplication now you need to like incur latency. You need to talk to somebody else. Um especially in the case of like pre-processing protocols, you

need to you know generate pre-processing material and then share that with other people and then when you need to do a multiplication engage in a a communication protocol and this all happens over rings and fields. Um so this like already sort of leads us to um you know trying to think about different sort of instructions or architectures that um might be amenable to like the nature of MPC computation. So what makes ISA design for MPC harder? Um so the first one is access patterns right. Um and then the second one is complex control flow, if statements, loops, functions. And then the last one is that you're inherently

in a distributed system. You're no longer on just like one machine. Uh so I'll go into more details. So access access patterns I mean by like accessing arrays, um data structures that are important. Um this is what makes like programming pretty powerful. Like one of the things that makes programming pretty powerful, you can store things, you can access them. Um but in MPC, you can't just access them. you have to consider um like sure like the elements of this array they can each have like secret shared elements but if you reveal what you're accessing then that gives somebody like a lot of information about um what you might be computing um right so this is like there are many options for solving this um or garble are like

the main options um there's also like special purpose protocols for this um one thing that you'll see commonly is also just like leak the access patterns but like saying like okay when you need to access an element in array you need to reveal it you can't do um any fancy or RAM things um so for the most part in a lot of ISAs this is actually like a solved problem um because there's like a lot of offtheshelf options for it um the next one that's also pretty hard to do is uh control flow um so if statements branching uh for loops while loops stuff like that um this is actually pretty hard because if you um branch then that reveals um what you're doing right if

like I can like run a program uh and look at what it's happening but I don't have like access to the problem then I can like say like oh okay most likely that this if statement happened and not that if so in practice what ends up happening is you need to run both branches in order to not reveal what's happening Um, and so this is the actual hard part. Um, and different ISAs sort of solve this differently. Um, but the main way that it's solved is by actually just running both branches, um, for the ISA, uh, sorry, for the MPC compute. Uh, and then the last bit that's also pretty solved, um, but I think it's kind of underrated is that you're inherently in

a distributed system. Um, what you're building for is like inherently distributed. like every like network device that's participating in NPC network holds a piece of it. It doesn't hold the whole um part of like the state of what you're trying to compute. Um and this is sort of what like dist distinguishes like NPC from like a lot of the other like programmable privacy primitives. um is that you know you have to design from the perspective of um every node is a part of a single runtime as opposed to every node running their own runtime and then talking to each other. Um and that's how normal computers sort of work for the most part is that they each have their own runtime

and then they have to like learn to talk to each other. Um but the learning part isn't really like learning. It's more that like we design protocols to enable computers to talk to each other. Um whereas like here you can you just have to do it from scratch and like consider that when you're building the ISA. Um so general approaches for actually designing ISAs for NPC that you'll see in the wild. Um so the most common one is to just take an existing ISA but then you do CPM emulation within an NPC network. The next one is to like design a custom one and just do whatever you want. Um and the last one is usually to do some combination of both um while trying to like balance um the

expectations um that both like give you. Um so so the first one uh which is pretty common actually is just take an existing ISA um that is like very familiar to you but then you emulate like every portion of that um instruction set within an MPCA protocol. Um and specifically that means like for a specific ISA you have a CPU um and the CPU is built up of like different components. Um so you would spec specifically um take the CPU and implement each of those components uh as an NPC program. Um so uh here I'm just showing off like the flow. Uh does this do something? Okay. Yeah. So this is like

the flow of what this would look like. Um so around here you get like the actual program from um like say MEPS here um like you write your C your C program you target the compilation to a MEPS by code and then you run the MEPS by code within like an MPC tool chain um and this bit right distributes state across MPC parties um that's where you do the the computation the sorry the emulation and you're doing that with a program counter that's also secret shared um so So you're doing the step for every like MEPS instruction um until the end um and like that incurs like a very large overhead um because you clearly have to go through like every

instruction um and perform like a separate like MPC protocol obviously composes all together um but it's like pretty resource intensive uh especially if you have like a really large program um but the nice part is like you don't have to like teach a programmer a new programming language Um, the next one is basically just invent a new ISA for NPC. Um, and like the world's your oyster here. You can really do whatever. Um, but in general, what you kind of see is that there'll be specific op codes for operating over specific NPC constructs. Um, so you can like have shares directly as a first class citizen. You don't need to have your ISA operate over something that's a

bit lower level. Um, you can have op codes that are specific MPC protocols themselves um, and have them be more expressive over just like being like a a load or just an ad instruction. It can be um, like a a concrete example can be it can be like a zero knowledge proof. Um, there are some NPC protocols that require zero knowledge proofs like special purpose zero knowledge proofs um, in order to ensure like active security. Um, and instead of like having to reimplement that from scratch as you would in in um an existing ISA, you can just have an op code that does that for you. Um, and the nice thing of being being able to do this is you can take into account this distributed nature of MPC and ensure that all the machines

that implement this ISA only hold part of the state and are able to like directly communicate with each other um, in order to like do the computation. Um, but then the main downside for this is that like you're inventing a new computer. Um, and so you need like new new tooling to make that work. Um, either like a DSL adapt existing tooling, um, whatever it may be. And then like the flow is more more or less the same. Where is this cursor thing? Okay. Um, the flow is more or less the same. Um, you have like some uh DSL or high level language. um it compiles down to some error, but then you execute the instructions I as you would expect any computer to execute. Um

you just expect this to just be faster um because you don't necessarily have like a secret shared program counter. And then the last one that's also like becoming more popular is to combine both of the previous approaches. Um and the main way this is done is that for the existing ISA uh you kind of extend like the the tooling but then for the spec for sorry for the custom portion you just have like base ISA that handles all of the NPC specific tooling. Um and then you use uh like special purpose MPC protocols to sort of make sure that um between the ISA the the not old but like

the offtheshelf one composes well with the base one. Um and you still do like CPU emulation over like the existing ISA but you've like delegated like a lot of the stuff that makes it expensive off to the base ISA. And so you kind of get best of of both worlds where you can reuse existing tooling. Obviously, you still need to change some stuff. Um, but it's, uh, like more minimal to like what people are used to. Um, yeah. So, uh, the implications of this is, yeah, I' I've said this multiple times. You you're getting a new kind of computer.

Um, tool change will need to be adapted. Um, in most cases anyway. Um, most likely, you know, people will make their own set of trade-offs and there'll be like DL cells for this. Uh, I think the last one is like the most interesting implication. Um when it comes to like speed ups in cryptography, you always think about like better math and better hardware. Um but in this case, uh you can get speed ups from sort of translating your pro your problem from a cryptography problem to a compiler optimization problem. Um which is pretty neat. We don't really do that very often in cryptography I find. Um and that means like whenever somebody says MPC is pretty slow, you can say like no it's not. you can use compiler optimization

theory which has like you know 50 plus years of research. Uh so where are we now? Um so yeah ISAs already exists for this. Um they're just in a state of being academic um and like hard to use. Um so there's yeah they already exist. There's all all sorts of them. Um these are just the names of papers and software that I've personally used over the the years and Stafle has like only so much space in his globe. Um but yeah there are many others if you uh want to learn more you can just come chat to me after. Um so yeah this is the end basically some takeaways. Um we can make MPC practical today by like designing

ISAs um that are like production ready to take into account like the way developers program today. Um there's also a really wide design space for like how you want to go about designing ISAs. Um and then the last one which I just said which is uh um you can use compiler optimization theory to like make NPC much faster um and rely less on like just cryptography. Um so yeah, thank you for listening. If you uh want a die-cut sticker of stafle uh come to me after the talk and uh just tell me a use case of NPC I may not have heard of. Um, and you'll get like a cute little sticker.

Um, if you want to learn more about what Stop Labs is building, there's a link there, a QR code. Um, yeah, cool. Thank you. Awesome. Thank you so much, Mara. Challenge accepted on the sticker. Uh, we have room, we have time for probably one question. Um, is anyone in the audience would anyone in the audience here like to ask a question of Mara based on the talk? This is what they look like. Really cute.

Okay, I have a question then. Um, so in certain NPC architectures, there's some assumptions around, you know, the relative strength of each of the parties. Does uh that impact how you would design an ISA at all depending if you had like one very powerful party and then one kind of meant like someone meant to be a client or is that independent of the ISA and and considerations of how you design it? So in the can I uh yeah so in like the gobbled circuit oh wait I should be using this sorry uh so for like a lot of the gobbled circuit based um MPC protocols for which like you're using existing ISA and then you like extend it um they do take into account that like

one party is like the garbler and does most of the work um so yeah I would say the answer to that yeah thank you and let's give Mara a Round of applause. Okay, next up we have uh Daniel Kang from UIU who's going to be presenting about ZK Torch. If we could all please welcome Daniel to the [Applause] stage. All right, thank you very much Daniel. Floor is yours.

Is this working? No, it's not. There we go. Okay. Is this working? Great. Amazing. Uh, so I'm Daniel Kang. I'm a professor at UIU. And today I'll be talking about ZK torch um and about how to compile machine learning inference to zero knowledge proofs via parallel accumulation. Uh, but first uh unless you've been sleeping under a rock, you will have known that AI is taking over the world. Uh there's new model releases every month. So just actually in the past uh six weeks or so 03 was announced along with the new version of Gemini 2.5 Pro which have shown amazing performance in different domains. Uh the issue with a lot of these models though is that they often

change underneath us. So I'm going to give a concrete example. Um there have been allegations that the 01 model release uh the system card accompanying the model release did not actually describe the release version of 01. And besides that, uh just two weeks ago, OpenAI released a new version of chat GPT uh which uh allegedly caused uh potentially negative uh uh consequences to some of their users who was who are using their platform. And so we have no idea what's really going on underneath the hood uh with these model providers. So uh this is one uh reason why we care about this. Uh I'm going to give you another example uh which is the case of medical AI. So let's say I'm uh u I I go to a doctor and I get an X-ray

and I want to classify my uh X-ray using a approved model. Let's say now you know here I'm showing the example of you might uh imagine that uh the correct model says uh one answer but then uh someone can hack the uh the system and actually just return a completely different answer. And this is obvious to see but there's actually lots of examples of uh instances where model deployers will deploy models as I said for example for chat GPT without actually understanding the consequences and so you might not actually know what model is being run on your own data and this is this can be benign it can also be malicious and as a model consumer I have no idea uh what uh um uh what model or or what are the guarantees of the

model that was used to produce the result at hand. Now, of course, we're at uh ZK Summit, so uh this should be obvious to most of the people here that one of the ways that we can resolve some of these tensions is by using zero knowledge proofs of machine learning model inference. And so I won't go into the details of of this in uh in too much uh too much depth, but basically uh every time you return a an inference from a model provider, you can attach a proof of computation saying that I ran say in this example an FDA approved model uh for this specific um on your specific data. Okay, so that's great. uh but there is this issue which is that unfortunately uh machine learning models

are extremely expensive from a computational perspective and so now we're stuck between this uh rock and a hard place. You can either have uh say generalpurpose technologies um but uh that can prove a wide v variety of models but they're unfortunately extremely slow uh or you can have these custom uh bespoke protocols which are unfortunately very specialized and don't actually uh uh prove a wide range of models. And in this talk I'll show how to uh start to bridge this gap. Okay. But first I'm going to talk about the two axes uh in the in the prior work uh before talking about ZK torch internals and then some benchmarks and applications if I have time

left. Okay. So the first set of techniques that uh people have used for ZKML broadly falls under compiling ML models to general purpose uh ZK uh circuits. So you take your favorite representation of a circuit or an air or something else. So you can imagine R1CS or um say Halo 2 style errors where you basically take the computation in machine learning model and then write a compiler from that to a general purpose circuit. Now this is obviously general because these circuits are universal. Uh but the issue is that you can have over a 100,000 times overheads with general purpose zero knowledge proofs. And so for small models like say linear regression uh or say small decision trees this can actually work just fine.

But the problem is as you get to larger and larger models which are becoming more prevalent in our lives, I'm sure most of you guys have used CHPT or some other form of LLM. Uh this 10,000 times overhead no longer becomes uh tenable. Okay. So then uh oh nice formatting issues. Uh well uh so the other uh approach that people have taken is you can develop custom protocols designed for specific models. And so for example uh here are two such examples in the literature zknn and zklm. Now one of the things I actually want to point out here is that this thing here gptj is actually an llm but by default zklm does not support gbtj and this is because of

the specific way the protocol is designed. Now this isn't an inherent limitation. you could extend it but the point I'm trying to make here is that if you want to prove a variety of different models uh the prior work is unfortunately inflexible and cannot support a wider range of models at least that's currently implemented. So key insight that we leverage to to making this more general and also higher performance is that ML models and this includes a wide range of uh different ML models that people actually use in practice uh consist of a small number of composable computations.

Uh I'm sure everyone here has heard of matrix multiplications. uh but there's also some other form other things like non different linearities that can then be uh that if we can prove each of these individually we can then put together to prove general purpose machine learning models and also a wide range of them. So to support this vision we built zk torch which is both extensible and high performance. The general way this works is that we have some specification of a uh of a model and currently we support onyx and we built a compiler which takes this specification and compiles it down to zk torch layers and then given these zk torch layers we have a transpiler to what we call our what we call basic blocks which I'll describe in detail but these are basically

cryptographic primitives and then we have the actual prover which then executes and creates the proof. uh uh as far as I'm aware uh ZK torch is the first uh proving system that supports all the MLF uh version 1.4.1 edge models um and it's about uh six times faster than general purpose uh zero knowledge proofs on LLMs and we also developed a new parallel accumulation scheme uh to be succinct and high performance. Okay, so now that I've talked about uh zero knowledge proofs and MLS in general and a little bit about the high level of ZK torch, I now want to talk about the internals of ZK torch and how we accomplish this. The first and most important uh

sorry the first thing that's really important is how we represent the uh intermediates in a machine learning model and these are generally called tensors. A tensor is simply a floatingoint uh n-dimensional array that is used uh that is used between uh layers of a model and also the inputs and the outputs. So roughly speaking let's say you uh let's say we use chatbt as an example. Uh your text that you give to chat GBT is turned into actually a floatingoint uh tensor and then it's passed through many layers which produces intermediate tensors before producing the output tensor which is then turned back into text. So these tensors are fundamental to to these machine learning models. So what we do in ZK torch is we

take the original tensor and then we quantize it and then we kg commit the tensor along the last axis. So here I'm showing a twodimensional uh array but you can also imagine n dimensional arrays where we just simply commit along the last axis. Uh one thing I want to point out actually is that you might want be worried about this quantization step. Well, it turns out that um a large fraction of machine inference uh perhaps I don't it's hard to get the exact numbers but perhaps over 95% of it is actually done using quantized weights.

So this is actually standard practice today outside of uh ZKML. Okay. So why do we use uh KG? Why do we use KG? Well, KG easil easily supports lookups and arithmetic operations. Homorphic addition is great. If you want to add uh two KZG committed vectors, that's very very cheap. Okay. So given the tensors, we want to now be able to perform operations over these tensors. And so we selected uh uh 20 basic blocks which support the 61 layers that are necessary to prove the uh MLF uh v 4.1 models. uh and the the we have a list here. So they

span from arithmetic and boolean operations. So for example adding two two tensors as I mentioned uh table lookups for nonlinearities and scaling implemented using uh uh a modified version of CQ and this is for things like uh the value nonlinearity and also for other operations like the softmax which are critical uh for modern machine learning. And then we take uh some uh and then we uh also support matrix multiplication uh shape operations to uh change the shape of tensors and then also other things like sorting and max operations which are used for some of the more specialized models like retinaet. One of the key primitives that

we use to implement these basic blocks is what we call a polyop. uh and the basic idea is that we know a set of witness polinomials and we have some uh know some relation f sorry some information relation r such that the r on these polinomials is equal to uh zero. So for example uh this r here of this f for a boolean check basically to determine if all elements are zero or one can simply be f of one uh times 1 - f of one and you should be able to convince yourself that if this relationship is satisfied then f the kg committed uh polinomial uh is all zero the coefficients are all zero or

one okay beyond the boolean check which was very simple that I mentioned uh our poly IOP enables many different operations. Uh so for example, one of the uh uh uh checks that we use is we have an ordered check basically to check if the if a vector is sorted in ascending or descending order. It doesn't doesn't really matter here. So let's say we have some some input. uh what we can do is that we compute the difference between the uh uh the shifted difference uh using the polyop and then we simply uh check that all of the differences are positive and you should also be able to convince yourself that uh if the difference between consecutive

elements in a vector are all positive then it is uh sorry I guess it's technically not negative uh then uh this should be an increasing vector Okay, so I talked a little bit about the basic blocks which is this uh component here. Uh now I want to talk about another component of our system which is the compiler. So uh operations that are efficient on the GPU are not necessarily efficient uh in uh uh ZK. So for example uh this is a nonlinearity that is widely used for LLMs. is called the gel nonlinearity and this is how it's implemented on the GPU.

You have some input, you take it to some power, you multiply, add, multiply 10h add, multiply, multiply on the other side and then get some output. So you can see here there's 1 2 3 4 5 6 7 8 different operations that that are required to implement this on the GPU. And this is because the GPU doesn't have this amazing thing which are these lookup tables. Uh and so instead of uh computing this, we actually take uh at the com at the onyx level uh replace using a um a pattern matching uh uh uh uh compiler uh these complex operations with operations that are simple uh for uh zk proving. So this is entirely at the onyx level. This is actually not this

actually doesn't work at the prover level at this point. Okay, so I've talked about this part and this part. Uh now I want to talk about the transpiler. So one of the things about uh uh ZK is that there are many ways to do the same computation. And here I'm just showing one simple thing, one simple uh way that you can do two uh uh two protocols for the same operation which is matrix multiplication. Now for matrix multiplication uh there's a protocol developed by u Ariel and uh Liam uh I believe uh called CQIn and in CQN you actually need to know one of the

matrices but it's uh you can do a very efficient matrix multiplication but if you don't know the matrix multiplication we can use another protocol or variant of another protocol called Aurora to do the matrix multiplication and the basic idea is that you do a random linear a randomized check uh and that's uh the rough intuition. Now deciding between these two, we need to know if one of these matrices is not known ahead of time and also depending on the size of the matrices and some other factors which one we want to use. And so here the transpiler decides which of the different uh um implementations of the same operation uh we select to to get high performance. Another uh thing another important class of

operations that that the transpiler operates over are these shape operations. Uh here I'm just showing a a list of uh basically the decision tree for how we decide which shape operation to use. Uh the details here aren't super important. Essentially there are many ways uh to do uh to to basically reshape or transpose or change the shape of a uh of a tensor. uh and which one we want to use depends uh quite a bit in terms of uh the generality versus the efficiency trade-off here. And so we want to use the most specialized version which is generally the highest performance version for shave operations. Okay, so I've talked about our compiler and our transpiler. Now I

actually want to talk about the prover and specifically how we optimize certain uh parts of the proving stack to both uh obtain su succinctness and also high performance. Uh okay so um I want to talk about some prior work which is uh this idea of a proof accumulation. I think that we actually specifically use folding. Uh the general idea is that if you have uh two proofs uh generally speaking they're uh they let's just say they're the same operation for the time being. uh you can uh accumulate uh a1 into sorry p into a1 to get a proof uh a2 um that basically says that a1 and and p are correct and I have something that's succinct as uh

after doing this this is a very standard technique in uh in zk why is this important well uh in zk torch we can produce thousands of of proofs and of course if you produce thousands of proofs you're going to have a very very large proof size which is not desirable and in fact in some of our uh some large models uh I think we can actually produce tens of thousands of proofs. So to resolve this we extend this prior work by mirror by uh Benfish and some others um I believe at Yale uh and by using accumulation we can reduce the proof size by over 2,000 times and this is again because uh ZK torch can produce thousands of small proofs

depending on the uh specific operations and the emission learning model all right so how do we extend mirror well okay so as far as I'm aware there aren't really that many uh uh settings where you are producing literally tens of thousands of proofs And so uh the way that this mirror does things in general is that they do this uh proof accumulation sequentially and instead we can basically do a merkel accumulation which is substantially more efficient if you're accumulating thousands and thousands of proofs. Okay. So so far I've talked about uh zk torch internals. Now I want to move on to some benchmarks. So we evaluated all the models in the mlperf uh v1.4 for edge

version and the hardware that we used was this uh uh you know Intel processor with 64 threads and 4 terabytes of memory. The model spanned from LLMs to CNN's uh to assorted ones and here we have RNN's and also this model called stable diffusion which is used for image generation. Here I'm showing the endto-end performance including the proving time, the verification time and the proof size. uh as we can see uh the uh we can prove all these models the proof times obviously vary stable diffusion for example is very very very large uh um and so it's obviously more more complex but as we can see here the verification time is generally relatively low and this can be reduced further using other

tricks like uh recursive verifi uh verification and what I want to show here also is that the proof sizes are also generally low for these for the size of these ML models in addition by Using mirror we can actually produce smaller proofs. So for example here I'm uh showing proof sizes for uh ResNet 50 for Mystique and ZK torch. I believe actually a smaller these smaller models for ZKNN and PVCNN. And so ZK torch has more than three times smaller proving sizes even using a larger CNN compared to prior work. Uh and then finally I want to point out that our parallel implementation of mirror improves proving time by six times uh reducing you know the prover for say GPTJ from

about 8,000 seconds to about 1400 seconds on the verification is also substantially reduced as well. Um can I get a quick time check? 10 minutes. Great. Okay. So now I've talked about um uh zero groups in ML, some ZTOR internals and benchmarks and I want to talk about some potential applications of uh ZKML. Okay. So the first thing I want to talk about is uh how generative AI uh works which is that you have some inputs and you have uh a prompt for these inputs. For example, I'm showing here stable diffusion where we have the prompt of an astronaut riding a horse

which then generates uh this uh this this image here. Uh, one of the fun facts or not a fun fact, one a fun anecdote is that I uh visited uh the folks who work on midjourney and they actually have uh um uh something in their office which actually shows the images that are generated live and you can actually see people playing around with different prompts especially for work when they want to get something that specifically uh targets what they have in mind and so this process of generating going from a prompt to an image actually is a bit of an art. Now beyond uh image generation uh this is actually also true for LLMs. As it turns out you have to often do this thing called prompt engineering to achieve

high performance using LLMs in different circumstances. Uh so for example this image here was generated from this uh fairly long prompt. The prompts can actually even get long can get even longer than this. And let's say I wanted to generate this this image. Uh hopefully there's no one is offended by this. uh you know I would have no idea how to go about uh doing this and so there's there's a question of how do you actually uh uh uh generate these complex prompts for uh these images that you want to be able to uh create from these models. Okay, so this was as of you know a couple years ago, but nonetheless, uh, you know, there are these prompt engineering jobs that can pay up to $300,000 a year. So quite

valuable. Using, uh, zk proof, uh, we can take a prompt and then actually uh, uh, have the output and then have a proof of the computation while hiding the input. And so this is one way that you can imagine actually uh proving to say an employer or someone else that you can actually uh generate highquality images or highquality prompts for LLMs uh while preserving your IP. Okay. Uh right. So this is uh prompt engineering uh but doing it in a provable way using zero knowledge proofs. Okay. Beyond uh LLMs uh and image generation for high performance, I

also want to talk about uh this idea of auditing ML systems. Well, okay. Well, first of all, why do we need why do we need audits? Well, there's many reasons. uh one is that there's this amazing line of work uh from Chaffy Goldwater at all uh that shows that you can actually plant undetectable backdoors in ML models uh which is quite scary which basically means that on specific inputs the ML model can uh you can make the ML model output something specific and it this is undetectable from simply looking at the weights. Now beyond this, I showed earlier in the talk that there were allegations that the 01 model released by OpenAI, the model card accompanying it was not actually reflective of the

actual model that was deployed in production. Okay, so uh one of the things that zero knowledge proofs enables is this idea of a trustless audit. And a trustless audit is exactly what it sounds like. I don't need to trust the trainer or the model provider. uh and I can actually be assured of some properties of this model. So one example is that I can prove that you ran an FDA regulated model. You can also do something like proving uh say my uh Twitter timeline is not biased. Okay. So in order to do this uh we will going to do two steps. The first is that we're going to do first do a proof of training and in this proof of training we first commit to the training data in a way that um preserve preserves

privacy and then we produce zk snarks of the training process itself. Now obviously today this is uh too expensive to do on say an LLM but you could imagine doing this in uh using fine-tuning in a costefficient manner uh or you can imagine also doing this on smaller models. Uh then uh if you want to do an audit, you can then write down another function which is a fun uh a function over the data and the model weights at the end of training. And you know that this model these model weights came from this data because you have this proof of training. Okay. So this audit function can be actually quite complex. uh you

can even have an audit function where you run an LLM over the input data itself. So you can do quite complex things like saying uh you know does this input data refer to uh some sensitive property of a user that I don't want for legal reasons or something else of this form. So yeah, so this is you can uh actually prove that that the training data isn't biased uh that the model performs well and many basically any other computable property uh you can uh uh prove using this procedure and I actually want to emphasize this one more time that this f can be arbitrary and in fact using a technique like uh a system like ZK torch you can in fact use LLMs

as part of your audit which is uh um I think very powerful and allows you to start to do sort of these arbitrary computations over your input data. Okay, the final application I want to talk about uh is uh proof of personhood in a decentralized and trustless manner. So uh I'm sure everyone has seen deep fakes in some form or another. Uh this is a simple example from meta. Uh and you know here we have this don't go to this website by the way ftx compensation.com. Uh these deep picss are used by state actors to spread misinformation, tricking businesses into miswaring funds and also uh uh scamming uh people on the internet. So in order to fight deep

fakes uh one thing you can do is use this uh uh uh this thing called a tested camera. And a tested camera basically you put a trusted ex uh an enclave right on the on the device say the camera and you sign all the pixels that come off. So again um uh this is a well-known technique uh in the literature. What can you do with this? Well, the first thing you can do is that you can edit images privately. Let's say we have this very sensitive credit card information here. Uh we can then uh just uh remove it and then prove that that uh edit was done honestly. Okay. What does this have to do with deep fakes? Well, one thing I can do uh all with this technology is I can then compose it and then do privacy preserving biometric authentication. So

starting with an Nessa camera, I can prove that a photo again this is all private uh was uh originated from a real camera. I can then perform uh photo editing uh again using in a completely privacy preserving way using a zero knowledge proof and then actually run face ID again using a system like ZK torch and in a completely privacy preserving way uh that I'm a real person while not actually revealing say who I actually am and this can be combined with things like um uh zero knowledge proofs of uh let's say uh government uh sanctioned u identities and other things of this form to really uh increase trust while

preserving anonymity. Uh beyond that I should gave some examples of audits. You can also for example uh uh audit say the Twitter algorithm or other other uh algorithms for for providing recommendations to your timeline. I'll just skip through that. Okay. So I'm just going to conclude. uh AI is becoming increasingly important as I believe everyone is aware uh and zero knowledge proofs provide a method of doing audits over both private models and private data which I think is very powerful uh and we built a system called ZK torch which which is extensible and also high performance. Uh I was hoping to have this open sourced uh this week but unfortunately we're going to push it

back till next week. So if you want to follow me on Twitter uh which will where we'll announce it. I also want to uh briefly announce that project veil is hiring. Uh if you want to chat with Jonah about that uh he's in the audience over there and I'm happy to take any questions at this point. Thanks [Applause] everyone. For your transpiler, how many op codes are going from Onyx? And when you do accumulation, are you paying for all those up codes per step like an IVC or are you doing something more like NIVC where you pay per upcode?

Uh sorry, I think the the echo is unfortunately a bit difficult. So my my my understanding of the question is that are we doing accumulation at the onyx layer level or at some other level? We're actually doing at the basic block level and they're actually uh uh many uh onyx layers that actually get decomposed into many different basic blocks. Uh so it's a bit complex to determine what the relationship is. Um, but uh we'll be open sourcing it. So if you want to do a deep dive uh when it comes out next week, happy to help with that. Cool. Thanks. Hey, uh thank you for the talk. Um I noticed when you were talking about the benchmark stuff, u you said them the specs you were running was 4 terabytes of RAM uh for generating the proofs.

Obviously that's not feasible for a lot of individuals and even if like for example in your the example you gave like verify that this X-ray was was passed through this model even for like a hospital that that's just not feasible hardware. So I mean obviously we want to get to that point but in the meantime you would want to delegate that kind of computation to some kind of you know third party brewer. Have you considered how like you would do privacy preservation in that context for obviously delegation? Uh yes the question is that the hardware requirements are quite severe for for this work. Are there ways that we can do delegation or other techniques to reduce this? Uh there's a few things to say.

The first thing is that purely in terms of memory you can simply cut this down by doing uh proving say one layer at a time. Now obviously this would increase the proof size and you have to also increase the amount of computation because you need to prove that the uh the input the witness from the previous uh layer is actually the the correct one for the next layer. Uh but there are ways to reduce the uh total uh memory consumption. Now, in terms of delegation, um I haven't been keeping up to date with uh uh uh the uh the the mechanisms that allow you to do uh proving uh privacy preserving delegation. But I'm pretty sure almost everything that we use is fairly standard and can be delegated uh if you want to do it in a privacy

preserving uh way. Uh but I'll have to look into some of the specific details around that. Um we are working on next generation systems which uh already are giving us 5 10x speed ups over the results I'm showing here and we're hoping to uh reduce the the hardware requirements even more uh beyond that. Thanks. We got time for one more question before the break if anyone would like to ask one. Oh yeah, go for it. Why do you choose mirror?

Okay, so the question is why do we choose mirror over sorry if I can just can you just repeat the question for the benefit of the audience? I've read mirror so I kind of understand but I don't think it's obvious like why did you choose mirror over the other folding scheme that are out there? Uh yeah so to to answer your question quite directly um we it it simply supported a bunch of things that we were doing already. Uh so it they fold CQ and CQL in uh and because that was already built into their protocol it was just a simple thing for us to extend. Um uh there are many different uh choices of uh protocol at the different layers and they actually result in very very different uh uh performance characteristics. uh we didn't have a chance to look into others um and we're hoping to do this in the

future but as I mentioned uh there are some techniques that we're already developing that can reduce the cost by five stacks or more and we're also looking to reduce the cost even more beyond that uh this is going to require uh optimization across the whole stack right let's all give Daniel a hand thank [Applause] you all right everyone uh we now have a 30 minute break uh we'll be coming uh back here at 15:30. So enjoy your break and we'll see you guys at 15:30 for a talk from Jeremy Brussell at risk zero.

Check, check, check. Okay. Hey everyone. Uh, welcome back from the break. Uh, we've got a series now of kind of lightning talks, each of which will be uh, 15 minutes here. Um, so first up we have Jeremy Bristol from Risk Zero. Jeremy, please come on up to the stage and let's give Jeremy a hand. Oh, I need a clicker. Is a clicker? There it is. Yeah, cool. Uh, hey everyone. I am Jeremy Bristol, CEO of Risk Zero. Uh, and today I'm going to be talking to you about the latest the soontobe version of the Risk

uh zero VM uh version 3. Uh so you know a little bit about me quickly. Um you know I've been programming since you know the age seven on the Apple 2. Uh and you know have always loved building software messing with software. Um you know I've also always loved math. I love to read a good math paper before bed as something to relax. Uh I I'm not a working mathematician. I've never proven anything novel or interesting. Uh but the abstractions from mathematics I think inform a lot of what gets done. Uh I am also the co-founder and CEO of Risk Zero. Um and we were the creators of the first sort of Risk 5 ZKVM. Um so today I'm going to I'm going to start by

giving you a brief history of sort of the work that we've done in the Risk Zero VM. Uh so long ago there we go. Uh so many years ago um I think it was probably almost 10 years ago now I first learned about the existence of ZK. I was reading, you know, something about probabilistically checkable proofs and the idea that you could verify an arbitrarily large computation in 01 time sort of blew my mind. And so, uh, I was very interested in figuring out how that actually worked and understanding it. Um, and once I understood it, I was really wondering when it would be practical to make something that actually was usable in the real world.

One of the limiting factors in my mind on that was being able to do fast recursion. And then with the uh sort of release of the Stark paper by Ellie Ben Sassan, I was like ah this is coming into practicality, I tried to convince all my friends that this was a good idea to build zero knowledge proof systems. Uh but the sort of consensus at the time among my sort of hacker friends was that uh writing a bunch of polinomial con uh a bunch of constraints uh polinomial constraints in finite fields was not really programming and uh that there would be a lot of difficulty making these things practical. Um and then over years me and my other two co-founders came up with the idea of building a ZKVM that was actually based on an existing

well-known ISA the risk 5 ISA. And so we introduced sort of the first uh came up with the first idea of the risk 5 ZKVM. Uh and basically right after that I started building a prototype. Um and we were sort of also the first at the time to use a very small 32-bit field which was the baby bear field. At the time Goldilocks was another common field. So we named it baby bear because it was even smaller. Um and the original version of the risk 5 which was sort of our pre-incorporation prototype was uh very limited. it it had represented the constraints in a C++ EDSL. Um we did a lot of inefficient things like putting the risk five registers into the columns of the stark. It took three you know rows to do a single instruction. Um the

memory argument was pretty mediocre and most importantly it was not possible to run arbitrarily large programs because of the fact that uh you know as your program got longer your start got bigger and you eventually ran out of memory. Uh that said, it was enough uh to go get ourselves some funding um which we then parlayed into sort of our risk zero VM v1 which is our first production grade uh sort of VM. We moved we made a bunch of efficiency improvements including the memory mapped registers which are common today uh you know and reduced the complexity of doing instruction. One of the big things was we also were the first to sort of introduce the notion of continuations wherein to run a very large program uh that takes up many many

cycles. You would actually break the execution into segments where each segment was say a million cycles and then you would prove each of those uh independently and then use recursion to glue them all together into a single proof. Uh and what that allowed is to be able to run arbitrarily large computations. Um and so very shortly after that we uh built ZETH which was the first type one uh ZK EVM. So and you know we also moved to the we also had to produce a mechanism to do paging to Merkelize the memory state between uh each of these segments uh which we used originally shaw as our mechanism for that. We built the first GPU acceleration and uh as of 1.2 we also introduced this idea of algebraic

pre-ompiles which allows us to do sort of big integer arithmetic. Uh so for quite a while that was our our ZKVM. We recently uh have introduced the uh Z the V2. Um and this is really entering into sort of the real-time era. We've actually made massive performance improvements in terms of the amount of time it takes to do verification of Ethereum or proof the correctness of an Ethereum block. Actually when I sent these slides in we were just under 30 seconds and since then we are now uh around 20 seconds. Um, so we're very ho hoping to very quickly get down below the 12 second mark so that we can prove the correctness of an Ethereum block in real time. Um, I think it's worth noting that uh one of the unique features of

our system is that it is the only sort of 100% open-source uh risk 5 ZKVM including the fact that the GPU acceleration is all fully open source as well. Um and after building circuits a number of times we ended up deciding that it was better to build sort of a DSL and a compiler for building the circuits. Um this has a lot of advantages uh specifically around the verification. We also just made a lot of just straight performance improvements. You know reduce the amount of work it takes to do a single instruction. Um move to Poseidon based paging for more efficiency. Had a better memory argument. I think one of the key things too is that uh we are the only ZKVM to my knowledge that

has done some work to formally verify that our circuit is um fully deterministic. So um people here probably know that one of the biggest sort of causes for soundness bugs in any kind of ZK system is being under constrained. We've actually proven in fact that uh our circuit uh is not under constrained in any way. So at least in that that entire class of soundest bugs is uh ruled out. Um and we're also working on some interesting work with regard to supporting kernel mode in ZKVMs. So mostly I want to talk about with all that history uh in I kind of want to talk about sort of our next big innovation which is the version of the ZKVM that is currently under development

which is the sort of V3. Um V3 is a fairly major refactor of the way in which we are structuring the circuit. Um particularly we're moving toward this uh idea of this M3 or multi- multis set matching uh which is a new arithmetization scheme that was pioneered by the folks at irreducible. Um and using this we're going to actually be able to support multiple proving systems for the back end including both our existing proof system over baby bear. uh but also we're going to be supporting binius from irreducible uh and we're going to reuse many components of the circuit across those.

Now one of the big advantages of sort of M3 is that it's highly modular uh which will which both simplifies the circuit itself but also there's a number of places where we're able to use reuse and we expect that plus the other improvements we're working to give us a major performance boost. Um currently we have some early benchmarks and some back of the envelope that show us that greater than a 10x performance improvement is possible. Um obviously you know everyone will be excited to see when the thing is working enough to have real numbers but we're very bullish on this. Uh so I let's just talk for a moment about sort of arithmetization in sort modern ZKVM. So going back all the way to the original Starks the and the notion of air arithmetization

uh effectively when you're building a ZKVM typically the idea would be that you are sort of executing uh over time and every row in your uh table that you are committing to is related to previous rows by some sort of set of constraints and so you're sort of viewing the system as like a a digital circuit. in some ways operating over the time dimension. Um, and then typically you also in addition have needed arguments for doing lookups or for memory arguments. And there's been a movement more toward supporting sort of multiple tables and arguments relating them via sort of a bus or some other kind of memory argument. Uh, not only for for really for two purposes. One is

for sort of the pre-ompiles that people have been building and of course we use this for our pre-ompiles. um as well as there's been some work in terms of subdividing up the VM itself into sort of multiple components each of which has its own separate uh table within the Stark proof system but sort of M3's basic notion is to break this down into even finer grained components wherein effectively you actually make each row of your stark tables unrelated to the prior or preceding uh and instead you connect them only via sort of this argument this uh multi multis set uh sort of mechanism and the

idea is that you do this with this concept of channels uh which I I'll get into in a little bit uh more detail in a moment here but basically the the the key here is that you don't have sort of a main trace anymore you simply have these tables which each have rows the rows have no relation to other rows within the table. There's no sort of notion of temporality um or inter row relations. Instead, the idea is is that each row represents some kind of a logical constraint and that that row uh sort of interacts with these channels.

Uh the channel itself is effectively a tupil that or each channel has sort of a a tupil that you can push some value into the channel and then some other row of a different type or the same type can pull a value from that channel and the idea is is that M3 imposes this sort of channel balance condition where uh I if if you push a particular tupil some other row must pull that tupil and if there's anything that you ever push without pulling, then the channel balance condition fails. Uh, and it fails. So, oh gosh, I'm running a bit behind. So, let me run through some really quick things here then. Um, so this simplifies the design quite a bit.

Um, and it allows you to break things down into much smaller pieces and have much more natural abstractions, particularly for things that have nonsequential operations like Merkel trees, which I'll go into in a moment. Um, it also allows the it makes many things much more trivial row-wise parallelism because there's no relation between rows anymore and it allows this memoization concept which I will cover in just a moment here. Uh so really quick example I'm not going to be able to go into this in as much detail as I was hoping but basically if you imagine say the paging argument uh normally we would have to sort of linearize this but now what we can actually do is we can make these relations between uh sort of multiple pages and basically for each one of these sort of you know page in

nodes what that is is it's a row and it's basically pulling from a channel the previous Merkel one node of the Merkel tree and it's effectively pushing into that same channel uh the two nodes that the Merkel that that compose that Merkel tree and there's basically local constraints within each of these things. Uh and by doing this we're basically allowing uh to sort of prove the correctness of sort of a graph of constraints rather than some sort of linear set of constraints which makes the process uh both much more efficient. Additionally, uh you can look at for example when we're doing uh a risk 5 instruction, we can actually break down the instruction into sort of multiple different components. Uh so for example, we can move the actual unit that does

say the multiplication outside of the main uh instruction processing engine and we can also for example move the instruction decoder outside of the processing engine. And because we can use the ability to push with multiplicity to a channel, we can for example reuse the same instruction decoding every time the same instruction appears. So since typically an instruction is executed many times in a loop, we only play the decoding cost of that instruction once. And by breaking the problem of doing the full VM into much smaller parts that are connected via these channels, we're able to sort of get a lot more reuse and uh duplication.

So this also gives us the ability to build sort of something that works across multiple proof systems and I wanted to kind of cover really briefly how that's done. So effectively the idea is is that once you have this model each of the individual tables becomes much simpler and you can actually use the same logical set of blocks and channels but with different concrete representations across multiple proof systems. So in this case we may actually use different encodings for what's the tupils that go over the channels between say baby bear and uh binary fields. Um and we in fact arithmetize each component separately. So if we have say

a 32-bit multiplier the way that we build a 32-bit multiplier in baby bear is very different from the way we build it in binas. However the logically they're doing the same thing. And so what that means is that we can use logically the same circuit across multiple different proof systems. And while it does require arithmetization of each of the components, they're much smaller and more importantly much of the sort of highle work in terms of how do you do pre-flight, how do you do early parts of witgen, uh much of that can be reused and so both the design of the circuit as a whole as well as um much of the implementation can be shared across the proof systems. All right, so I think I'm out of time. So, uh, and any questions?

Uh, sadly, we do not have time for any questions for Jeremy, but let's give Jeremy a big hand for this talk. Sorry, I kind of needed a timer, I guess. I'll get it. No worries. Uh, okay. So, next up, we have uh Ean from Axiom as our next lightning talk speaker. Let's please welcome him to the stage. testing. Uh, should I start?

Cool. Yeah. So, hey, my name is Ye and I'm here to talk about OpenVM. And so, I think I can skip this slide given Jeremy's talk right before, but OpenVM is a ZKVM framework. And the main impetus for OpenVM is this trade-off be between performance and usability of current ZKVMs that occurs primarily at the ISA level. So I think broadly there are two types of ZKVMs today. I would say some use a ZK adapted ISA uh things like Cairo or Valita where they've created a entirely new ISA um which is tailored for the performance

characteristics of ZK. Now the advantage of this is that it's going to be much faster if you're able to pair your ISA to the actual proving you're doing. up the problem is all programs need to be rewritten to run on this ISA uh which is a challenge from an engineering perspective and a security perspective. Now the other approach which Jeremy was speaking about is to use an ISA which appears in an existing processor and this has the very big advantage that you can use existing compiler tool chains.

Uh but it can impose some performance overhead because risk 5 is not designed to be proven in ZK. And what's common between both of these choices is that the VM is committing to a fixed choice of ISA. And so with OpenVM, our design philosophy is to try to remove this trade-off between performance and usability of the VM by introducing a modular approach to putting together a ZKVM. And so what is a openVM? It's really a framework for constructing ZKVMs that is modular and designed for customization and extensibility. Uh so it can prove

arbitrary Rust programs. Um, it's fully modular around a concept of VM extensions and it all rests upon a new type of ZKVM architecture we're calling the no CPU architecture. So, first let me tell you what OpenVM can do today. Um, as I mentioned as a developer using OpenVM, you can construct your own modular ISA using a concept we're calling a VM extension. An extension is a set of op codes that's able to interoperate over op codes interoperate with op codes from other extensions over a set of common address spaces. So these address spaces can be typed meaning we can have address

spaces for risfi format memory or address spaces which are natively in the native field which is particularly useful for recursion. Um so OpenVM ships with a default set of extensions covering riskfi support, recursion support and all common pre-ompiles which occur in proving Ethereum blocks. However, the design of OpenVM is fundamentally extension first, meaning the framework itself does not commit to any particular extension and all functionality is implemented through extensions that live on an equal basis to extensions that you could yourself add to OpenVM. In particular, it's possible for

developers to write and add their own OpenVM extensions without forking or modifying the core library. Um, one thing this allows us to do is to accelerate performance for particular workloads with custom VM extensions. So for the recursion part of OpenVM, we applied this technique to heavily optimize the recursion circuits and we recently worked with Powder Labs to create an PC to automatically synthesize extensions uh based on user programs.

And one thing to note is that these extensions created by powder are able to interoperate with user programs without any modification to the core open VM libraries. So another possibility that the modular approach opens up is to support multiple tool chains over the same backend. So today we support uh Rust tool chain by building to RV32. Um and we also support a tool chain that's more adapted for native recursion. Both the Rust and native tool chains build to an openVM program binary after which we have a uniform process of

turning them into Stark proofs applying recursion and ending up with a proof verifiable efficiently on the EVM. And so in particular on both tool chains we support arbitrary unbounded execution. So how does this work? Now the key design consideration we had was to not be skumorphic to existing processor architectures when we're building the ZKVM. And the reason is that obviously the constraints of ZK are quite different from the constraints of physical hardware. And the one thing we realized is that existing CKVMs have a central CPU trace where essentially

every op code in the VM must be processed in this trace and as a result there's a centralizing effect in that this circuit needs to know about all the op codes and process all of them and typically this will be the largest trace in any segment of a VM. So in OpenVM we're introducing uh what we're calling a no CPU architecture. What that means is that there is no single tra chip in the open VM circuits that knows about all the op codes. And so instead the execution consistency of the VM is just spread out around different components each of which only apply to one set of op

codes. So this has two advantages. First, it just removes a lot of cells from the trace, allowing for faster proving, but probably more importantly, it allows us to create modularity at the ISA level. If you want to add more op codes to the VM, you simply create a chip that plays well with the other chips and conforms to the API interface. And in particular, because the central CPU circuit doesn't need to know about any other op codes, uh you don't need to fork the core library.

Another feature that we've added to is the ability to handle variable word sizes in memory. So in existing ZKVMs typically there's a fixed word size that's applied across all all of memory. Um that's similar to how in a sim in a physical processor of course physical RAM has a word size. And so what that means is if you're running an operation that's accessing larger blocks of contiguous RAM, then you'll typically use multiple u memory accesses. So in OpenVM, we actually introduce offline memory checking with a variable word size. So we allow block sizes between 1 and 32. And in

particular, if you write a block of size 32, you can directly read it without breaking it up into blocks of size one. behind the hood, we convert between these blocks uh with length adapters if you happen to write a larger block and read a smaller component of that block um later. And so the consequence is that when you're adding different chips into the system, you don't need to keep a uniform word size. You can create chips with the block sizes that make sense for your application and behind the scenes the framework will convert between them for you. And finally, we're able to handle

proving unbounded programs via a continuations approach. Uh so we separate a large execution into different segments, prove them independently, and then apply a recursion program um all the way to an EVM verifiable proof. Uh one thing to note is that we're able to config flexibly and configurably change the degree of the recursion um as well as the configuration of the VM in the recursion without modifying the final verifier. All of those can be done dynamically in the recursion. So let me just tell you concretely what OpenVM can do today. So we're able to prove Ethereum mainet

blocks. Uh currently we have a CPU prover and on a range of a thousand recent blocks uh we're able to prove in 8 minutes average for close to 0.1 cents per transaction. Um if parallelized we're projecting around 90 seconds uh parallel. Um, we just went live on scroll mainet uh last month and they were able to see a number of the benefits of actually using a ZKVM instead of using handwritten ZK circuits they had previously. And I want to say that we're continually working on the performance.

So give to give you a sense on the progression over time, we released the first public version of OpenVM in December. So that actually already had onchain verification and as you can see in the last couple months we've been able to improve both the cost and latency of proving quite a bit. Um these graphs show our progression on block 21 million. Um so as of the latest benchmarks which are a bit more recent than the average sample we're able to prove that in a little over 6 minutes on a single CPU machine.

So in the next couple months, we're going to continue to optimize and add features for OpenVM. Uh to talk through a couple of the highlights, first we are building a GPU prover to further accelerate uh proving and working on making our execution and trace gen zero copy. Uh secondly, on the ISA front, one thing we think is really exciting about the modular approach is to add support for different ISAs like RV64 and web assembly while maintaining uniformity on the VM back end. Um secondly, we think it's interesting to keep pushing this programspecific pre-ompile direction to really enable developers to accelerate

uh a ZKVM for their specific workload. And finally, we're building out a hosted API for OpenVM uh to allow developers to try out proving on OpenVM and deploy to production on Axiom's hosted cloud infrastructure. So if you want to find out more about OpenVM, you can check out our developer book or the codebase. And if you're interested in getting support from Axiom on implementing OpenVM in your application, you can fill out a form we have at our website. Uh so I think we have time for a couple questions. Yeah, we got about 2 minutes for any questions for Ye.

Yeah, I really like the slide on when you were comparing the Rust. You write in Rust and then at the very end you have this uh EVM verifier. Um I just wanted to understand how does that compare to things like risk zero from a app developer or a developer point of view? Like what should I be like considering in terms of trade-offs? What do I get here I don't get here? Yeah, I I would say the the developer experience at a high level is pretty similar. You write in Rust and you get an EVM proof. I think there the ZQVM trade-off space is quite highdimensional. So I think there are a number of places where we do differ. Um in terms of the VM architecture, I think it's pretty different. Um Jeremy would be the person to talk to about that. Um

on the EVM verifier, we don't use Grath 16. uh we actually use a Halo 2 verifier that does not have a circuit specific trusted setup. Um in terms of the way we handle VM extensions in Rust, it is actually quite different uh to risk zero. So risk zero I believe uses e- call to do sis calls for pre-mpiles. Uh we use uh rust intrinsics and kernels to call out to actually new op codes that we're embedding in the risk 5 elf. Um, so this is parallel to how Rust handles SIMD intrinsics and calls to GPU kernels. So one feature that this enables is the kernels are allowed to not just run a single instruction that

reads and writes to risk 5 memory, but actually operate on an address space that is not rised. And so this enables us to have a feature to recursively verify an openVM proof from within an openVM program. I'm sure there are many other differences, but I just want to call out some highlights. All right, I think we're about at time. Thank you for the question. And let's give a hand to Y up here for the talk. Thanks, man. Appreciate it. Okay, next up we have Michael Zu from A16Z Crypto. Uh he's gonna be talking about lasso and jolt or twist and shout or some combination of those

verbs slashnoun. I guess there's one down in there. Uh, let's give a round of applause to Michael, please. Hi everyone. I'm Michael. I'm a research engineer at A6Z Crypto. And today I'll be talking about twist and shout, uh, two new memory checking techniques authored by Shinasi and Justin Thaylor, and how they fit into the Jolt uh, road map. Um, oh, I realize I don't have the clicker. Okay. Are you looking for the clicker?

Yep. Sorry. Table. Um, some quick disclosures I'm obligated to include here. Uh, yeah. So, what is Jolt? Uh, fortunately, I was preceded by two other talks about uh, ZKVMs. So, I don't have to explain what that is, but what sets Jolt apart from its peers is is that it's uniquely designed around sum check and lookup arguments. Hence the uh, backronym just one lookup table. Um, this makes Jolt fast and relatively simple. It achieves state-of-the-art performance on CPU and we have GPU acceleration in progress. And by minimizing the amount of low-level circuit code that's written, um, it makes it easier to audit and formally verify. Uh, so to make the simplicity point concrete, uh, so this is basically

all the verifier needs to know for the risk 5 less than instruction. Um, put another way, you can kind of think of this as the uh marginal audit surface of one instruction in Jolt. As you can see, it's just a handful of lines of regular rust. No low-level circuitry uh required. Pictorially, this is roughly what the Jolt architecture looks like. So, in the center, we have this small R1CS instance, which we prove using Spartan and it serves as sort of the glue between the other components in Jolt. So we perform lookups into the bite code uh fetching each instruction based on the current program counter. Uh we prove that using uh the lasso lookup argument

currently. Similarly we do instruct instruction execution using lookups and for read write memory uh we use the spice memory checking argument. Um so we use that for both registers and uh loads and stores to RAM. So now with twist and shout this highle architecture remains the same. We're just swapping out uh spice for twist as the memory checking argument and lasso for shout as the lookup argument. Um in a bit more detail what are twist and shout? So twist is a new readr memory checking uh technique while shout is a new readonly memory checking

technique or also known as a lookup argument. Uh what makes them unique is that they don't require any permutation checks. So that means no grand products, no read, solid and fingerprinting, uh no multi-et hashing required. Um all you need is some check. They use large but sparse polinomials leveraging the fact that zeros are basically free for the prover as long as you use an elliptic curve-based commitment scheme. And this results in a faster prover and shorter proofs. Uh we'll see some preliminary performance numbers uh in a later slide. Um at a more philosophical level uh we see that this um with twist and shout the prover cost profile kind of

start to converge towards more hardware-like performance characteristics. Specifically we see that register accesses are faster to prove than RAM accesses and that uh memory accesses are also faster with more memory locality. So now I'm going to give a very high level sketch of what I see as the key insight of shout the so-called meth method of one hot addressing. So here we have a uh lookup table val um and for each access we're going to represent the query as this one hot vector. So if three is the element being accessed we have a one at that index and zero is everywhere else. Here RA A

stands for read address, RV stands for read value which contains the uh the lookup output at each step. So in the next step we're accessing this eight and then that one and then this one. And so with these RA and RV polinomials we have this very nice sum checkable expression here which conceptually all it's saying is that the value read at time step t is given by uh the index that was accessed and the value of the lookup table at that index. Uh and this is nice because ra is extremely uh efficient to commit to given that it's all uh zeros and ones.

Uh in fact you're only committing to one bit per cycle basically. uh and also this sum check is uh efficiently provable using some techniques described in the twist and shout paper. Uh one caveat here is that we still need to prove that RA is indeed uh one hot. Uh but for that I'll again defer the details to the paper. Now for a highle uh sketch of twist or rather the key inside of twist which is the method of increments. So now instead of a static lookup table val we have uh val which can be both read from and written to. So you can think of these as like eight registers uh initialized to all zeros

here. And so every time we write to one of these registers we're going to represent that as um instead of the right value they increment or delta. So here we're uh incrementing that register by eight and then at the next cycle we're going to increment this other register by three. And then we're going to decrement that eight by two giving us six in that register. And once again this gives us a very nice uh sum check expression here. Conceptually all this is saying is uh the value in register K at time step t is given by uh the sum of the increments for that res register up to that time step t. So here the lt polinomial is basically just the multilinear extension

encoding that bit of pseudo code. uh which is if t prime is less than t it's one otherwise it's zero. Uh so for an example here val of 52 um is just the sum of those two increments and um similarly val of 33 is the sum of those three increments. Right? So everyone's favorite topic performance. Um so with the caveat that these numbers are based on some preliminary uh benchmarking in a still work in progress branch in the Jolt repo. Um specifically this uh branch does not yet integrate a polinomial commitment scheme. So we're

just comparing some checks to some checks here. So some checks before twist and shout and some checks after twist and shout. Um so we can expect these numbers to shift around a little bit but um this is giving a rough uh idea of what to expect in terms of proof size. We see that the jolt proofs go from about 240 kilobytes down to 45 kilobytes which is a 5.3x reduction. Uh prover time the big headline number here is is that instruction execution lookups get 7.3 times faster using shout instead of lasso.

uh we see a about 2.6x reduction in prover time for read write memory and bite code lookups and sort of incidentally we got a 2.2x 2x speed up on Spartan. Uh this is due to the fact that we were able to eliminate some of the R1CS inputs and constraints uh when moving to twist and shout. And the Jolt prover also uses about 3.3 times less memory at peak. Um and all this is with uh more optimizations still in progress. So what's next for Jolt after Twist and Shout?

Um the main thing on our minds is streaming which is a method of uh controlling prover memory usage without relying on uh snark recursion. Um so currently the jolt prover uh uses memory that scales linearly with the length of the execution trace being proven and um other zkms as you may have just seen in in the previous talks address this using continuations um which is basically breaking the trace into chunks or shards proving each shard and then recursively proving those. We're pursuing an alternative approach uh based on streaming algorithms. Um in the interest of time, I'm going to zoom through this a little bit. So this is roughly what continuations look like. Um and compare that to streaming where we're going to

make a sort of streaming pass over the execution trace or rather multiple passes uh generating the trace sort of on the fly. um so that we only have to keep a small portion of the trace in memory at any given point. Um and there are some ways to speed this up. Uh for example, we can take some checkpoints of the VM state on the first serial pass in generating the trace and then in subsequent passes we can uh generate the trace in parallel.

Um so the benefits of the streaming approach uh first and foremost is simplicity and security. So no snark recursion means that there's no need to implement the verifier as a circuit. Uh there's no need to introduce some sort of recursion VM or other proof system. And um also the security of snark recursion is thought to be on sort of shakier theoretical footing than non-recursive snarks. In terms of performance, we avoid the uh potentially costly snark recursion step. And also uh specifically for twist and shout, we expect the prover to to perform best on larger trace lengths. So we don't necessarily want to break the trace into small shards as we would do with

continuations. Um and finally, while we're excited about this streaming approach, we acknowledge that there are certain benefits of the continuations approach as well. So it's important to note that um streaming is also complimentary with continuations. So eventually we hope to get the best of both worlds. And that's all I have. Thank you. And um happy to take [Applause] questions. And I've got the mic if anyone would like to ask Michael a question. Do we have any questions for Michael? All right.

In lasso, it was required that it was MLE structured and decomposible. Do you know if in the new work it still needs both of those things? Sorry, I missed part of that question. So, in the original lasso paper or the original Joel paper, the arguments you were doing need to be MLE structured and also decomposible. If there weren't those two things, you couldn't use it anymore. Um, with this newer work, do you know if you still need both of those things or is this just one? Like can you not have the decomposability property? Yeah, so the the lookup tables still need to be MLE structured. Um, and there's also a notion of decomposibility similar but not exactly the same as lasso. It's this uh something called prefix suffix decomposibility which is described in

actually not the twist and shout paper but um a different paper proving CPU executions in small space. Awesome. Do we have any more questions? One more. You had mentioned there's some advantages to twist and shout if the uh system is instantiated over an elliptic curve based commitment scheme. Uh to to what extent could you apply these to a nonhomorphic commitment scheme to a non homoromorphic commitment? Yeah. Okay. So the main property out of um elliptic curve based commitment schemes that we need uh well one of the main properties

is is that zeros are free to commit to. So as you can see like the RA polinomial here is mostly zeros. Um so that's the main one. In terms of uh homorphism I I think you could get away without um just we we're actually not committing to that many polinomials total. I think it's something on on the order of like 16 or 18. Um so you know you'd be paying like that constant factor of overhead on the um proofs. But yeah, currently we're just looking at using um elliptic curve based commitment schemes. Awesome. Uh we have time for one more question if anyone else has a

question. All right, let's give Michael a hand. Oh, thank you. Thank you, Michael. Awesome. All right, we've got one last talk here uh for the kind of lightning talks round. Um this is actually two speakers. Uh Howard Woo and uh Aleandro Klio are going to be speaking about formally verifying a ZKVM. Um so with that, please welcome them to the stage. And fortunately, we have two mics. So see you too. You're on. You're on. Thank you. Thanks very much. Slides are here.

Okay sweet. All right. Hi. Uh my name is Howard and uh this is Aleandro. We work together. Um and today my talk is going to be on formally verifying a ZKVM. Um for those of you um who may be new to the field, um I wanted to start by talking about what formal verification itself means and what it uh aims to achieve. Um behind every formal verification system starts with a formal verification expert like Alessandro. And um what the formal verification expert is trying to do is to construct using a theorem prover a model a representation a concept um of the system that is being studied and pursuing properties that you would like

to test for and check against um to give yourself strong mathematical guarantees of soundness. Now this can be applied in many different forms. Um I think many times you can break it down into two forms. Uh hardwarebased systems and softwarebased systems. The requirements can sometimes differ in terms of what you're trying to look for in each. Um but uh at the end goal is always the same. And for instance, in a hardwarebased system, you might be trying to check for the correctness of a flow of say a risk 5 chip um and one of its opcode sequence and the way that it processes um is being performed correctly. And you know that that that's kind of one example of of a form of verification in the hardware sense. On the software side of things, often times

you're trying to check for um some form of completeness or soundness about a piece of code um or a behavior of code. Um for instance, if you have a compiler and you want to write a new pass in your compiler, you want to make sure that under all circumstances or all inputs um um that uh this uh pass will behave in the expected um uh form or pattern there. And so this is kind of a way to really try and ma mathematicalize and formalize uh your notion of what you're building. So as I've mentioned, there's a correctness property here. This is what you're really testing for. Um and that property is is effectively what you're trying to evaluate on. Now based on what the theorem prover says you can

get one of two possible outputs. One could be a green check that says hey the this uh this proof of theorem is correct. But it's it's more nuanced than that. It's not just a simple green check. There's there's honestly much more to it. the um you you you want to really dive in and understand what it is that it checked and and to what level and to kind of what extent um the check was complete. Um but I think one thing that's worth noting here is that this type of a check this type of a guarantee is much stronger than many other techniques that you may have heard of. Uh some of you may have heard of for example fuzzing um where you run a run a fuzzer uh with and and you have it kind of uh give just a random set of inputs

uh random in random out and you let it run overnight or you let it ran run for a week and you know you you give yourself some level of assurance with fuzzers that um the system behaves as intended. However, what makes formal verification so much more powerful and why this proof becomes even more powerful is that you have a much higher assurance um than this type of fuzz testing. So you can now address cases that are really sampling for all types of integers or for all types of variables for all types of circumstances and that gives you a strong assurance. Um it can also be used to justify complex optimizations and also suggest new optimizations. So, for example, for those of you who have dabbled a bit in

formal verification, you may be aware that um if you're trying to formally verify um an R1CS circuit, um often times you might actually realize by running this that yes, my circuit is uh is constrained correctly, but I actually have over constrained and I can actually reduce some of my constraints and these models are actually quite useful with the eye and interpretation of of a formal verification expert to identify that. Now on the contrary let's say that the theorem prover errors out it fails. What do you do then? Well unlike unlike you know how many of the talks here on zk proofs have gone it's not just a simple false like it's not it's not just going

to come out and be like it it's a little more nuanced than that. Um you have to go through and actually parse and understand again with an expert why the proof itself is not working. and and this process of discovery is actually how you go to kind of remedy and find the bugs uh in the original implementation. Um you in the process of discovering this with a formal verification expert, you attempt to reveal and find new bugs. Um and so that that effectively is uh is an overview of how formal verification works as a system here. Now, myself and Alessandro and many of of our team members who are here today, we all work on a blockchain called Alo. And some of you have heard

of it, some of you haven't. Um, I thought it'd be useful um to talk about form of verification in the con context of a blockchain like Alo. Why? Because Alo is a ZKVM. And just to help paint the picture for you, um I often like to use this uh graph of programmability and privacy where you know Bitcoin is quite low on both. It's it's just a coin and it's it's pseudo anonymous, right? So it's not fully private. Ethereum said, "Let's take that idea and add some some programming to it." And so you ended up with high programmability. Zcash said, "Let's go the other direction and extend Bitcoin um to offer full privacy." So extending that pseudo anonymity into full anonymity. Um and now there's this upper right-hand quadrant of saying, well, what if you could achieve that full level of privacy but also have the

programmability of Ethereum, aka private smart contracts. That's the that's the holy grail. That's the kind of goal that that we wanted to build and achieve with Alio. And so this this graph is meant to illustrate that. Now based on what I just described, you can probably imagine that there is a myriad of potential risks in building a system like this because you are now building a general purpose VM uh that is being proven mathematically using zero knowledge proofs using uh circuits and constraints under the hood. And so you to to really give you the level of assurance that this is working and this works especially with privacy you want something like formal verification. And so to give you a sense of all the parts where things could go wrong this is an

illustration of the actual dev flow of the actual user flow from top to bottom. Um user comes provides some LEO code alongside it they provide some public and some private inputs. um that then gets operated on and run via dev tools specifically uh you know the program is compiled into AVM bite code um and you get out these public and private outputs and you get out this zero knowledge proof this proof of um an off-chain execution you've ran your code your smart contract code offchain and in addition your your your contract might say hey uh in order for me to finish I need to settle on chain and when you go to settle on chain there's some settlement logic that you need to finalize as well before it fully lands uh in in a block. And so this is kind of

every arrow that was illustrated here is a potential point of failure. And so we wanted to formally verify as much of this as possible. And yeah, more so once you've done all that, then you need to submit it to the blockchain, right? So the AVM by code on the left gets sent via a deployment transaction. It's like deploying your contract on any blockchain. Um and then over here you have the verify and the execute pieces. So you need to verify the proof of your offchain computations and to settle you have to run a small bit of code for settlement. Um and and that's that's this execute piece which again lands in a block.

So you may be wondering why apply formal verification to alo. Well, I've already started to prime you and give you some of the answers. Um, but to make it very concrete, bugs in blockchain software can lead to, for instance, the creation or destruction of currency. And as we all can agree, the soundness of your money minting system is pretty important. Uh, I see some thumbs up there. Um, but even more so, we're talking about a chain that actually is going to offer users privacy in their accounts on chain for the first time.

And so for their program privacy and for their program data, they may not want to make it available and revealed to everybody. And so a loss of data privacy or integrity would also be detrimental to a system like this. And for the cryptographers in the room, I think you can also come to understand that um a lot of teams, especially in this room, are working on new ZK circuits. There's new I I hear and see new circuits being built day in day out. And um under constrained bugs can be particularly pernicious. You may ask what are under constrained bugs? This is a bug where um you expected the adder to take in two

two variables x and y and spit out the value z uh being the sum of x and y, but maybe you forgot to think about overflow and underflow behaviors to make it safe. In that case, you would have under constrained because you didn't provide the necessary checks, the value checks and balance checks to reflect for the case of when that happens. And so these are the types of models that you know you you tend to run into and tend to get caught fairly quickly when you're using a formal verification uh method to to kind of formally prove the correctness of that circuit. So you know that is that is kind of what under constraint means. Now you can fool a verifier to accept a fake ZK proof then with that technique. You know if that if that

overflow bug exists. Um I could exploit that and then convince someone that I actually had all this money when I didn't have all this money. Uh that would be very bad. Um, but I think the bigger problem and as many of you know is that as an industry a lot of teams in ZK are moving fast and shipping fast and uh these are bugs that are very hard to test for and to make sure that you actually catch these bugs there's very few techniques that get you that strong level of insurance. We alluded to fuzzing but in reality formal verification is probably the most surefire way that we know of today to actually detect these types of issues here. And so formal verification can prevent that. And in order to demonstrate that, uh, I'd like to hand it over to Alessandro, uh, for him to

walk you through a few examples of how formal verification applies in Alio. I think you have a mic. Here's the clicker though. All right. Can you hear me? Yes. Good. So, uh, for verification can apply to, uh, different parts of the, uh, Alo ecosystem. Here's a notional flow, let's say, of data. you know, one writes an Alo application, uses development tools to build the transactions that include, you know, knowledge proofs, finalization code, etc. And that gets gets deployed to the Aloon blockchain. So, there's a lot of components here where you can apply for notification. One is to check uh application properties of of LEO programs. You know, for example, is the

program secure? Is it leaking information? Is it doing the right thing? Things like that. development tools they do compilation of chain execution the knowledge proof generation. So do they do that correctly? So do they preserve the semantics of the le application which is what the user is writing things the smart contracts in. Um and also in the blockchain itself there is a consensus layer to uh organize the transactions into blocks. uh there's the mechanics of zero knowledge proof verification onchain execution and so on and those you know for example for consensus we want to show livveness and safety properties uh for knowledge proof verification on chain execution we want to uh show correctness is it doing the

right thing you know what um so that that's where it applies so uh to date we have applied these techniques to some of the components and so initially we we worked on the Leo language we formalized its syntax and semant semantics. Uh it was for an early version. So we we need to update it but we know it was complete at the time and we also uh developed a tool to generate theorems um every time the compiler runs for just initial phases of the compilation. So like parsing and what you call canonicalization and we did find bugs in the parser in in that way. So that that was useful. Um later we we we moved to uh the zero knowledge circuits that Howard was describing. So what we did is

formalizations and verification of a number no good number of the operations of the circuits uh in the uh in our blockchain that implement operations and we did find both bugs and optimizations in the process. Uh more recently we worked on the consensus layer on the BFT Alo BFT protocol. We formalized the protocol uh verified uh main property which is blockchain nonforking and you know we are extending it towards other properties and we also found some bugs and some optimizations. Uh so let me give you some details about the last two the circuits and the BFT. This is a super simple example of a of a circuit which is uh in R1C because that's what

we use. Um it's what does it do? It's a division. you know the x and y are the inputs and outputs and c is the output it is the quotient if y is not zero otherwise it's an error so um for this we want to prove two properties for this kind of circuits one is soundness which says that every solution to the constraints corresponds to a non-erroneous computation and the other property the converse is completeness so for every non-erroneous computation uh there is a solution to the constraints So another super simple example of a circle that is actually wrong is the one for positive square root. If you write the circuit like that it's under

constraint. That's what our mentioned before which is a problem. So we we we try you know because it allows a negative root. So we we cannot prove soundness. It does not hold. And when we do the proof we we discover why. Oh yeah because there's another solution. Um incidentally completeness still still holds but you need both. Um now briefly the the the hopefully it gives you the flavor. The circuits are more complicated the ones that we did but this is a simple example. So uh the the consensus protocol here um it's there's a number of validators. Some are correct some are faulty. The red one is faulty.

They achieve consensus and our protocol starts from the the existing nar protocol which serves to uh partially order transactions into a DAG. If you can see the top parts of the green boxes, there are little DAGs. That's what they agree on. And then there's the Bullshark um protocol which locally linearizes the DAGs into blockchains. And that's the the lower part. You see the little blockchains there. But then we made some significant I mean the whole team Alio and Provable made significant extensions which was one is that the validators are dynamic. So they can change potentially at every block even though usually they don't but they could. Um also we use a stake and not just numbers of validators and then

there's also a phase of syncing when a validator comes up it has to sync and there's some no subtle issues there for correctness. So u what what we did um here is that we formalized the protocol as a label state transition system like an infinite state machine and we proved properties mostly in the form of invariance which say that you know the invariant holds initial state and is preserved in um in every state. Um the main thing we proved which involved quite a bit of work was to show that the blockchains never fork you know. So essentially if you have two correct validators they have the wrong copy of the blockchain. So sometimes they have the same blockchain that's fine that's

perfectly good. One may be a little ahead that's okay that can happen. Uh but they cannot be incompatibly ahead of each other. So they they they need to so that would be would be wrong. And so we proved that for every reachable state from initial state you will never end up in a state where they have forked. So blockchain is never that's the formula just if you're interested um more information there are some papers uh if you want to take a picture you can on my web page just look up my name and you'll see there and uh with that I will give the mic back to how to I think we're out of time I think as a

just finishing thought for those who are interested to give this a try uh there's the Leo playground it's playle-ang.org um obviously Alo is at alio.org and Provable, which is the Ali Labs company, is at provable.com. Go check out our Twitter as well. Um, but with that, I'm out of time. Thank you very much. It's good man. All right, so this was our final lightning talk for the session here. So, we now have a 30-minut break with two talks to follow. So, go grab a coffee, uh, use the restroom, and then we'll see you back here in 30 minutes to finish up the day.

[Music] Yeah. Yeah. [Applause] You hear [Applause] [Applause]

Yeah, it's like an internal never gets We make tweaks. [Applause] [Applause] question.

[Applause] You [Applause] never All [Applause]

[Applause] right. Nice. [Applause] All right. [Applause] [Applause]

We have a lot better. [Applause] [Applause] [Applause] Yeah.

[Applause] [Music] the program. You got 30 minutes. I'll

give you a But I always slower when I come. Would you like me to give you a 10 minutes? I'll give you 10. I'll be in the back and All right. All right, everybody. Let's find our seats. if you're out there in the break area, come on in and uh we'll get started here. Um, okay. So, this is our we're entering the last hour of the conference today and uh we have this first of what will be two sessions here

uh vibe coding ZK apps with uh Liatron ZK platform. So, with that uh please welcome our next speaker to the stage. [Applause] Right. I don't know which is the better hand to hold the mic and the uh um and the clicker. All right. I'm going to give like maybe 30 seconds for people to uh uh to come in.

Um I hear from Anna I have I'm humbled but I also honored that I have this slot where there are no other like going on on the side stage in the breakout stage in the breakout I have all of you uh to myself so um all of you have pen and paper it's going to be like heavy on math like you know get pumped on coffee um just kidding um all right so let me art. I'm the CEO and co-founder of uh uh Lihero. I also am an associate professor at Georgetown University currently on leave. This is some of the work that we

are doing at our company uh Lihero. Liatron is the new version of Lihero which was published last year in uh it security and privacy. It's essentially the same blueprint as the Lihero system that was published back in 2017. um except that it is memory efficient. It can run directly from from the browser. But first I want to walk back through sort of a biased uh view of history. So that's actually my dad. He's sitting on a punch card system while he was working at Tata Institute of Fundamental Research uh in Bombay. he was computing something on weather data uh at

TIFFR. He used to tell me that these punch card system you need a lot of discipline. You you write your program, you punch it in the card, you give it in the morning, you get the results in the evening, you don't know if it was right, wrong, you can't change it until the next day. And to me this um not to um you know not to it's similar to like Groth 16 and CIRCOM with trusted setups. It's some of the most used technology we have. But once you set up the circuit in your trusted setup, changing it is uh uh is heavy. My dad uh he taught me everything like you know he taught me programming and he passed away in co uh with CO in 2021. But the first machine I used was

uh the IBM PCXT machine. It really looked like that. You got to take a five and a quarter floppy disc with uh the operating system DOSs, plug it in, wait for it to boot. Uh actually the first programming language I learned was uh cobalt and I also learned basic uh um which is a programming language uh on this uh on this system and you know we all still you know there are many parts like the financial system as well as the government as I hear still use uh uh cobalt again just tracing through history you know we started off with punch cards then came cobalt and forotron which I want to say has actually survived through time quite a

it then we got you know the more popular which is I mean still popular the C C++ we got the Unix operating system PCs etc and then object-oriented programming I should also tell you like my dad taught me small talk which was one of the first object-oriented programming language which I think was invented in the uh in the 80s but then now you know Golang rust this is very popular and today I want to talk about the next evolution of this wipe coding. So what is wipe coding and I actually didn't know this uh until a few a few months back. Uh this is Aravan Narayan. He was my high school

classmate. He's a professor at Princeton University. Um he started out as a theoretician. Now he you know does a lot about AI uh demystifying what can cannot be done uh with with AI. And I saw this post he did on LinkedIn where he said he could code web apps in minutes. He could build an app for his uh uh for his kid to teach fractions etc. In fact, he even had the app linked on uh in the LinkedIn. And I went and I looked at it. It was it was a simple app. It was really really good. Then I heard of this term VIP coding which was apparently coined by Andre Karpathi. I have huge respect for him. come and ask me later like you know

in the industry. He said he could start coding like applications without touching the keyboard just talking to things talking to your LLM generating code then just deploying this you just forget that code even exists. So let me show you a video of me trying of the first apps that I did using uh this kind of vibe codec. Let me talk to you about the first

edition that I should say yes and once I did [Music] additional [Music] hours of the app. I did This does u you know addition modulo you know primes. Here is the simple sha generator. Uh it just generates the SHA

256 of any text that's typed uh in hex. Once you have a hash you can build Merkel trees. Here is a nice visualization of uh generating a Merkel tree on the fly. As you can see here um as I type the root gets updated. Furthermore, you also see the path from the leaf to the root uh that gets uh updated. I did all of this uh in claude. So I thought okay, why not try doing uh something in chat GPD. So here I'm doing another Merkel tree visualization. Again I give u the data elements and the leaves of a Merkel tree [Music] um and generate. Here is the Merkel tree

with this being the root. Uh I added an extra feature here where when I click a leaf uh it gives me the decommitment. If you recall this is what is needed when I want to prove to you that a certain element sits at the leaf of a merkele tree. I have to give you the siblings along the path from the leaf to the root and that gets displayed over here. This can become really a very easy teaching tool for anyone uh you know to generate these apps for every day for your lectures. Once I did Merkel trace the next what is used in uh Lihiro is pack secret sharing. Uh most of you would call this read Solomon encoding. You give the secrets, it pads with randomness because it needs to be secret

sharing. Generates the coefficient the evaluation and then I pick from the evaluation points outside of the domain used for the secrets and that becomes the encoded. That's it. And you know once I got going I was u uh it was just easy to build uh the next app. You haven't tried VIP coding. I will tell you like this isn't uh hard. I used to code a lot when I was in like you know high school a little bit like in uh in my undergrad of course uh but then for a long time I was a theoretician but then I got back to this it's like really empowering like they give you really a base for launching these apps and then you can just ask it to generate an app

and like you can deploy it on a GitHub page um like really in a matter of minutes once the first time the setup will take time but then after that it's uh um it's pretty uh it's pretty fast. So let me switch gear a little bit from VIP coding why we are here. We are here to do um to talk about zero knowledge proof systems. So I'm going to talk a little bit about what is knowledge. Now knowledge is a question as old as uh humanity and you know it's been pursued in philosophy under the branch of epistemology also neuroscience, psychology, economics or all of this care about knowledge. More recently I

want to say the last couple of decades um you want to capture knowledge for artificial intelligence or lack thereof for cryptography. I want to talk about the people who invented zero knowledge systems. um Sylvio Mikalli and Shafi Goldwaser they did win the Turing award for laying the foundations of modern cryptography but also for zero knowledge proofs and it's important that I mean to capture even the security definition of zero knowledge takes a lot of work and I have one slide this is probably the most technical slide um I have the the foundations of knowledge itself was

first done in something called probabilistic encryption to define encryption to define what knowledge an adversary gains from looking at a cipher text was there in these works and then of course it was refined in their work of zero knowledge proof systems and this is really the essence of what they did they did not defi they defined zero knowledge without actually defining it this is the best I can actually really tell you about this The way they capture knowledge is not that the data you have. It is about what you can feasibly compute from the data you have. And really feasibly compute has two things. You're bounded

by a computer or a supercomput or like you know uh tons of 4090 but you know you can execute this for bounded time and you have randomness. Really these are the things that you have and what you can gain from computation on data using these resources is knowledge. Things that you can't do in this is considered hidden from the adversary. So coming back to zero knowledge, it's about generating a proof to the verifier that it learns no additional knowledge beyond the input statement or the public inputs that you're giving to the verifier. And really what this means is that the

verifier can learn nothing more than what it can compute from this input statement that you give it. And I think this is important. I mean I am the biggest fan of zero knowledge proof systems. But you also have to understand what is really the privacy it gives. And especially when we want to deploy this in like privacy focused applications this definition in mind is important. For example, if I prove to you today that you know my you know I have a commitment of my salary etc. I prove to you that this is my salary is at most $100,000 and then a few days later I come and prove to you hey my salary is uh more than I don't know $99,000. Now really combining these two

proofs there was nothing to do even if you use the perfect zero knowledge system you all have a pretty accurate version of what my uh salary is. So you you need to know what privacy is guaranteed by zero knowledge proof system when you deploy it in the open. Okay, that's it with me preaching about zero knowledge. This is a little bit outdated version of the ZK landscape. Maybe you should look at ZK mesh. It has more the latest version, the latest list of all of these. Uh don't squint your eyes looking for your project. Even Lihiro is not listed over here. Um we have a lot.

We have a lot of effort, a lot of investment, a lot of protocols being developed in this landscape. But I kind of want to say that this promise of ZK for privacy is you know still a promise. It's still a niche. And here I have a list of reasons you may or may not accept this. Maybe we don't care about privacy. And I'm sure a lot of you have faced this running zero knowledge companies. You go talk to people. They're like, "Yes, I care about privacy, but that's not the first thing I'm going to do for my stable coin. That's not the first thing I'm going to do for my decks." The PMF, the real PMF is probably not yet uh identified. And Starks and Starkware have done a tremendous work in this

industry like bringing really zero knowledge to the masses and you know pretty honest like most of the implementations are Starks and you know um they are not zero knowledge more than I would say 90% of these things uh don't come to the formal definition of zero knowledge not that they are insecure they aren't but I want to say Starks themselves are not and there was a beautiful uh work and presentation by Olrich in ZK proof 7. They are really working hard. It's a lot of pain but they're working to make Starks uh ZK and maybe DSL is a barrier for adoption. We have all these languages CIRCOM, Noah, KO etc. Is it that we are not able to get developers in this space

like they have to there is this threshold of learning a new language? And the last point is also true. Most of the performant zero knowledge systems we have today requires heavy hardware. A lot of GPUs, a lot of memory. So is this what is stopping us from making you know ZK for privacy? So just going back to this and um take whatever I'm saying with a grain of salt. It's just like my view of these things. I look at R1CS and you know as like sort of punch card systems and CIRCOM like improving this to languages and you know KO doing the next generation and now we have

ZKVMs you know we can um take a rust program and uh be able to pro generate a zero knowledge proof of this uh uh of what this program is uh computing. And once you think right like I mean if I can do ZKVMs I should be able to do WIPE coding. I mean what is WIP coding? An LLM generating a code I should be able to plug it into one of these systems and and do it. And this is what I saw after I did all these VIP coding examples. I was like this is my obvious next step.

But before I go into showing how like I have a video of me wipe coding for u zero knowledge I want to talk a little bit about liatron system. So the liatron system as I mentioned to you at the beginning is it follows the liarero blueprint that was done in 2017 but it is the only memory efficient hashbased zero knowledge system today. I want to u like clarify or qualify what I mean by memory efficient. It means that like for example our we are a ZKVM with the underlying VM being web assembly. We want our prover system to use roughly the same memory if I had run the underlying web assembly program which would which would be like if you know

the web assembly semantics it would be the maximum stack height that it would need and the memory RAM that it uh uses and this is achieved by uh the liatron zero knowledge system. Ligatron is zero knowledge by default. I know I stressed this point, but there isn't a knob. It's not a snark. It's like it is a zk snark. And finally, you know, once we got this memory efficient version, we wanted the capability of people to build applications and deploy it anywhere.

Anyone should be able to run it from their cell phone, from their laptop. And we also wanted it to be scalable. Had we implemented our current version with CUDA, I'm sure we would have gotten more performance, but this is not going to be useful on a cell phone. So, we kind of restricted ourselves and said we are going to do this on web GPUs. So that anyone should be able to run it from their phone or from their laptop. And for that matter, even Raspberry Pies actually have uh GPUs today. And this uh was a really surprising announcement. Well, okay, I shouldn't say surprising, but you know, this was a announcement uh recently that Google adopted zero knowledge systems in

their wallet. And really what they're doing is you have these things called mobile drivers license that are issued in like 11 states in the in the United States and Europe is moving to the EU ID um similarly to uh offer credentials to uh their citizens. You can put these digital credentials, you can, you know, tie it to your cell phone and then you can prove to anyone thinks about your credentials in zero knowledge and really like you know the application we talk about going into a bar and saying that you were 18, you can literally do it with this project. What was nice is that the team behind building this Google wallet ZK you know tried different

system and they chose a combination of the Lihiro system and the GKR system to get something that would run from a phone. So uh this actually I mean they have tested this it runs in a couple of seconds. Uh it runs from an Android phone. I want to say that on our platform we'd be able to implement this and you'd be able to run it from a browser not just from Android but from uh from anywhere and they used the work that was published in 2017. Most of their work was based on it. They are not quite memory efficient but the circuit are small enough that they would run from uh a small device. But our system we would be able to prove much more

complex statements about your identity. maybe multiple identities through our platform. All right, so enough of all of this. Let's wipe code with Liatron. I have maybe a five minute video. I apologize. Next time maybe I'll try to insist on doing a live demo, but uh bear with me with this uh video. Let's wipe code with Lihero. I want to walk you through our platform just to see how you can uh run applications from our platform. Recall that on our platform you can uh build and deploy completely from within the browser. No tedious GitHub cloning etc.

You can write your C program compile uh deploy. Go to platform.ligatron.com. Sign in with your Google credentials. And now you will enter a marketplace where people have developed some applications. I'm going to pick one of them. Edit distance. You can look at the source code to do uh edit distance computation. Uh this program is showing that the edit distance between the first two strings are small where the first one is private. It generate it generated the proof. Now you can send this proof uh verify this proof on this browser on another device. That's it. I'm going to show you later how to create projects etc. But let's start coding. Here's Chad

GPD. I'm going to give it some basic instructions on some function headers, how to do SHA, how to do assertions, etc. And then I'll be ready to give its uh um uh instructions to generate the first program we want to uh prove in zero knowledge. All right, here's my instruction. Write a C program that takes in three input strings from command line. The second and third inputs are public. The program computes the edit distance between the first two strings and asserts the distance is less than 10. It checks if the shot 256 of the first input is the third

input. All right. Now let's wait for it to uh create a program. All right, here it's generating the code for edit distance. Checking the hash and done. Now I'm going to copy this. Let's go to projects. I'm going to create a new project. I'm going to call it edit distance ybing. I've copied the program. Copy it

down here. Compile. It should generate a web assembly file which is our intermediate representation. We are a ZKVM. And now I need to give it uh three inputs. um you know I'm going to give it um three uh uh I'm going to mark the first one as private just like before uh I need the sha of this so I'm just going to use uh online sha generator to get the sha I need to mark that the third one is in hexadimal and

prove this circuit has about 20 million kits. It has generated it in 6 seconds. Done. So let's do another program. Just one more. write a C program that takes two integers n and m as input from command line where the second input is public. It asserts that the nth Fibonacci number is m where Fibonacci is computed using an iterative algorithm. Right? Let's see.

I'm going to copy this program. Let's go here. Uh we can use the same uh uh codebase. I'm just going to do that. I'm going to uh copy the new one. I'm going to hit compile. And now this new program has only two inputs. So it's going to be 20. I think the 20th Fibonacci number is 6765. Uh I need to mention that these two are integers and let's hit prove. That's it. And let me try a wrong number and see what happens. I get the answer is false. you know you need to

make sure that the zero knowledge is you can go to a marketplace many of them actually I did you know try to generate it using um using chat GPD battleship being one of them you know it it checks if the placement of your ships uh is correct as well as whether it's a hit or a miss uh I've also tried a little bit with um some um uh reg x thanks all right thanks everyone for your patience to to you know for having watched watch this. Um, I want to say that this is really within the realm of what we can do. We can make this a co-pilot where you could just directly give instructions uh uh to our platform to generate this code. Uh I think it's

not hard to see uh we could even do the Google wallet identity thing by saying hey you need to parse an MDL which is an ISO format and verify an ECDSA signature and check that my age is greater than 18. This should be really I mean possible to do it on our platform. The battleship is another example. I couldn't uh get that on the video but this is I want to tell you this is what I did with battleship. I went first I bcoded I generated an app to play battleship. I'm probably dating myself.

Many of you probably didn't play battleship but you know I could create an app to play battleship you know by just opening two browser pages and doing this like in a matter of 20 25 minutes. And I also wipe coded to generate the predicate to verify the instructions. Now you could play battleship peer-to-peer over the internet where you know each person commits to their um commits to their inputs their input plates and then they cannot lie whether they it's a hit or a miss. And I didn't integrate them together but I have both of these codes separately. All right. So a little bit our mission, we want to make ZK useful, usable, all running on your

device. Just a word, we are trying to solve, you know, privacy, compliance, decentralization. We're trying to build tools where people can prove compliance themselves. We talk about self-s sovereign privacy. What we want to do is self- sovereign compliance. We're going to do this by, you know, ZK Validiums offer a lightweight form of privacy. When you have service provider launch their own networks and you can get compliance by having these predicates on our marketplace where people could prove for different jurisdictions what they want to establish for their own uh you know respective state jurisdictions, countries what kind of compliance they want to do. So we imagine that you know eventually we'd be able to just have

like a marketplace for all these compliance conditions that could be integrated directly into your network. you want to test, you can go to our platform. There is a speed test you can try out. If you have an Apple machine, you have to web GPU is still like in in the trial phase. You got to go and set the feature flag for web GPU. So this is what I want to say at ET Denver. I have this I'm going to modify the slide. It's not the same slide. it. I talked about building you know in the browser building in any language but today I want to say vibe anywhere like you don't need to even think forget that code even exists. Thank you.

Awesome. Thanks. Right on top. Awesome. Thank you very much. And unfortunately we don't have time for questions but I did learn that it's Lao. Thanks. So that's a good that's a good actually clarification. So thank you and thank you for the talk. It's wonderful talk. We are on our last talk of the day. I've been promised by the speaker that this talk will be the most spectacular talk of the day. Um, no, in all seriousness, it does build nicely on this last talk here talking about some of the identity use cases uh for ZK. So, with that, please uh welcome Merik of Cello uh to the stage. He's going to talk about their work with self-protocol.

[Applause] Thank you. Amazing. Um, can I have the clicker? You can click. I can just point at you whenever we need to do the next slide. Um, well, it's wonderful being here. It's a real honor actually for me. This is um where I did my undergrad. Uh, and so I used to walk these halls uh halls back in the day. So, it's a real uh nice nostalgic moment for me. Uh, I think I used to play volleyball in the basement of this very building. Um but uh yeah, today we're going to be talking about self protocol uh and the work that we've been doing to bring uh ZK Passport um um technology to production uh so that all

of you uh can now start playing around with it. It's it's really exciting. Uh if you like this talk, you can find me at on Twitter. Um I'll stick around afterwards for questions, but you can always DM me if you want. Uh and then uh you can also find the protocol at at selfp protocol. Okay. And so yes, I did want to make this fun for you and make this the best talk of the day. Uh and so I threw in a little game. Um since again, this is the last talk of the day. Uh you know, you guys are probably all low energy. Uh I wanted to find a way to make this interactive and you know get you guys a little bit more uh excited as we go out of this amazing amazing conference. So the game is guest a

country. Um and so the way it works is there's going to be shapes of countries on my slides at random places. If you see a country that you recognize, yell at the name. Um you don't have to wait for me to look at you. Just yell out the name. We're going to make this a competition. The folks on the left are going to be competing against the folks on the right on the right. Uh and uh and this is not random. Uh these countries are all countries supported by self-protocol. And so this will be educational as well. So I'm going to warm you guys up uh with a really easy country. I think left had that. So one point to the left, zero still on the

right. Oh, I think right got you guys there. Okay. One, one. I think left had you. So, 2-1 uh for for the left team. Okay. So, that's just to warm up. So, now we're going to get into the talk and if you see any any shapes that you like or recognize, just yell out the names. Uh France, by the way, is where a lot of um the gigab brains behind self-protocol are from. Um, and so we got some really strong uh French founders on this project. Okay, so now that you guys are all warmed up, you guys can now also

yell out some of the big unsolved problems in crypto today. What do you guys think? What do we need to solve still? What hasn't been solved? Privacy is a good one. UX is a good one. Any other big ones? Product market fit. These are all really good ones. Uh, anything else? Data availability. I feel like we're doing better with that. Identity. Yes. User applications. Um, so one one that I think is is very big. Uh, and I'm not hearing any country names.

Okay. Wow. 3-1 guys. Folks on the right need to step it up. Um, it's kind of ironic, right? Bitcoin started, you know, off by solving this very problem if you burn a lot of electricity, but we still to this day haven't really solved this in a way that really is satisfactory. And so I would argue that this is still a very, very big problem. Our next one, are you a bad actor? Uh I feel like this community, the Zika community is probably more attuned to this than maybe all of crypto. Um just by virtue of how much uh bad actors seem to like um you know privacy protocols and other things that ZK uh folks work on. You know this is a real problem in our space. Um, you know,

obviously the upbit hack was just a really terrible reminder of just how um big of a problem it is. And we don't have a good solution at the smart contract level for this particular problem. Certainly not in a decentralized way. And as if that weren't enough, now we have to worry about this problem, right? Like who would have thought you know five years ago we'd be worrying about whether we're actually chatting with humans or AI agents you know now with agents beating the touring test. This is increasingly a big problem certainly for humans. So we don't give AI agents a UBI in the future. Um but even for AI agents if they're communicating with us they probably want to know if they're communicating with a human or an agent. And so this will

increasingly be just a really big problem. And you know I think decentralized identity can solve these problems. Um but you know it still to this day remains inaccessible. And if you look at the hardware solutions like world you know it's hard to scale that to everyone. If you look at the web of trust solutions they're very gameable. Uh and then you know there's folks wrapping you know just centralized KYC. Um but sadly you know as we know that's not very privacy preserving. And so we need something better.

And oh, Greece. No, this is not Greece. It's not Russia. It's a very small country. It's a small country that's not Estonia. There's a very big conference that happens there every year in September. Okay, I'm gonna move on, but you guys can keep guessing. Yes. [Applause] Okay, the left side continues to dominate. I think we're going to have to like reset at some point just to make this more competitive again. How about we do front and back?

Maybe that's what we'll do going forward. Zero zero. Anyway, and so, you know, this has been a big problem to this date. Um, but I'm here to tell you that, you know, these are now actual solved problems. And so, self, we we launched it at ETH Denver um just a few months ago and and it really is designed to to address these issues. It can help you with civil resistance. It can help you with seeing if folks are bad actors and it can certainly help you with knowing if you're um a human or not. And it came out of a a collaboration that ended up with a merger between the open passport team and self labs. Self labs spun out of the cell foundation uh where um I've been involved with for the last

um kind of five six years. Um and once again, yeah, we we launched it um very recently at ETH Denver and critically we launched it at a production level. And so this is fully audited by ZK security. I don't know if David Wong is in the house right now, but he and his team did a wonderful job uh getting this uh audited in time for the big launch. Uh and it's available now on iOS and Android. Again, ready for you to use today. And the way it works is, you know, leveraging what I would argue is the most trusted meat space at the station of who you are, and that is of course your

passport. Turkey is right. Looks like back is now in the lead. Um, and so how many people here are aware that, you know, passports nowadays have these little microchips in them that have these kind of the ones that have this little biometric logo over here with a little u gold rectangle and circle. Hands up if you know that there's a chip in there. Okay, most of you do. That's amazing. Um, that's pretty exciting because that chip makes this machine readable and it's readable by your mobile phone.

And of course on top of that passports are you know difficult to obtain. Um typically you know most people only have one passport certainly one passport per issuing country. Uh people tend to store them pretty securely right you need to travel with them and so you keep them safe when you're not using them. So they are perfect IDs to bring uh onchain. Uh and because of this biometric chip in them um you know there's some really nice cryptography in there. Um and so basically your passport data uh that you see on your front page of your passport that is of course in that microchip available and readable over NFC but more than that it is cryptographically signed uh by your issuing country through a

certificate authority chain and so it's signed by this document signing certificate which in turn is signed by this country signing uh certificate authority. uh each country maintains roughly two of these country uhwide authorities. Uh and so if you have you know on the order you know less than 400 um certificates you can verify the validity of any passport in the world. And this is of course useful uh for countries you know as they let people into their countries to ensure that you haven't forged a passport. This is why they created this so that you can really cut down on forgeries. But it turns out that it's useful for for other use cases

as well. Um and and that's exactly what we have done is try to bring these other use cases to the to the forefront. And what's really interesting about this when you combine it with with blockchains is you can actually now prove that you have a valid passport without a counterparty. Right? Typically when you do KYC you are giving your ID to someone who is looking at it going okay it doesn't look forged it looks like the same person okay I believe that this is uh who you are uh and you're basically getting an attestation from that third party so you're always interacting with a third party that means that if they ever get hacked your

ID might be leaked a lot of the a lot of folks who had to KYC for airdrops uh there were a few prominent KYC companies that got hacked um And you know, obviously that is a real shame. Um, and so what if we didn't have to have third parties, right? Wouldn't that be better? What if we just verified the certificate authority chain uh on a blockchain? Who would prefer that? Okay, a lot of you are raising your hand. But it's a trick question because if we were to do that, you'd be revealing your personal data to everyone on chain. So what if we did that in zero knowledge instead? Um, also on chain, right? That is effectively what we're doing at self and it's really exciting because it means that you can prove that

you have a valid passport without a counterparty and better than that you can also disclose information about yourself um to other third parties. And so say that um you know you've onboarded into self and there's a third party that wants to know that you're over the age of 18. Uh you can prove that in zero knowledge uh using self-protocol. Um you can also prove that you're from that you have a valid passport that you're from a specific country that you're not from a set of countries. Uh a lot of the um dating sites that we're talking to are actually interested in proving that you're above a certain age. So not just below a certain age. Uh you can also and this is

where the um proving that you're not a bad actor comes in. You can also prove in zero knowledge that you are not on the OFAC list. So without revealing your name, without revealing your birthday or really anything about yourself, you can prove with these subsequent disclosure proofs that you're not on the effect list. And that's pretty exciting. Pardon? Czech Republic is right. Technically Czecha now, but I'll allow it. Uh, okay. I feel like the the back continues to dominate.

Um and so on top of proving these um disclosure proofs that we call them, you can also associate these proofs with a wallet address. And so you can create you can use a wallet address as one of your public inputs. And so that you can prove that again, you know, this address is associated with a person that isn't on the OFAC list or this address is um associated with a person that is over the age of 18. Okay, so I think I've given you a nice overview of what we're doing, but what does it look like? What's the what's the experience? You can definitely check it out by just installing the app. But if you're curious, you know, this is what the onboarding flow looks like. The first

step is to scan the uh front page of your passport. We need to do this to be able to decrypt the data on that microchip. Uh once you do the NFC scanning, uh once you've done the scanning of the front page, you you're ready to NFC read. You typically have to move your phone around a little bit to find where the NFC chip is in the passport. And as soon as you've done that, then then we're off to the races. We can start generating this registration uh ZK proof. uh we do it actually in a very reasonable amount of time. It's you know under order of 15 to 30 seconds and uh and then you're done.

You're registered. You're onboarded onto the application. You can start doing disclosure proofs to third parties. And so what's going on under the hood? Um you know once you've scanned that passport uh again with your phone uh then you have your you know your data that's available um you know on your passport and we need to one create a a proof that proves the authenticity of that data and so again we want to verify those signatures going up that certificate authority chain. Once we get to the top, uh we then do a Merkel improve inclusion proof that proves that this specific uh country

um certificate authority is inside our Merkel tree of um certificates uh with the root being onchain. And so we verify that you have again this valid chain uh going up to the certificate authority. Uh and then we also calculate a uh nullifier that's deterministically um derived from your passport data. Uh and and then we also calculate a commitment that is uh derived from both your passport data and a user uh generated secret. And so the ZKP first proves that you have a valid passport. Nullifier is used to prove that you haven't

registered before. And then the commitment you insert into a Merkel tree so that you can later do these disclosure proofs. And what's important here is that this uh commitment is derived not just from the passport data but also from a user supplied um secret. And the reason for that is we want you to have full privacy um from your issuing country, but also from any country that scans your passport as you're entering uh through border security. Uh we want them not to be able to quickly see what you're actually using self for. Uh and and the way we do that is by requiring that you you add some more entropy. You create

this this secret. And so once you've onboarded, you can now do these disclosure proofs. And this is what the flow looks like there. We start by pressing that button on the bottom. Um, DAPs request disclosure proofs using a QR code which you scan. Uh, the app shows you what the app is asking of you. In this case, it only asks you uh if you're over 18, if you're not on the OFAC list, but um, and so it's not very sensitive. Uh but if for example an application asks for all of your information, your full name, your birthday, everything, then we can pop up a little warning that says that this is asking you for something pretty sensitive. And if you're okay with

disclosing this with this third party, uh you either do face ID or put in your PIN and then we create that that ZKP. Uh and this ZKP is relatively easy to do uh because um you know that tree that we talked about, we're using Poseidon hashes. um to to make um make doing that Merkel inclusion proof easy. Um and so the way that this works is we we generate that um inclusion proof uh and then we also prove whatever statement you're trying to disclose. So for example, that you're over some age uh or that you're not on the OFAC list. The OFAC list is interesting. We're actually doing a Merkel exclusion proof uh over three Merkel trees. If you're at all

interested, come come talk to me later. I can talk share more about how we're doing that. Um but um um because again we're we're using Poseidon for all of these hashes. This is all very very efficient. Uh and then there's also a nullifier uh per DAP uh that's requesting uh these disclosures. And if you look here that nullifier is not derived from your passport data. And so the idea here is again we we are able to anonymize these disclosures even from your issuing uh country and even from any uh anybody who you know steals your passport and and scans the the passport data. Um and so that's very very

important. Cool. And so how does it all come together? How does it all work? Um this is kind of the high level architecture. Uh your passport's of course read by your phone. Your phone is communicating with um either the Apple key store uh that's now stored in iCloud or with kind of the application specific part of Google Drive where you can store application specific state. And so that's where we back up the secret that we generate for you so that even if you lose your phone, you can still continue to use self and restore uh the application. And then of course um probably one question that many of you might be asking about is where do we generate these proofs? Uh it would have been nice to generate these proofs uh on

the phone. Um but you know we've been working on this for a while and we started doing everything with the growth 16 and circom and so these um zks are sadly a little too big to run on uh mobile phones using kind of that particular proving system and so we offload the proving to a TE. So the TE is only really an accelerator. It's not required for soundness of the protocol. You don't even need to generate the proofs using the TE. You can generate them however you want. But the mobile application that we've developed uh uses a TE only if it's running an image that we consider safe one that deletes your passport data as soon as the proof has been generated. So even if the TE is

compromised um the soundness of the overall system is not compromised and then the TE uh can either share this proof directly with the third party DAP or have it be verified directly on chain. uh if it's verified on chain that happens on Cell. Cell recently transitioned to becoming an L2. Uh and so we're working to have these proofs basically be uh readable by the whole Ethereum ecosystem fully trustlessly um using native bridges uh over time.

And so this is the the kind of high level uh architecture. Uh and yeah, this is what allows us to basically generate these proofs very very quickly even though the proving keys um you know are quite large and require a lot of memory. By the way, there was a country back here that nobody guessed. What's going on? This country is next to that. Say that again. Poland is right. Are you front or back? Front. You're definitely front.

Okay, more points to the I think it's like 2-1 now. So, front can can get back in the running if they guess the next one. Okay. So, just to wrap it up, um you know, I thought it might be nice to share some learnings um about this project. you know bringing anything into production is you know a sizable effort. Uh it took took a big team um you know over over a year year and a bit year and a half uh to do this. Um and you know I think one of the biggest things for us is that you know picking a proving system you know

continued to be a challenge. You know, there's obviously a lot of excitement about a lot of new proving systems, but you know, we u were a protocol that unlike many protocols out there, you know, actually cared about zero knowledge. Um, and so the ZK part of um ZK Snarks was really important for us. Uh, and because we wanted to bring this into production quickly and and have it be used by a lot of people quickly, uh, lindiness for the proving system really mattered. We wanted it to be, you know, robust and and and um and time tested. And so, uh that's the reason why we picked um you know, CIRCOM and GR 16. Um and I think we're happy that we did because we also are the

first uh ZK Passport protocol to to launch and to be production ready. Uh and and so we're pretty excited about that. Uh one thing though that has made our lives more difficult is is iterating. So, one of the really weird things about these passports is that there's no standard for how these countries are um creating these certificate authority chains. Um there's just an insane amount of hashing functions and signature schemes that are permissible. Uh and every country seemingly is picking uh their own combination of these. So, we've got RSA, we've got ECDSA. Uh obviously the ECD DSA stuff has made you know our proving

keys really big and our memory requirements really large. Some countries use both. Some countries use different signature schemes at different levels of going up this certificate authority chain. And none of this is really well documented anywhere. Uh and so we've been discovering a lot of this just by having people scan their passports and and seeing oh there's a new combination that we haven't seen. And so we have to uh deploy a new circuit, do a new ceremony and get it out quickly uh so that we can then inform that user to come back and and say that everything works again. And so we've been doing this now, you know, for a while and we're getting to the point where we're encountering these things less and less, but certainly, you know, having to do a ceremony after each new

permutation of signature schemes was certainly a little challenging. Um proving keys of course still suck. uh 5 GB is a lot certainly too too much for um bringing onto mobile devices and so we're excited about being able to get rid of that over time with new proving systems. Um but you know again because we are running in a TE it's manageable for us for now. Um and then you know the ceremony tools you know back when uh we launched Plumo way back in the day for for Cello uh Plumo also had um a massive proven key and insane amount of circuits and um you know there was no ceremony tool that

could handle it. So we had to build our own. This time around we said okay let's try potion uh take something off the shelf but you know we broke it very very quickly uh and then had to spend a good amount of time unbreaking it for our needs and so I think you know a lot of the infrastructure and tooling is still uh not where we would hope it would be for you know launching production grade applications quickly. And then this is interesting. This is just a total coincidence um that you know I'm talking about this after the last speaker. Um but at least for our needs when we were onboarding new new folks and trying to get them up to speed quickly and encouraging them to

play around with LLMs uh certainly for our code it was um a little difficult to uh for the LMS to be that useful. They were hallucinating way too much. You know, I think we could as a field probably work to create some MCPs that create give these LLMs way more context to be well well way better. Uh because back when we were using them, they weren't good. So it was really interesting seeing the last talk. I think that's really timely and I think it'll be probably good to bring more and more developers into this field. Um so that's mostly it. I just wanted to end with a with a short plug.

I heard Chile, but I don't know who said it first over here. Okay, front. Wait, is it 22? Back is claiming they got it, though. So, they're even high-fiving. So, I don't know. I didn't quite I didn't quite catch that, but let's let's make it front so that we're even. Um, and if there's one more after this, uh, we can see who wins. Um but yeah, you know, we have a developer SDK. It's available to play around with now. Again, this is all audited production ready code that's out there. And people have started building with this and integrating into their protocols. You don't have to be a web 3 protocol. You can do this even with as a web 2

company. Uh, and so if you have a use case for defending against civil attacks or maybe preventing bad actors from using your protocol on chain, you know, being able to know for sure that someone's not on the OFAC list is pretty pretty useful, especially if you're building privacy protocols. Uh, maybe you want to verify that someone is in fact an actual human. Uh, then this can work really well for you. Uh, recovering multi-IG wallets is a very very frequently discussed um, use case for uh, ZK Passport Tech. Uh, but there's also fun kind of silly ones as well. Um, say you wanted to launch a memecoin that, you know, gives out tokens to people who have a certain name. Maybe you want to do a Bobcoin. Maybe you want

to disperse tokens on people's birthdays. Maybe you want to give them out based on people's hair color. Um, all of that is in your passport and you can actually create ZKPs that disclose this without disclosing anything else uh with self really, really easily. So, anything that you can think of pretty much um you know that you want to have disclosed from your passport data uh self-supports uh and so would encourage you to play around with it. Uh so yeah, that's everything. Thank you so [Applause] much. Uh we've got time for a couple questions here and we're at the end of the day so we can we can take two or three questions.

I think my big question here is does anyone do people need to scan their eyes to use your product? And if not, why would you choose not to do that? Yes. So, you do not have to scan your iris um or yeah, build a 3D model of your iris uh to use this protocol. Um yeah, I mean I think all jokes aside, I mean the world team is doing something interesting, but I think realistically, you know, by having this hardware component component, it's just going to be much harder to scale to billions and billions of people. We're currently in the process of adding Adhar support in India, uh the EU ID support uh in the

EU. Uh once we do that with biometric passports, we're going to cover uh three billion people uh that will have an ID that they could use with self. Um I don't think there's any other protocol that will get to being able to prove civil resistance uh for 3 billion people uh in a in a privacy preserving kind of decentralized way quicker than us. I think I think it's going to be the best way to reach that number of people. So, if you want to, I don't know, share your token with up to three billion people, um, self is going to be the best way to do that.

Um, hi. Um, great presentation by the way. Um, uh, my question is, uh, related to how about people that don't have passport? So, how you achieve that? For example, I came from um uh I I live in Argentina and came from Uruguay and Uruguay a lot of people maybe 12% of population have passport and maybe it's lesser. So that's my first stuff and the other one uh the SDK is very cool. I just Thank you. Yeah.

Yeah. So, we're prioritizing, you know, ID formats that allow you to prove in zero knowledge and trustlessly that you have that valid ID. Um, and so that's why again we're starting with biometric passports and we're actively now integrating ADAR support. So, that's there's over a billion people in India that have ADAR IDs. And then the EU ID actually has the same biometric logo on the card itself and has an NFC chip in there. And so, you can use that. Um, and so across those three ID types, again, that's three billion people out of the roughly 8 billion people that will be covered. Um, but you're right, you know, we want to get to all 8 billion. Um, and so we're looking at different ways uh to do that. We're uh talking to some web of

trust folks. Actually, my co-founder at Celos invented IGN trust, which is a uh decentralized reputation protocol. I can trust is gameable unless you have a really solid foundation of pre-trusted peers. And so if you have, for example, three billion pre-trusted peers in a protocol where there's 8 billion people, uh then actually it becomes much much harder to to potentially gain that. And so that's one interesting uh avenue that we're exploring um with kind of the Karma 3 Labs folks. Uh and um and then finally, you know, there are some customers that are coming to us and they're asking us, can you ZK P wrap some existing KYC

um kind of centralized um process and so we're looking at that. I'm not sure how we feel about it because there are some trade-offs of course, but if the market is pushing us to offer that as well as this, then then maybe we'll do that. We'll see. um which companies support the use of the app right now? Yeah, so Talent Protocol launched uh like a few weeks ago, maybe a month ago. Um and there's a few other smaller ones that I'm forgetting the names of right now, but we're actively uh talking to some very very big web 3 projects and some very reputable well-known web 2 companies uh some of which are actively developing against

the SDK today. And so, um, yeah, expect a lot more, uh, exciting partners being announced soon. Are you Yep. Uh, is there a way to mark passports as stolen or deactivate them before expiration date? Yes. Um, under this whole um system, countries do share revocation lists. Um, so that if passports are uh stolen, you can't reuse that data. uh or if worst case one of the certificate authorities gets stolen uh either the document signing one or even the country issued one then you know it'd be nice to be able to revoke those and so there are uh ways to to do

that um not every country shares these lists not every country shares them publicly sometimes they only share them privately amongst each other uh and so we are working on on doing more with those lists um for countries that that we can get access to Um, are you taking advantage of the APDU or the challenge response chips in any way in the mobile phones uh in some more modern passport implementations? Oh, you're talking about active authentication? Yeah. So some passports, some countries uh have private keys in these chips that you can use through like a challenge and response mechanism to prove that the data that you're

pulling from this NFC chip is in fact not cloned. Uh and so we are looking at at that. The challenge is that for a lot of countries uh where you know our maybe our initial users will be coming from those countries don't issue these passports and so it's a bit of a shame. Um but increasingly you know this will probably be useful in the future. So yeah we're definitely looking at that. Two more questions. So you mentioned that if the tea is compromised you just you don't lose uh soundness. So I'm wondering like what's the bad side of that and if there's no bad side why you are using tea in the first place and there's like a one yes or no question by offac do you mean like citizens of

certain countries or like a list of addresses? Yeah. So for uh OFAC uh screening what I mean is um the US Treasury shares a list of sanctioned entities and individuals where they give names, birthdays, uh passport numbers and and all of these. And so we are actually looking specifically that you are not on that list as an individual. Um so that's what we mean by by um making sure you're not on the OFAC list. And then your first question, remind me again what it was. So if the T is compromised, what's the bad side? Yeah. So if the T is compromised, then someone could see the passport data that's being used to generate these proofs. So they might be able to steal someone's passport data.

Uh but they wouldn't be able to do uh much beyond that. All right. I promised the last one would be a banger and sure enough, Merrick delivered. Thank you very much. Let's give him another hand. Thank you. And uh welcome Anna back. She's going to close us out here. Yeah. Wow. Folks, thank you for coming through for ZKS Summit 13. How are you all feeling at the end of the day? You feeling good? Did you learn a lot? So, we we learned something. I have to add a small correction to the uh intro slides. After we did our intro, we had described what was it? GKR as having

come out in 2015. the brother of the R in GKR texted Nico to say false. It was from 2008. So, I felt like I should share that here. Um, he had been watching on the live stream and was just like, "Nope." Um, if you did find anything, I don't know, else to correct, do let us know because we're always evolving these things. Yeah. And I just want to say a big thank you for everyone coming out to Toronto. This is only the second time we've done this event in North America. Uh the first time was in San Francisco back in 2019. Um so it's quite a milestone and also great to be in this city in this school. Uh Merrick, you said you went here and it turned out

we went here around the same time hilariously. So it's very cool to be back. Thank you everyone. Thank you so much. Yeah. And I think just the last thing is there's still some swag. I very much encourage you to grab some if you have not yet. Um, I don't think we're going to be leaving it at the venue, so it's really for you to take. Great. And I guess see you in the ne at the next one. Bye. [Applause]