ZK Summit 12 - LIVESTREAM

Transcript

like I guess a year and a half ago we loved doing the ZK Summit 9 here and so we decided to host it here once again um I want to quickly introduce myself my name is Anna I'm the host of a show called the zero knowledge podcast I'm a co-creator of a project called ZK hack and I'm a co-founder of a company called zkv I'm just laying these out because these are three different companies a lot of people mix them up but they are distinct teams uh distinct orgs distinct business models a little brief on what they are ZK podcast is a podcast has anyone listened to the ZK podcast maybe yeah uh ZK hack is a Learning Hub is anyone in the ZK hack

Discord we have some people ZK hack also produces ZK mesh it does a bunch of hackathons and then zkv is a validator running on over 12 networks um we actually have like zkv also does like industry reports outside you can actually pick up the state of ZK report which is a quarterly report that zkv produces every quarter so throughout this presentation I'll be mentioning some of the initiatives of these projects so that's why I wanted to introduce okay so ZK ZK Summit specifically is produced by the Zer knowledge podcast and we currently have 342 episodes in counting which is kind of cool uh this is the team behind the

podcast if you're not familiar it's Rachel Henrik myself Tanya and yonas and we have our wonderful co-hosts Kobe tun GMO and Nico and Nico will actually be hosting this stage with Tanya today I do this every time I basically um we calculate kind of like what are the top listen to episodes and almost every time I do this there's a new episode or two who join the list so this time it was returned to MPC with Nigel smart and very new the gr 16 IVC informal verific ation episode with Yen Scot made the list for this Edition uh we have a YouTube channel this is where you can find the podcast although the podcast has no video it's

just like a a like static screen but we all videos for this event as well as some other videos related to the ecosystem can be found there we also have a jobs board uh actually for this event we have a lot of our sponsors who've added new jobs to the jobs board so I really recommend checking it out if you're looking for your next opportunity also if you're a team looking for good talent we've heard like stories of people hiring amazing people we're actually trying to collect testimonials so also if you're a team who's hired through the jobs board come find me later because we'd love to talk to you this is the website you can find all those links from the website this is our Twitter we're going to be using a quick note about the podcast and I made the

announcement earlier this week um I'm taking a short break from the show starting starting October 16th I've been running a weekly show for seven years or almost seven years which is kind of crazy and I want to take a pause probably not full pause because I have a few ideas for a few select shows I want to release in the next few months but we are going to take a little break um the reason I mentioned this is that we have another series I kind of want to promote ZK hack has recently dropped ZK whiteboard session season 2 and while I'm taking a break from the show we're going to be releasing ZK ZK whiteboard sessions every two weeks for the next three months has anyone seen the ZK

whiteboard session season 1 great has anyone seen the first module of season two just oh wow just a few people okay so go check it out uh the hosts for this Edition is Nico and Tracy and the first module is called what is zero knowledge like actually we thought that it would be good to actually def it properly in the series so do go check that out all right now a little bit about the event so ZK Summit we've been doing this since March 2018 the event has been hosted in Berlin San Francisco it's been online it's been in Amsterdam Lisbon London Athens and now Lisbon again and this is a spot where we get to hear

about cuttingedge tech and honestly there's been like uh presentations on the on these stages of systems that maybe we didn't know it at the time but they went on to become standards to become really really important so it's great to be here with all of you to hear yeah about the latest Cutting Edge research here's a few picks from previous editions we have ZK 6 8 4 3 11 11 uh 10 2 7 8 and nine was actually here so this is from this stage yeah and any more info you need you can

find over at ZK summit.com you are currently at the Lisbon Congress Center one note if you're staying around here I very much recommend visiting the Lisbon City Center it's to me one of the most beautiful cities in the world and I think even though this area has some cool stuff it has a beautiful view of the bridge really check out the center but yeah we're very excited to be back here for the stages we have four tracks today we have a main stage side stage breakout and workshop we also have the co-working upstairs and a sponsor area that you've already walked through I think this map actually exists out in the hall but just to go over it we're

currently in the main stage maybe just to note the workshop room is a little bit harder to find if you go to the info desk there's a little hallway behind it that's how you get to the workshop room and it's only got 20 seats so if you really want to see a workshop be sure to get there early I think in the past we let people kind of pack in but this time we're going to cap it so if there's something you really want to catch make sure you get there early upstairs we have the side stage the breakout room as well as a like co-working area and this is the program um I'm not sure if we had a chance to correct it actually but we had two talks cancel so I just want to highlight those the one at 10: we've now moved to 11: so that

talk Vish Reay she's still speaking but we've moved that up and on this on the in the afternoon we had unfortunately one speaker not be able to attend at 4:00 so that has also been removed oh oh actually so then my bad we there is a talk I should not have blanked it out okay we have a recording of that talk so actually forget what I just said only one talk is missing um we have a wonderful program it's been really fun putting this together um I think we had I didn't actually count the final tally but it's something like 110 to 120 applications to speak we only had 35 spots it's been really hard to choose but I'm very very excited with how this

turned out cool every stage also has some hosts so Nico and Tanya are hosts of this stage they're going to be moderating it the side stage has Henrik and Gaylord the breakout has Cohen and quente if you're a speaker be sure to contact your stage host just so that they know who you are and especially like before your talk just let them know that you're in the room as mentioned all videos for this will be on the Zero knowledge podcast YouTube channel and I actually maxed out I think the number of videos I can put on a playlist for ZK Summit so now there's two ZK Summit playlists we have ZK Summit 10 1 through 10 and then it will be ZK Summit 11 12 onwards this is the password and I hope

everyone's already gotten this if not I'll give you a second to take a photo phot I think there's signs around with QR codes so you should be able to log in quite easily ah and now I want to in I want to invite Andrew to the stage to share a little bit about the NFC cards that you'll find in your lanyard pouch thanks Anna uh yeah so all of you should have an NFC card in your badge it's in your pouch um and the way you can actually get started with this is you tap your own badge to your own phone and that allows you to register for it and then once you've done that you go walk around and tap other people and collect their contact information one of the coolest things you can do uh in the app is we have a bunch of different

topics in cryptography ranging from MPC to t uh ZK TLS to tees and you can rate whether or not you think each one of these is underrated overrated or fairly rated and when you meet someone you can figure out what hot takes you have in common which is pretty sick and it's all private so unless you both agree then nothing gets shared so thanks so much Anna thanks so we did this we did this actually at zk1 as well we had the cards but at the time basically what will happen every time you meet someone you can actually make that connection and you can collect those connections we have a leaderboard for the number of connections you've made and last time I

got really competitive and was like I'm going to be top of the leaderboard but there wasn't really anything to win with the leaderboard so this time around uh zkv has joined eort with cursive to basically offer some prizes so if you make the most connections and rank first on the leaderboard you're going to get 250 usdc if you rank second you get 100 and third you'll get 50 um thank you so much to the cursive team though for building it it's really been an amazing effort so thank you maybe we'll give a little round I want to say thanks to that yeah so have fun with them and you can win prizes um I'm going to set the cutof time to be 6:30 so that's the moment where we're going to snapshot it so it won't go all week

it's really just for the day and if you are on the leaderboard and you see yourself ranking go talk to the zkv team there's a booth um just so they know who you are so that we can get in touch with you for those prizes easy all right so yes I want to say the ZK Summit um is this is something I don't know if everyone realizes but like unlike some of the other events in the space like the ZK Summit is not backed by a foundation or a token or a single Network this event is built from the ground up every single time it we actually could never do it without our amazing sponsors joining us and for this Edition we have one return sponsor or

two return sponsors in the form of risk zero and zkv and two new sponsors irreducible in veriday faradise I want to say thank you to all of our gold sponsors for joining us we really couldn't do it without you let's giv them a [Applause] round we also have our silver sponsors for this Edition also return sponsors anoma fushi and Neil Foundation thank you to the silver sponsors and our community sponsors for this Edition argument alio brevis fluent snarfy lrange and ZK verify thank you to everybody for joining again

we we really do try to keep like the ticket prices I don't know if you if any of you got the early bird tickets or student discounts we try to make them relatively affordable and this is why we really rely on our sponsors if you're interested in sponsoring future events please get in touch here's the team that brings you ZK Summit 12 we have Agy on Ops standing right there Agy thank you again let's give Agy a hand she's like the main uh we had Natalia and Hana supporting on Ops as well on the programming committee we had myself Nico Philip and Kobe and then helping on AV we have Henrik who's also the editor of the show and we'll be editing the videos after so thanks to everyone who put this

together so here we have our hashtags and our Twitter account um I think I'm at the question point so if you applied to at for an early bird ticket you would have seen this question so every time we do a summit we always ask a question and we always get great answers from the crowd weird answers like brilliant answers strange yeah anyway we get we get a lot of answers and we always select a few to share with you so this time around the question was how would you explain random oracles to a friend it is a pseudo random hash based Black Box number

generator I would first explain hash functions and then explain random oracles as the ideal version of a hash function hash functions for nerds how would you explain random oracles to a friend theoretically useful inherently impractical uh imagine a magical box that can only answer any question that can answer any question you ask it you write down your question put it in the back box and out pops an answer that seems completely random but is actually determined by your question this box is kind of like a random Oracle ask me anything you want and I'll respond whatever I want I lost all my friends after I tried to explain them what nullifiers do so

great throwback to zk1 on that one a random Oracle is what every hash function wants to be when it grows up oh it involves a black box and a gnome I this we got a lot of these actually I wouldn't I couldn't and someone just wrote no Okay Google's random oracles how would you explain random oracles to a friend I don't know I'm the friend to be honest so whoever wrote that um there are a lot of people in this room who can help you out with this so I hope you'll ask around and actually this could be a good Icebreaker for the card swaps as you're making friends with

those NFC cards so so I am doing something I've never actually done before usually at this point in the summit we have the Platinum sponsor come up and share uh basically a 5 to 10 minute talk we don't have a platinum sponsor this time around so instead I wanted to use this time to share a little bit of like history so I want to do a very very very brief history of ZK research and history of ziki applications one of the reasons for this is if if anyone is newer to this space the words we use the terms for research papers and proving systems and applications you may not know where to place them and so my hope with this is

to just give you a bit of a framework to understand where these words come from so we're going to start on the ZK research front and believe me this is going to be very brief so we're going back to 1982 zkps are invented by goldwaser maau and rakoff in 1984 5 they first appear in a publication now I'm going to fast forward 30 years almost 30 years to 2012 so in 2012 the term ZK snarks is defined for the first time as succinct non-interactive arguments of knowledge but as I learned yesterday in a conversation with Yen sarel snarks are older than 2012 there are two papers

that I didn't include one in the '90s and one in 2010 that actually first described the concept for snarks but here in 2012 is when they're first defined as snarks 2013 we have the zero coin paper which merges blockchains and the snark concept for the first time it's followed the year later by actually a lot of the same authors but adding more authors to create the zero cach paper the zero cach paper goes on to influence the founding of zcash and zcoin in 2016 we have Groth 16 which is published you will hear throughout the day the term Groth 16 mentioned often uh this is what what it is it's like the

paper that is foundational it's become a form of a standard as I understand it there is a standardization process happening around grth 16 I think at this point it's the most implemented paper in our ecosystem and we are I'm very excited that after my talk I actually have the author of this paper yens gr coming on stage to uh present uh okay following on 2017 we have the fry paper fry you know this is when it comes out but you see it being very influential also in the snark World further along 2018 Starks and bulletproofspeaking.com the story um I don't know if like I just

wanted to list those four because it was kind of exciting in March 2018 we had the first ZK Summit in May of that year we had the first ZK proofs event in July we had zcon zero and in September we did our second ZK Summit you might wonder why we're at ZK Summit 12 we actually have not been running it for 12 years we've been doing two a year and then we skipped one year so anyway just a little bit of backstory okay back to the research 2019 was considered sort of I I think the end of 2019 especially there was this boom in research we had snark tber and snark toober where just like week after week we were getting breakthrough research coming out Sonic introduces Universal trusted setups followed by plonc which again a standard

you know you'll see this throughout also some of the naming of future um proving systems but a lot of plunk was incredibly influential you have Aurora red shift Spartan Marlin all that year in 2020 we have fractal and then Halo and Halo 2 Halo 2 again being implemented like quite often in many different ways lots of teams who worked on it we have plup which was this I think it was the start of the lookup argument train of research uh we had quarks and we had plony one in 2021 we have Nova which introduces IVC and folding which we're going to hear actually right after this two talks focused on that uh we have breakdown snark pack

fanan and the variations on the word plon never end there was a pause I feel like there was a moment where people thought okay maybe we should you know put this away but I know it's back I know it's not it's never going to go away um I heard yesterday also from arel that schan is not technically the name of that paper but it's been kind of given the name and it's a good one 2022 plony 2 we we have planky 2 which again has been implemented many times is a form of a standard we have hyperplan Supernova cul and CQ all in the lookup argument or those two are in the lookup argument thread and then kimchi and now I'm at 2023 and I have to

say 2023 and 2024 are hard to say what the real important research will be looking back we can pick out the ones that you know really stood out over and lasted the test of time we don't know but I'm going to list the ones that I'm going to that I would highlight for 2023 2024 today so boam from the matter Labs team we then had three Works focused on optimizing the IVC concept with hypernova protostar and protostar and Proto Galaxy we have Bas looking at the small fields and I know we have the irreducible team here so behind the Bas work we have jolt and lasso which utilized some Che and now this year and it's very hard to predict which of these

will stand the test of time but here's what I have polymath stack proofs plony 3 Circle Starks Garuda and Parry stir which was presented at zk1 and were which is going to be presented today um both looking at that fry protocol that was introduced back in 2017 and optimizing on that so that is the end of my short history of ZK research if I made a mistake let me know if I missed something let me know these are definitely like this is the second time I present that timeline and it's actually changed a little bit since doing that presentation this is a work

in progress I hope to actually give this talk again sometime in the future now I'm going to share with you the history of ZK applications and here I'm not going to go quite as granularly like year by year but look more like at a at an era so back in 2016 this was the map of ZK we had payments private payments we had two projects working on that zcash and zcoin there may have been other projects working on zero knowledge research but I'm going to try to I tried to focus on teams that are still around today and uh yeah share kind of like how they've evolved and where they've gone

so I'm going to fast forward now four years to 2020 and I remember thinking in 2020 wow there are so many use cases now we have payments private payments we have scaling we have ID and we have games so on the payments front Aztec is founded and I'm putting Aztec for now in payments I know they move but they were private payments at the beginning as far as I know um l2s are introduced with ZK sync and Mina was using recursive ZK to compress a blockchain for the first time also kind of like using this scaling idea Iden 3 had identified the ID use case and we had our first game in the

form of Dark Forest so just these five categories the L1 the L2 the ID the games and payments I wanted to share what it looks like today in 20 2024 so here is what our ecosystem looks like today and this is probably not complete um in payments we have new players like zkp top Doo and pay Aztec is still privacy focused but I think I've now put in the L2 category we had a number of new l1s zave focused l1s join the fry on the ID front Iden 3 which had originally pioneered it became polygon ID and now Privado doid and obviously all these other ID uh systems emerged a

lot of them a lot of them actually involve like scanning passports and really different ways of thinking about ZK and ID and there's all these new games a lot of which I haven't actually explored yet but as we were doing this research we learned that ZK is now in a lot of onchain games but the map is bigger than this um these are just a few use cases here is what the larger map looks like today so we have all sorts of applications for ZK we have the hardware we have zkl co-processors verifiable compute cross chain prover Networks and I have a category down here just called miscellaneous tools because I don't know how to define them yet um and actually one thing about Maps

like this whenever I've seen someone else do a map like this I've often been like that's wrong or I wouldn't put that there that seems like it's in the wrong place the re and then now that I've created one of these I totally understand why this is at any given moment any of these teams may be pivoting there might be new teams emerging they might Rebrand uh they might decide to do like two things at once there's they might disappear there's all sorts of things that are happening it's very much like a living map and for this reason uh zkv who's one of the sponsors today I don't know if you guys noticed but there's this map of ZK out in the lobby which looks like this it's been printed and

there's magnets we want to hear from you where you think the teams belong so please go interact with that move those teams to the spot you think they belong one of the challenges one of the challenges though I'll just point out is there are teams that actually exist in like three of the quadrants you could have a co-processor prover Network zkv M so what do you do and I think what we're going to ask you to do is try to figure out what are they most what what are they most well known for uh where do you think they're like putting most of their energy and place them in that quadrant we also left a few empty quadrants because we know that there's new ones

coming as mentioned I have this like miscellaneous one but if you know how to define a category for some of those teams in miscellaneous please let us know we can add them um yeah we're going to be taking F I think the team at zkv is going to be taking photos throughout the day to try to just capture what you guys think and I hope you have some fun with it cool I think that is how am I doing on time good uh okay so that's the end of the history of zero of zero knowledge research and the history of ZK applications um yeah as mentioned these are Works in progress so I really would love to hear from you what you think should was good what you think we should maybe write different for future

presentations I just want to highlight for all of you the side events to this event if you haven't yet checked it out on our website there's on ZK summit.com there's actually a link to the side events I'm going to share a little bit about tonight's Side Event but there's Tomorrow there's five events kind of happening one after another um you do have to sign up for them so you may want to do that during the day just to make sure you're on the list um I do want to just flag the zck Meetup which is you know the zck project uh that is happening on the 10th so if you're still in town it would be great to see you there and this time around we have an official Afterparty which is brought to you by pay and Celestia um thank you guys for putting this together I don't

know where the pay folks are I don't know if they're here yet oh yeah thank you for putting together this Afterparty um you do need to I think you need to sign up as far as I know there is limited space so it's best if you sign up just so that they have you on that list and this is happening at 8:30 today so yeah thank you guys for putting that together all right these are the hashtags and please do tweet at us like let us know that you're here and share what you can maybe just a note though these events do have do tend to have people who are somewhat privacy conscious so try not to take photos of people's faces unless they overtly want you to take photos of them um I know

that people on the stage you can definitely take photos there or your team or people you know if they're cool with it but just maybe be aware that some people might not want to have photos yeah all this info is over on the ZK Summit once again here is the program as it is on your lanyard just with that small correction so on this stage I'm very excited that after this we have yans grat coming up to to do his talk on memory checking in IVC Bas ckvm on the side stage we're going to not open it until 11: so don't go to the side stage yet on the breakout we have Arno Cube presenting soobi and on the workshop stage on this floor we have bobin and philli from

polygon Maiden so I'm going to actually I think I have well I have what right at time I'm going to actually give us all two minutes to decide where we want to go and then we'll kick off with our talk with yans scat thank you guys so much and welcome to [Applause] zk2 e e

check yeah hello hello thank you can I please get everyone to get their seats quickly we're about to get started please have a seat thank you very much great thanks for being with us on the main stage as said our first talk is by Yan Scot about memory checking in IBC based ckvm could I please get a bit of quiet in the room hello hello thank you very much yens please take it

away thank you um yeah so so I'm going to talk about uh CK VMS uh and I'll give a bit of introduction to these Concepts since um you there's a lot of teams and projects that are building ckvm and working with IBC and so forth um the problem I'm going to talk about is in ckvm if you sort like use incremental verifiable computation you sort of like slice the computation in multiple Parts those parts may be computed by different provs and then the question is how do you check that they have a consistent memory throughout that computation right because they might be a write in one place and a read in a completely different place of that one um and it's a topic I've talked about

before but there sort like a new twist we' been exploring this concept of multiset hashing um and how efficient one can prove multiset hashing and it's one of the techniques that one can use to do memory checking um we go okay so so it's something that people have worked on uh before uh there sort like a a standard techniques based on Merkel trees which is not very efficient um but then there are also some efficient techniques the multiset hashing technique was uh actually came out in in a paper in 2018 by settin L um called spice um and then there are other

techniques uh to pass offline memory checking um uh which is quite recent um and if you want to know about that one you can check out my talk on on CK proof which was talking about that topic uh and there's also a nice idea by by B and and Chen in in the paper proof for deep thought where they're sort like doing a Peterson commitment to the full memory and then just making sort like an update of a Delta the changes of the memory in each step um at a low cost um okay so I'll start by giving some some background uh to ckvm and and the problem that we are looking at in memory

checking so let's start without the CK so a virtual machine uh is a machine uh that can take a as input a a program um an explicit input X and another input W and then it outputs some result and the question we are asking ourselves when we're building CK VMS is why how do we know that this output why is actually true so the idea in a ckvm is that you would also output a proof that this has been computed correctly and then there will be a matching verification algorithm that can

take us input the program and and the input X and the output Y and and prove and check whether this is correct or not and it's important actually here that the then the reason I split the input in two parts right so the W input is not part of what the verifier sees and that's part of why you can have succinct proofs that are much shorter than computation that you don't actually give that to the verifier and therefore the verifier doesn't have to read it and and the computation the verifier invest doesn't have to depend on the size of w so this means that we can have proofs that are succinct that are really small

really cheap to verify and cheap in the sense that the verifier has to look at the program and the explicit input and the output and the proof but not W okay if we Peak inside the ckvm typical design is that you would have the virtual machine um that produces an execution trace of every step that it executes and produces the output and then you have AAL that looks at that execution trace and then proves that there exist a valid execution Trace so every step in the execution Trace corresponds to a correct execution of an instruction and those execution traces

may be big right and Computing proofs is a expensive operation um so one strategy could be that you would want to slice that up and you would have multiple provs you would have many machines uh that are proving that this execution Trace is correct okay so let me sort like dig into a little more technically speaking what happens here uh so this is incremental verifiable computation concept that was proposed in 2008 um so think of this function VM as a state transition machine it's all

like takes what is the current state it produces a batch of cycles and it output s like what is the next state of the machine and you can sort of do that in a sequence and there may be some auxiliary inputs as well right and at the end you would output y okay and there's a s like a lot of details into how you actually prepare that right so for instance maybe it's a big program and big input X right and you wouldn't want to give everything in one go so maybe you instead you have some sort like digest of that and then you're not actually giving so like keeping that as state but you're instead sort like inputting that along the way

as part of the auxiliary inputs Omega 0 Omega one and so forth so so you can for for the purposes of this talk think of the Omega as I saw like this is the execution Trace that we drip feeding into the c v ckvm and then you would have a that's sort like proves that the first iteration has been computed correctly and the next Pro would sort like consume the proof for the from the first prover and so like the next slid of the execution Trace prove that is correct and so forth right and that way you accumulate these kind of proves and you get a proof in the end that

everything is correct so so let's look inside now what what is it that this machine does right um so so think of this as we have a virtual machine it has a CPU and has a random access memory and one way we could think of of this so like the naive approach and what people were doing in the early days when they were're looking into their knowledge proofs uh for for execution of of programs is that you have the state is everything that you have in the virtual ma machine so it have like a

snapshot of what are the register values of the CPU and so forth it would have like the memory uh and so forth right and then you execute it and it outputs the new memory and the new state of the CPU now this is super expensive though right because now you actually have to keep track of the full memory in each of these transitions right and and who knows how many cycles maybe you're executing a few cycles and then it's really costly proportionally speaking to keep track of the full memory right and you have to place constraints when you're proving that this is a correct transition that constrains all of the memory right and a

lot of the memory cells would just be unchanged but you have to say this one is equal to what it was before this one is equal to what it was before and so forth so so the natural idea now is okay let's try to externalize the memory so the state now will just be the state of the CPU what are the register values and things like that and where is the program counter at but now we give the memory access as external input so it would say look I was writing this value to address three I was reading the this uh value from

address 17 and so forth okay and this reduces the cost for the Prov right because now we just have to keep sort like the relatively small state of the CPU so like what are the registers values and thing where's the program counter at okay but everything else is has been externalized okay so you only pay for what you use right so you still have to prove something about the memory accesses you do make but you don't have to prove something about the rest of the memory okay so let's um be naive and and

go go with that straight away right what happens okay so now the initial state is just the CPU State and that's what we are progressing and now we've externalized the memory accesses so the memory would be so memory zero would be a batch of memory accesses some some reads and some wrs memory one would be some accesses again to the memory and so forth and we're basically giving that as advice to to the to the CPU okay and now we can run the Prov and we can prove that all of these transitions are correct now there's an obvious problem here right which is that if you're

cheating Prov and you're running this system right you get sort like to choose what is the external input you would feed to each of these things that the provs are proving so you can feed them an inconsistent memory pattern right so you could have for instance a memory where you know you're saying to the CPU yeah yeah you are writing to this address this value here and then a few steps later you can say oh yeah and you're reading from this address and by the way it's this value here which is a completely different value right and you will get out the wrong output from the computation but none of the proos will be know that something is wrong because

their local view everything looks great right I mean you have some state of the CPU you have some memory accesses that you're getting from the external and you're doing the right transition right so the proofs will look great and the problem is just that you're proving things that Lo about the local transitions but you're not proving that that globally speaking the memory is consistent so that's a problem of of memory checking and and people have come up with several different techniques to address that um so the high level of these ideas is

um we want to insert some memory protection for the CPU right so we still want to prove that the CPU transitions are correct and they're progressing correctly but then we need to give them some protection that also the memory uh accesses they get to see are actually correct so we can imagine augmenting the state of the CPU uh zi with a digest of the memory right so think of this for now just as like a hash or commitment to the memory and then when we give

the transition function these kind of memory addresses then let's also give it some information so it can check that these axises are correct so let me give you um okay so so the big picture here then is okay so now with these additional checks with these additional digest when we do this incremental verifiable computation now we also have memory protection and now when we get out the

correct proof for the result we know that both the CPU has executed correctly and also all the memory access are consistent with one Global random access memory so let me give an example of how this could be done okay so think of a miracle commit m to the memory so we start by giving committing to the full memory in a Merkle tree and we give the root as a digest as input right so part of the state okay that's just like small hash value so it's a very small addition to the state and now whenever you are accessing

the memory we will not only give the accesses to memory but we will also give miracled paths to the root right now it's something you can for every access to the memory you can check that this is actually consistent with the memory that's committed in that Merle tree route okay and the cost is well so sort of the logarithmic size of of the the memory we write is is sort like the length of this path right and you have to check each of those right and that's s like you know if if it's a large memory and you're only doing a few memory axises in that's going to be cheaper than having constraint constraints for the full

memory so so this is great it works um however it's inefficient right because for each access to the memory the Prov now has to prove that it's seen a miracle path to the root of the tree and proving hashes is expensive right so it cost a lot of constraints uh so we implemented this with Poseidon which is like a fairly friend CK friendly type of hash function right and we're talking about like hundreds of constraints that we have to uh Implement and to check this path here so the question is can we do better

okay and the answer is going to to to be yes um so let me give you first a little bit of background is what it is that we really want to prove in order for the memory to be consistent so here's a a common technique that is often used is to think of a a read set and a right set that tracks all the memory accesses okay and we will think of the execution as first we will do some initialization that's just where we're writing what is the initial memory in this case I only have two addresses in in here right then we'll have the execution okay and when we do an

execution if we load a value then we would read that value and then we will write that value back again okay so for every access to the memory we both do a read and a write if we store a value then we will read a value and then we would write the new value that we're storing and the reason we're doing this is that well every time we write something to a cell then we update what is the time stamp when we access them what was like the last time this uh cell was used so when we have a like always read and then write pattern we make sure that every cell has been written just

once before that was the last time was written to and then we sort like read that and then we write a new thing right so we always making sure that the read set s like Trails the right set and then we when we are done with the computation then we'll just have final read of everything and discard that and the reason we do that is that we can actually now check that the memory consistent it is equivalent to the um constraint that the reset is equal to the right set okay so you'll have some local checks so you will check locally that for instance whenever you load a value then you should be

reading that value but you have to write exactly the same value back right you cannot change the value whereas if you have a store operation then you would read a value but you can write something different back so there these kind of local constraints okay and then if those local constraints are satisfied and we also have that the reset is equal to the right set at the end then we know that the memory is consistent throughout the question is now how to check that right because these resets and right sets they also grow really big okay so that's not something we want to store inside the ckvm and for that uh I'm going to talk

about using multiset hash functions okay so something that was proposed uh in the CK uh context by setal in 2018 so a multi set hash function um takes um a set of uh values from a message space okay and produces a small digest okay and should have this compression functionality that that digest should be really small regardless of the size of the multiset the other property we want is that if we have a couple of multiset hashes to two sets we should be able to compute the multiset hash of their Union okay and remember these are multisets so

all the elements are counted with multiplicities they may be repeating in the set and finally we should have Collision resistance that if we had two different multisets then it should be hard to find them so they're actually mapped to the same thing so let me give you a St standard construction for that so we're using here uh a group G okay and think of this like a standard Prime order um Group which um where the discrete logorithm problem should be hard and then we take a hash function um and you may think of that as a random Oracle for now so and then we just take

go through the all the elements in the multiset hash them and we add together these hashes right right because hash outputs group elements okay and it has the compression functionality right because now regardless of the size of multiset the multiset hash is just one group element it's also pretty easy to see that we have the incrementality property right so if you want to you know if you have the multi set hash for one set of the multi set hash for the second set when you add those two right then you're just taking the sum of all the hashes in both of the sets you get the multi set hash of the Union of those two sets and finally you have the Collision

resistance uh property right if you have two multiset hashes that are equal to each other well the first one is just the sum of hashes in that set you can subtract then the hashes in second set and that should be zero and if those two sets well if the two sets are identical yes obviously you get zero right but if they're different then when you count with multiplicities so those are the A's right you would actually get a non-trivial sum to zero and if you model the hash function as a random Oracle that means that now you have some group elements where you don't know the discrete logs and you

have made them sum to zero right so now You' broken the discrete log problem so how can we use a multiset hashing to check memory well the idea is now that instead of directly keeping track of the read set and the right set we will just have the digest of those we will have the multiset hash of the read set and the right set and keep updating that okay so on the right hand side here here we have the digest of the reset and digest of the right set the digest of the reset well we've not actually had read any

value so that's just zero to start with um the right set starts with the first initialization we do and then we hash that right and then we keep on updating whenever we do one of these operations we update those two sets accordingly okay and at the very end right if the reset is equal to the right set then those two digests they match and if the read set and right set is not equal to each other then by the Collision resistance property the digest do not match so that gives us a guarantee that resets and right sets match in the end and the cool thing is that this is

like you only keep track of the group elements right that these set hashes along the way and update the those okay and even if you have different workers that are doing different slices of computation then that's still fine right it's just a local operation I'm getting some digest and I'm updating that digest regardless of what has happened elsewhere in the execution so multi set hashing is a way to allow you to check that the memory is consistent just with local operations and then this multi has digest that you're evolving over time okay okay so how does that usually

work well you have the group that could be an elliptic curve let's say it has a prime number of points for Simplicity we can generalize that we have a cryptographic hash function that Maps into the field fq and then we typically have a map to group function that Maps into the group right and then the hash to group function is the composition of those two so that's the standard construction and it's an expensive construction right because what is the cost here well you have to do this hash function first and then you do sort of like a mapping okay and that hashing function is an expensive operation like this is a cryptographic hash function so

now you have to compute and verify a hash in every step and and this is where we sort of like starting to think then okay what are the minimal requirements that we want from this uh hash function hash2 group function we want it to have Collision resistance right because you if you have two elements that hash to the same value then it's very easy to find Multi sets with just singl ton elements that hash to the same but maybe we don't need cryptography for that maybe we can just use an injective map right that's so so that's s like the idea we're exploring

here okay so can we just use that that map to group function instead of having a hash okay and of course this requires that the message spaces of modest size right because if it was arbitrary large uh multi elements then well you do need a Collis in cryptographic function for that but if it's a small size set then maybe actually the size of the set is smaller than the group and it's possible to have an injective function and get Collision resistance through injectivity um and interestingly when we do memory checking then we do actually maybe have small

sizes right so think of like what would in practice be the size of like you have an address you have a value you have a time stamp well maybe there 32 bits 32 bits 32 bits or something like that that's 96 bits right that is modest size so we are actually in the situation where we could use just a hash function for modest size sets uh for mod siiz elements right and therefore maybe injectivity is something that we can use when we're doing memory checking in ckvm so there's one other thing that we need to be careful now when we don't have like this hash function inside to

make things look random and that is you may also be able to find two elements where we're mapping to the inverse of the element right because in an elliptic curve group it's very easy to just in take the inverse of a point by flipping the y-coordinate so we actually need and if you can find that right then you can also find a nonempty set that maps to the same multiset hash as the mty set right because M1 and M2 would the multiset have hash of those would they would just cancel out right and you would get zero okay so we need to be careful about that so we actually need a map to group

function which is injected with respect to the x coordinates right so it's s like uh resistant to the sign flip okay and interesting we can show that if we have those two properties then we can actually get um um just use the map to group function and it is secure in the elliptic curve generic group model okay let me see I have two three minutes left yeah okay so I'll just very quickly give you sort like a feel for what could this function look like okay so so it's pretty

straightforward um you take the message you add a little tweak to it and you try to use that as the x coordinate right and The Tweak is there because only not not all the x coordinate half of them are actually good x coordinates so we need the tweak to just make sure that we get something which is a valid x coordinate and then the function also needs to make sure that we cannot flip the sign um we suggest if Q is equal to 3 mod four that we just make sure that Y is the quadratic residue right because one of Y or minus y is going to be a quadratic residue and you return that point okay and let

me okay and okay so what are the constraints we need for to ensure this well we need to make make sure that X is actually something that matches a point on the in the group right we need to make sure that X is a valid jump with this tweak we need to make sure that the y-coordinate is unique so we cannot flip the sign okay and all of those are pretty straight simple constraints to verify okay so using this kind of um multiset uh hash to to group function then we have a

um deterministic map that can be used to sample such points okay there's a one more thing to be little careful um about which is that um you could imagine that the pro instead of using the smallest tweak used a different tweak um and this is why I'm I'm switching from map to group functions to map to group languages because actually it turns out that it doesn't help the provs if they're cheating that way and that means that we don't have to go through the trouble of proving that The Tweak is

the smallest possible one right it just be one of the valid tweaks okay so the construction if we instead use the map to group function looks like this just as before um and as you seen we only need a very small number of constraints to check that a map to group function is evaluated correctly okay and with that I'll stop my talk thank [Applause] you thank you very much yens unfortunately we won't have time for questions but yens if you're okay with

it maybe people can find you just outside the room thank you our next speaker is Ariel gabison from Aztec Labs who's going to present about going from IVC to rcgs uh let's give people a few seconds to make their way in or out and then let's get started I'll be sat here and I'll wave at you thank you very much oh sorry you ready yeah cool Ariel please take it

away use this one yeah uh okay uh thanks um and so I I I always uh get a a haircut that conveys zero knowledge about where my bald spots are before I talk about zero knowledge so uh okay so let me give you a a small outline of the talk uh first I I'll start with some simplified details about the Aztec uh smart contract

system uh this will lead us to define a notion called the repeated computation with global state that um then we'll go over how to deal with global State uh using uh log derivative methods uh and I'll end by highlighting a theoretical issue I want theoreticians to look into so so Aztec is about uh private smart contracts so so like ethereum a contract has

functions uh but since everything is snark ified every uh function say A and B have some verification key uh that Ma matches the function and uh what can functions do well one important thing they can do uh for this talk is that they can call each other a function can call a function in the same contract or a different contract so let's spend a few minutes thinking about how what is what does it

mean for like snork circuits to call each other um so for example let's say we have we have this execution um we're calling a with args a somewhere in the middle of this execution it's calling B with args b and we want to make a proof of such an execution um so the the basic idea is uh A's public input will contain the

verification key of B and the arguments of b um and one you may be wondering what why why is this an issue at all to prove such an execution like don't we have such stuff and we we sort of do like what's a little different in the Aztec scenario is that the functions are already individually snark ified so a has vka B has v dkb and we're expected to use those keys uh okay so so here's what what what

uh this could look like so we we'll construct a proof for a uh called the proof Pi a where the public input now contains the arguments to a but also the verification key of B and the arguments to be and now we'll construct a proof for B where uh the the public input is is just the arguments to be and we'll have a verifier check uh check the proof for a with uh key vka and public in XA we'll have the

verifier also check proof pi b for uh with verification key vkb and public input XB and since this V will enforce we'll use the same args B and vkb for checking a and checking B this corres responds intuitively to a calling B that's the basic idea okay

um but now we we want to massage this to a more uniform form uh so we want to think of these different steps as iterations of the same function so we'll have this function f where the inputs of f are the current VK uh the current public input which again is consists of the the current arguments of the current function the next ver ification key and the next arguments and by the way this is sort of an arbitrary choice for

Simplicity that like the current function is calling at most one other function um it might be even more natural to think of it as calling several in the code it's four the maximum uh so and also uh another argument of f is the current proof Pi uh and the current stack of functions to to be called and now what is what is f check um so it checks that the element at the top of the stack is the current VK and the current args and it'll pop it off the

stack uh it'll check that uh the proof Pi with public input X and the current VK except and it'll push to the stack the to the top of the stack the the next function the next VK and the next ARS um another sort of simplification here for presentation is so here it looks in in step two that Pi is like a full snark proof and we're verifying a a snark

proof in the actual protocol uh we're uh the step two is just uh what's called folding um a proof of correctness uh or really just folding the the witness so like if you want to make it closer to what actually going on Pi is you you can think of it as just a as really as a witness as the actual original witness um yeah but for Simplicity you can also just think of pi as a proof all right so so this is just this

this F is like a way to when we have a sequence of calls just a way to think of those SE and in each call is right for a totally different function potentially uh right CU different contracts have different functions uh but this F is like a way of thinking of of this you know process of one function calling another calling another is just iterations of the same capital f but we we so far we forgot to deal with

global state in in addition to functions uh a contract in Aztec will have notes representing its state for example the notes N1 and N2 and in in addition to calling other functions a function while it's executing can add read or delete notes of its contract so to enable these uh Global

State operation we'll add to the public key uh public inputs so so far we had the the current arguments the arguments and the VK of the function you you're you're going to call next maybe will'll also add um to the public input the note operations you're do you're doing so for example the here like the call to a and and these operations they will have timestamps so for example here uh the call to a is reading note n at time stamp 8 and the call to be is reading uh is reading is sorry is

creating or adding note n at time stamp 3 and and now the problem to deal with is so when we're verifying the the proof to a we see this note operation um read note n at Tim stamp 8 but while we're verifying this proof we can't be sure that in some future IVC iteration will indeed see the note and created and moreover created with an early your

timestamp right we don't want to read notes that haven't been created and we also don't want to read notes at an earlier timestamp than when they were created so at a higher level uh the the order of proving here is different than the order of execution since like I said before the functions have already been individually snark ified right in execution we we start with a go into B finish B go back to a finish a but since the functions are individually already

snark ified we have to prove it in a different order we have to do all the proof for a and then all the proof for B so in execution the note n was was created before it was read but in proving we're only get to going to get to that creation of the note and later in the proving process so to conveniently deal with this

setting uh we Define the notion of rcg repeated computation with global State uh at a high level or even a less than high level rcg is very similar to incrementally verifiable computation IVC which you've probably heard of a a lot uh but there's two there's two differences so the the the first difference is that in rcg we know the end point the computation ends before uh proving starts so if in the original IVC

paper Paul Valiant is talking about a computation humanity is going to be doing for Generations uh here we're assuming the computation has ended uh before the proving is started um so then well you could say okay so then is it like IVC at all if it's already ended so what's the what's the why is it even similar so the the desirable property in IVC is what people uh they call complexity preserving uh sometimes that the the Prov

memory even if the computation has many steps the the Prov memory depends on the memory of uh of that the one step for example one execution of this function capital F we had below so in rcg we we still want to sort of have have that property but we we relax it so we say uh the Prov memory uh should mainly depend on the memory for for one iteration but it's also allowed to depend on the size of the global state so let let me walk you through a a

simplified version of the the actual definition uh so we're going to have uh to Define an rcg relation we're going to have a transition predicate and a final predicate and now we're we're going to say these uh transition and final predicate they Define the the relation of pairs X W uh where X so what is X x contains the the final proof the final State sort of Z final and the number of iterations

N and W contains uh three vectors z w and sorry and S uh where intuitively Z is going to be the different states we we go through uh W is going to be the the witnesses that get us through those States and the s's are the the chunks of the global State we use in each uh each iteration so we so we say that uh W xw is in the relation if well we end ZN is Z final so we end in the desired uh

final State um for each I the transition holds so F of zius one wi Z SI is is valid is accept uh and the the final predicate uh if we if we insert into it the the all the s's from all the iterations it's it outputs except uh right so this third thing is like where we have this additional ability that we wouldn't have in IVC we can we are allowed to test some final

predicate of little we think of them as relatively little chunks from from all the iterations um and again the the point is you could just say okay just build a snark for this relation what why do you call it rcg uh just build a big circuit and the the again the point the IVC like kind of point is uh we say a snork is space efficient uh if the prover requires SP space uh I'm not formally defined here the size of f but requires space which

is roughly the size size of one step plus the size of the the global State that's the memory that we allow the prover to use so like I said this is a simplified definition I I I will raise one little hole in this simplified definition and maybe is occurred to some people here maybe we want to hide the number of iterations when we do the DK snark so in the actual relation this n is not part of of the instance X what's part of the instance X is some bound C on n and n is part of the

witness yeah uh okay so uh to to illustrate this point uh so let's see how we use uh you know an example of an sort of rcg uh to deal with these uh these memory operations um so uh we're going to add to the to the ad operations we're going to add uh the number of times

uh by the way if you don't have Lake Deja Vu is because I prepared these slides according to previous talks of of yens so uh so we we're going to add to the ad operations the number of times a note and a note was read so that's this this num reads uh field we're we're going to add to the uh to the read operations uh and we we have the time where the note was read we're going to add to the read operations uh the the time

stamp uh where where the note that's being read was added so that that's this a and now what what are we going to check so uh in the transition function we're we're going to check for each read that a is smaller than T that the alleged time of creation of the note was smaller than the time we're we're reading it and and now we're going to sort of use the fact that we're allowed uh we're allowed more more

memory in in the size of the global state so the prover is going to store all the node operations from across the the iterations and and it's going to Hash them to get some challenge beta and so now right so our goal is to our goal is to check that every time you have a read um you're reading a note that was create really added and also added at an

earlier timestamp so so this check at smaller than t uh sort of checks that if this node is legit that that the the time stamp of addition is is is smaller as needed but but right it could be that when I have this read n at it could be that they're actually does not I'm not going to have an operation ad like n a I'm it's just so so we need to check that all the alleged creations of of notes really happened and that's going to be done by this this fractional sum so right we're going to check that the sum of the reads

of this expression think of the Noe as just a value in the field uh we're going to have this sum over the the reads of 1 / n + beta * a the alleged time of creation of the notes and we're going to compare that to we're going to sum now over all add operations from from all iterations and we're going to compare that to to now for each read we we put in the numerator the the alleged number of times the note was read and we divide that by n plus beta * t plus the timestamp of the ad um and and you can you can see that if some attempt to cheat was made like uh

there's a read operation for a note that doesn't exist then with very high probability over beta this this sum won't won't be equal five okay uh okay so that's that's some details from the uh construction and I want to end by highlighting a theoretical issue that I think needs could benefit from

scrutiny uh so in this paper to to make our proofs uh easier or easy or at least easier uh we use what I call uh the recursive algebraic group model that was implicitly introduced in this in this paper analyzing Nova uh by Leon SE I hope I'm saying that right and let me explain to you what this recursive algebraic model is so let's let's talk about the original AGM what was the idea there the idea there is that if I have I have some structured reference string of elements of the group uh then when an adversary outputs some a

in the group uh they must also explain how they got to this a by the SRS elements so they must output also a vector of of scalers C such that this a is equal to some CII okay but now let's say we these group elements were're representing them as pairs of field elements so fix some representation function of G by by pairs of field elements and now suppose that you know the algebraic adversary outputed this Vector

C and it just so happens that for some two adjacent indices in this Vector of scalar C CI CI + 1 is a valid representation of some group element B so you could ask if if you uh you could ask well shouldn't the algebraic adversary now also give us a explain to us how he got to be using the SRS and some would say no you you shouldn't do that but the recursive Al group model says yes you should

definitely make the adversary's life a bit harder and your analysis a bit easier and yes you should you should demand uh an explanation of how how to also make B uh from uh the SRS elements so so the the arive algebraic adversary now must also output C Prime such that b is uh some C Prime C Prime I VI and then you ask well what if C Prime there's some two indices that are a valid does does he have to do it yes that's where why why there's recursive in the name so the recursive algebraic adversary must keep outputting these

vectors of scalers C until he his output vectors with no that nothing there no two adjacent elements there are um right as a sanity check you could say won't he always by accident there' be some C I plus one like this and it'll be an infinite Loop well it shouldn't be because right if if f and g are of similar size say in the elliptic curve case it it shouldn't happen by accident that you know so but so this is the question I want theoreticians to look at because I I I really like writing proofs with this thing uh for IVC uh so I want people to look into is this legit and yeah so that's sort of a shout out for that yeah and so thanks for

listening thank you thank you very much Ariel we have a bit of time for questions if you have any one over there oh hi Ariel great talk um in the recursive uh AGM uh sorry uh algebraic group model um is it necessary that CI and CI +1 they are consecutive like it could be any like any two yeah that's a great question the it is a little ad hoc to look at all adjacent pairs the reason

why you can't look at all subsets is there's an exponential number of them and then you will be in a situation where oh just by chance some something is a representation and the the adversary will be an infinite Loop any other questions right so let's thank our speaker again we will now go on a break until 12: um so feel free to go get coffee and mingle and we'll be back here at 12:00 thank you for

[Music] [Music] [Music]

[Music] [Music] that [Music] [Music] [Music]

[Music] [Music] [Music] for [Music]

[Music] [Music] [Music]

[Music] [Music] for [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] in for

[Music] [Music] [Music] all

[Music] [Music] e

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

e [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

that [Music] [Music] [Music]

[Music] for [Music] [Music] [Music] [Music]

[Music] in [Music] [Music]

e e [Music] [Music] [Music] [Music]

[Music] [Music] for

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] for [Music] [Music] e

[Music] [Music] [Music] [Music]

all right welcome back to the second session on the main stage our next speaker is Albert Rubio and he's going to be talking about circum bosses uh the power to structure ZK circuits please take it away Albert uh thank you action um one second okay so I'm here welcome everybody so I'm here to present this new uh feature of of circum and uh well I will I'm expecting that all of you know a little bit of circum otherwise it won't be easy to to to follow but in any case just to show that we are

adding uh an important feature from the point of view of ccom programming language Okay so um just a bit of context of of of uh what is ccom intend intended to help us in a in a knowledge uh protocol is just this part that is in in in in Black which is we have to build a a circuit and be able to run this circuit okay so this is where circum uh help us okay and uh so C is a DSL that

has this special way of working which is to explicitly provide the constraints of the circuit okay so all is explicit and and then you some you can also provide an efficient way to compute the the witness if you need and in many cases this goes together so circuits that we can use to build our new circuits on top of it and this is this is encouraged because we can trust on these circuits and then we build on top of this and and and in in many cases we can get really safe circuits just because we build on top of things that we know are safe okay so uh we have this nice ecosystem of

tools and and so on but when writing circuits programs with uh with circum we we have a a little bit we are lacking types like in other languages okay so because in currently until now until yesterday the the only types you you you had in in circum were signals and array of signals okay so of course you can do everything with that but well it's not the best way to to to work okay so what I'm going to present here is that we will now be able to Define new types collections of signals and so on so then what's the compiler doing the

compiler produce both things the circuit with me which is a constraint system in our 1cs and an executable in web assembly curring web assembly or C++ that can be used to run efficiently the circuit okay so this is what the compiler produce out of the of the circum code okay so now let's motivate the problem so this is just a a piece of code of the of from the library from the baby jabjab uh uh circuit and this is the other for this elliptic curb and uh and here you see

that what we want to express is an addition so two points added give a new Point okay but since we have no types uh what we can do so we produce we we have four inputs and and two outputs that are just signals okay because of the names maybe you can figure out what is the meaning so the first two are the one point the second are the other point and and so on okay but nothing is is really making this as a as a each of or each pair as a as a whole okay as something that you know it goes together okay so this what you can do but and and then what happens that you really want points

but you have signals just signals okay and even worse in fact they are signals in this case in the Twisted award form okay so but they're just signals okay so we are not seeing this anywhere and it's not going to be checked in any place by the compiler okay so we need after this clear we need better types okay to to structure the information and then also to increase security because if we add new types then the compiler can check these types okay and then we know that we are what we are passing is of the appropriate type so this is what what uh we pretend to do this and and here is

what we get with buses okay so buses are like strs in other languages but we are programming circuits so then we have buses because bus is the name in in a circuit so from now on we will use buses and and buses the nice thing is that all all all can be mixed up from now on so you can you can use uh uh you can Define buses using signals arrays of signals all and other buses combine it with a raise of buses whatever you like so everything can be used in an orthogonal way okay so the only thing that we don't have currently but it will

come I hope in in in in a a few time is is a recursion in the definition of buses because we have to well you have to decide how to handle the the the null or something like this okay so then buses Define new types okay and then type checking prevents from from mixing different types okay so the the the security is is is obtained like in other programming languages from now on okay since you have types so the the compiler will type check everything and and you will avoid maybe using signals that have not a real

meaning you expect okay so this is the the point and uh and and then very soon we will uh release a new version of the circum uh Library which is circum lip with using all these buses uh and and and change completely I will talk about this a bit later so what we believe is that a complex circum program in production and we have seen many projects that use circum in the in the in the intro in the in the introduction so must use these buses to to increase readability because if you want to audit your your circuit buses will help a lot

and also to increase security okay so let's do a little bit of practice with this so the bra the example okay so suppose that you want to compare dates or whatever then we have the problem as before okay and then you have you can use names of the signals to help a little bit but uh there is not much okay uh later you can say well no let let's put it all together because then it will be clearer but I'm not sure this is clearer than than before because now what's the day the zero or the one position okay you you don't know and it's not it's impossible to to know okay so it makes not much sense to to do it

like this okay so what can we do so of course use a bus use a stru then you define it like this and from now on you can now Define templates you see using this like before we had signals okay so it's simply as as simple as this okay uh uh note one little difference so there is just a tiny difference before it was the input and the output keywords were in the middle and it is quite ugly with buses so we decided to to change a little bit the syntax and from now on the recommended syntax is to put the input word uh keyword and output keywords first then

the type and then the name okay but the old style will be still valid it will compile and and no problem okay but just take this into account it's nicer if it is written like this okay let's go a little bit further what can we do with with h with buses not only this simple thing we can now have parameterized uh buses like we have parameterized templates okay so this parameter is something that will be known at compile time and same exactly the same you have for templates you will have it for buses and then here what we do is just we Define this array of of uh dates using this uh this uh this parameter and and

the nice point is that then everything fits well with the templates because for instance here I can define a template with a parameter n that uses an input with uses the same parameter and then everything will work well with the sizes of things and so on okay and then of course then you can call another template with the same end but then I pass field of the of the array of dates and everything matches the types and and everything compiles okay in general I would say that clearly this looks nicer in the and it's far more readable okay otherwise there will be all this amount of signals around all mixed you have to choose whether you

have arrays of arrays or many arrays so it's just uh much cleaner and easy to to read okay now we we we go step further and we mixed buses and tax tax is something we introduced kind of two years ago and uh they we were having a bit of subtyping with tax and now we'll have types and subtypes this is what I want to present here with this mix of uh buses and tax so the point is is is this that tax provide a simple form of subtyping okay we don't have inheritance and things like this but we get a little bit of subtyping uh with with tax but now it's

really far more powerful combined with uh with buses because now we have types and then we can just uh get a little bit of of subtyping with with uh with tax and then what happens that we create new types with buses and we Define subtypes Rel sub type relations using tax okay so you you see here but then when you define a bus or use a bus so TXS can be inside and outside and with different meanings if you have it inside they somehow are restricting every instance of this bus I'm seeing that this field has this property okay so I'm restricting what should be in the

in the bus and if I had it outside when using the bus then I'm restricting the particular instance of the bus okay so I can do it both I can define something that I always want to have this property in the in in a field I add the tack inside the bus but if it's something that maybe sometimes I need it and sometimes I don't then I add it outside when using it okay so the the point is somehow that before we were only with t with signals we were only able to express T properties of a single signal now since we can put a tack on a whole bus we can Express properties of a combination of signals okay so it's much nicer in this sense and later on if you add verification techniques and so on it

will go much better because we can check the semantics of of a whole bunch of of signals that go together okay so let's see it in in the in the in the example of this and going a bit farther than this so This what I mean by tax inside okay so I I hear say for instance don't don't be much worried about the semantics of of these tags and and why I'm using Max bit for day and just to show that you can use different taxs and and as many as you like non one two different things for different signals okay what whatever you like okay so this is just meaning that there is some bound restriction on the on the

signals you can get there okay so there is one thing but then suppose I create this BS which is profile for an ID and then for a a bunch of of dates meaning whatever and then what I want to add for date is that there a valid date okay so then I add this this TX saying this is a valid date and what's that so I can have a template that creates a valid date from and what's the meaning of creating a valid date it means adding constraints that ensure that the date is valid okay we are creating circuits that ensure things okay so we we can do that and and look if if I do the template with without any assumption on the in on

the input signals then I add here constraints and so on checking all the properties the properties of of the of the day the month and then also the global properties of if the month is this one is January then it should be between 1 and 31 if it's blah blah blah okay but the difference between the input and output and uh uh the fact that whether I already know some or not suppose that I because this is used in some context I already know all these taxs from outside then if I know that it should be like this then I have it in my circuit and I don't need to recheck it again you know if you have built a circuits many times

you since you're not sure whether you know or you know something or not you keep adding the same constraints again and again and again so using types and subtypes by means of tax we avoid a lot lot of rechecking of things and which end up with a with a better and more efficient uh circuit okay so now what's the impact of all that in in the in the circum liap so well huge okay but uh but I will just show a little bit so the what what we are doing in this one while writing is adding buses and tax everywhere or in many places and also making it

compatible with different primes remember that initially we only have this uh this BN uh Prime and and uh and then circum lip was intended to be used with this Prime but now we have kind of I don't remember maybe six more primes or even more and then what happens with the ccum lip it's not adapted to this so we are just ensuring all the all the all the circuits that we can being compatible with every Prime okay so of course you will use which prime are you exactly using and so on but you can you can make it and and uh and this will be a nice uh a nice

Improvement so the the nice thing is that we have added this these buses and and uh and tax and still we've been able to prove and formally prove that in most cases the number of constraints is Remains the Same well when using minus 01 okay ah by the way which is now the default Until Now the default was uh O2 but the def from this release on the default is 01 because many people is using circum for plung and then o O2 is not the the the the way to go okay so from on this is the default okay so keep

it in mind because it's important um and uh and uh and of course looking at the at the new circum lib will help to understand and and and get ideas about how to use and where to use this so let's show a simple example of of the one single example of this use okay so let's come back to this baby jabjab electric curve so you have the the the the the others and so on for for the twisted uh other words form okay look there point it's just like this you

you have six six in uh four inputs and two outputs no meaning apart from X Y used in the name and then you have the the version the Montgomery the the the others for for the Montgomery form and all of a sudden now it's no longer two signals but an array of Dimension two okay so as the Creator I was not there so uh and and and you have this okay so for instance this this difference but even more if then you look at the conversion conversion from Ed to to to Montgomery and back so here you see you have even this kind of well it's

not the type inconsistent but you you inconsistency but you have the two express the point with two signals and here is the ray of of uh of Dimension two okay but it's all the same because are two signals okay but it's not it's not helping to to to read and also it's clearly error prone because you can mix things that you don't want to mix okay so let's do it with buses Which is far more natural then I have a type for eward point Edward Point okay so uh two fields and that's it and then oh what a nice thing okay you see this P1 point point P2 point oh now I go to the to the

Montgomery form another bus okay so Montgomery point then nice again you look is clearly different okay and we you will never mix both because you cannot pass one type to the other because the the compiler would say no with a type error okay and now look it matches perfectly you get a conversor that takes an adward point and produce a momary point okay and same reverse okay so now it's readable and thanks to the type check you have type safety okay so it's clearly more reliable of course it's far more

readable and more reliable you can you understand a bit more what you're doing but now now let's do this with tax then the point is this subtyping so because we've seen that they are all points so should we have these two points well a proposal is no use only points and then use stxs to distinguish them so here you see you have points and then you have the attack Edwards H and in the other way we don't add a new boss but we use the same but we add attack Mongomery okay now you can mix them again because you will check whether you have the T and you or or not and of course except if you for some

reason decide to to add yourself two TXS which you I mean still is possible to make mistakes like in other languages but on purpose you have to define a type for something that you really don't know if if it it is fulfilling the properties or not okay so this is the kind of things that will be prevented thanks to types in in this context okay so then what we have is this the the and this and then when you have the conversions everything matches again because here I will get this other SP then I get a an output point with the Montgomery tack that will be that I will be able to use there in the other because it has a tack

okay everything matches types and and it works nicely okay of course all this is checked by the by the by the compiler in the type check and it has no impact at all in the amount of constraints and so okay if you need to add some extra constraints because you need to be sure that that the conditions that you have Associated to the type are met then you add constraints okay but this is the what you should do it cannot be that you assume that something fulfills a property but you don't have constraints because then of course uh maybe what you produce with the windows will fulfill it but someone can send you a proof that is not uh fulfilling this and you will just say okay

good so then with tags and and and and buses we get readability type safety but also we are far more re reusable with the code because maybe we have operations for points that always the same and we can reduce it in both cases okay so it's just just the the the standard situation with uh with uh subtyping okay it simply helps in re re reusability so finally um what we have in this uh as I said in this new circum we have the we have added this bus stacks and make it compatible and the

nice thing is that what we pretend is that if we if someone builds circuits on top of the of the circuits from the circum Lip lip can be in the safe site in the sense that we can even certify that if you only use the the templates of circum Li to create new buses or to add tags and so on then you are sure that the properties are fulfilled and you're using properly the the baby jbjb uh elliptic curve and so on okay so it's these kind of things you're not making mistakes in this sense you're using things prop and you can trust all this okay so you you are safe just by default because

you're building on something safe so we will later in in the future we will really give a precise definition of this but this is what we intend to do to to to have circuits that are safe by construction okay and well we are still improving and extending it so it will be ready very soon but it's not uh it's not yet so conclusions so ccum is really one of the most widely used languages for G knowledge protocols I I as I said many of the of the projects that were shown in the intro are built using uh circum and uh but until now we we missing this this uh

this this extra types or or this type system a proper type system in the language and this what we are providing with uh in in in this new release okay these buses that provide us the the way to structure circuits it provides a far more convenient type system and then we can ensure this type safety and also we believe that it will help auditing uh GK GK projects and uh and the new will take advantage of all this thank [Applause] you thank you very much Albert do we have any questions oh

great yeah so er at what at one point you said H that ciron LE 2 was using some kind of formal verification uh what did you exactly did you use and how did you do it well I said what what what I said is that what we we have formally verified I mean you you know these are circuits made of many uh sometimes thousands of constraints uh for even for the circum liap for just a a a simple part just using one of these uh um circuits in the circle lip okay so then but is imagine that you want to check that introducing

all this you are not having an overhead in the number of constraints okay so you want to check and and also you want to check that your saying the same because the circum La was already audited okay so imagine if we just don't know if they are the same after changing we need to audit again so what we have verified for most of them and and the ones that they are they they don't fulfill the property of being exactly the same as before is because we already know that we have added some extra constraints okay because we know it in purpose or we have removed some constraints because of the tax we know that this was already checked so then we

don't need to add them but apart from these situations we have proved that the circuits before and now are the same but simply are the this defined and described in a much better way okay more readable and also uh nicer in the sense that you can use them in a safe way okay so this is the the the key point so this is what we have verifi I think we have time for one more question uh could you perhaps compare and contrast what sorts of things can go in buses and what kinds of things can go in templates for example sorry in bus is in is it possible to put something like

a constraint or a witness generation procedure inside of a bus such that all instances of the bus have that or not no we that so that would okay nice question so the thank you so there is the point where we have code inside the the bus and and and and this producing constraints so we are not allowing any code inside the bus by now but probably we we we will but only to the finally so for instance if you want to have this recursion it would be good to to to have using the par met deciding whether some

field is there or not and then you can have a nice form of because the the the the the notion of of of null of null in in in a circuit is not easy okay so it's it's a weird it has a weird semantics but if you cannot code you can have a a conditional saying well if n is zero then you don't have this field okay for instance and and then you can probably add some code Le this way I don't think we will like to add code in the sense that if you have some some bus it will just directly introduce a set of on things we we are not planning to have

this great thank you very much let's thank our speaker once again and welcome to the stage our next speaker V and Andrew from the cursive team who are going to talk about building cryptographic apps for human connection okay hello everyone my name is Andrew this is Vivic and today we're going to talk about building cryptographic apps for human connection so first off why combine cryptography and human connection why are they such a good fit well it really comes down to two things

human connection is centered around discoverability and depth ability means finding more quantity of connections more opportunities to connect with people and depth is about making each one of those connections more meaningful first off is discoverability so many social apps today are using a push-based model so big algorithms or advertising feeds tell you what you're going to look at uh you don't really have control over what you see and in addition these feeds are based on maximizing how much time and money you spend on the apps on the other hand cryptography offers a few advantages here you own your own data so

you get to choose how you interact with these apps you get to choose who gets to see your data and also what types of connections you're able to find now depth is another facet where a lot of social apps today are lacking if you look at popular apps like Tinder or in Instagram these are all centered around you making a public profile that's based on who you want other people to see you as rather than who you actually are they're not centered around connection they're centered around your public Persona in addition to that none of this data is verifiable you can basically put whatever you want on your Tinder you can put whatever you want on your Instagram and you're crafting an

image for other people to see and as a result this leads to a lot of fake data a lot of fake profiles and a lack of genuine connection cryptography helps this in a few ways first off it makes sure data is verifiable that it has a source of Providence to it in addition to that because now you have access to private data you can include a lot more meaningful sources of information within your profiles you can include data that is more personal to you and reflects who you actually are in addition to that compute Primitives like MPC or FH ensure that you can still create meaningful Primitives on top of this data okay so why do we care right now why is it so

important to build apps with cryptography at this moment well there's really two reasons one of them is technological and the other one is social first off is the technology side as many of you uh might have experienced last year at ZK Summit we actually did a similar experiment with these NFC cards that you all have um but actually a lot of the tooling we have access to today it simply wasn't there a few months ago things like non-interactive multiparty fhe and Trinity both of which Vivic are going to is going to talk about later on uh in this presentation they simply weren't production ready at the time so a lot of The Primitives that we really depend on are now here and they're ready to go in addition to that Primitives

like ZK Emil and ZK TLS ensure that we can actually use this data today we can take data from Web Two silos make it portable and include it in our applications finally consumer devices are getting a lot better client side proving is becoming more important tools like no tools like mpz Phantom Zone all these are designed for computational loads on commodity hardware and they ensure that we can actually do more meaningful computation in the devices that are in your pockets okay uh now the other side of this is social uh it's about how social media apps have developed and evolved up until today uh this is a really interesting Twitter post and it's about how in a recent marketing

campaign Facebook didn't mention the word friend a single time they just didn't say it and instead they were talking about feeds they're talking about content and all this other stuff uh but the original values of friends and connection that Facebook started with simply aren't there anymore social media today is about attention and not connection but at the same time people are searching more and more for connection uh maybe these are a little small and you can't read it but to some summarize people have fewer friends today than they've ever had uh and they're spending more time alone today than they ever had before so people are looking for more types of connections but social media isn't giving it to them so what can we do about this what tools

do we have access to uh specifically how can we use cryptography to help enable human connection the first tool that we can use is cryptographic NFC cards all of you are experiencing this right now you all have these NFC bges uh as you entered the event and NFC is really great uh for one useful primitive which is verifiably digitizing physical interactions I can prove to you that I actually met you in person by collecting a tap from your NFC card there roughly two different types of cards that we experiment that have cryptography on them the first one is an ecdsa based card and the second one is a message authentication code or Mac based card so we're using the second kind which I'll

explain more more about later um but roughly speaking these both use cryptography to secure physical interactions at a high level the ecdsa cards are signing cards that actually have an internal nons which increments upon every tap and in addition to that they actually custody signing Keys within the chip so whenever you sign whenever you get a signature whenever you tap one of these EC DSA cards it increments a nons and it signs that nons and gives you back the tap on the other hand the Mac based cards use a shared secret so basically the server has a secret that's uh shared with the card and when the card generates this incrementing nons tap it just generates

a Mac for it and the server verifies this tap to ensure that the tap is valid so why do we use one card versus another well at a high level these ecdsa cards have two really important properties they're fully decentralized because the card actually custodies the keys so interestingly enough these cards actually just act as full wallets they custody signing keys they can sign arbitrary data they can sign arbitrary transactions and so they act as full wallets but on the other hand these cars are somewhat difficult to use namely they're expensive they cost a lot more than the Mac based cards and they're also much slower and this is the main reason why we use these Mac based cards the N tag 42s for ZK Summit it's because

the tap experience is way better takes less than a second versus these signing cards would take uh multiple seconds to generate a signature and that's actually because these signing cards are generating signature on the chip it's a low power environment um and hopefully that technology can improve in the future okay so to summarize NFC is a really great educational tool it's really tactile and physical uh when someone is introduced to NFC for the first time something we hear a lot is oh wow this actually feels real it feels like you're actually getting something when you tap an NFC chip and that's how cryptography should feel uh it's really engaging and it automatically elicits human connection when I tap you I have to be in the same physical vicinity as

you I have to be right next to you uh and so we're engaging in a physical ritual when I actually get this tap but at the same time NFC is not super expressive it kind of can only express one thing which is that we have this physical relationship so we were looking for more ways to have programmable computation on top of this NFC data layer and that's where we got to ZK proofs and specifically we use ZK for verifiable data and being able to prove things about your social graphs and about your own personal private data so our Tech stack is roughly this we use baby jujub signatures for NFC Taps that's what the chips give uh their ZK friendly signatures uh we use ZK email and TLS notary to be able to export web2

data and be able to use it within our applications in a verifiable manner Gro 16 proofs for efficient client side proving and we use Nova and other folding schemes for folding multiple signatures together to be able to generate summary proofs of an entire event experience so at a high level these are some of the uh experimentations we've done in the past at devc connect we did events gated upon Taps so you meet the event organizers get Taps from them to actually join their event uh at e themer we had prizes based on generating ZK proofs of Engagement meeting certain people or going to certain uh events ZK last year we did a Spotify rap like experience where you could fold all your signatures that you generated

throughout the event into one single folding proof that represented your whole event experience and finally at a re recent residency we experimented with uh ZK email um and basically allowed you to import your calendar social graphs from your email uh as well as verifiable events uh that you were going to attend in the future and this allowed you to ask other people within your calendar so graph to see hey am I going to any events with you in common am I going to see you anywhere in the future okay some quick Reflections on ZK it's useful for importing personal data you can do it in a verifiable manner um but largely speaking ZK is still limited within this social app use case uh it

doesn't allow full expressivity and it's largely a single player thing I'm proving things about myself about my own data to other people and it's great for these low trust environments where I want to like limit what I send to other people and this is really interesting because comparing ZK versus other tools that we'll uh experience later on ZK is centered around minimizing the amount of data that you share versus something like MPC and FH as we'll see really allows you to maximize the amount of data you share and look for more connection and share everything because it can be done in a safe and privacy preserving way so that leads us to our first multiplayer tool which is private

set intersection all of you can experience this on the app if you uh go meet someone you can see what you have in common and what this enables is for someone like Alice and Bob who've never met to actually see what similarities they might have how this works is that Alice and Bob's interests are both encoded as interest vectors and this PSI primitive allows us to find the indices where both of them share something in common so in this case Alice and Bob meet each other they filled out their interest vectors PSI allows them to discover that they both are Lana fans and also are going to Coachella to see her this expands naturally to the multiplayer setting where Alice Bob and Charlie want to discover times to meet they want to find out when they can all

interact with each other and hang out uh and so they all share their calendars but they do so in a privacy preserving way here PSI is used to find similar times where all three of them are all available and this leads to more effective social coordination in general in the multiplayer setting now some general thoughts on PSI it allows you to use privacy in an offensive manner so often times we think about cryptography as defensive tools used to secure your data keep something private prevent you from getting hacked in this case it's offensive it actually allows you to share more because you can do so in a safe way and therefore discover more meaningful social Connection in addition it's pretty easy to understand and

explain PSI is largely centered around hey like let's just find out what we have in common it's a very simple thing that people do anyways um but ultimately at the end of the day PSI is still largely limited primitive it is just one interaction that you can do uh it's only hey like let's see what we have in common and what we realized when we were building it is we wanted to look for more expressive forms of computation more things that allowed you to do uh comparisons or averages and Vivic is going to talk to you more about PR like that yeah so this naturally brings us to more General multiparty computation and the specific scheme that we've spent a lot of time and resources in is multiparty FH and the reason for this is

that we're mostly building in consumer settings where liveness and compute are both kind of like bottlenecks liveness here uh represents a number of back and forth rounds between two parties uh because people put their phones away um that basically stops a computation from happening if it takes multiple rounds so multiparty FHA has really favorable kind of rounds compared to stuff like secret sharing and garble circuits and the other nice thing is that it kind of offloads computation to a server there's two main modes that we've worked with uh multiparty FHA in the first is interactive and so basically there's uh initial NPC to set up a collective public key amongst a group of folks so this Collective public key is generated such that no individual party

knows its corresponding private key and so everyone can basically feel safe to encrypt their data to this Collective key at that point you can send all of your data to a server and the server can do different operations in this case it's just a multiply and get some output all you know encrypted to this Collective public key and then finally there's a second NPC process to decrypt this data and so again this is really nice because you basically can offload all this compy to the server but there are a lot of rounds initially and in the second phase so as Andre mentioned PSI is available in this app and actually it is built using multiparty uh FHA because it happens to be you know very efficient and one thing you might notice when

trying it is that like you we actually require both of you to opt in at the same time so it's kind of a synchronous process and the reason for this is that there's probably like seven back and forth rounds and it's really difficult to build a good ux unless you require both parties to just kind of sit there and let the whole compute finish and we've tried in the past where sort of it's more asynchronous but then yeah if someone puts their phone away then basically the whole computation is blocked and it can just take a long time for any sort of like results to populate one thing we'll highlight actually with the PSI is um you can also in the app put in cryptographic hot takes you can get overlap on that and you can sort of safely share those things uh update from

these zk1 mock the second mode we've started to work with is something called non- interactive multiparty FHA which I think is not quite a thing in the literature it's something that was uh pioneered by this group called G Labs uh that we work closely with and it basically gets rid of this initial MPC where instead the server generates a shared key and key switches different parties data to the share key itself and so this is nice because it skips this initial NPC but also each party only needs to encrypt their data once they just encrypt it with their own public key and then the server can handle basically this key switching operation to bring it to the shared key the rest of the process continues as normal the server doesn't

compute there's a collective decryption process but you do save a bunch of rounds here here so we actually built this at a recent conference uh called Frontiers in San Francisco and the setup there was essentially private job matching so a candidate and a recruiter uh could post basically a job profile and a job description privately and every time you sort of met someone we basically run this computation in the background to see if there was overlap in your kind of uh sort of encrypted data you uploaded and we found this interesting because as a candidate often you know you want to be looking for better opportunities or at least search what's out there while you're still employed at a specific place and it's really difficult to do this in like a public fashion because

you don't want to you know mess up any relationships with existing employers and so this setup basically enabled this sort of stuff to happen only if there actually was an overlap you don't need to reveal that hey I'm looking for a new thing it'll only surface if like the candidates you know interests and salary requirements actually fit with the recruiter has in mind so you can imagine the candidate putting like some super high salary requirement just to see what's out there and this actually reduced the number of rounds significantly but there's still four rounds of communication which means there's still kind of this weird back and forth where if Alice puts her phone away then Bob is kind of like blocked from receiving any results but overall um this is a significant Improvement upon a lot of other NPC schemes especially in a consumer setting and again it's really

nice because the server can handle all this compute as well and so like the user on their you know you know compute limited device only has to handle generating a public key and doing encryption and destion one huge downside of FG schemes in general is especially in the multi party setting it seems like is the uploaded public keys are huge um so to get like you know SEC like 128 bits of security uh you usually require like keys and like the tens to hundreds of megabytes and you know if you're kind of trying to set this up in like an app experience this is a huge load for someone to upload even on good Wi-Fi but especially on like you know something like a conference Wi-Fi or like on data and there's also a huge huge uh blow up

in the data you're encrypting as well because you're adding all this noise and other stuff to make it fully homomorphic so uh that brings us to um Trinity which is a scheme that we've researched inhouse that we think answers a lot of these different requirements in particular um there's kind of one round necessary of computation with one kind of initial pre-processing phase that can be used for many different NPCs and it also comes with verifiability out of the box the inputs that are going into this multi-party computation uh can you can basically verify that they you know correspond to other data it's called Trinity because it's a combination of three different powerful cryptographic schemes the first is garble circuits basically the same one from you know Yao and the 8S um k your

witness encryption which is a relatively new result from 2024 and good old plunk uh actually any sort of ZK snark that uses kzg works but uh We've chosen to use plunk because it has great tooling and great performance I'm going to go through each of these quickly I'll keep it pretty high level um but for Garbo circuits this is essentially a general purpose uh two-party computation tool you can make it multi-party but it's really shines in the two-party setting and the problem or the reason we haven't used it before is like this oblivious transfer section here classically requires like usually three rounds there's ways of like kind of lowering that to two rounds with some other techniques but in general there's basically a bunch of back and forth that needs to happen and so again it makes it really difficult to use vanilla garble

circuits in consumer settings cases witness encryption comes to the rescue here um the high LEL API of kg witness encryption is basically you have a normal Vector commitment you have different indices from one to n or roots of unity and you're committing to some dictionary and what you can do is you can essentially encrypt to this kg commitment at a specific opening so if this kg commitment at you know Point like index I opens to D ofi then uh the sort of like committer can decrypt a specific encryption you make but if that opening proof doesn't exist then you can't decrypt so it's basically like you can sort of yeah basically do these sort of like um committing to a vector and

it's all very efficient just inquires like a few pairings and some EC moles and the main application that uh the authors of this paper built it for is something called laconic oblivious transfer and so this is also kind of um very detailed but the rough idea here is that you can essentially batch a number of OTS into one round of pre-processing which only shares a like constant siiz kg commitment and then you can use that constantz kg commitment across many different oblivious transfers and so if you kind of include this oblivious transfer data alongside your garbling you just have one round total of computation which is really really nice for Consumer settings finally plun comes in because this kg commitment you can essentially attach a succinct proof of

validity in the settings we're operating in this kg commitment corresponds to the various parties like inputs into a garbled circuit and by default there's no verifiability on this it's kind of like you're trusting the parties to put in the right data but you can essentially for very cheap attach a proof uh like a plun proof where you know your kg commitment at a high level can just be this First Column and you can attach a bunch of other data like ZK email ZK TLS data to prove that your commitment is valid and this is all very efficient and very succinct and so altogether U basically Trinity enables this sort of like one round of data transfer to do a qpc uh which again in consumer settings is like super useful because people put their phones away

basically and in addition you also get um validity proofs of your data uh for very cheap and also very small proofs like small enough where you can you know feasibly put them on a blockchain the upshots of this are that Trinity actually we're still working on implementing Trinity uh should be up in a few weeks at Edge City and Devcon so these are more kind of what we're looking forward to uh versus Reflections but we think Trinity will enable really simple developer experience and user experience for building and using uh consumer GPC um because yeah when you don't have to think about all these rounds of computation that's actually a huge load taken off of both the developer side and also on the user um basically interacting with this app next um the cool thing is because we're building off plun and in general

any kzg based um ZK snark you can actually build off other ZK proven data that users have posted whether it be in blockchains or other settings Trinity can plug into this very naturally uh which is really really neat especially in a world where you know hopefully people are generating more and more proofs about themselves and maybe the overall sort of like mental model to think about with uh Trinity is that you essentially for Alice and Bob Alice can send Bob this encrypted email with basically a set of criteria and some sort of hidden information and Bob will only ever get to see the hidden information if he actually matches this criteria and so it's kind of this combination of like witness encryption and multiparty computation and it just enables we think a bunch of new kind of

affordances that we will go through now because we think we finally sort of through these Explorations G to some really exciting views of what future coordination communication could look like with between different humans the first one is this idea of unbreakable consent and this actually is kind of flipping what's often thought of as a flaw of NPC which is that parties can exit a protocol early which basically means that for everyone else involved they might not get the result of the computation they might not get to decrypt in the case of like FH based multiparty stuff but at least when you consider the 2pc query response setting this actually is like a real feature in that for Alice to learn anything about Bob um it like Bob needs to sort of

participate or consent to participating in this kind of decryption process for any information to be revealed and so it's kind of like mathematically required that you know both parties or all the parties involved consent to what is going on before anything is real and this is a very very different model from existing situations where we just kind of Hope servers do write by our data um which often times you know they're training their own models they're selling it to whoever they're selling it to other people to train models so this is an exciting new sort of way of existing digitally the next is the idea of digital pheromones so for anyone who's unfamiliar a pheromone is a chemical substance produced by an animal to signal to other individuals to engage in some kind of behavior other individuals

in the same species and one way we've been thinking about these sort of uh Trinity kcg commitments which again are sort of commitments of different people's like input data is that there's these very lightweights you know they're like constant size and also like undetectable and that there's you know computationally hiding signals that we can start putting out into the world and then using this sort of like encrypted email kind of like querying we can just sort of freely discover Synergy in a way that is like safe uh consent is like deeply baked into and potentially just like discover a lot more sort of serendipitous Synergy between people in a way that the sort of current model of social media with like public Billboards really just does not facilitate very well finally uh there's idea of narrowcasting so narrowcast is the

opposite of broadcasting and this kind of really builds off the sort of like encrypted email idea where instead of just being dependent on like public feeds or group chats you can sort of just narrow cast information to the people that it would be most relevant to where you can be sure that you know only if they match the criteria that you set set for this data could they actually see it and interact with it and we also think this will enable lots of interesting ways of connecting and coordinating with people that aren't easily available right now so where can you experience this technology um all of you can experience it right now um the app that all of you have built off the NFC cards in your badge have a bunch of these experiments and we want to reiterate there's some fun prizes for people on the leaderboard

and right now the first five people who get I think 33 was the number we decided um get to take home some NF rings as well um which will be sort of Early Access to different experiences we're building so at Z Summit we've basically kind of just like thrown a bunch of fun cryptography apps into one experience but for Edge City Devcon and onwards we're building a more cohesive single app called cursive connections where you can sort of take your social graph from many different events import data from many different places and essentially discover new connections you know learn more about different people in your community get recommended events and sort of a kind of holistic platform for a lot of these different ideas we're exploring if you're at either of these events please come see us or come find

us we would love to get you a chip get you started on this and yeah happy for any and all feedback finally uh we're very lucky to be hosting a really large booth at Devcon uh right near the entrance of the venue and it's going to be modeled as a museum exhibition focused on cryptographic connections so this is both like past uses of cryptography for connection like ciphers encryption even like ethereum uh demos from some some of the sort of Cutting Edge projects in the space as well as a bunch of different art exhibitions on just you know for different artist friends of ours like how they interpret cryptography connection and this sort of thing and we are actively trying to find collaborators to do demos to to make art pieces so please reach out to us if this is something that interests you or your

company uh we would love to collaborate and make this cool a little about cursive uh we're research and Design Lab focused kind of exclusively on these directions and yeah this is a place that's very near and dear to our heart and everything we've described here has been the result of many many collaborations and we want to continue that going forward so yeah if this is a research or product area that is of interest to you or to your group uh we would love to try to figure out ways to work together uh get this Tech into hands of more people and finally we owe a big thank you to privacy and scale expirations uh cursive is Grant funded uh from PSC which is a sub team of the ethereum foundation um the grant support is amazing it's allowed us to do very for

exploration but the network of collaborators and sort of positive sum public goods work we've been able to put out while being supported by PSE has been nothing short of miraculous so huge shout out to them and yeah these are places to follow our work going forward thank you thank you very much do we have any questions otherwise I guess we're at time oh here we go let's give you one second thank you um really interesting talk um I'm just curious what is a um

like a ZK consumer um product that you would like to see in the world that maybe you in particular don't want to make but think should exist that's a great question um do you have a good answer up do you have a good answer ZK consumer product I prefer MPC consumer products I think well this is more of a shout out like I think some of the stuff that the folks at ZK P2P are doing is really interesting um I think that's really focusing on the verifiability aspect of ZK which I think is a lot of sort of room to or like a lot of value to get from that um yeah basically

enabling sort of more verifiability on data Exchange that sort of thing um also especially around High sensitivity data like financial data passport data that sort of thing I would love to see more ZK on and yeah I think in many ways we have chosen not to focus on ZK because a lot of the stuff we're working with is more social and personal in nature and we think doesn't benefit as much from um ckps as some of this other stuff but uh yeah we think there's a lot of cool stuff to explore I think last question and then Lun time great talk um was wondering if you if Trinity can in any way counter like the raidering attacks that you have with PSI

like you just create a lot of uh sham accounts um and try and see how you intersect with someone like with triangulation yeah that's that's a great use case of this sort of verifiability and it's a it's a big sort of bug of the current PSI actually one thing I'd like to shout out is um a project called Greco U built by Tima is now working on new iterations of it off of work from enrio and J maaya um that's one that is basically doing a similar thing where it's proving that data has been encrypted correctly as inputs into a PSI into an NPC so yeah ZK is a super important tool uh in all sorts in like all of these crypto systems in basically ensuring that the Integrity of this

stuff is is is strong because you can basically just do more meaningful computations that way but yeah that's that's a great use case number two thanks let's thank our speakers once again thank you very [Applause] much and we now break for lunch I believe lunch is served upstairs don't remember that remember there's also a bunch of merch that you can take uh we've been getting messages that it's all for grabs and we'll be back at two I believe [Music]

[Music] [Music] [Music] is [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Applause] [Music] [Music] know [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

e [Music] [Music] [Music] [Music] [Music]

[Music] YouTube premium a YouTube Say and G [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

is [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] foree [Music]

[Music] [Music] [Music] [Music]

[Music] e [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

in [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] hello hello hello okay everyone we're going to get started with our talk after lunch we have stepanos here from Imperial College and ziki security uh so today I'm going to to present a joint work with uh itamar Adria yens AIS and Ben on analyzing and benchmarking ziki rups uh so I will start with a

brief uh introduction ction on what is blockchain scalability what are rollups and what are ZK rollups and then I will describe what we did uh our analysis some preliminary Benchmark results for uh ZK sync era and polygon ZK VM and also then I will discuss a bit the implications in particular for transaction fee mechan design for ZK rollups so blockchain scalability is often framed in the context of the blockchain in trila which is basically um which highlights uh that we can't have a simultaneously scalability decentralization and security and

blockchains such as Bitcoin ethereum has have historically focused on decentralization and security whereas someone might claim that some of the modern blockchains can achieve all three of them but that's a different topic so if we want to scale something like ethereum what we can do is we can use rollups and rollups are L2 Solutions scalability Solutions uh that basically move the execution of chain they execute transactions update the states of chain and then they submit some data and we will see what data on chain and do some verification of that execution on the main chain which is what we call on

chain and in particular ethereum in the last couple of years it has a very very rollup Centric road map there has been uh improvements that are mainly focused for improving the efficiency of rollups uh the most important example is a Proto dun sharding AP 4844 which basically introduced blobes that makes da much cheaper in ethereum so how a rollup works is that we have a completely different blockchain which we call the rollup or L2 or offchain computation and um in that rollup we get transactions we M transactions into a

block or validate them into a block and then we batch together multiple blocks that we will then submit um uh the data for that BGE on the L1 and later we will actually verify the correct execution of the transactions of the bats and we have two main types of rollups optimistic r s which basically um they secure their transactions with fraud proof in an optimistic way so they assume that all transactions are valid by default and only run some computation a fraud proof basically mechanism in uh the event that some observers says that

uh some of the execution was not correct and they have to submit all the data and typically they have a quite long finality period because you have to give give uh uh at the moment it's one week for observers to make sure that have check the BS and uh to basically finalize completely the transactions of the Bots uh the other option are ZK rollups which are basically using succinct proofs of valid execution that can be verified on chain without re-executing them um verifying um uh validity proof uh on the old chain has become much cheaper the last couple of

years uh we have more options on compressing the data we need to publish all the L1 and also time to finality it could take some minutes or at most some hours noway uh so now I will give a more uh thorough overview of how explicitly Z rollup Works uh so we have LT users that interact with our LT to blockchain the ZK rollup in that uh uh case and they submit transactions to the sequencer at that point their transactions are pending then the sequencer creates some blocks and BDS together all the transactions into a single Buds and the

size of a buds could be from uh uh some dozens of transactions up to some thousands of transactions and at that point we say that our transactions are uh pre-confirmation have been executed in the L2 and then we commit to that BS in the L1 so we create an L1 transaction that publish the data of that BS the data of all the transactions of that BS in um the L1 and at that stage we say that our transaction is committed uh in the meantime the uh L2 will send the buds to approver and the approver will actually uh create a succinct proof uh for the

bats and when that succinct proof uh is created we will submit that proof to enl one smart contract that will actually run the verifier and verify the correct execution of the transactions and at that point we can say that uh our transactions have been finalized and we are safe to proceed so uh we had a few research questions for Z rups in particularly and we wanted to investigate it what are the fixed cost and fixed costs are the cost of uh a bats independently of the transactions that have been included in the bats marginal cost has to do

specifically with transactions and uh then we have um we want to explore the tradeoffs between fast finality and uh cost minimization uh we will present a complete breakdown of the different cost for um Z ging era and polygon with some custom pretty naive payloads and uh finally we will discuss a bit the impact of uh blobs so here are some of the ZK rollups that have been implemented we have polygon scroll and ZK syera which basically use a ZM evm as their VM and they try to be either evm compatible or

solidity compatible and then we have some other options for example Stark net we have Aztec which is more like a privacy oriented uh rollup so we chose uh to go with h polygon and znc era because we wanted to focus in scalability Solutions we wanted to focus in systems that are in production and we also wanted to have a solidity compatibility to be able to compare kind of apples to apples although that's not completely true as we will see and um those were the only two solutions that at that point at least were fully open sourced um so some notes Here is that

both used two proof systems uh one for the initial proving and then they want to convert a larger proof a stark proof typically to a smaller more extinct uh proof that will submit to the L1 and another main difference is that polygon submits transaction data in the L1 published transaction data whereas Z sinera uses STS and finally polygon uses a large CPU based machine at least at that point and ZN era has a more complicated Hardware um specific ation where basically they use many GPU based

kind of smaller machines so here is another way to see the landscape and basically the compilation process and as I said we want to start from the solidity part to be able to transa to um compare similar payloads so what are the cost first we have fixed cost which is composed by settlement and proof con proove compression by settlement we mean two things first is the transaction to commit to a specific bats on the L1 and that includes all the gas cost but not the da cost for that bats and uh

secondly is um submitting the proof and executing the verification logic in an L1 contract and secondly another uh fixed cost is the proof compression of proof uh transformation which is going from a stark proof to snark proof that's also fixed independently of the size or uh the type of transactions in the bats and uh for um uh marginal cost we have da uh which is how much does it cost to publish some data on the L1 we have the proven cost which is how much does it cost to uh prove c c transactions and we also have some other

to cost that for that work we will say are negligible so here is our methodology so we start with some payloads and we opt for some very naive and simple payloads uh because we wanted to have full control we wanted to be able to run um our methodology for both um uh rollups ideally you would want you would like to experiment a bit with a get some historical logs from ethereum and run them through both but that's a bit more complicated it's something we want to do in the future um and then we have our metrics so when we run the payloads um uh through the the rollups we get a bats

and then in the bats we extract uh the da we will need to publish in the L1 we also extract uh the settlement cost the L1 gas we will have to pay for both committing and and verifying uh the proof and uh then we have the prover so uh for the prover what we decided to do is to keep track of uh seconds per proof and also USD per proof and USD per proving a transaction and we will I will present some results uh later on and finally the configuration for both uh uh machines is this one uh here I should I should note

that both prices are a bit not a bit like two or three maybe even five times more than what polygon and Zar mat labs are paying because uh they have better deals with uh uh Google and AWS we just got a machine for a month and that was it um so you can bring those cost even lower so here we break down the fixed costs and I want to start with describing the first major change between the two approaches um zik Sync has really huge batches whereas polygon Works in smaller batches that then

actually Aggregates multiple buds into a single proof and it works in that way uh so we can see that ZJ Syer budges are in terms of uh some thousands where polygon are some dozens of transactions the theoretical mat buts size was at that point maybe it has been improved and um it's also um simple e transfers so if you want to do more complicated transactions then uh that it's much smaller uh then we have all the fixed costs and there the numbers here are pretty uh comparable uh we can see again the difference in polygon's case that

you have multiple budges included in a single operation for example typically they submit five bues when they perform one commit transaction Etc and what we wanted to focus here is the normalized cost per transaction and we can see that it's pretty low and as we will see later on fixed costs are uh the main uh cost for um uh ZK rollup transactions at the moment and uh we will analyze a bit more how that might change if da becomes more expensive if proving becomes cheaper Etc and also we had uh the normalized

cost in the theoretical case where you have as many transactions as possible and we can see that the number is pretty low for uh both uh rollups so here we have uh the first results for the marginal costs and we have how many um uh bytes we require per each of those payloads in terms for da uh the our payloads are uh super biased towards State divs and that's because for example if we have many transactions um that means that uh if we have many transactions all those

transactions will kind of touch similar state so State it's the perfect situation for St this um and I want to highlight that result uh because we will see later how that might affect how you want to actually sequence transactions um but we can see that in extreme cases you can achieve pretty good compression I will say by using State divs H next here are some marginal cost results for uh polygons zvm and uh we can see on the left um figure The Proving plus compression time and how it evolves when we have more

bigger inputs this is I think for transfers or erc20 transfers I don't remember and we have the time it requires to uh do the proving and that's important because basically our finality time is bounded to our proving time and on the right side we can see the cost per transaction and we can we have two lines uh the first line it's when we use C data as our da so that's why it's more expensive and the second line is when we use blobs so we can see that especially for blobes if you manage to fill a buds then it doesn't make sense

to wait more time and uh to detriment your finality but it's another tradeoff and there could be different options on how to handle that on the zsite uh here is the total costs of polygons um ZK VM and um so first of all da at the moment it's virtually free for rollups in general uh so all those results should be taken with a bit of Sal because that might change in the future if changes happen or if there is more usage of blobes and more uh demand and prices go up uh and that's why we

also captured what will have been the cost if they used C data with prices before uh the introduction of uh Proto charging um which you can see when we have a larger size of buts then da it's our main cost in case of uh uh using C data uh here we have basically our main fixed cost we can see that proof compression is pretty cheap already and I think both teams have done uh an order of magnitude um Improvement in their proof compression and um we can see um on the left side is the percentage of

commit cost when we use blobes Asda and on the right side is when we used C data and we can see that the fist cost actually decreases as we increase the size and that's because the fixed cost per transaction it's lower because we have larger Bates and um also we can see that proving starts to become relevant only if we try to actually minimize our costs which is the case when we try to have huge budges and only that case it starts to be a bit relevant in the cases Where da it's not expensive at all it's virtually free and also uh here is the cost per

transaction and um uh we can see that um as we increase the bat size then the cost and transaction decreases but that comes at the cost of longer finality times which might be important for some users might not be important for some other users so what are some main tradeoffs um we have the trade uh we have the some main takeaway sorry uh we have the trade-off between fast finality and cost efficiency and that's especially important when you don't have uh High volumes of transactions and maybe you want to delay a bit so you provide cheaper prices to your um users or you

might have to have a different mechanisms there so some people might opt for uh fast finaly and some others are okay with waiting a bit to be included in the next bats uh then we have state divs efficiency and here we saw the extreme case of how much better State divs could be um what I want to mention here is pretty close to the next Point importance of sequencing so for State divs uh normally in L1 I would say which transactions are going to be in the next block it's more about meev in rollups at the moment we don't have me

uh but even if we had it's a nice question especially if da is your main cost um to try to put in the next block in the next bat basically transactions that will maximize your state diff uh your state diff's impact and similarly what we noticed is that we have a similar case for provs so for example example in polygon's case if you have a transaction that does um a single chak H you will have to pay the cost for proving chak CES so what you want to do to amortize that cost is to include as many transactions to fill that gak space

in the prover uh to minimize your proving cost per each of those transactions and finally we also um so that basically the impact of a 4844 what's great for ZK rollups there is a lot of discussion if that should change if that should should not change uh but we guess that some strategies it will be nice to be uh developed in case that um uh blobes start becoming more expensive then you might want to move temporarily to H C data or if you don't have many transactions and many data to

post for your budges but you want to have a fast finality you might want to try to um share blob space with uh other rollups if that's possible Etc so some open uh research questions we have identified uh is basically what is the impact of this decentralization on cost what happens if we have if we start having more costs in the L2 now we said those costs are negligible but that might change um what are some strategies for bad size and uh sequencing optimizations and how you can basically uh take uh the best out of your approver

and out of your of the state divs or what other else compression uh you are applying um we also want to do some uh metering mechanism evaluation because in some cases the proving cost may not completely captured by the existing metering mechanism uh and also we want to uh try to develop a proving Market mechanism specifically for ziki rollups that take into consideration all the results of this work so uh that's it you can find uh our paper in that Q our code and we also have published all the scripts all the results in the GitHub repo that you can

find through the paper thank [Applause] you are there any questions everybody understood everything it's impressive all right thank you again [Applause] cheers just quickly um we just want to to announce quickly uh if you guys want to join the ZK Summit Afterparty happening tonight the link has been shared in the ZK podcast main telegram group and we'll put up the QR code uh

after during the break so up next we have Elon from bar Elan University discussing hash-based multi-linear polom commitment schemes wow just maybe maybe we just give it a minute so we give people the the shuffle in Shuffle out yeah the title has a slightly slightly changed if you want if you want

e e e

e e e okay everyone welcome next up we have

Elon from bar Elan University uh take it away okay thank you hi so first this is Joint work with my student ginon and alesandro Kessa and Jak fenzi and I'm kind of very excited to be here and this is a kind of present we this is the premere presentation of where last ZK Summit we presented the stir and this is kind of a new Improvement on top of that so where is a readed Solomon proximity test and it has super verification and so I'm going to go slightly into technical details about that and we're also going to see benchmarks and uh yeah so let's

start so first in the zik summit um conference and what we what are our goals we want to construct snarks okay these are sucin non- interactive arguments of knowledge so we have aover we have a verifier the prover wants to convince the verifier that he knows the solution right he know a witness to the to this instance and in our case the prover and verifier are going to share something's called a random Oracle as Anna discussed this morning so they both have access to this Rand Oracle which they can query and get back a completely random answer and we want the proof of course to be kind of very small okay in

particular much much smaller than the size of the witness itself okay so we're going to only have a random Oracle there's no other assumptions okay assumed in this talk once you have such a scheme you can replace the random Oracle with some concrete hash function okay so you instantiate the random orle with a hash function and uh what you get is a snark that you can deploy in practice and the advantages of such snarks are that they have a transparent setup okay so the only setup that they require is choosing this hash function they usually they usually are quite highly efficient so there's no

public key crypto there's no elliptic curves and stuff like that there's only um hash functions and usually over small fields and stuff and so they're quite highly they're fast and they're also postquantum secure if you care about that of course today these snarks are used to secure billions of dollars in blockchain transactions I guess you know about this this is just a small subset of the companies using this stuff today okay so how do we construct hash based snarks what we do we do the follow we first construct an IOP an IOP is an interactive proof between aover and

verifier where the verifier does this small number of queries to the proof these are the green locations here then you take this proof and you compile it using something called the BCS transformation okay um roughly speaking every message of the IOP you're going to mirle tree okay you're going to create a mircle tree and commit to it and then when the verifier wants to read something something you're going to send the authentication path and all these long rounds of interaction you're going to use f to compress to one message okay and the efficiency of the snark is mainly determined by the efficiency of the IOP so the prover is roughly the same the verifier isly the same with

additional hashes and if you have some proof lengths of length L and Q queries okay usually the proof length is kind of big this is the size of your computation let's say to 24 and you have some number of queries this is going to affect the argument size at the end and the verify running time and so on okay so we want to construct more and more efficient iops okay for the relation you want to approve for R1 CS or something like that how do we construct these iops and this is the last slide before we go to steer to to we um what you do you construct this polinomial I s okay so a polinomial IOP is just an

IOP where we restrict the honest and malicious Prov to send only pols okay so they have to send pols and the verifier what can he can do he can query this polinomial you can evaluate them at any field element that he wants okay so the prover is going to send some polinomial Q then the verifier can query this this Q at some point x and then you have maybe some polinomial p and Q and and so on and once we have this polinomial IOP what we do we compile it to a standard IOP okay that is then later going to go to the BCS transformation and how do we compile these polinomial iops what we do we

either use a polinomial commitment scheme which is just a cryptographic way of enforcing the prover to really commit to a polinomial um but actually more generally I just want to take this slightly higher view as any compiler that takes a polinomial and outputs an IOP okay so one way to do it is using a polinomial commitment scheme and then doing this function by function but any such compiler is is what we want uh and any such compiler is in particular actually a polinomial commitment schem okay um we have many examples many of the snars we know today use this uh this blueprint to construct snars and

there's many examples not going to name all of them the polinomial commitment scheme that you use underneath could some could be kzg or something based on latices or something like that or it could be something based on hash function so a hash based polinomial commitment scheme and this is going to be the focus today and I'm just giving a few example this could be fry based or steer based or Bas fold based and this is the three examples I give because we're going to mainly compare to them because they're the most relevant to this work okay so the way these hash based Pol commitments can work we ask the prover to kind of instead of sending a

polinomial evaluate it at many points and then we kind of need to test what the approver do so this lead us to a result so in this work we're introduce a new polinomial commitment scheme has a a really super fast verification okay so more technically what we do I need to uh Define what the read Solomon code is so we recall what the read Salomon code we had some finite field F okay we have some evaluation domain L and we have some parameter m m is going to be the the degree and then we're looking at the read Solon code so these are all

functions F from this domain l to the to the fields okay so all evaluations of functions such that the function is uh univ low degree polinomial of degree at most 2 to the m okay so m is going to be log log the degree in this example so this is the re Solon code and equivalently in this work we kind of have this dual view of the re Solon code where you can look at it as a universe polinomial or a multilinear polinomial so you can take the 2 to the m coefficients and you can view them as coefficients to a Univar poomi okay of the GRE 2 to the m or a multilinear

polinomial okay that has M variables okay so we have this Duality between the two either we have M variables or just one variable with degree two to the m okay so what we do we're going to h define a constraint R Solomon code okay this is going to be very helpful for us H and this will allow us allow me to tell you exactly what we is H so a constrain read Solomon code is just a subset of the code words of read Solomon that has this additional sum constraint so there Su Check Line like constraint that you add upon it so my

code now is not all code words okay but just a subset that satisfies some additional constraints so this W is going to be some some polinomial and sigma is some Target sum and then I'm looking at all the polom in the multilinear okay notation that satisfy this additional sum and this additional sum in particular is expressive enough um to express a constraint of evaluation of this polinomial F so I have F and I want to say oh but F on some point Z equals Sigma and there is a way to translate this to to such a constraint okay and this is what allows

us to use we as a polinomial commitment scheme okay so what is we we is an IPP an IOP of proximity for constrained R Solomon codes okay where a fry if you know fry fry is an IPP for read Solomon codes and steer is also an IPP for Solomon code we is going to be an IPP for this constrained read Solomon code okay or in other world in world of you know higher marketing world it's a polinomial commitment scheme for either univ or or multi-linear pols okay so it works for both um so for degree 2 to the m okay in

the univ case or M variables with some security Lambda and folding parameter 2 to the K this folding parameter is some parameter some of that we can play with it means that like in the fire protocol in every query you kind of read two to the K field elements okay the query complexity of Weir is this expression this is Lambda over K * log M okay and forget about this complicated expression we'll we'll see it in a second and we'll have Ben benchmarks also soon uh we kind of set K to be roughly log M and then what you get is the query complex is actually o of Lambda which is actually optimal the verifier running time The verifier

running time is this query complexity well the verifier needs to do something per query right times 2 to the k + m so again 2 to the K is going to be the bigger term here and for every query the verifier reads two to Decay field elements this means that in terms of of field operation the verifier is actually linear in the number of field operation it reads from the proof okay this what makes it makes the verifier very fast and uh not only that actually the verifier performs zero divisions okay so not divide by zero but doesn't perform any any divisions okay the alphabet is what I said you have you read two to the K kind

of field elements in every query this is the round the complexity it's M over K and the proof length is is linear okay so what does this mean how does this compare to Prior work and what did it mean with with the actual numbers okay so first let's compare the query complexity to to some prior work so base fold Bas fold is a multilinear polinomial commitment scheme their quer complexity is Lambda times M fry if you know the fry protocol has qu complexity Lambda over K * m so Bas just just doesn't have this folding parameter built in so it's kind of fixed to one H stir stir is a uh polom scheme

that we introduced last ZK Summit that kind of improves the fry so you can see the Improvement here so the quer complex is Lambda over K time log M instead of time M so it gains a huge Factor there and we just borrows the same query complexity as still okay so it has like the the small query complexity now in terms of the the running time base fold is actually linear in the number of queries so it's O of Q base fold okay that's good but it kind of has a lot of queries H fry does this has a running time okay this is the verifi running time of O of Q fry time K * 2 to the K this makes a lot of sense because fry needs to do like this small

fft of size 2 to the k for every query that it reads and so this k 2 to the K is just the time of an fft of of size 2 to the K okay still has this H slightly even walls running time okay has this plus Lambda Square okay which sometimes is actually could be quite big and the the running time of our verifier is actually qwi which is the the smallest Square complexity times 2 to the k + m okay so we even shave off shave out this Factor K okay now it's really linear in the number of queries and not quasy linear an extension field of the goldilux field I really want to thank

Remco for helping us rco from World C for helping us with like a optimization of the the P and verifier um what the Benchmark are going to see today are like partially paralyzed so there's a lot of room for improvement for the P running time if you if you have a lot of CPUs and we compared it with fry and steer and base fold as a polinomial commitment scheme so let me tell you about the the results so let's start so the Weir verifier typically runs in a few hundred micros seconds okay other verifiers even those that have a trusted

setup kzg and and other usually take several milliseconds if not more okay and we do this without like compromising or without some bad trade-off between the running time of the PO and the argument sides okay so it's like a a true Improvement and not a tradeoff as an example okay as a polinomial commitment scheme for degree to the 22 you can think of this as like roughly equivalent to 4 million constraints with 100 bits of security I run this last week on my laptop I have a MacBook Air the Prov time took roughly 1 second H the commit and open together were roughly 60 kilobytes okay and the

verifier time to verify this opening was 27 microsc so roughly 1 of a of a of a millisecond okay so this extremely fast verification ah sorry here's a slightly more comparison with other schemes so we have kzg here andero and break Di and HX and you can see the numbers so usually these numbers are either large or a few milliseconds where we is the only one depending on par kind of go be below the millisecond barrier okay once you have such a fast verifier you can kind of think of new

applications that that open or improve H so I just want to really You Know sketch two things that I think are interesting so first is on onchain verification and all of these are kind of you know this is the back of envelope computations that we did and you know to get exact numbers you have to really implement this and and see exactly how much you get but today we verify go 16 proofs okay on chain over the BN 254 curve and this takes roughly 280k gas okay uh possibly you know one future is where we use we uh to

to verify this stuff over smaller fields and kind of uh some estimates that we did said if you take a degree 2 to the 22 you're going to get roughly 50k gas okay and even if you go up to degree 2 to the 60 two to the 26 this should be 80k gas okay so this could be a big Improvement in the gas cost of of of very fine poofs okay H second of course is the recursive verification so if you use we as the first step you know in a recursion in the the Second Step the p is going to run and prove the code of the

verifier and here we did another set of computation so here we went for 128 bits of security with degree two to the 28 so kind of a large computation then because the query the query complexity of we is small and the verifier is fast kind of what the we verifier is going to do is roughly 3.4k hashes okay this is to verify Amer three hashes and if you kind of assume that this hash is a posidon or most of it is Poseidon which is roughly 400 R1 CS constraints then you're going to get that the recursive circuit okay that you need to prove is of size two to the 20 okay so

you start with a computation of size two to 28 okay and then you do you run one weird iteration okay and the next step you have something of siid to do the 20 and then you can you know much smaller computation and everything is much faster and you can run whatever you want okay um comparison so here's a comparison to base fold I want to be fair and say first that we are inspired by fry and base F and steer and kind of this work accumulates many ideas and new ones from all these books H and also that uh to my best of understanding this these numbers from

the Bas fold paper are kind of not optimized in the most significant way and probably can be can be better um but okay let's see how how we compare so red is the base fold in blue we have we UD which is the unique decoding radius this is kind of without any conjectures and in green we have this Weir capacity bound so this is with this list decoding type conjecture that is not the same but kind of similar to what happens in Fry and steer and all these kind of schemes um so we start with the argument size you can see that the basal argument size is kind of very big compared to

both the the we unique decoding and capacity bound okay so even for quite large computations the argument size really is less than 100 kilobytes H the PO time you see so we didn't compromise in time so the P time is roughly the same as as base fold here it's slightly better but I imagine you can also improve the basb pver okay to make it better and you can also improve the wear pver to make it better and so this is kind of a competition um but for the verifier on time there's kind of you know there's not a lot to improve it's kind of a small piece of code which is usually kind of optimal and that's just what you get and uh so you can see that both the both version of real are kind of nearly

the 1 millisecond sometimes below maybe sometimes above if you don't assume the conjecture or the bfold one is kind of high around 20 milliseconds uh let's compare if you are familiar with fine steer maybe I'll say this point that we is a you know drop in replacement to places where you use fire steer or base fold as a polinomial commitment scheme okay so again if I compare that we can see that so steer what we introduced last Summit okay is in blue now and in red is is fry so the argument size is much better than fry this is that was the main point of steer and we just you know gets roughly the same

argument size H the PO time you can see is roughly the same in all schemes okay mainly the bottleneck of all these scheme is to do some big fft and this is kind of what they do anyway H the verifier hash complexity is much smaller in steer and and and wear okay but in wear also the field the field operations complexity is much smaller so you can see here okay so the green one is where okay and the both steer and and Fire have like a much much much larger verifi time okay how am I on time I have okay so a little more results okay

so because we was not just a readed Solon proximity test but actually a constrainted r Solomon proximity test um what we can do with it we can compile not just polinomial commitment scheme but actually this Su check polinomial commitment scheme or as I denoted here just a sigma IOP so a sigma IOP is going to be like a polinomial commitment scheme where I forc theover to send pols okay here I'm going to allow the verifier not just to do evaluation queries to this polinomial but actually sum check queries to this polinomial okay so the the verifier can specify a polinomial w okay this weight

polinomial w and you can get back this answer Sigma which is this sum okay so you can kind of do a a su check like query to these polinomial that the approver specifies once once you have this power then a lot of the effort is reduced from the polinomial IOP itself okay because the verifier is much more powerful and all of this is encapsulated anyway into the we l degre test that we run and so what we do we actually give a sigma IOP for generalized R1 CS which is a kind of has you know much more efficiency than other polinomial iops

that you get and all of this is compiled and batched together to one we invocation at the end for some polinomial and and for some constraint okay that kind of is a combination of all the constraints that the verifier quered okay so this gives a an efficient way to go from from RS to iops uh we kind of didn't implement this year yet and so I don't have like benchmarks for for this part um yeah okay so I think I have just one more minute so I'll going

to ER we have something new called mutually correlated agreement um I have a just a quick minute on that so kind of the main technical tool that we use is this proximity gaps which roughly says the following oh I have many evaluations of functions okay and I don't want to test each one individually so I'm going to take a random linear combination of them so I have C1 up to CL and I have the C star and I have this theorem by benal okay in this proximity G paper and also Dan Carmon that should be here in the conference saying that if the C star is close to read Solomon with high

probability then all the CIS were actually also close to to to read Solomon so you see C star the green spots it's where it's close to read Solomon and every CI also has to be close to with Solomon but actually what they proved is something much stronger they put something called correlated agreement okay so they Pro that this is not the right picture actually all the CIS are going to have a correlated agreement they're going to agree with re Solomon at the same domain okay so the picture is not like this but actually like this okay so all the CIS not only that they agree with with re Solomon but they have some shared domain where on it they agree with read

Solon and kind of what we do we introduce this new proximity gaps um where we say that it's not enough that the CIS have shared call it agreement but the SE star should share the same domain as well okay so the picture should be like this where C star and all the C I have a so we call this mutually correlated agreement um so we prove that any time you have correlated agreement you have mutually correlated agreement up to the unique decoding radius and we kind of still leave it as a open problem to prove it Beyond um okay conclusion we introduce we where's an IOP for constrained read

Solomon codes I think it can have other applications but the main one is of course using it as a a polinomial commitment scheme we have verification time within milliseconds Pro time within seconds and the proof size is really tens of kilobytes we introduce this new mutually correlated agreement proximity Gap H we have this Sigma IOP where we combine it with our wear okay and then you apply the BCS transformation and all of these together gives you our hash based snug this fast verifier can gain new application that's you know efficient onchain verification recursion and other

stuff um yeah that's it thank [Applause] you okay do we have any questions in the audience question this is where I get my cardio in so surely I'm I'm just not understanding something I'm I'm trying to understand why this Mutual correlated agreement doesn't follow for free from from correlated agreement can't you in other words assuming that that the CIS are are have correlated agreement on some domain can you not always just take the the underlying code words combine those in

the same way and then you get the same error domain for the C star why does that not come for free yeah good good excellent question so you're right so the CIS have correlated agreement which means that c star which also be close to the code word but what I don't get as a guarantee from the you know proximity gaps paper is that c star might have additional domain which is which it's close to the read Solomon code where the CIS are do not agree on that domain okay so I want every place that sear agrees with the Reed Salone the CIS have correlated agreement on that on that domain I see so that that needs to

be the only domain that only could be more than one could be more than one the others have to also be CL if carar has 10 domains where it's Clos that's fine but all the CIS have also have 10 they need it to okay okay it's kind of if and only if got it okay thanks that was great question any other questions okay br Round of Applause for [Applause] Elan so we have a quick break right now and we're going to share the HP uh the Afterparty information up on the

screen oh it's there there you go scan it come drink [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] all right everyone we'll be starting in one minute all righty so up next we have

Nicholas from lrange um yeah take it away so perfect yeah okay okay thank you everyone so hi everyone today I'm going to speak to you about what we're doing in BR I'm going to talk about a bit of SQL and uh more technically what we are doing behind the scenes um so let's go about it so why do I mention SQL here basically we are

building a verifiable SQL VM so that means you can crey the database and get a proof uh and the results that the result is correct um so how does it look concretely then okay looks like this uh basically we are focusing first on the historical blockchain uh data so basically if you have for example take a rc20 so think about usdc for example where there can be millions of entries from the user address to the balances um then you can actually register your SQL query where you say give me the average balance of this user for the last two weeks uh and for this address you can use placeholder as well and we're going to give back the result and the proof on chain okay that's more fact the product

facing point of view um and I'm going to explain to you how we are doing it uh doing this work and I'm happy to talk more about the produ side after my talk because it's going only 15 minutes it's very short um cool so what do we do here um we are talking first about indexing historical blockchain data so that means that every block we're going to insert the values of some slot of interest in the contract for if you have the mapping we're going to insert all the mapping entries into our own database okay that's called the indexing parts and we're going to do this at every block because because we want to keep the values uh and one to do the average F or over more complicated SQL queries down the line then comes the uh query part okay so this first time is just

insertion think of it as a Time Ser database and the second part is uh the quing parts where we actually run the SQL qu across a subset of this database and we prove the results so what is our database I'm been mentioning this uh since the beginning but we need a database which is well proof friendly okay uh because we want to give a proof so that means we we can't use things like I mean it's not very nice for us to use things like ketak and rlp uncoding for those who know how the MPT trees works on evm uh we want also to be Oly scalable just to give you a not of magnitudes if you want to do an average across a full week that's like on eum on L1 on eum it's like 50k blocks if your mappings have I

don't know 1 million entries you already 50 billions entries okay so we want to be originally scalable to be really andl large scale computation um the third point we want is also want efficient updatable that's a very very important point for us imagine between block I and block i+1 there's only one swap of token I sell some of token and gives to to another holder then I don't want to have to reprove the millions of entes for this block I just want to efficiently update my database such that we only insert this new value for me and the recipients okay um so how does it work like I'm hinted before at every block we are looking at the interest in for some contracts so for

the variable mapping thing this we can do St we can use single variable thing this uh later we also working on the transaction try reip try and everything and we are we are extracting this value we're proving that all this value belong to this contract and we are inserting the same values but in a more ZK friendly uh format so no rlp no Kack M this with a nice think of it of database as a nice BST mer with poson okay it's a fairly bit more involved than this but I'm going to skip the detail for this stock um and we do this at every block and so we transform we insert all this value into our database and then comes the query phase okay so the query phase uh here it's a very simple example where you can imagine you want just to compute

the average so you compute uh V1 plus V2 on the left node on the left side V3 plus V4 on the right side you can compute this in parallel so this is where the pars property comes into before and then you can aggregate uh the proof to get the final proof at the end so here for the C phase we use recursion uh as well bit um I'm going to focus a little bit more on the indexing part because this is like really the Crux of of what we are we are building here um let's skip this one uh so how do we build this database so we need two major ingredients there first we need uh what we call record Tre which is paper invented by the research grunch so let's take the problem of we want to prove a

membership proof for many leavs inside a tree okay it could be a Merc tree could be MPT tree um let's take the naive approach okay if we if we use a regular proof system like gr 16 or for example dkm will you the usual way you would do it is like you feed all the witnesses so you feed the value one 2 three four and you directly prove that they all uh are inside this uh this tree okay uh what happens when we update the tree so for example from block I to block I plus one there is one value a change let's say now you said the three it's eight okay well uh basically the path changed okay but the rest didn't change but inside the proof you still need to give all the values still so the comilation is linear

in the number of entries here because remember we are appending uh things so we are copying all the values from block I to block I plus one and only change the one that change uh here I still need to make Runner proof across all the values so that's not good for us uh because again think of a a large scale contract where millions of mapping entries uh that's that's not scalable enough for so what we do instead is we go more into the map reduce Paradigm instead of doing one big proof over many data we do many proof over small set of data so now we turn the thing around and we say one node of the tree is equal one proof okay so we have one proof for the node one one proof for node two three and four each proof expose the hash of

the sub tree uh that is rooted at this note okay so for example in the left orang one then we're going to have uh the hash of the conc of the hash of one and the hash of two okay and so we're going to have two proof at the middle and one final proof for the roots here we use a lot regression you can see that the proof in the middle needs to verify the proof for one and verify the proof for two and the top group proof needs to verify the children proof as well okay so we use regression all the way here so we pay a bit a bit more because Rec is not uh cheap the nice thing about it for when we update well we don't need to recompute everything now we only need to recompute the proof from the value to

the roots that change okay so this slide is wrong it should be eight here but imagine uh three is eight then you just recompute the proof for eight it's parent and it's parent and here for the four you can just load it up from the previous uh block you don't need to recompute it just take take the one that we had before okay and so that allows us to be to have a complexity logarithmically in terms of number of updates now so our assumption is like the block entropy the entropy between blocks is fairly low so there's going to be a few updates between few transfer between blocks and so that allows us to be very fast in proving updates now and so what we do is just copy the whole database and we just recompute the proof that we need to recompute and we'll

leave it as it is that's the first tool okay um the second one is digest translation so this has been hinted already by uh Yan gr this morning and we is also using uh multi set hashing so the the problem here is in MPT the order is complicated let's see it really depend on the key you're putting in a mapping like this uh evm and solidity they have very special rules and so you you don't have a nice structured order fle we could have the value 1 1432 in this order if you just enumerate the leaf like this uh and we have very different kind of branches and filling this and extension node and all this stuff uh these are non proof friendly at all and and also it it imposes a certain

order into it okay and we don't want this we want to build a database which is efficient for crewing so that means we want indexes we want a BST property as well proven so how can we turn this Weir ordering into all n's database we can't just use a hash function because the orderer is important here and this is where uh the multic set hashing comes into place so uh basically it's as explained this morning you just uh take your message you hash it and you might to a point in the group for this right now we're using plun 2 and we're using the EC gfp 5 curve and so we do a hash2 curve on this uh curve which is an based on an extension field the fifth extension Field of Gold Delux and we just compute the digest in vmpt okay so

we have digest D here we compute the digest on own database from the same value so you can see D1 plus D2 plus D3 plus D4 this is the Merle Tree in order the D2 is from the MPT but then the result is the same and so we at the end we we we ver rosly verify the true proof and to make sure that both have the same digest and see both have the same D that mean both contain the same data that we extracted and that's the second tool so basically when we put things together at each block we are extracting the value of interest from the PT ex uh extracting the value of interest for One DB we show that they contain the same digest we only update the proof that are needed during the update right

and uh that's it we do it at every block then now com the curry part of it so um I think I have this slide so the C part of it is uh fairly short because of this talk is quite short but um basically we treat each node of the tree as a logical SQL R so think of it each node can contain your balance the total balance and the uh the user address for example um how we going to do with the the query well we going to our tree is kind of a BST tree so we're going to look right in the portion that satisfy the predicates on the index so for if we had an index on the address then we're going to sort the tree we have a BD Tree on the addresses and so

we're going to look at all the rules that satisfy the predicates we're going to show in circuits that they satisfy the predicate going to compute the results and then we simply grow up the tree and accumulate the results uh one by one okay so at the end when we reach the top of the tree we got the AG aggregated proof aggregated results and uh we can just submit this on chain um and we of course we do a wrapping rting of chain to to submit on uh evm chain so that's our main target right now um went a bit F okay get five minutes so the other thing I want to quickly mention to you uh today is also the fact that as you saw we are using rtion a lot so that means we are generating a lot of proof

like I'm talking about uh 200 300 400 proof per minute easily so we're dealing with thousand and thousand of proof uh to generate all this proof in parallel we need a strong Pro Network so we also building our own proven Network basically um so we're building the proen network and the application building of it dog footing and so here also requires quite a lot of changes so we are an AVS uh with restak security from ion layer so here the economical security only comes for the live property so if I send a task to approver and it doesn't reply me with approve in certain timeout before a certain timeout then it's going to be penalized but the the guarantee that we the proof offer is still relying on Purely on the cryptography

assumptions uh the the stake is only there for the liess issue and uh yeah that's really basically the oversight of L gr also what we are building again the pro Network and the application building on top of it um just a final quick slide to just where we are right now we delivered the we shipped on the April vly test net with a B basic site of query where we can only extract mappings we implemented The Proven Network in May and we just recently rela launch our Z processor one Zer where we have the basic of the SQL VM now fully implemented and now it's just a matter for us to implement more and more SQL functions for we're going to be working on joints order by Group

by all these things uh simple select and we also more and more data that we want to extract we want to extract the reip tries and the transction try as well um and then coming up for Z two this is when uh the all the features will be will be there and I guess that's about it for me um I have two minutes for question if there is any questions do we have any quick questions we have two minutes over there sorry Greg presentation can can you do uh zero gas transactions with um

with L granch can we do zero gas transaction yeah what's the cost usually for a query okay so right now the cost First is to verifying a gross proof on chain so it's like 280 gas or something 200 gas depend on which type of gry we're using um and uh there's also the cost of uh quering so for example if you are quering uh a month long average or a week long average if this is 50k blocks simple for a week long if you're only crying for two hours if you 600 blocks so it's not the same range of uh computation as well uh so also the the the price Model is is to be determined as well according to the size of your

query and there's also the part this is for the query part there's also the indexing part because uh we automatically index some table so we need to also to uh to take inite into ion that we at every block we automatically making some proof so we we are doing also some some work there uh so the we have to pay for the indexing and for the cre but the the the the cost there is not that significant as if we can use our proven Network efficiently and so because we are not paying the cost of proving thems directly okay that's all oh is it a fast question it's ZK it's not thanks for the presentation the the values that you're storing in these

record trees are like usually public values or like a representation of like the storage of a smart contract on chain or they can be also private values yeah so here I presented our main use cases which is onchain historical data but again we are building a verifiable SQL VM so we could put any data into our SQL the nice thing about blockchain is we can prove that we correctly extracted this value from this contract from this loot storage from this variables from this block header with this chain ID even we can be cross chain compatible this but we can totally also upload just nft metadata which are not proven at all and we just said we just put a hash as a kind of commitment and that's about it

but we can't the client will have to trust that it's done correctly because we can't prove it's come from thanks okay thank you Nicholas Round of Applause and up next we have Ali from PSC and Y Academy hi everyone my talk is quick and high level and the tools and ideas that I'm talking about they have been around for some time but I think sometimes we may not be aware of something because we are in it

I think collectively collectively they are part of like an emerging um an emerging Paradigm so we have been at this blockchain thing for a while now right and uh what we have been saying to ourselves for a long time now is that Grandma is coming on on chain any minute now um but obviously we can all agree that she hasn't she's not here um and we can't blame that on scalability because that has been solved that has been solved already so we can't use that execuse anymore um so things uh things are getting awkward I

think um and I think we we we have to uh come to the to the realization that Grandma is not coming we we have to go to her grandma is not coming on chain any time uh not now not uh not uh ever and uh the thing is um in my view uh the blockchain what we call call the blockchain it has been isolated has been really isolated from the from the real world uh people will bring in oracles uh but I think uh oracles are not it um oracles may not cannot possibly uh support everything they can't arize private data and obviously also they come with a garden variety of

assumptions which is defeats the whole purpose we are all here to dis intermediate things not to insert new intermediaries so articles are not it um but programmable cryptography May finally uh be the thing that uh removes some of these barriers uh so with the advances in in proof systems for example we can take anything now that has a signature and just shove it in a circuit uh and and then we use it and uh what we are now able to do is what I think of as Recycling and repurposing of any and all cryptographic artifacts whether they're coming from the blockchain or coming from web2 we can now uh recycle them repurpose them and extend

the life of them uh into uh fresh new uh use cases uh we also have New Primitives and these have been around as I said for a while for uh grouping signalings and many other things uh but they have existed in isolation and mainly I think it's because of this barrier this isolation from the re world you can create an anonymous group with super resistance but on its own it's not really that interesting what do you going to do you created a group you're part of a group now what do you do you need something it needs to be part of a whole experience um so um obviously we have uh you know the advances in in proof systems now regular expression should not come to us a surprise that we can

prove it in circuit and uh some excellent developers have done exactly that and uh since emails have patterns that we can describe with the regular expression and they also have a signature coming from a private key that belongs to a certain entity that we can verify publicly together we can get something called Z ZK email so you can get a proof that I have received an email from uh um from uh certain uh organization or something um and with that simple primitive you can do a lot of things in fact you would be surprised by how many use cases you can do with just this uh primitive we have semor which has been there for a while but again I think

it hasn't been used to its full potential because it lacked an environment in which it can grow uh as a as a seed uh Anonymous grouping and signaling you can signal and vote on on on uh on multiple things um uh in a non uh in fully Anonymous and without double signaling the same way that we uh in zcash they prove uh they you cannot double spend a note you use a nullifier you can do that as well here if the Voting is high stakes you can use use a tool called Macy uh which has been iterated upon many times and get some uh excellent uh uh features like collusion resistance so basically if you vote for someone you have possibly no way of proving to anyone else what you have

voted for so if someone bribed you um you can get take the bribe but Al still vote for uh your conscience for example um uh now these things can already in between themselves without looking at the outside picture and the some of the things that I'll talk about you can already take some of them and and and use them uh in a useful ways between each other so semaphore could be a gatekeeper for Macy and ZK email itself can be a gatekeeper for semaphore so you have to have received an email in order to join the semaphore and so on in fact I should mention uh the gatekeeping feature itself there is a whole new project at PSC that is uh uh launched this week just around this idea of

creating as many uh a garden variety of Gatekeepers but also allowing you to create your own gatekeeping uh and then we have also uh mtls which has been gaining some some tractions there is a bunch of projects working on it uh basically you log into your bank and the the the TLs session is split between you and a verifier or a notary and the neat thing is that the uh the verifier doesn't need to know the content or the server identity but you can still prove to them part of the uh of the data obviously that comes with some trust assumption in the not if you're using it rather than verifying uh directly um and the the the the performance you have to be mindful with

the performance as well of the MPC but it's it's usable and some of the new project emerging projects are improving upon that idea and finally the uh ZK co-processors obviously uh uh my friend was just talking about lrange uh we can now uh uh recycle and repurpose historical uh cryptographic artifacts from the blockchain so happened in the blockchain a long time ago the blockchain states or contracts do not have access to them but we can reuse uh previous uh truths basically um uh I won't speak uh too much about this because you're I'm sure you're already familiar with it but the exciting thing about the co-processor is

how different uh approaches uh have emerged people are coming at this uh from different directions and you know one of the things that we heard over the past last year is that we have enough infrastructure we don't need any more infrastructure we need ABS we need people to come we need use cases but actually this is one area where I think we need more we need more not not to mean we need more projects and so yes we need more project but we need way more people to think about abstraction how do we abstract um uh the chains how do we how do we um create the right abstract so if you are a software developer or architect I think this is uh one of the most exciting areas you could be looking at um obviously zik Co processors do not

have to be limited to uh historical blockchain uh facts you can uh use them or integrate them as well with proofs from web 2 from artifacts from web 2 and together we they can start creating a collective uh a holistic um non-trivial and fresh experience um yeah so one of the ways we can reuse or recycle repurpose some of the things is Discord like in Discord a lot of us exist on discords we have roles we have communities so you can prove that you have a certain Discord role and based on that you are giving certain tokens that you can vote uh or allocate to someone and that voting Could Happen through Macy for collusion

resistance and to to uh start voting to begin with you would have to have a a ZK email proof that you are part of the organization um or a zik email that you use to join a signal group so this use case alone giving appreciation tokens to colleagues you can see that it already uh employs all of these um Primitives together uh obviously this is a simple example but just to drive home the idea that uh uh the uh the the whole is extremely exponentially larger than the sum of the individual Parts semaphor in its own is really not that interesting it's only when you integrate it with other things uh because this is the lightning

talk I don't I didn't have time to go through all of them but they you'll have them on the slides there are so many uh there are at least three dozens uh projects uh some of them uh proof of concept some of them actually um uh in production now um uh the folks at ZK PTP are creating uh marketplaces from only one primitive which is the ZK email which is exciting so there's a bunch of projects there to to look at um so all of these what I have talked about right now I mentioned at the beginning of the talk that we might be part of something but we're not aware of it and I think all of this together looked at together the recycling and repurposing of cryptographic artifact is

is is sort of like here in the in the in the middle it's happening in the middle um and uh they coexist with other also exciting things that lower level things like pre-confirmation markets and the super building and all of that and so what I if I may speculate like what I think is going to emerge uh over the next uh years is that this uh this middle is going to get much much much larger than what what what it is now and what we have uh uh uh previously thought of as the uh blockchain I think it's going to you know go a bit further to the back you know you will blockchains

will be similar to what you know the relevance to them to the the average developer will be the same as the relevance of database management system um not all developers are writing SQL store procedures or things like that um so this layer I I speculate that is going to get much much larger and this is one of the reasons why I say Z go processing we need a lot more uh projects a lot more uh ways of abstracting things a lot of a lot more um um outof the Box uh things that people use if you look at the Z co-processors you will notice that some of them you know they they um try to provide out of the box uh solution in there SD Cas for things like D5 for example so now if

you're are familiar with the Unis swap uh V4 for example they have hooks and there is nothing stopping this Hook from consuming uh an offchain computed zero knowledge proof proving something about the history or the track record of this address so this guy is an OG we're going to give you a discount to trade on our deck and and things like that so this is something like project like previs is is is doing for example um yeah this is the same thing so we'll soon think of smart contract developers even I would I would even say that smart contract development itself is going to go all the way in the back and uh uh most developers will be will be U um dealing with with this big uh here which is something like the

equivalence of Lambda functions and uh Cloud Solutions so this is the bizaar uh cloud of of uh um of the blockchain compared to Cathedral Google cloud or Amazon or so on um so yeah with that uh I included a link but I think I forgot in the this the slide I'll uh find me after if you want to link to the slides but that's my talk and thank you thank you and we have time for one question if anyone has any questions nobody okay thanks again

Ali okay two minutes ahead of schedule congratulations Jacob you can take him all right okay Jacob from risk zero up next there's a microphone up here yeah test test test all right um hello everyone my name is Jacob waitman I'm a compiler engineer at risk zero and today I'm going to be talking to you about zuren our new DSL for writing efficient ZK Stark circuits first a little bit of context about risk zero uh we recently announced a new network called boundless uh which we envision as sort

of the full stack solution for zero knowledge application developers so this is everything from how you actually get your zero knowledge proofs on chain for use in real applications all the way down to the zkm layer where the execution actually happens So today we're going to be zooming in on that zkv M layer as we're talking about how circuits actually get built at risk zero so back in the old days of ZK applications were built with custom circuits per application and uh you would pass in some sort of input and you'd get your proof out at the end um the the primary innovation of the zkm

model is that that application specific circuit gets replaced with a general purpose circuit that uh implements a general purpose architecture at risk zero that is risk five so now the program itself becomes part of the input such that when we want a proof we can just hand it a program written in a conventional language compiled with something like the rust compiler or anything that works with lovm along with the input and get our proof um but in uh in pursuit of higher performance um it seems ideal to have uh some additional accelerators so in paral

or in sort of analogy with the way that conventional software engineering Works where you write a program in a general purpose language and run it on a general purpose CPU over the last few decades we've seen the emergence of heterogeneous Computing that it's beneficial to offload intensive computations to specialized Hardware that can do them faster things like gpus fpgas dsps things of this sort and so the model that we're pursuing here is to have our general purpose risk 5 CPU in this model as well as a series of accelerators for specific operations that we could do a little bit more cheaply with a custom circuit these are things like

accelerators for the katak hash function or alternate commitment schemes elliptic curve operations things like that so when you do go to do a proof on risk zero typically uh it's useful to have sort of unbounded duration of computation and so in a stark based proof system like ours we have to subdivide this into fixed size segments uh but after we've done that we can roll them up together with recursion and so the traditional picture of what you can do today without accelerators looks like this now when we introduce accelerators the picture stays pretty much exactly the same except that the third line here changes we can swap out some of these

segments with accelerators and roll them up in exactly the same way to a single succinct proof so with this in mind right this architecture calls for a lot of different circuits we have the zkm itself which implements risk 5 we have a recur cion circuit that is able to verify these receipts as well as an unbounded number of accelerators that might be useful to plug into different applications depending on the application developers needs and so with all these circuits it would be really ideal to have a really great experience when designing these in order to be able to effectively design Implement test them and be confident that they're secure and

efficient so it turns out though that a lot of the ways that people have written Starks comes with a lot of drawbacks um in particular each of these drawbacks comes with an opportunity to do something better so one thing that we saw was that a lot of Stark description languages really split out different parts of the implementations you have separated constraints from witness Generation Um and it's all separate from for example The Logical structure of the circuit that you might use to achieve some notion of composability when writing your circuit the other is that composability options are often quite limited uh and so it would be really nice if we had the ability to describe a small fragment of our circuit and then

glue these pieces together and test them independently and do all of those things that we get to do in traditional software development and lastly there's a lot of boiler plate and complexity that comes along with writing circuits for example for every circuit that we wrote we found ourselves reimplementing things like permutation arguments and uh lots of other things of that sort so let's zoom in and look at some real zuren code and see what it looks like so um we have a single concise representation that captures everything of Interest here so for example let's take this bit regge component it's going to take as input a value called X it's going to write in into a register a register is an abstract view of a column

in the Stark Trace register this reg component comes along with an implicit constraint that the that register value is equal to X then we go ahead and add another constraint here so this polinomial is satisfiable if and only if R is equal to Z or one in order to make these terms zero uh and lastly we return this value R uh this is not exactly a return statement but it's quite similar and it indicates that this bit reg component can in any context be used as if it is a register that register R in particular so you can kind of see how we've comingled all of these things together into this very short representation next let's talk about composition so you see here

implementations of four distinct uh combinational logic gates that you'd see in traditional uh Hardware design right you can negate a bit register by subtracting its value from one because 1 minus one is zero which is not one and 1 minus 0 is one which is not zero uh and and similarly so you could go in and check all of these Expressions but the thing that I want to call out here is that we have this very nice almost functional sort of composition that you can do with this the other major type of composition that we have in the zuren language is called a MX or a switch where we can Multiplex over uh set of selector values

so with this component full adder we're implementing a um add with carry component using the uh components that we just composed at bit regge in order to do a one bit adder with a carry in C and A carry out so the sum should be true if it least two or sorry if an odd number of x y and C are true that is our sum is three or one um which can be done in this way which should be a familiar expression for people that have studied Hardware implementations of adders and uh the carry bit should be true if at least two of them are so we do this by cases if C is true that is C is one then this selector becomes the array 1

Z and so this first MX arm becomes active so if C is true then we only need X or Y to be true for the carry bit to be set and if C is not true we need X and Y to be set for the carry bit to be set in fact when I look at this I actually think it feels a little bit simpler than the combinational logic expression to do this in traditional Hardware design uh there's a lot of other niceties that sort of come with this uh that are a little bit harder to fit in slid sized examples but one of them is that permutation arguments are built into the language that is you can simply declare a component with the argument keyword and we will automatically synthesize a log up sum for it in order

to do a log Up Style permutation argument and all of the layout constraints that come along with that will be implicitly enforced similarly we have an abstract way to describe the structure of a circuit which which enables this sort of composition that is you can abstractly describe the uh logic of the circuit that you want without having to bother with the particular column offsets or how things are precisely arranged in uh the concrete Stark implementation and then the compiler can go and generate an efficient layout using a uh constraint solver at compile time uh lastly it has some built-in facilities for testing such that you can

write unit tests integration tests whatever you feel like directly alongside your circuit implementation which ends up saving a lot of work and eliminates the need for um test harnesses and extra Tooling in order to test fragments of a larger circuit now you might be thinking maybe this comes with some significant performance tradeoffs that is you know we're losing a lot here by accepting all of the abstraction and it turns out that that's not entirely true in the same way that most of us don't write assembly anymore if we want to do low-l program low-level programming we write something like C or even rust with some extra restrictions so in particular there's a

lot of room to optimize circuits with this representation because we have so much information about the structure of the circuit in this approach for one we have all of the traditional compiler optimizations that you might think of when you think of a c or a rust compiler even you get constant propagation dead code elimination um con uh common sub expression elimination and all things of that sort uh as well as some more circuit specific things so in particular there are some layout optimizations that can be done automatically for example if you were to generate two separate registers that are constrained to be equal you can coales them such that they land in the same actual column of the execution

Trace which saves you a register um there's also a lot of room to do optimizations directly on the constraint sets for example if two constraint if one constraint implies that another constraint is satisfied that second constraint constraint can be eliminated altogether and so it turns out that there's a lot of things that can uh be optimized to get us pretty optimal so um Zur genen was released as open source software just last month uh and we have a couple of exciting things coming up for for it uh in particular we have some accelerators in the works written in it uh namely a catak accelerator uh to speed up proving of

ethereum among other things uh and we're also excited to provide some better support for users of the risk zero platform to write accelerators for the operations that they care about uh even if we haven't written accelerators for them ourselves and lastly there's also an interesting opportunity here to use compiler tooling to assist formal methods circuits so you could think about doing things like emitting a lean specification from the uh actual source code or you know based on the the uh circuit definition um or even doing things like emitting the uh constraint set in a format that would be amenable for um consumption by a tool like pus to

do determinism analysis uh ultimately we're not entirely sure what we're going to pursue in this vein but there are a lot of opportunities for this uh so with that I'd like to invite you all to check out the website for boundless the new risk zero Network as well as to check out the zuren open source repository uh through the QR code on the right uh thank [Applause] you it's 410 I think we have five minutes for questions okay thank you for the great talk um

what are the current backends that you have uh I guess first question yeah so are you asking what proof systems we support well I mean like I don't know plunky 3 or whatever else yeah this is um purpose built for our own proof system so risk zero has its own Stark based prover and it targets that any plans to support other ones or make it configurable somehow um well it's open source so we would certainly be amenable to people contributing that I don't think risk zero is going is likely to invest in that okay thank you questions uh yeah thank you if I recall

uh correctly uh there was a talk in CK proof 5 that was talking about seren but I think it was a product that was very different it was more about backwards compatibility with the cids if I recall correctly yeah so seren was the old in uh internal to slightly external name for this compiler infrastructure and uh that name was largely used to describe uh sort of an earlier version of that where we were really only doing the compiler based like traditional compiler optimizations on Uh custom intermediate representation for the circuit so the the language front end is totally new as well as most of the

optimizations so that's what we've been working on for the last two years yeah thank you yeah I think we had another question here on the left thank you for the talk uh it's just what kind of constrain optimization techniques do you plan to apply yeah so one in particular that's really obvious is if you have two identical constraints um you can prune one of them one that's a little bit less obvious but not hard to explain is that if you had a constraint like x * x -1 * x - 2 equal 0 and another constraint like x * x - 1al

0 yeah one of them is implied by the other that that's the kind of thing that I'm talking about when I talk about about that any other questions so do you allow to write your own like pre compiles in the sense like can I write my own Kack implementation for in this language I I'm I'm not sure I heard the question do you allow to write your own kind of pre compiles in the sense with this language uh you as a user of risk zero uh of zerun yeah yeah it it's it's not well supported right now but that is on the road map yeah okay thank you again

[Applause] Jacob okay you have some extra time next up we have George from Powder labs and this is our final lightning talk before we take a break so yeah welcome George hello hello working nice so this talk is about how can we build a zvm in a way that's agnostic of the proving system which is something that we're concerned with at powder um so let me give you a very quick introduction so um at powder we kind of have a DSL to describe a VM and looks like this the user can declare some

registers and some instructions and then provide an assembly program using these registers and instructions um and then that comparts to ckvm but we want to do this in a way that is agnostic of the proving system um obviously this zkm is extremely simple and um kind of useless um but we also have an implementation of risk 5 for example but you could also Imagine ZK evm um yeah and that would take a few hundred lines of code in this language but this talk is is going to be more about the low level so let me walk you through the compiler pipeline so on

the left hand side you see the high level description and the first step would be to compile to pill pill stands for polinomial identity language and has originally been developed by polygon um and describe some low-level constraints and then from pill we can compile to different proving systems an obvious choice is darks because that was the original use case um by polygon um but this talk is going to be about how can we also go towards uh folding based backends or tkr so in order to explain that let's go through some of the details of

pill so this of course I'm going to explain this using Fibonacci and um so on the left hand side you see a very simple pill program that describes if it a computation on right hand side you see the corresponding execution Trace um so in the first two lines um the program declares two fixed columns and fixed columns are columns of the execution tray that have a fixed value so the values are fixed ones at setup time and the approver cannot change them and in this case they're only used to indicate whether we are currently in the First Column or the last column and then there there are two

witness columns and witness columns can be filled with any value by the prover but they're subject to some constraints um and so if we look at the constraints for example the first two constraints essentially Force the prover to initialize the Fibonacci sequence correctly with the values one and one and you can see that we have to multiply with this is First Column because one property of constraints is that they always have to be satisfied in all rows of execution trays and then the the next two constraints basically Force theover to update the Fibonacci sequence correctly and you can see that we have

this next operator which is kind of this Prime operator um which means that we're not referencing the value of x in the current row but in the next row so that's mostly the obstructions that we have um so just to recap there's columns which can be fixed or witness columns there are constraints which involve additions and multiplications and they can have a next operator and they need to be satisfied in all row of execution Trace um and one thing I haven't yet talked about is verifier challenges which are just random field elements sampled by the re ver by the verifier after some witness cols have been committed and this is useful to

implement uh lookup implementation arguments and other things and here you can see an example of of how you would Implement a permutation argument so let's go through all the proving systems um and first up Star as mentioned before this is the most straightforward one because that's kind of what P was designed for um and I don't want to spend too much time on it but basically a star is going to interpretate a polinomial for each column of execution trays and this is my attempt at drawing these pols um and then the constraints just become constraints on these polinomial

and Starks are designed to prove that um constraints and polinomial are satisfied and next up um is folding based back ends so what are folding schemes so one thing they do is they provide for incrementally verifiable computation which means that you start out with some initial state which you can think of it's just a small Vector of field elements and then you keep repeating the application of a function which is fixed function it's always the same function in each step until you end up with some final State and that's the result of your computation and this function at least

in the simple cases should be the same in each step of the computation and that is kind of similar to pill which has the same constraints on all rows of the execution Trace so if we if we look at a simplified version of this Fibonacci program um here it's the same program as before but I left out this this first and this last column because um voting schemes kind of have a native way to represent the first and last state um but given these constraints we can essentially extract a function f that computes the next row from the current row row and so we can view the execution Trace as a collection of intermediate

states where each row has been computed by the function f from the previous row um and so if we view it like this and it fits into this IVC scheme and then we can compile to a folding based backend and last not but not last but not least JKR as so gkr is a is another protocol that proves correct computation of a shallow layered arithmetic circuit so let's go through each of these terms so an arithmetic circuit is a circuit that computes something just using additions and

multiplications and a layered circuit means that each node in the circuit can be assigned to a layer number and then you can only receive inputs from the previous layer and by sh shallow we mean that the number of layers should be small um which is important because the verification time is going to depend like it's going to be proportional to the number of layers so in particular the the number of layers should not depend too much on the size of input layer for example and another property that's desirable if it's a structured computation which you can see here so you can see here it's not an arbitrary circuit it's uh copies of a small

subcircuit so it's kind of describing um um a data parallel computation it's applying the same function to different inputs and eventually all these layers the value of these layers are going to be represented as polinomial and the verifier needs to be able to evaluate this polinomial but only for the input layer and the output layer which typically means that for the input layer there's going to be some polinomial commitment scheme and for the output layer it could also be committed or it could be easy to evaluate by the verifier for some other reason so that's it for background let's look into um how does it all relate to

pill and how can we take a progam program and compile to gkr so in this extremely simple program we just have two columns and one constraint and the idea is kind of to to just put a concatenation of all the rows of the execution trays and put them into the input layer and then the constraint needs to be satisfied in all of the rows so we can instantiate a small arithmetic circuit many times that just evaluates the left hand side of this constraint and if and only if all the constraints are satisfied the output layer would just be the vector of all zeros which is encoded as the zero

polinomial so as trival to evaluate by the verifier and that's it so just to recap I kind of view pill as a language uh to express constraints on vectors of field Elements which is kind of a data power way to describe computation and yeah like a structured computation that is exploited by different proving schemes but in different ways um but we can kind of compile to all of them or at least the ones I've mentioned and um yeah that's nice because then you can describe your zkv M ones and decide on the proving system later or even prove different parts of

the zkm with different proving systems time for questions any questions okay these lightning talks are getting shorter and shorter thank you again [Applause] George all right we have a 15minute break coming up now and then our final talk and then followed by Anna Rose and Friends panel so join us back here [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

for [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] h

[Music] [Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

[Music] um welcome everybody welcome Zach you made it I thought you were in the back uh loading the T-shirt cannon I thought you were in the back loading the T-shirt cannon oh sorry all right everyone for our final talk we have Zach from Aztec and then stick around after for Anna and friend's uh panel so take it away Zach there's a microphone up there

cool hello everyone so uh do I have a clicker ah here it is I'm just blind so yeah I'm Zack I am the CEO of Aztec and I'm here to bring the good news about about honk Mega honk so um who here has heard of Aztec hey okay I'm still going to explain what Aztec is there for like the few of you don't um so Asic is a privacy preserving um programmable layer to for ethereum so we do SNS but we also do privacy private stat All That Jazz um can't do technology um is this uh hello

help h ah okay hey okay great so um um yeah so we've been around for almost seven years now um which in web 3 years makes us geriatric um you know so I'm about to about to retire to to a home but um yeah so we've been pretty busy this lot all that all that time um so I got I I was learning about ZK snars and all of that jazz in 2018 and it's ever since then the goal has really been for me and and and our team to create programmable privacy preserving smart contracts um so

you know as a a regular with free engineer can write a smart contract like they do on ethereum like they do in salana but you have uh private status first class Primitives and you can do all sorts of fancy things like um identity controls and um uh hidden State information games basically allowing the real wealth to interface with web free by creating trustless oracles as you get email the works and so yeah this is we've um uh this originally what we're now calling Aztec was called Aztec 3 because we've uh released several several private rollups um uh and various pieces of tech uh over the over the past six years but this is the culmination of all of our

work this is the grand plan and the grand project for Aztec uh to create that fully programmable privacy preserving L2 uh and to ship it sometime next year this is our road map so just want to just want to tap this uh we put this together announced it the other day um so we have a plan we have a concept of a plan even um and this is that so yes um uh if you want to know more that is the website link I don't think I've ever seen anyone actually follow a website link from a slide presentation so if you'd like to be the first person in the world to do that please feel free um okay okay well the laser poin is more jetlagged than I am

maybe it's just me yeah it doesn't like me who needs slides anyways um so well if if you can get it working uh that would be oh yes oh fantastic amazing what a wonderful modern world we live in so um yes um by the way you might have noticed or may not have noticed um uhi one of our um event managers has made some wonderful Taylor Swift te friendship bracelet so we're all friends here this is the uh 11th ziki summer I've been to I believe so um who would like a Astic themed friendship bracelet yes ah who else anymore okay right in the back

let's see if I can do that ah almost okay all right you ready for some plunk I didn't hear that woo you see I like to raise the expectations of everyone before crushing their dreams with boring cryptography and maths so what do I want to talk about what the hell is privacy what the hell is and like okay so I want to talk about a few things before getting into what the hell is megap plun because ever like the ziki SN landscape is extremely diverse these days and um a lot of preious Sy previous systems are very much getting becoming like tailored to quite specific use cases on the on the

various tradeoff space and so at as we made some pretty pretty specific choices to satisfy some specific requirements that I want to talk about and also maybe sh Aztec slightly as well so privacy um what do we even mean by privacy in a in a blockchain context you know like do we mean um like what is a hidden transaction so there are three times of privacy I think this was this came from Anna and I've been stealing it ever since basically you have data privacy user privacy and transaction privac contract privacy code privacy data privacy is you know you can see who's sending who's transacting but you don't know what they're doing what data they're transferring user privacy

is obviously you don't know who the senders and the recipients are and code privacy is when you do not even know which smart contracts are being executed um and the goal of atic is to achieve all three and that's something that we are doing with the current Network so um this can kind of be summed up as basically saying if you have all three private privacy properties if you look at a blockchain you look at the list of transactions going through you look at the transaction data or you can conclude as something happened and that's about it um so um how do we actually create privacy preserving State models um I don't know why I'm even looking here I can see it here I'm just blind um so there's there's a there's a problem

with privacy well there's many problems with privacy but it wouldn't have taken seven years otherwise but one of them is that if you have private State that's encrypted it's owned by effectively owned by the people that can decrypt that State uh and that can be a problem for things like shared Global States how do you create a decentralized exchange with a total liquidity Supply um if that thing is encrypted because well who owns the decryption keys and you can solve that kind of thing with very very complicated multiparty computations or you can just be a bit lazy about it um and have a hybrid system where you have um individual user state which is private but you also have protocol state for things like decentralized exchanges which can be public and you have composability

between um the private and private public aspects basically things like uh you you in this example um you'd have a public token transfer function and a private token transfer function and so um basically you can you can selectively disclose information if you want to but you can keep it private like the way that we refer to this is this this pattern is very much the concept of privacy for the user but transparency for the protocol um which generally we think is the best of all world because when you have you know decentralized protocols you do want to be able to apply oversight to them and if they're hiding their data that's hard to do so the asset contract model is you have these private functions and public functions they modify different state

trees and the S network so you've got this unspent transaction object tree uh that handles the private side and on the public side you have a more regular ethereum based account and of course we trying we want to abstract pretty much all of the like messiness around handling utxos away with um uh um using no very Advanced semantics um but this is fundamentally what's going on under the hood uh so the idea is that uh you have a data tree that is encrypted notes and a data tree that represents account based State um and yeah that's how you do um privacy so yes hang on let's oh let's not see that again so architecture um how does the ACH Network function

broadly um so this was um our original kind of uh first attempt at creating the architecture diagram I don't think you can see it but it says this diagram is Mike's baby please do not edit it without first Consulting Mike smiley face um so very complicated very messy so let's try to break it down um a user transaction in a network like Aztec um is what do you what what an observer actually sees when they send that transaction to the transaction pool is you have this concept of a kernel proof which is a bit like the ZXI protocol uh a kernel is a program that validates the correctness of individual transactions so you have a Kel proof um a list of state variables to create a list of

nullifiers which represent State variables to destroy a list of public functions to execute and the world state that was used to compute the kernel proof that's all that that an individual will see when they look at uses transactions um and from that uh you can acquire very little information if they are not executing public functions and the number of utxos and nullifiers that they're creating uh is conforms to some kind of standard say two in two out then this transaction you can make this transaction look uniform with thousands tens of thousands of other transactions um so the transaction flow is very much you have this concept of Kernel proof which is going to be validating client side a lot of the assc protocol uh hiding a lot of information um that then gets sent to the the proof

gets sent to a sequencer Network peer-to-peer transaction network uh the block producer which is selected through a decentralized mechanism called finet um uh when they include your transaction in a block they will send that block off to proov a network to make a proof that's when the public functions that um you're calling in your in your transaction flow uh get proved um and then it goes to a L1 worldl contract simple right um so how do we build privacy preserving abstractions well we use a language called Noir um it's very much based on Rust uh and very uh actively under development um so we've been working on it for about three years now uh and it's a very different Beast to what it once was um pretty Advanced

and sophisticated and um we could use Noir to create very bespoke um abstractions around how to handle privacy preserving information how to efficiently encode programs of snar secets so data is represented as encrypted notes so you know you have a contract address Aon your storage slot some storage data it's a bit like how ethereum does it except this stuff is encrypted because um there should be a secret in there no we forgot um and then you have this concept of a nullifier so uh who here knows about nullifiers wonderful that's a lot of hands I'm very impressed uh so um for those who haven't raised their hands the problem with privacy preserving uh um

transaction networks is if I let's say I send um some uh I send I want to send an ethereum to yens um and uh it's I want to do this in encrypted way well if I have a um like a note that says Zack owns one ethereum um even if it's encrypted the act of deleting that note would leak information Lively uh because on the blockchain network you'd have to say Okay that not is destroyed now um and uh and so you could see the transaction that created that note you could see the transaction that destroyed that note you see the transaction graph that's a problem nfy solved this because nullify is effectively a way of recording a note as being deleted without uh revealing that

information effectively what it is is a nullifier is is the is the note but encrypted under a different encryption algorithm um and so in order to spend a note I need to prove that the note exists and the nullifier does not exist and I prove that locally client site in a privacy preserving ZK snark so nobody else leaks this information and because the nullifier encrypted with a different algorithm if I create a nullifier and post on the Chain um nobody can link that nullifier to a note that I originally created um so basically you see if I wanted to send one e to yens I would create Yen's note and I would create one nullifier uh but nobody would know like the the owners of those two entities

uh so yeah encrypted notes in Aztec they're not I say notes because I'm using the like the Bitcoin nomenclature of utxo unpent transaction wait they don't use note either I don't know where note came from maybe zcash basically uh in Aztec notes don't represent cryptocurrency values they represent abstract arbitrary state that a smart contract gets to Define how it's used a bit like storage data in an ethereum smart contract so here you know we're saying basically encrypted notes they live in storage slots within a contract uh so instead of having the the idea of um in a lot in other PR preserving architectures the the concept is you have you have state that exists on a blockchain and you define birth and

death predicates on that state um very literally creating State transition functions for single state variables we're taking more of the ethereum approach of you have a smart contract and that smart contract controls a bunch of arbitary states and you can Define like the modification rules um in a in a in a much more abstract way um public private transactions of public effect so you can emit an event if you want you can uh call public functions obviously this will leak some information so you be be careful with it uh but sometimes it's necessary uh um so yeah Tada um and then provs and sequences create this concept of recursive rup so once you have all your user transactions every user transaction has a very chunky Zer knowledge proof attached to it that's

not cool expensive to verify on chain so we don't we um had this roll up architecture basic Bally this two to two: one compression function where you recursively verify two proofs make that one proof um and then you create like this tree hierarchy of um uh recursive provs uh which basically means as long as you have arbitrary computes which for a pro a network you basically do um then the the overall time required to make that the full rollup proof is logarithmic in the number of transactions in the block which is nice allows us to get in theory High transaction throughputs Okay so I know this talk was titled Mega Punk and I haven't talked about honk or plunk or anything yet so this is a this is a way I do that one

second okay cryptography cryptography right so what do we want what do we want our cryptography to do um So based off of everything I've said we have a few requirements because we are focusing on privacy we need to do fast client s side proving because you don't want we don't want to have to have users share information with other people uh that client side Pro it needs to be low memory because if you're working on a phone and you're interacting with a web application then your phone's browser is going to Nuke any tab that uses more than a gigabyte of memory which is fun um and we need extremely fast recursion of folding client side partially this is this is um how we uh architect our transactions

because if you have a smart contract that calls another smart contract that calls another smart contract and you want to represent that all in a single transaction well all the smart contract calls are basically representing um arbitary the execution of arbitary untrusted code and so recursion creates a very nice abstraction where you can basically Silo that those those programs into individual snug circuits recursively verify them together and then apply some additional logic to validate the snars of doing what they should be doing in our kernel circuit but that needs recursion we can also use recursion to get past memory bottleneck by um uh reesing before you use too much memory and we need relatively small proof sizes this one is a little bit oblique um why do we need small proof sizes when all our proofs are going to

be combined in a rollup it's because atic is a going to be launched as a fully decentralized Network which means every user transaction is broadcast through a peer-to-peer Network and so if every user transaction is large say it's let's say for example it's 100 kilobytes then in order to get you know 100 TPS that means you have 10 megabytes a second you need 10 megabytes of t throughput on your P top network uh which means you need considerably greater latency um to get that much throughput so small prises are kind of important for us so how do we do this so we have a rather complicated cryptography stack now um you know back in the day you used to just have a proving system and you were done um but

nowadays we have lots of additional high level abstractions to handle things like the concept of incrementally verifiable computation which I'll get into it a little bit so our main thing is honk honk stands for uh highly optimized plunk it's basically it's an iteration of the um uh well both the plunk protocol from 2019 and the uh hyper plunk paper um from a couple of years ago basically it's take the original plunk paper replace the check the the um the quotient testing check where we check some quotient polinomial um is zero modular Vanishing polinomial and replace that with a sum check critical uh why do we do that I'll get into that actually um add a look up critical add a bunch of custom Gates and boom Bob rle

prot Galaxy is a incrementally verifiable computation scheme um produced by um RL andm it's an iteration of pro star uh and it's very very efficient at folding honk instances specifically it's efficient holding folding arbitrary H instances by instance I mean circuit so you can have a thousand different circuits you can fold them all together and it does the job perfectly which is very a very rare property of folding schemes uh but then we have something called Goblin plunk um so if if you uh if you if you if you subject your your brain to be rotted on crypto Twitter you might have heard this phrase before so Goblin plunk is a uh computation deferral scheme acceleration scheme basically Proto Galaxy requires

some expensive computations to be proven inside a socket these things called non-native elliptic curve operations they're very painful to do we don't like to do them we like to be lazy so we have this protocol to basically transform these difficult computations into easy computations which I'll get into a bit then we have this thing called the data bus which is um how to transfer information efficiently between um like multiple steps of an incrementally verifiable computation scheme so this one's a little a little little old uh we working we're working on a year ago I think Yen has a very nice memory checking scheme which which um which is better than this but uh yeah we're uh focusing more on security these days so honk what is honk uh um so why do we use a supic protocol

uh some checks are a much older technology than this concept of qu testing I think they were around in the 1990s um they they form the back bound of of like of the early um Proto ZK snarks uh but it fell out of favor because back in the day they had some they had some diff they had some problems specifically in order to efficiently like prove and verify some checks you needed this you need a multilinear polinomial commitment scheme which is more complicated Beast than a multi than a univariate polinomial commitment scheme and until the last couple of years we didn't really know how to both efficiently encode a multilinear PCS whilst acquiring important properties needed for plish circuit specifically this concept of a shift if you have a basically we use pols as vectors more or

less um and so if you're committing to a vector um how do you get a like how do you do a off by one shift of that Vector that's really important and until recently we didn't really have a good way of doing that um in mult with a multilinear polinomial because if you're representing your vector as a multi-dimensional ban hyper Cube then there's no like uniform transformation you can do on the hyper Cube to get a shift uh um so yeah there are a few reasons why some checks weren't used until recently but those problems have been solved so now some checks are lovely because they are um they have linear complexity um in pra time uh and they have very very low relative memory consumption because you don't have fph

Foria transforms you're not blowing up your your witness Trace um so for Aztec and the fact that we have a very very very small memory footprint of play withth this is very important for us and we have a paper we have a draft paper that's hopefully going to turn into a real paper before the end of the year so just teasing that now um honk. PDF um so we've had to be relatively uh um opinionated about like the specific configuration of honk that we're using for Noir and Aztec this is because we want to make sure that in the Aztec Network every proof that's being verified is has some has some uh common structures for example the the number of selected polinomial is the same the the

algebraic statements being checked in the snar are the same and so this is basically what we settled on is in how do you compile programs to circuits where you can do like pretty much like pretty Advanced arit computations without a BM uh because client side virtual machines add uh quite a bit overhead to to memory consumption um and recursion costs sometimes so yeah basically we have curve operations Artic gates gates to do nonn field arithmetic efficiently if you've ever worked with this stuff you'll understand why um uh we have these kind of memory checking gates for these what we call Rom and RAB abstractions basically readon memory random axis memory so in Noir if you're creating an array and then you're

reading from that array arbitary points or you're writing and reading into that array repeatedly um this is what's happening under the hood and then plug up Gates well for the well originally it was the pcker protocol it's now the log up protocol that we used so that should be changed and then we also have our a modification to our pation argument which create allows for implicit efficient range constraints for small range values um and the subset equivalence check concept basically in your circuit in your witness Trace you can basically Define u imagine you like you you color a bunch of wires red you color a bunch of wires yellow you can prove the set of red wires wires is equal to the set of yellow wires but the ordering of the two is undefined and that's very useful for memory

abstractions and range checks uh the paper will reveal all maybe if we have some of questions I can do that too so here's an example of what's in the paper sorting gate this is really basic um how do we do range checks I'll go into it so because of this this subset equivalence check what you can do is if you have a bunch of wires in your circuit you want to range constraint let's say you want to put them all to be within a well 14 bit um Range we the at the end of constructing the circuit we add additional dummy gates at the very end and then what we do is we we tag all the wires that are need to be range constrained and we copy them into this into the additional spare Gates we created and then we apply a subset equivalence check so we say like the the

copied the cloned wires their values are equal to the original range checked wires why is that useful because in the cloned version they're sorted basic they're sorted incrementing value um and so um with the addition of a few additional dummy gates to make sure that you can uh transition across the range what we do is in the sorted list we say we assert that the first wire is zero the last wire is 2 to the K minus one for a kbit range check and the relative difference between two adjacent y's in that list is 0 1 2 or three so as long as you have 2 to the K divided by three dummy wires in the circuit um you can um guarantee you can always that range and what that does

is it basically gives you constant complexity range checks instead of having to do decompositions um you can well in our case basically get a 14 bit range check for a quarter of a gate and then you can obviously combine those for larger range checks why 14 bits um it's because we optimize for small circuits because we're doing client side proving and the larger the range table the more dummy Gates you need IVC so yeah this is where things get really complicated um who here has heard incrementally verifiable computation got to say the level of literacy in this room is is amazingly High you should all you should be very proud of yourselves um so uh incrementally verifiable computation what the hell does that mean so imagine

you have some some permanent State some database or something some input State and then you have multiple snar um proofs that are modifying that state so you have some input State output State and then and then the output state becomes input state to a new circuit and on and on you go it's called incrementally verified by computation because you're just basically updating some blob of data over and over again uh repeatedly um and an Aztec transaction can be considered an IVC basically every single time you're calling a function you're modifying some State um and so it's a fancy way basically saying recursion um and recursion is a fancy way of saying verifying a proof and a proof um but um not fully verifying a proof because

that's expensive basically doing as little as you can to mostly verify a proof uh and yeah so for sches with this current state of the art uh and they enil for ridiculously efficient recursion the idea here is in azc each private function compiles to a distinct circuit and we need an IVC scheme that can compose what we say by compose a sequence of ARB functions means basically um we can uh we have a function call stack represented in our circuit and in the in the kernel circuit we pop a function off the function call stack and then we verify a proof associate with that function and then we examine that proof's public inputs and depending on what they do we may push additional functions onto the function

Co stack or emit other effects um and that's basically one iteration of the kernel circuit and so to fully execute a transaction you need to repeatedly prove the kernel circuit over and over and over again until the function Co St becomes empty uh so back in the day this was basically like a pipe dream when we launched Aztec connect in 2022 it was one of the first uses of recursion on ethereum and it was 700,000 constraints to recurse to to do like 32 recursions took 5 minutes of a 128 core server and 128 gbt of memory so the idea of doing this client side was a pipe dream but a lot has changed since 2022 now this is relatively easy um this is our IVC scheme can you can anyone see

that I can't even see that and I'm like one meter away okay um so basic let me try and walk it through I can use the laser pointer so the idea all these FS are functions that represent individual like smart contract functions and K represents a kernel circuit so the idea is what we're doing is every iteration um coming in as a function statement and a proof um and the and the previous kernel instance we then ver VI IC is basically folding we fold F2 uh the F function and the previous kernel circuit into some kind of accumulator um and then we spit out the um uh we spit out basically all the side effects that be created from the transaction as well as the the newly created accumulator and the idea is you

repeat that step that that process over and over and over and over again until we get to this concept of what we call a ceiling circuit which is basically where we add uh add in the zero knowledge because zero knowledge is somewhat expensive we don't want to do it unless we have to so here is where um all the information that used to be public becomes private and all you get out of this is the pure side effects basically those encrypted notes to create the encrypted nullifies to destroy the public functions to cool everything else gets hidden away so you don't even know who's sending the transaction um and then that gets sent to a rollup which verifies this this absolute nightmare in something we call a tube circuit um what's Goblin oh dear how much time have I got what a few minutes wonderful um so

what the hell is Goblin plunk so I think at one point it was basically a fever dream that turned into a sort of a protocol that is I think I think we're getting a paper out end of the year um I call this a computation accelerator the idea is when you're folding when you're doing this thing every time you want to do a fold basically you have a you have uh commitments to your to the to your circuit you have commitments to your incoming functions proof you have commitments to your uh incoming previous Kel iteration proof and those commitments are Tic C points and in order to fold them you need to do scale multiplications in those elliptic curve points which is annoying painful we don't want to do that because uh it's this you need it's it's a very uh like

Infamous problem in in ziki snars where if you're working over a single elliptic curve and you want to do elliptic curve arithmetic in that elliptic curve um over a snack to find that elliptic curve the prime field you need to work with is not the same as a prime field available in your circuit so you need to do emulated Prime field arithmetic very expensive very painful we don't want to do it so we use Goblin plun instead uh okay so how does it work I should know I designed it um so we have this concept of of an operations CU so let's say you're in your circuit you know life is good you're doing folding and then oh no you need to do a bunch of you need to do a curve scale and multiplication how about instead you don't what you do instead is you have a little you have

basically a table that you can write information into and in that table you basically you write in the elliptic curve instruction that you need to do and your claim as to what the result is and then you move on with your life you just assume the claim is correct um obviously that is very efficient because you're not you're not doing any work um and that table that you're you're writing stuff into basically becomes a commitment to what we call a transcript a commitment to all the elliptic C operations that you need to prove but have not yet proven and the idea is in our IVC scheme as we are folding folding folding folding folding What's Happening Here is in some of the out in this in the side effect outputs um we're getting an an incrementing list of elliptic curve instructions to perform so

basically it's a bit like um it's a bit like you know maybe when you know back University we have a lot of a lot of a lot of assignments that do lots of responsibilities piling up and you're just ignoring them trying to drink the pain away until at some point you finally have to deal with it uh and then how do we deal with it so um this I think we we we borrowed stole we inspired by the ethereum foundation um uh and their blob work with this which is basically so you have a commitments to elliptic C operations um over let's say curve a um and we know that elliptic curve B can can very

efficiently evaluate operations over a curve a um so in asex case these two the curves are called bn24 and grumpkin um and so we have a bunch of bn24 operations we to do we'd rather do them on the grumpkin curve because it's really efficient so how do we how do we do that well the idea is you have this bn24 commitment it's all the stuff you have to do what the pra does is they just magic out of thin air a commitment over the grump curve to the same information and then you need to do two things one you need to prove that the commitments are commitments to the same information and two you need to prove and then you need to actually prove that the elliptic curve operations are correct over the grumpkin curve that second part is what we we have a circle

called the elliptic curve virtual machine because it is the world's most um uni bespoke um artisanal virtual machine because it only does elliptic curve operations and nothing else uh that part is very efficient because now you're working with the grum con curve so B and 24 operation are really really cheap that's great lovely but how do you prove the commitments of the same well that's fairly straightforward we have this thing called a translation circuit I say it straightforward because I didn't write it but uh yeah that chaper over there wrote it so he might have a different opinion um uh wait yeah there um so two minutes okay good good so in the translator circuit we basically so you got these two po commitments one of BN I thought one of grum can use a a regular

bog standard Normy polinomial commitment scheme in over the grumpkin curve to open your polinomial at a random Point evaluate them and then what you want to do is for the B&T commitment you want to pretend that they're grumpkin commitments you want to you want to imagine what it's like to be a commitment over the grumpkin curve and pretend that you are one and then using emulated field arithmetic evaluate the information in committed to in the BN 2x4 curve um evaluate it as if they were coefficients of a grum polinomial and that's actually relatively easy to do you just create a AR circuit that does some non-native field arithmetic um uh to do that that step and what it effectively does is it translates nonnative elliptic curve group operations scal models into a constant

small number of non-at field operations which is an uh concretely asymptotically better um uh thing to do um like ASM totically can prove it it's less work um I think it's like by like um like something related to the security parameters of the C anyway it's very efficient really efficient it means that we can recurse in about 12,000 Gates and that's not even very optimized so um we're talking milliseconds there it's really good uh and so this is the the full completed thing um I did not make this diagram it's far too good for me uh this is one my colleague Mara um who did it but the idea here is you have um you have F and you have G so G is basically um uh

elliptic curve operations over the grumpkin Curve is it and F is basic it's your accumulated folding instance the as you're folding as you're folding as you're folding what you're doing is you are my Las point just yeah um as you're as you're fing folding fing fing fing you are um adding more information into this list of elliptic curve operations you're growing this list um and then um you uh basically you you kind of deal with this by creating these elliptic curve virtual machine and translator proofs um and so basically the output of an Aztec user transaction is the um proof of correctness for all of this IVC stuff which is where all the real logic of what you're doing is encoded and then these two proofs translator um so um

yeah it's pretty efficient uh at least it's efficient on the client side verifying this stuff on the service server is uh less less so but we're working on that it's not really a big problem because we have a lot of resources at play there and so yeah that's basically a very brief um overview of mega mega honk um papers coming out soon thank you for listening if you want to get in touch um join the Discord uh look at the road map look at our research um download Noir Tino around and yeah thank you very much for [Applause] listening all righty we have some time for questions does anyone have any questions

okay how's it going thanks for the talk um just to uh check whether you're aware the idea of Shifting um a a polinomial on the cube um is is is solved um yeah yeah yeah yeah that's why we use that's why we use some checks now but back in the day it wasn't a solve problem like you go back three four years okay yeah cool yeah any other questions okay thank you again Zach [Applause] and now we have the finale of the conference which if you've attended other ZK Summits it's a tradition uh

Anna and Friends panel is this going to be like park bench Style no that's just a standard panel okay forget forget what I said also Zach I'm I'm waiting for my friendship bracelet Anna who's on the panel who wants

to panelists if you know who you are this is this is the honor System of hello hello hello is it working can you guys hear me on the mic okay good um cool how are you all feeling now that you have reached almost the end of ZK

Summit 12 have you learned a lot yes some I need some reactions have you learned something yes okay good um did you have fun did you did you use the card the NFC card who used it who used it hands up oh yeah okay um very good I'm glad that you guys gave it a shot so what we're doing now is we're kind of wrapping up the main stage with a panel um kind of like every time I do a summit this panel comes together as the day progresses uh what we wanted to talk about oh nice thanks guys uh what we

wanted to talk about today if you were there for my intro talk I was talking about the map of ZK and I had this area on the map of ZK which I had just called miscellaneous tools basically it's categories that have not yet been defined and what we wanted to do with this panel was just kind of like explore brainstorms what some of those categories might look like um I think we're going to start really with the panelists and we're going to have a conversation about what might be coming but I do also want to open up the floor to you to think about what those categories might look like or maybe you're working on a project which you think could Define a future category and so we want to hear from you you in this

talk too all right let's kick off with some intros uh I introduced myself at the beginning of the day but my name is Anna I'm the host of a show called zero knowledge podcast I'm the co-creator of a project an educational Hub called ZK hack and I'm a co-founder of a company called zkv uh ZK podcast is also the producer of this event and we are now on our 12th edition I kind of can't believe that we've done a dozen anyway that's me what about you sweet um I'm aush I have mostly been thinking about ZK email for the last year and a half but I've spent maybe a little bit over two years thinking about General ZK applications um so things like anonymous group

signatures or uh data Providence um and things like that so yeah I'm excited to jam more on weird new applications nice uh I'm Andrew uh I work on cursive and we build cryptographic apps for human connection and I've mostly been exploring how we can turn cryptographic tools into social Primitives they're all very succinct I'm a bit shy I'm never so succinct when I introduce myself but I'm Ashling I'm the head of privacy at tat uh we are building MPC tooling for uh ZK at the moment but hopefully soon general purpose um my background is in cryptography I care a lot about privacy

I love web3 I love crypto I want everyone to use it so I now think about all the ways in which we can make it so that people actually do use it nice um I want to start Us in sort of discussing what what I what I think of is some of the new categories so you mentioned you know ZK email sort of the ZK TLS maybe what cursive is working on I want to sort of Define what has started to emerge kind of those categories that I think we are seeing teams line up in and then from there I want to talk about maybe some New Primitives new Concepts I mean even the co- snarks like what that actually opens up it's quite interesting but let's take

let's go back like I mean when when would you say the ZK TLS category happened was this in the last year I mean The Deco Paper was like yes more than five years ago so fair enough practically we first saw like maybe TS proxy style implementation like a year ago and then finally the the impation started getting a lot more traction I think this year let's define for the audience and like who may not be as familiar like what is that category what kind of teams what are they doing Z ktls yeah I think there's generally two main approaches these days there's the TLs notary approach uh which I think was originally an external project and then

PSC picked it up and revived it was like super old um so that's like notary based approach uses MPC um and the other approach is TLX proxy um I actually don't know who originated that um not not sure but I think now that's become a more popular approach it's like s simpler to set up and there's probably there there's quite a few teams working on this like off the top of my head like um Pluto reclaim opacity like ton of teams exploring this space so that's really good get a bunch of Builders here what when when you talk about TLS notary or TLS proxy what is it like what can you actually do with these things like

you're proving something about what about any like uh HTTP like TLS response so you send a request to a server and then either this request is initiated through an NPC session where your session keys are shared with a notary or it's routed through a proxy which assigns the direction of the traffic um and that allows you to actually like uh prove things about the API response or the TLs response um and you can also use ZK to basically like hide certain things from this proxy or like use selective disclosure to prove certain

things and like as I've understood it's I mean you're you're kind of tapping into like the web all of a sudden you're making proofs about something that's out there on like on the web websites um ZK email I it's funny because like I've sort of put it under the ZK TLS category but I'm curious what how you place it and also maybe let's explain what ZK email is yeah sure I'm happy to to dive in a little bit so I guess yeah I don't know if I would agree with categorization ZK TLs but there there definitely is a lot of overlap in the sense that you can kind of and maybe I even disagree with ZK TLS as a name but um you can you can think of it as like yeah like all the data in your email you already have signatures on

them and you can now make proofs of them um and it's kind of separate from the TLs work because TLS you have no signatures it's all symmetric and so you're kind of fundamentally trusting okay there's some party in the middle that's going to be centrally permissioned it can't be a decentralized uh a decentralized thing or else that person could collude and then drain whatever it is you're trying to prove um and so the way I think about Z email ideas is like it's it's kind of just the first example of oh this is one really interesting piece of signed data that we can make really interesting ZK proofs about but it's just like just one of like a category of many many of these like pieces of signed data like passports are also signing you see projects like open passport or rare remote doing really cool things with

Selective disclosure on signed passports and then you have uh ID cards are starting to get more and more signed around the world and then you have um even like sometimes web front ends are signed with like sign exchange um and so there's there's lots of signatures if you kind of go hunting for signatures and then you can make ZK Pro of these things and then people like to use the word like vampire attack in web 3 but I think of it more as like adding features to it like we're like helping the web two services like add little features their little products and all they have to do is add a signature nice I actually I want to come back a little bit later on in this conversation about signed data and like what that could look like um but now I want to hear a bit about Co

snarks um we did an episode Pretty recently where we went very much into detail about it but maybe you could just quickly explain what those are and some of the use cases that those open up sure I think I mean they kind of add to a lot of the stuff that you're talking about and it's so cool I mean I'm thinking also a lot about the ZK use cases at the moment and it's so super nice to see that there are actual things that people are using now that I can say ah look here I can actually point at things but Co snarks generally are collaborative snarks where you generate a snark in an MPC circuit so you have a distributed setting where you want to do some private computation and you want to generate a proof um yeah in a in a private way so one example I think that

was at the workshop earlier was suppose we want to determine who has a higher salary or who is richer we can engage in this NPC protocol um but suppose now Anna we reveal the result to you but you're not quite sure if you trust us maybe you want us also to provide or the circuit at least to provide a proof that yes indeed the computation was done correctly but because because we're in this NPC setting you need to do this proof in an NPC way so this is essentially a coark um and maybe like with ZK email and ZK TLS and all of this stuff with ZK passport this works quite well now if you want to just generate a snark in in a small circuit this kind of stuff it works pretty efficiently but if you start now talking about these types of

cards and you have smaller devices with lower memory and you don't have lots of RAM and you don't have lots of power and you don't have like uh yeah like memory space computation power it becomes much more difficult to actually compute something especially in a ZK like to compute ZK proofs in an NPC way so maybe you want to do some Outsourcing maybe you there all these proof markets now showing up um maybe you want someone else to generate your proofs but you don't want to send your witness in the clear because you're talking now about private data it's your passport it's your emails it's whatever um so yeah this is where coars fit into the sort of things that are emerging now is the kind of more human things where it's like

okay we want to share some data but I'm okay sharing it with you guys but maybe not like publicly for everybody cool I also want to come back to that and what kind of Ed cases could come off that but uh let's talk about cursive in the math ZK that I presented you're you're currently in miscellaneous tools because I don't know exactly how to find what you guys do so can you share some of the experiments and sort of areas that you're experimenting with yeah definitely so uh we're still figuring it out so that that explains a lot um I think the uh one way we look at

this is thinking about problems with existing social apps and problems users have and how we can solve those problems with cryptography so these were the three points that Vivic mentioned earlier during his presentation the the first one is unbreakable consent and this relates to the issue that a lot of existing social apps are push-based so advertisers or platforms or big algorithms will impose what they want you to see and that's just kind of what you get um you don't really have much Choice there and cryptography allows you to do the opposite in a lot of these MPC setups you have to consent you have to opt in in order to actually have computation run on your data um the second idea here is digital phermones

and this relates to the issue that a lot of existing social apps are closed platforms so your data stays within a platform and you can only use it within that space and digital fairmon is this concept that your data can be open it can be anywhere it can just exist and as I'm walking by aush like our digital fairmon can somehow interact and it can do so in like a safe and privacy preserving way it's a great metaphor it's kind of cre creepy when you explain it but it's also kind I you understand it's sort of like usually if if you try to do this sort of like two people walking by each other it's because you both have some app it's owned by a third

party it's doing tracking on both of you and then matches you here you're sort of imagining it being from something that you have yourself that's not owned by a third party I'm guessing like something where it's like something on your device that it might be provided by a third party like the ability to create this thing but then it's just living on your device and it's like being triggered if you walk by someone else yeah I think I like that that that like response initial response is exactly why cryptography is so important that's why like if this idea were to work or make sense I think having safety and privacy would be a critical component of it because otherwise it would feel like super weird if someone was just like

spying on you the whole time and you walk around and they like match you with this specific person person that's like really targeted that would feel like kind of creepy in way well that actually exists right now with like adte where it's like you walk by a certain store and then I remember this is from years ago there's like adtech platforms where they would like if you they knew your Spotify data and somehow like mapped where you were and then it was like you'd walk by a store and you just get the advertisement for that store while you walked by it in your Spotify feed and I don't know if this this is a company that was like pitching me so I don't know if that that actually worked with that if they ever got it into the hands of people but they're trying to

and it's very adte it's very web to it's very not privacy friendly it's scary related to that idea of like you whisper something into your phone or you're like just having casual conversations like oh like thinking about buying a cat and then the next day you get a bunch of cat ads and it's like oh how did this get here I don't know yeah yeah so that was digital phermones the final one is this idea of narrowcasting so narrowcasting opposite of broadcasting this addresses the issue that a lot of social apps are public Billboards where you just post a bunch of information it's generally accessible I think Twitter uh Instagram is somewhat public half public um Tinder everyone sees your profile and this idea

of narrowcasting is being able to specifically Target who can see your data and who can interact with you so you want to be able to say hey like I want to find out who's going to this concert but I only want to ask people who are maybe like two degrees away from me or people who share the same music interests as I do and would be interested in going to this concert as well so you get more targeted queries and the idea is that leads to safer and more intimate connection is there a connection between the co- snark idea and narrowcasting is that like a use case because you sort of you mentioned something around like yeah having at least it sounded like it was a smaller group getting access yeah well it's something that

we're thinking about a lot because it's a problem that we kind of can't really solve right now with MPC we can't really do this well I shouldn't say can't it's like we don't immediately see how this can be done in an efficient way with MPC right now or like in a very privacy friendly way because there I mean this is a bit this transitive trust problem so you're saying that okay I trust you and you trust him and like there are a few people that are a few degrees away from me and then you have the social graph and if you want to sort of Traverse this graph in a privacy friendly way you need to touch every node and then it becomes like um super expensive to try and actually do

anything if you want to say okay um I want to know what concert or like what music taste we have in common or whatever you need to just check the whole graph and so if your graph is big then it's yeah it's hard so it's definitely something that we're thinking about a lot um it's my favorite favorite Topic at the moment so I really like that you brought it up um but yeah I think like for me this is one of those things that should be on this board next year like um it's definitely one of those topics I think will it be called narrowcasting or what um if someone has a better name please let us know is that the word is that the term that you were using when you were thinking about I mean so I was thinking about it in the context of more in the

trust context so like how can I know how can I tell you that I trust him so you can have some relationship with him as well and like if you trust me how can you inherit some trust from him knowing that I trust him this kind of stuff so it's a little bit different and this is the the transitive trust problem so it's a little bit different to it's yeah it's a bit different to to narrowcasting but narrowcasting is yeah I I didn't want to the name is not bad I didn't want to challenge the name but the feromon also makes me think of like some sort of digital smell it's kind of it's it's quite descriptive smell it's also I don't know

what else that's it's actually quite good yeah it's great like if you think about it what what it means but yeah at first it's sort of like digital smell everyone in the 90s wanted like smell Vision they were thinking about how do we digitize smell and how can we like there you go I mean I think this is a nice way to do it congrats on your smell vision nice I want to go back to what you were talking about iush with the signed data so you talked about like ZK email being a like it's something you can get signed data from and that's sort of why you started there what other kinds of signed data are there you mentioned passports but maybe share some others that that you're thinking about yeah there's so

many I know Andrew also has a list of these up um I mean we've seen I know like credit card transactions some sometimes have signatures on them I've seen um what else have we seen we've seen so the NFC chip in your passport has it but also um when you download like um a digital version of your for instance your state ID if you're in the states and that'll often also have a digital signature on it um when you sign documents like on Doc you sign they'll often send you back like a signed copy which is actually also often like digitally signed with the cryptographic signature um I know in India they um team or one of the teams like adjacent to the other team basically all of your

documents like your Elementary School certificate and your high school diploma and all these things are all digitally signed and put into like the the Indian government has asked all these organizations to sign it and that's the only way you add it to your kind of central registry of all your documents and so now you have like a billion people with like crazy amounts of sign documents and data which is very interesting um do you when you're thinking about the signed data though are you also thinking about ways that like data could be signed in the future like what you've described is sort of like where you can now get signed data but like yeah absolutely I mean I think the ideal case is that for instance like I I spent some time with like the ITF conference like the standardization

conference all these internet standards and I was like hey we should go sign stuff and people didn't really seem to buy most of the use case but when you say oh you can get Providence you can stop fake news then they like really light up and so I think if you can pitch like even traditional uh web folks on hey look like you can you can get more Providence on data you can stop fake news and therefore you should add signatures to TLS you should add signatures to everything photos exactly whatever it is exactly then allow you to verified in the future and there's a lot of like really weird ways that people are doing this kind of like authenticity like I saw a paper the other day where so so like one of the problems with signing like photos or audio is that you

can often like put something like there's some connection between the thing getting input on the thing doing the signing but I I there was this paper where it was like oh you can use a like variation inherent in like an fpga to to detect the correlation between something like temperature which affects should affect in a correlated way and you measure this fpj so that you can say oh yeah is this correlated in the correct way therefore yes I'm actually live measuring the temperature and you can get this really weird like interactive ZK proof out of like a like Hardware defect which is like crazy to me um so I think we're going to see a lot of like crazy crazy weird new like attested sensors where something on this side is doing a hash here is doing like fbj noise detection and like you get these

really weird new attested sensors but I'm yeah I'm very curious to see where that field goes that's cool um you one of the points you mentioned was unbreakable consent but we didn't actually go into what that is so let's dive into that one yeah I think it's just the idea that this consent of using your data is actually enforced at the technology level so when you uh let's say run multi-party FHA on your data or run some MPC like you actually have to participate in this computation to be able to have the computation execute correctly um so I think there's there's roughly two different scenarios here

when we talk about like FH MPC security um this terminology I believe comes from Enrico from psse but it's delegated versus Direct Security so delegated security means I want to Outsource some computation so I send it to a bunch of different parties and they run this computation for me and then I get the result back uh Direct Security is what we mean when we talk about unbreakable consent it means you are actively securing the computation because you are participating in it and so if you don't consent to this computation if you don't like what's going on you just don't participate and nothing will actually happen like is this currently though very conceptual or is this like do you have you seen something like this in practice I think this is how we

Implement NPC stuff in practice right now our NPC schemes like these uh PSI implementations are based on this idea where you actually have to like say yes to this to decrypt I think this is yeah like suppose I mean even with these uh cards suppose we're in a four party NPC protocol and we're all the notes and we're all Computing on our encrypted data between us suppose you at some point become un comfortable with the convers uh computation and you don't want the result to be revealed or somehow I don't know whatever you can pull the plug and and before like the result is computed then the network breaks and essentially you don't get the result so if unless everybody stays in

till the end and I mean yeah this is a bit different to the delegated case that's cool so I feel like we've started to tease out like a few of the future ideas I do want to sort of get the audience slightly primed I don't know if you're ready to jump in but I'd love to like start thinking about these use cases or the things that we're talking about I'm kind of hoping to hear from members of the audience if you've been thinking about these things or if maybe you've been thinking about something else that comes off this um Tanya do you have the mic just to be ready and so just put up your hand even if we're like

we're in the middle of talking if you have something you wanted to add or if you're thinking about anything around this um do you have any like especially maybe you in the miscellaneous category do you have any like other than these three do you see any applications emerging maybe people like things coming out of psse like kind of other application categories yeah I mean I think for me the big topic is around trust and like it covers I mean for me this is a whole new industry that is kind of bobbling a bit now and like it comes up in pretty much every single

conversation that we have like that I've had today and like even just a few examples um one is let's say you want to set up an NPC Network how do you trust the nodes that are in the network um how do you trust the data that goes into how do I trust the results of this uh computation from the two of us how do I know and so like one conversation like also with the signatures okay I can sign some data but how do I know that the data put in there was is was fine so there's all this kind of stuff about trust and like a nice conversation with yens earlier was a bit like how do we know we've won actually is it when your granny is on boarded to

web 3 or is it when the government trusts that your ZK passport is valid yeah yeah and like how then does does your granny trust the government or does she trust the cryptographers and like you know how does all of this play out and I think like it's really hard like we're all kind of trying to figure this out now how how who do we it's not who do we trust it's yeah it's not trustless and so somehow this needs to emerge and somehow and then even with the code like what about you know how do we trust the code for sure do we need now more like um yeah like yeah like there's just so much about trust like from the technical

aspects like both like okay um proving and formally verifying code to forming these like mini governments or institutions that sort of say like this is a good protocol this is a protocol whatever um so yeah there's like on the technical side there's a lot about trust on The Human Side there's a lot about Trust on the like fun side there's a lot about trust like so for me that is the kind of key topic that covers and touches everything both in web 2 and web 3 it's like for me that's the topic that ZK like starts the little spark and then it's just going to explode I think W yeah I think one one concept related to

trust I think uh this is from our node but I might be wrong talking about trust infrastructure I think the quote is something like crypto allowed us to build stadiums uh programable cryptography allows us to build bars or some something like that um but it's this idea of like uh not just having trusted spaces that are like building Global trust or Global consensus but programmable cryptography really enabling uh more local areas of trust so there's this team called Tonk that's building this concept called speak easys um and I think the idea is like you have to provide some ZK proof that you meet a certain criteria to join this private gated space and within that space you can uh you know talk freely to other members of your community but the

purpose is it's more of like a small cozy space rather than a large scale venue I just want to I want to highlight what you were saying there too because the word trust I mean we use I trust this I don't trust this but I think the concept of thinking about trust now is in contrast to the promotion of that trustless mentality which I think actually dominated the conversation in in our space for many years like as long as I've been in it I think I was introduced this like trustless sounds like untrustworthy when you first hear it and then you have to learn that trustless means you don't need to trust anymore because everything is built by engineers and it works perfectly and you can just trust the

cryptography and the ma and the engineering and and don't worry but then you in that conversation with Arno he kind of brought back and I I think it's been talked about a lot in certain circles is that idea of like still there's going to be someone who makes that code and there's going to be someone who maintains it and like there are other places there there's like you may still need institutions or something human that creates trust for those trustless systems to be trustworthy anyway yeah I know we have a we have uh someone from the audience yeah okay amazing what I say uh uh don't trust verify it was always uh

but um I think with on on that I think um you know not from a non- tech um perspective I always uh find this uh system fascinating because it helps us to remove human error and create better ways to relate to each other but going back to what was it MPC feromon what was it right digital exactly digital pherone catchy name um I was recently looking at an app right and they are kind of web two SL trying to move more in web 3 and they had those kind of um uh ads exactly that um you have to look at and I checked a little bit what was the issue

or the perspective that um certain de rails had about this app and one of the um thing that pop up was I shared a lot of data with them and I don't think I got what I uh was expecting back and and so I think it's a really important use case because a lot of times we have you know problems in our space with user engagement but imagine a a web two app you know trying to cross over into web 3 and being able to utilize um uh MPC or you know DK to allowed at least that layer of privacy or consent um it could definitely be a great uh use use case and it will be lovely to see more of

that nice thank you yeah I think something interesting there is this question of uh most existing social apps are based on ads and require ads to run um and inherently this idea or the way ads have been implemented is based on this like Marketplace model um it is based on this auction and so this question of like can we create pole-based ad systems does that even make sense as a business model uh is there any setup there that these like new projects that are based on consent based on user ownership like what are the business models there for ads or do do ads just not work at all in that model just going back to oh is there

another question yeah let's go I was going to go under a different line of questions so if you um want okay yeah so I've been thinking about um web proofs a lot in ZK TLS and it seems like the um the the main focus of those projects is is building like an identity product first and to me that seems like it's one of the features of a wider product that eventually will come and sort of like an internet of trust or an internet of truth whatever you want to call it I think I understand the end Vision I think I understand the identity products I'm struggling with the middle and what comes next um any hypotheses can you say that it says you the ID Products and the yeah like it seems like a lot of like the ZK TLS or like the like those types

of projects are focused on identity looking products right now um and eventually I understand that like yes of course you need an identity product in order to engage with like an internet of true statements or something like that but I'm struggling with like the next thing um to get to like that eventual internet well I think I mean I think like a lot of the ZK VM stuff that's going on at the moment is maybe a first step towards that because at least there you doing computation that's verifi like verifiable it's maybe not fully private it's like this sort of going towards scalable verifiable computation not necessarily private so

maybe not so good for like all the all the use cases but like I guess that's the first kind of step towards it it's one of them at least I think but yeah like that's the hard question like how do okay we we're here we dream of being here how do we get there it's like that's that's why we're here that's the job and maybe one note on the like broadening of possibility from like things that we've already intuited is combining ZK with other cryptographic Technologies like starting with ZK and NPC or ZK and fhe we've also seen like oh you can now FHA things verifiably and then I think also some of the stuff that c explain like oh now what if you combine that with a witness

encryption like oh you get some really interesting stuff and even though we don't have full witness encryption we have partial witness encryption actually that gives you like enough um that you can do really interesting things and I think it's kind of like okay we've now had like almost like eight years since like bro 16 since like practical ZK proofs to be like okay like what can we do with these things but we've had only like less than six months since practical like witness encryption could be combined with like ideas from ZK etc for us to think about what can we even do with this technology and so I think as we see more of the cryptographic infrastructure getting built out then it'll allow us to be like hm okay we can verify this kind of like weird cryog graphic computation what does that let us do and it's kind of a different

mental model necessarily than the kind of narratives we've seen play out repeatedly in ZK or web 3 or whatever these existing spaces have been I think just to follow up I think this is like exactly the nice way to think because if you think about TLS itself like Security on the internet for communication there were all the building blocks like people were building like okay public key encryption and signature schemes and deploying them and making them efficient and like all sorts of stuff like handshakes and like you know reducing latency and all sorts of things and reducing communication and like you know it was always this kind of like ah here this bit tweaking this bit H you know and like um cryptographers would complain that maybe this is peace

meal engineering whatever but at some point enough tweaks here and there lead to the whole thing just kind of working kind of not overnight but like just working and the same with Bitcoin like uh all the pieces there was ecash and there were like Merkle trees and there was like all sorts of stuff and eventually someday they're just kind of put these pieces that these weird pieces that you plug in together somehow just form the right configuration and it works bitcoin's there TLS is there and then yeah maybe this is the um the way forward I want to like what you mentioned there this like ID to web proofs it just made me start thinking about the ID Products that we have and

programmable privacy and something that like something that web two stuff gives you I'm going to I'm going to do here's my slight case for what web2 is good at is that you sign up for something you live on that thing for a little while and then at some point you kind of get bored of it and you move on and as an identity so usually we are in our space claiming the problem with leaving your identities fragmented but I think there's like a freedom in leaving a plat behind like I think of my like Myspace account and I'm like I'm okay with that not being attached to my current person do you know what I mean like in a weird

sense the siloed effects of web 2 allow you to leave identities behind which can be good I think to grow and change in what we're building like do we have the ability to leave your identity behind like I mean I guess I guess guess so but it's this is something where it's like if you own it and it's attached to you we can carry it with us everywhere like can we still opt out well I I sorry random yeah I think that's a good point but I would say like in this data ownership model we can do something even cooler which is that we can have multiple simultaneous data profiles at once so you can own all your data and at

any given point in time you can choose who you want to be so you can set certain profiles of like oh I'm at ZK Summit I want to be this person like let me show this data let me surface this data when I interact with people uh let's say like I have this like digital fairmon setup my digital fairmon are tied to my ZK conference profile right but then I go home I go back to my friends and I want to go like hang out uh with people maybe I put on a different profile and because I'm in control of my data I get to choose who I want to be in any given moment and to me that's like a really exciting primitive that's cool I think that key word there is choose like you have the choice with the web two platforms like you don't

have the choice you don't have the choice to leave and take your data with you you okay maybe you can create second account but like you don't really have so much choice and in web three like you have the choice to first of all change but you can also choose to kill them I mean you can burn them burn an address or like burn whatever I mean it's hard to kill something completely but yeah choice is the key and maybe one small rephrasing the identity is like I feel like historically identities have been oh I'm going to collect all of these little badges that show who I am but I'm not sure that necessarily encapsulates like how we want to think of identity moving forward it can be like a weirder thing like oh like I'm going to add aspects to profiles or I'm going to pull this piece

of data from here for this one action I'm going to do so that one action can be more relevant it's not like a badge I keep on my profile forever but it's like oh this one thing I attached to this one piece of anonymous speech so that that can become more relevant or in context or whatever and I don't necessarily think identity has to be this like longterm thing it can be something shortterm that you apply it can be like oh I just did this thing yesterday and therefore I'm going to tell you this thing about today and then I'm never going to think about it again I think it's when ID becomes attached to immutable ledgers though is where you start to think can you choose like isn't it somewhere and I guess if it's private it kind of is not visible but it

is Al also there forever then again I mean no my MySpace account might actually be gone I mean is my space still around well maybe one pitch is that you if you have an immutable Ledger this is just one of like many cryptographic tools you can use to build your applications and maybe The Ledger doesn't need to be the place where all these adest stations live publicly for anybody to see maybe you just put commitments there and then if you want to delete it you just delete your the preimage of the commitment and now nobody can reconstruct it or you use the ledgers as a place for everybody to share the verifying keys or to come to consensus on the public keys or whatever it is and like that's what these chains endend up being used for and not for actually the way people currently

conceive oh let's like throw identity into this little like token and have everybody keep it like that may not be the way that we actually use them that's cool any other thoughts from the audience curious if you guys are thinking about anything like this are you working on anything that you think is sort of in a new category or if you want to talk about anything we've talked about uh do you think that giving people choice like at at some point people don't want to choose right they just want to go through a flow that like simplifies their user experience uh do you think this will be like how do you go about that how do you think about something like that that's

interesting are just to rephrase are you sort of almost like are we is is there sort of like too much power given too much control given like sometimes you just want an experience to guide you and you just want to do most most people will not like I that's correct um and I think the like ideal situation here is you have multiple choices but each of those choices is quite opinionated and so you can choose your path but your path is still like determined on a certain personality or certain opinion or certain perspective worldview whatever you want to call it um but you can still switch if you don't like

that although that still has a lot of agency I think some maybe what you're talking about is like situation where you want less agency I feel like we're in a room full of people who want agency but but maybe but maybe you're right maybe there's I think these are a special group of people but there are reasons why there's like Bitcoin ETFs or like why certain Banks you know store your Bitcoin because people don't want to manage their keys or they don't want to manage their Investments and that's fine like I totally agree that sometimes these services are needed for helping people so that they don't have the choice I mean but it's nice to have the option like if you want to hold your keys you should be able to and I think this is

the thing that the people in this room are sort of working towards another way that I might look at this is that this layer where you have Choice doesn't have to be the application layer it can be the infrastructure layer below it and now the instead of currently the world of applications you build you have to build in a world which you have no choice oh you can build one which you have choice or you can say my users don't really seem to be like that I don't want to do that and you can now build on top of the infastructure have one in which there's no choice for the users and that's totally fine but at the base layer like there should be an option to have that and I think the world can look very different if users have that option at least simmering in

the background even if it's not directly exposed to them in the way that they interact with the applications but then going to that application idea like if you think about how applications tend to get built and how also they tend to get funded one of the questions will always be like what is the moat so like they're building to hold hold you there that's what they're they're trying to do it's part of their business model it's part of like what makes them competitive so I wonder if like yeah it's almost like as a crowd like there that there'll still be a gravitation towards applications that make a lot of it easy and then there's power in that and there's some sort of moat and you can always go around it but the same way

you could always run your own like what is it you can run your own website off your own server sitting in your house or something I think you can do that I I've never done that but you know what I mean like I think you can do those things but they become so unpopular and like everyone else is over here now and there's more power in being in that closed Garden I just wonder how we really break out of that like it is crazy that Twitter and like those platforms still like they still capture us like all of us I gave you hashtags to tweet like we're not away from it yet we don't like it I mean most we're not like into it but we can't seem to jump to anything else but I think this is like again this The Stadium versus the bar is

like now if it's easier if it's easier to build something like you know if it's easier to build a bar than it is to build a stadium then people are going to build bars and you know if you can tear it down quickly people will do it and I think because of the sort of Open Source nature and whatever replicability or composability of programmable crypto generally this makes this sort of yeah the bar building easier and so and I think like it should be I mean a lesson for all of us to build the tools that allow people to build the bars and not

like I mean always in cryptography when people talk I mean yeah like again another conversation earlier was like how like even if you have a PhD in cryptography you can't verify that all of this code is correct like I mean so at some point yeah you need to make sure it's open and composable and that people can build I would also say that uh if these things are easy to build they can also become like the default path can then be technological to resolve these and not legislative like we notice you know oh now there's all these cookie Banner rules and the solution to the cookie Banner rules can either be add a bunch of banners to your page or it can be use NPC for analy so that you don't actually see the analytics or the individual user

data and now even though you have cookie Banner legislation it's solved the problem by pushing us towards a more cryptographic technological friendly solution and we could do the really hard path of okay let's like really get super screwed by all of these things and then build legislation to stop it and then come back to the technological solutions that allow us to keep the flows we want or we could skip all that legislation little Loop and then just say okay what is an actual technological endgame can we build this now can we at least build the tools that allow us to build that later I want to go back to your what you were saying about the bars um because actually as you were saying this something I realized is like I think there needs to be something so like the social aspect the fact that what is a

bar it's like it's a group of friends that meet often but there's a size to it it's not like yes you could have like the threepers bar the dive bar or the I don't know Dungeons and Dragons game or something like it could be the smallest group but I think you think of those it's Community it's about like where are people and that kind of going back to that idea of like if everyone goes to the big app even if it's a d app even if it's on a decentralized thing it's all owned by something somehow or or C or could be captured like I think what you have to build are these Alternatives but they have to be they cannot just be like solo Solo webcaster solo blogger like if you look in history you know yes you had

power you could you had agency but if you were sort of stuck on your own in a desert like eventually most people just sort of drift off but if you could keep some sort of community like if you could keep people still stuck together around something or in something or at a bar then it might work anyway I think that uh relates to one of the like most important questions here which is how to like how to fund these types of projects right that's the elephant in the room it's like how do you provide a sustainable funding model for apps that provide a ton of value to maybe a smaller group of users traditionally funding is designed for apps that just Target everyone um and

we've seen how that turns out and I think like it we like a lot of teams have still yet to figure out if you want to build the bars if you don't want to build the stadiums um but for the people who go to the bars like that is really important to them and that matters a lot to them how can you still build a sustainable entity around that I think there was a question over here or a comment is this one on um is this a general question like how do you see ZK interfacing with AI now I'm investing in AI infrastructure and I've done a lot of investing in ZK in the past I'm interested in your thoughts it gets thrown around a lot around things like proving computation on graphs um proving

provence of data and ZK is like thrown around a lot in that but you guys are the experts I want to hear where do you see the real applications today ZK AI yeah yeah I think the kind of canonical examples you see are usually around like proving that a model execute did correctly or proving that you trained on some private data correctly or proving that you ran inference on somebody's private input correctly um but I think there's like also another side to these which is not actually about the like training or inference of the model but is about the like verific of the outputs which is like oh like how do I verify whether this thing this image that I'm seeing online came from an A Genera model or not and then oh now like the

thing that cryptography does best which is like Providence and adding unforgeability like one of the things that AI cannot generate like you cannot generate a fake digital signature you can generate almost anything else you can generate pretty convincing looking text but you can't get 26 bits of entropy out of a 4005 billion parameter model or whatever and so this becomes then one of the defenses that we have against oh like can we verify whether this text came from an AI or a human can we verify whether this image came from an AI or human and you can bake a lot of this cryptographic techniques into the models and then help ensure or into the model outputs and help ensure that okay like a camera is going to sign this thing came from the camera and therefore I know that it could not possibly have been generated by the AI and so you can

I think a lot of the the thinking around AI also can be around like not just oh how do we like get privacy around the training or the inference but oh how can we like get Clarity around the Providence yeah there's been I mean I think it was in early 2023 there was like a group like a zkl group that was founded and a lot of ideas were thrown around and I think there was a moment of a lot of excitement around it and it sort of chilled out but I've been left with this and but I I don't know if I can Define it that well but it is that like things like ZK and MPC they they almost add this like human protection thing like against some of the AI stuff maybe for a while I don't

know if it's forever because AI is pretty smart maybe they'll figure out a way around it but like in the in the uh short term it seemed like just coming out of those conversations that ZK could be a guard rail maybe cryptography certain kinds of cryptography could be guard rails to what this thing could do just to help the human brain decipher like in the case of Providence or to help look inside what's happening when it's a very opaque system yeah at a at a fundamental level like if you think about AI is an extremely enabling technology it allows you to do all these especially generative AI being able to like just create things on a whim cryptography in

the spirit of adding hardness directly is a remedy for that hopefully hopefully all right I think we're getting the nod we're getting the signal that I think that the event is meant to wrap up really soon um thank you guys for this panel uh talking about some future ZK applications I have a a bunch of notes things that I want to explore um thank you all for joining for ZK Summit 12 and for coming for speaking for being part of this thank you all thank you yeah dozen um maybe just a quick note there I think we don't have it up

on the screen but there is this Afterparty happening tonight there's a ton of side events happening tomorrow please do sign up for them um I think the teams are like they're kind of calculating how much how many spots they have based on who signing up I know some there's also sort of an assumption that people are just going to show up but it's better if you do sign up actually cool okay thanks everybody see you soon y