zkSummit6: Espero: Optimistic SNARK setups for Plumo - Kobi Gurkan - cLabs

Transcript

[Music] so yeah i'm calling um some of you i know that know me but those that don't i work on applied cryptography i do a lot of work on cell and part of the work i've been doing with cello is this is the plural ultralight client yeah which is a snarf accelerated uh life client that that's optimized for mobile phones um but today the talk is actually about espero which is the system we've built

for doing a good and efficient snark setup for this normal ultralife climate all right so before we get into the setup itself i want to give a little bit of a plumber recap just to give the motivation of the tools that we're using and the different curves and all these kind of things so let's do that in general we know how light clients work and if we quickly recall in proof of work like clients what you do is you download the headers and then what you do is you verify the proof of work on those headers

and then you assume that this is enough assuming um assuming general math works that you get reasonable security if you verify just the proof of work headers and that works nicely especially if you don't have a lot of headers um so maybe contrasting bitcoin and ethereum for example for how long the header changes um and you also have some efficient methods um to do it more quickly with like flight client and nippopal where you can probabilistically just get just verifying less blocks or less headers

and still get reasonable security when you jump to the proof-of-stake world where you have let's say bft style protocols where you have 100 validators and these validators sign each block let's say you need two-thirds of the validators to sign each block then it becomes a bit harder because you don't really have a single chain to follow and you just have a bunch of signatures and blocks so forks are in some way harder to create because you need to break honesty of like unless it is hard to break like two-thirds of

the validators should be okay but in some other ways it's uh annoying because now you can use things like flight plan at least for some bft style systems so what can you do so the first thing that we should talk about is how a naive proof of stake lifeline would look like and that would be sort of what i was alluding to so let's say that you want to verify your balance let's say it's an ethereum style blockchain where each block has the current state route and the state route for example contains um leaves that are balances of users let's take that as an example so let's

say that i want to know my balance i need to sync to the latest state of the chain and in order to do that i need to download each and every block and verify the signatures by the validators to see that the validator has agreed on what is the validator said and what that this block is valid so assuming for example that the validator set changes every block then you need to verify every block but usually you don't really have to do that practically so what some blockchains

including cello do is that you do validator elections once per epoch where an epoch is some amount of blocks where in cello it's about a day it's like 17 000 blocks given five second block times so the first thing that you can understand from this is that if you really want to check something within an epoch like to check your balance you don't really have to verify every block in this one epoch you really need to make sure that the validator said that you know is the most current one and to know that all you need to know is that the last validator election that

happened at the end of the previous epoch happened correctly and then after you do that you know what is the current value intercept so then you can take any block throughout the epoch and verify its validity because it's signed by two-thirds of the validator set that you know is the current one and when you know that you can continue as usual so this is what we call epoch based syncing so first of all you don't need to download all the blocks you just need to download all the e-book blocks and then whenever you want to make a lifeline query you download the blob verify the signatures according to them to the valid or second dc block and

you're good now the next thing you want to optimize is um the amount of signatures so let's say you have 100 validators and you need two thirds so like 67 validators have to sign at least and what that means is that you would have if you use the cdsa for example you would have 67 ecds injuries which is not ideal but what you can do using bls signatures you can non-interactively aggregate them and then have one single signature all right now the next thing is you still need to download every epoch block and that is not ideal for mobile phones or for resource constraint

environments so what we figured out is that all right instead of having live clients actually running this protocol of downloading every blog and verifying dealer signatures what we can do is we can write a snark that does exactly that verifies the signatures and outputs what is the most current validator cell and that's exactly what plume is plug is this snark that takes a bunch of epochs and does the symmetry verification and validators a transition and that's you know what's needed in order to create a single proof that takes you

from some initial validator set to the current value all right so quickly going over what we check so we need to check that the validator set together with a bitmap that's saying which validators participated because not all of them have to sign only two-thirds which so aggregating the bls public key according to this bitmap check that more than two-thirds signed check that the epoch number or let's say block number is exactly the block number that is expected which is the next one after the previous

ipo um then you need to do all of the bls signature verification so you need to do this encode encode it to bits and then hash to group and that's a bit hard because you now have to hash like a hundred validate your public keys and that's about a 14 kilobyte message so called the kilobit message so that's pretty um large and then you check availa signature essentially like a big aggregate build signature across the inbox so that's basically the plus for now in order to facilitate that because normally you cannot efficiently verify pairings inside the

snare we use this 2 chain from that was originally introduced in the sexy paper what was then improved by uh ewy and you know we saw that yusuf got in the top uh he's one of the creators of bw6 uh which is a two chain in the sense that in the in the snark that's written on bw6 you can write statements that verify tearings on bls 12 377 and so if you have bias signature it'll be last roughly 77 you're good and you can verify it inside the store so that's the curve that plumle uses essentially

uses bw6 for itself so let's since the last talk in zika summit like previously we gave a talk about pluma and some things that changed is that we moved from swc6 that was introduced in zaxi to bw6 and some architecture changes that are make all this construction more available to slashing and some we have this future subcommittee attack that we've seen so all this prevention and if you attended praticia's talk from yesterday about artworks so we also use the artwork style gadgets basically

plo is written over the artworks framework all right so this was um an introduction or a recap of pluma to give them motivation for a sparrow so why we need it what it is essentially and a sparrow oh just seconds oops sorry i'm losing my okay so aspara is essentially

um it's an end-to-end system for performing optimistic setups which will cover what it means soon that is optimized for large circuits um and especially for circuits that are um as large as the plume circuit um it aims to be end-to-end including verification tools and so on and the name itself is pharaoh it means hope or in esperanto in some way and it's a play of words on explain words on on optimistic i guess

so before we we dive really deep into what a sparrow does i want to remind all of us what it means to do a trusted setup what what we actually compute so in order to do that let's switch gears and go into doing some drawing all right so what what do we compute in a trusted setup so let's say that i'm some participant p is what i have i generate let's talk about the subset of the center okay so i generate a secret tau which is a field element

and what i want to output is something that looks like this all the output powers of tau but hidden so i'm given a generator of the elliptic curve and i want to output tau tau squared times g and up until some predefined power which is pretty large let's say n equals 2 to the 28 and i want to compute all of these so that's what i do let's say as the first participant so let's say this is tau one and now um as the second participant

i'm getting this and what i am computing is i'm taking each element and i have my own secret tau 2 and i multiply my tau 2 by all the previous elements so i do this i do this and so on [Music] and yeah and there's a result what i'm getting is you know we can write this to be differently we can write it as follows right we can do exactly this

so essentially i'm getting after we do a lot of participants i'm getting this tau which is tau 1 times tau 2 times tau m and i'm getting an srs like a structured reference thing which looks like this with this combined tile which is the product of everything and this is for example a subset of what you do in growth 16 and also in marlin or plonk like setups so that's what you do in a setup so

this is what you want to compute and this is how you usually do it you have a coordinator and the coordinator initializes the ceremony they create some initial setup they pass it to the first participant they have the randomness then you go to the second participant and you continue and so on so that's how it usually works um and eventually you get your srs and it's enough that one party is honest for this whole thing to be secure i know there are some like more details

like if do you need a random beacon and all things like that but let's not get into that right now so that's kind of the model all right going back to the setup itself now i described what a normal setup looks like from the point of view of participants but what they didn't describe is how do i verify that this protocol ran correctly and in the sense that we have a coordinator that passes the challenges or the srs from participant to participant but we don't want to have any trust in the

coordinator because that would kind of defeat the purpose because then we have a single trusted party so what we really want to do is we want to have a coordinator which is untrusted so that we can verify anything that it's doing so let's find out what exactly this coordinator is doing so first of all what we want to verify is what we call proofs of knowledge and actually let's go back to this and the proofs of knowledge mean that if i'm computing tau times g i actually need to prove to other participants to the world to the

coordinator that i know what tao is and maybe people that are kind of familiar with raw key attacks it's maybe a good analogy because if you don't verify that you know that the person that participated knows the tao then the participant might craft some bad contributions that would cancel out our contribution and that would be pretty bad because you want to make sure that nobody has been cancelled in others that's how you get them one person honestly uh okay the second thing you want to verify is that any of these

tau ig are not zero or infinity because if it's going to be zero then any operation you're going to perform on it later it's going to leave it zero and this whole thing is just not useful anymore and the next thing is you want to verify subgroup membership and which means that where we when we're doing a setup then we're working in a subgroup of the entire elliptic curve so we're working in a prime order subgroup and what can go wrong if we are not in this sample

so let's say that we have times g which is in generator of the sub group but some small let's say order three element t then if i get this then i get something of this sort t13 times d and then as someone who receives it i can just try maybe subtracting 0 subtracting t subtracting 2t and whenever i succeed and getting back into the subgroup this is like a small subgroup as

smaller you know yeah forever but smaller suburban that essentially you can discover some information about the secret about tao and that's not the idea like you can discover talmud three here which is not so good and you want to prevent that okay so that's the next thing you do now another thing you want to verify is the ratios and what do you mean by ratios so i have tao and i have tao square and i have um tao cubed so i want to verify that when i i divide in quotes

this like this then i get the same thing as if i divide this tau cube by tau squared is the same as tao squared by tau um and you can do that using some pairing but you really want to do that because you really need these things to be powers of tau and consecutive powers and if it's in incorrect then the stress will not be useful to create growth 16 rules for example so that's what you want to verify all right now the last thing is that i didn't draw is you want to verify

another station or what does that mean so let's say that i'm a participant in the setup and let's say that the coordinator says that yeah kobe participated that's that's great and this is their contribution and but if i don't publicly say that yes this is what i got as a challenge as an input and this is what output as a response like this is my output then people can't really be certain that the coordinator didn't lie so i need to attest as a participant that yes this is what i got these are the hashes

that i got as an input this is the hashes that i output and if i do that then people can be more confident that i kobe actually personally worked on this part of the setup and what i want to do is to go over some history of setup and show how it was done there to see what we are doing and let's start with the with one of the most famous setups which is zika sprout and that was for the pinocchio proving

system pghr 13 on bm 254 it involved six people it involved a few stages and it was quite involved people had to put some special operating system and burn dvds between different computers there was an automatic coordinator system that i think sean built but also i think he also monitored it very closely um [Music] people drove to remote locations and there was a lot of it was quite complex to run it um and

there is a tool that allows you to verify the transcript which is the combination of all the operations of all the people that allows you to see that the coordinator operated correctly it was for a specific circuit it was for the zika spout circuit and it took from what i've read and remember is like 27 hours for six people and the next one is zika sapling which was for the growth 16 improving system and that was on bls 12 through 81.

this time they had two phases one which is called powers of tau which was generic for every circuit up until a certain size it had 87 participants it ran for about three months then there was another phase which is the phase twos the specific for the sapling circuit 90 participants three months and this time it was manual like there was no automatic coordinator that people can just run and that's it there was a human coordinator operating over the mailing list and people would sign up

and they would attest to their hashes on the mailing list and they would also publish some of the stations and this is one of the famous of the stations by andrew miller that he went to to chernobyl and got some some actual foxy place and got randomness from it to see the the secret value uh i think this is the geiger counter i don't know but this is what happened there um but yeah people got creative and did some interesting [Music] side channel prevention mechanisms and this is what psychics zika something was

another interesting one is the acetic ignition which was a bit smaller than other setups in some respects so it was large in the amount of powers you needed but it also it contained only g1 powers so growth 16 includes let's say tau powers and g1 but also some other alpha random alpha times the tau power is in g1 and then beta times tau and g1 and so on so this was a pretty large setup and with a different construction all right so this had more participants like 176 and it took only

32 days and it also was pretty nice that you could i think it had pipelining of network and compute in the sense that while you were downloading the challenge you are going to work on you are already computing the ones that you are downloaded so you save some time and that stations in this case i think addresses and signatures were involved so you had an address an ethereal address attached to your identity and aztec had an automatic coordinator which was pretty nice you just needed as a participant to put

your participation software leave it running and when your team arrives it would contribute and that's it and then there is the perpetual power of tao that is run by wagina which i think is also in the top um and this one works is a pretty big setup it's 228 powers on growth 16 so it's pretty large and it's still running for more than a year it has about 58 participants and there is manual coordination um which means by email yeah or telegram there is an active telegram group where

it happens another one is the tornado setup where it's used for its phase one the perpetual powers of tao and for phase two it used some version of wasm compatible phase 2 implementation and they ran it in a browser so they had an automated browser setup you can go into a website and just run the setup i think it was a coordinator which was hoping that there are no collisions so contribution there because the circuit is pretty small about 2 to 18

gates then you could compute it in a few seconds your contribution um in contrast for example the perpetual powers of time where it takes hours and even more than half a day for some people and here it was a few seconds so people would just contribute and if there was no collision between people then they their contribution was verified and continued and then there was the falcon which is both 16 mbs 12 381 also pretty large 50 20 participants in each phase in circuit they have a few circuits and a manual coordinator and uh i think this is the last i have in my examples which is the semaphore

phase two setup for the seven four circuit again the perpetual powers of tau was the input as phrase one and phase two is worth 16 of the server for circuits and it was an automated setup and it's based on the ignition um ceremony and software that and it had about 51 participants okay now this sounds like very complex and a lot of people are investing a lot of effort into doing all these setups why are we still doing them like this is very annoying why why are we doing them and there are a few reasons so one is the proving time proofing time is

still pretty good with all these systems so that's one reason like you can run them run them on browsers run them on phones and it's pretty good but maybe more importantly verification time and proof sizes are very small you know some might say it's like constant size um verification time for growth 16 is pretty good and if you look at gas cost it's about 200k gas for verifying rough 16 proofs so that's pretty good and the proof size is two g1 elements and one g2 element which is

very small and if you have a universal setup or universal improving system like plunk and marlin um then you don't have to do more than one setup or at least more than one setup assuming that you trust one of the people in that setup was honest and i guess like i'm reading kev's question in the chat um [Music] then yeah you don't really need to do different ceremonies if you use the same curve and the same base field you can reuse it for

universal system again exactly like what alistair said in the chat which is any kcg public commitment basically right and what's different about the setups that we've seen in the history like the zika ones from the beginning and the setups that we see today and the difference is that we see that some setups are just much larger for like larger amount of constraints than we used to have so the perpetual powers of star is for 228 powers so it's pretty large right and

yeah so let's talk about experiment and the spiral to remind is this system that we've developed in syllabs to do um setups for large circuits especially for plumon that's what it was built for and you maybe some of you have seen this comic strip from xkcd so like if we have a bunch of setup systems why don't we need another one um i'll try to convince you why maybe we need another one or why it's good to have it so this is some details about what it gives you

so this is work that we based on work that we've done in the past with georgios that created some pretty good set of code base it's based in spirit of the zika and retro lab code basis and one of the main thing that we do here is we have we use an observation that's been noticed by justin and vitalik on his research to do some optimization and let me recap let me show that later actually all right so what we can do using this observation is we can

run the setup somewhat in parallel or that's a good question what's the right term here as long as they work on different chunks so let's see what it means so let's say that we have to compute a bunch of powers let's say from tau to the 0th power to the 100 and then to the 200 and then 300 and if we want to compute let's say that we have participants one and participant two this one has taiwan and this one has ta2 so let's say that is participant 1

work on this chunk of powers that is comprised of the parts from 0 to 100 so what i would do when i get the initial input that just contains the generators what i would compute is the following i would take my tau 1 to the 0 power and do 10 g and tau 1 to the 100th power times g and the second participant working on this second will do the same but for different powers okay but now let's observe something

nice that now let's say that we continue and we switch places now iwork or participant one works on the 100 to the 200 and then what they compute is the following let's say for the first element and in the same way what we compute here is for the last element is going to be this and since this is what we do in the setup this is all commutative so there is no problem in switching the order like this has the same meaning as this right

like there's no problem doing this so the observation is that we can execute things out of order while participant one works on the first chunk participant two can work on the second chunk and so on so this is in some way you can parallelize so this is what we meant here when we said that you can run setup in parallel for the participants as long as they work on different jokes and another thing that's being when we design the sparrow is that it's optimized for large setups so it doesn't require you to have large amounts of ram

this can run on one gigabyte random or two gigabytes it's enough like you don't need more than that even if the srs is 70 or 100 gigabytes that's not a problem um and one other thing that we felt was important is having end-to-end verification tools so you can receive a single json file and using the json file you can verify the entire operation of the ceremony using this verification tools and another really nice things that i'm really happy about is that since this is based on what used to be sexy because execute base which is now called our quarks um then it supports any curve that

ironborn supports so if you have work supports like a bunch of carriers like bn254 380 bl 12381 bls1237 um and you can do a setup on any of these especially for plumber when we use bw6 and you can use any kind of these parts so um this is recapping what we've seen when drawing you can divide the srs this structure reference thing into chunks the order when you contribute into channels doesn't matter but there is a disadvantage like this is there is no free lunch and you have a problem if someone for

example drops in the middle so let's say that i computed participant one on five out of ten chunks but then i i'm malicious and i said i don't want to continue it anymore so i turn off my computer i delete my toxic waste and i just don't participate but while i was participating some people already built on my contribution and on the contributions of the chunks that i already contributed to and what that means is that all these contributions you can't use them anymore because no

one nobody knows my toxic waste and therefore they cannot continue to contribute using minerals so we need to delete all of my contributions and all the contributions that rely on it so you might have like liveness problems might get stuck yeah which is annoying but the goods the good thing is that what we've seen in previous setups is that that's not usually the case usually the case is that people will have a hard time with the time the setup takes and they usually have a hard time um like getting things ready and coordinating and things like that but people are not usually usually malicious

and and moreover this type of malicious behavior is detectable in contrast to someone who uses bad randomness or colludes with other participants here you can know exactly who made the problem and the worst that could happen is that you need to restart or restart a part of the ceremony so that's like the trade-offs that you have to take here and maybe some something that we we've been thinking about is all right let's say that we have something that is not malicious but decides that they cannot continue the setup the computer doesn't work anymore and they don't have any other machine to

work with and they don't have the capability to work on the cloud machine for some reason and then if they really want to they can send us their or send like anyone their toxic waste and they continue for them so you lose the security of that participant like the randomness does not contribute to security anymore but liveness is maintained so this is a good trade of insults um specifically for plomo which is a 227 roth 16 setup on bw6 which is a pretty large curve it's like 761 bits which is much slower

than the corresponding let's say 381 bits on b 12 381 we felt that we needed to do more optimization so what we've built into arc works or like our work of artworks is the capability to do batching versions on on like a batch of scanner multiplications together um another thing is an assembly implementation or on intel like x86 of beta bw6 arithmetic another is glv implementation which actually now works for almost any character in artworks and we

also have an experimental gpu support using the excel library um because all this is written in rust and excel is seems to be a wonderful library to take rast code and run it on with a supporting hardware then this also works so the result of all of this optimized arithmetic is without gpu support is about 3 to 4x performance gain which is really nice and what we found is like which is a big plus and plus in working artworks is that optimizations were pretty easy to have and generically because artworks is so generic

so we really like that um and maybe some more details on the sparrow itself so the coordinator that we've described is very simple and it's simple in the sense like it does some things it's not it's it's smart but it's simple in the sense that it's not resource intensive all it does is coordinates participants and make sure that participants don't work on the same chunk at the same time and that participants can lock only a certain amount of chunks and that verifiers like this the verifiers that some people run

like the coordinator group runs and know what they need to verify and manage all this workflow so it's pretty simple it's not resource intensive so that's what we mean by a simple coordinator um and you have scalable verifies in the sense that you can create as many verifiers as you want and the coordinator just gives them the ability to to verify um any contributions that are ready to be verified and we also work directly against cloud storage so that resulted in pretty fast download and upload speeds um and also does not require any

hard infrastructure to deploy and you may have noticed that now since we divided the srs into chunks and in the case of plumber we divided it into 256 jumps then if i want to do these solicitations that we've talked about before then i would have to publish a lot of hashes and that's a bit annoying especially if you want to put it in a single tweet then maybe what what you want to do is instead use signatures something that is similar to ignition i think where you have an address that you attach to your identity and what you do is you add to the transcript

of the ceremony signatures or from that address or from the public key on the hashes of what you got and what you responded with so essentially once you attach publicly to your address then people can already be pretty certain that this is exactly this person that worked on these chunks and one maybe an additional last thing that it sports both growth 16 and marlin but actually like it supports just creating

srss that are from kg10 but actually it also supports this degree bound um polynomial commitment which is nicely described in oral light which you just need to add another login elements to the srs and you have better degree bond for lower commitments so it supports both of these kind of setups and yeah i guess like i have some call to action here is that i've described the plum setup like yeah when is that happening so it's happening pretty soon so i would encourage uh anyone that is

interested to read the post about it and i will send the links somewhere more accessible later um and read the post that's about why we're doing this which i kind of summarize in the beginning and sign up and to the setup and see what's happening here awesome and uh looks like uh gab put some uh oh sorry you're gonna you're i'd interrupt you before you finish let me know yeah just one one last line i promise no problem uh yeah i just wanted to thank like everybody who's been involved here which is the

cell team a bunch of people from syllabus specifically and some people from earlier that also contributed to making this setup system work really nicely and lastly all the others of the mpc setups that we based all this work on but uh yeah that's pretty much it um yeah and alex please go ahead with what you were going to say oh i was just going to say thank you kobe and uh yeah it's great it's it's great this work i think lays the foundation for hopefully a lot of other future work in this area and we'll see this technology uh become easier to instantiate and hopefully that will bring a lot of new and interesting

applications so uh with that um i did want to just say let's maybe turn to questions and then also i wanted to highlight uh some of the stuff the the resources that kobe just mentioned i've been posted in the chat there so take a look there um and yeah there's a couple questions maybe i don't know if you can see the chat kobe but uh looks like kev that has uh has a couple questions and maybe you can start by addressing those and if anyone else has questions uh feel free to post them in the chat or raise your hand and we'll call on you cool okay let me go over that all right so yeah kev was asking would an attack vector be that i assign myself to the first chunk and then wait

for other participants to work on further charms then i abstain from publishing my channel making the work of other participants unusable yes this is an attack vector and this is the trait of that you have to take here and that people attach themselves their identities to what's happening in the setup and essentially if this happens you have to restart for the chance that people already built upon and but what you should also do as the coordinator is monitored for any participants that concretely are

either not contributing for a lot of time or or hold lokichang for too long of a time and remove them from the setup early on or as fast as possible but yeah definitely this is an attack vector and some some way that we do to cope with that is to divide the ceremony into rounds so not only divided into chunks but also into rounds so if you have let's say 500 participants maybe you don't want to run all of them at the same time because then a single malicious participant can

hurt the livelihood and you would have to restart the ceremony so what you want to do is divide it into rounds where you have a group let's say of 50 people in each round and then after each round is finished you do all the verification you need to do and only then continue to the next round now if someone is bad in the second round then the output of the first round is not heard you can continue with it so you can either remove all the participants from the second round or you can remove only the malicious participant then continue from there so this is

some way that we mitigate this by dividing the whole setup into rounds yeah awesome uh are there any other and does anybody else have any questions um feel free and post here we'll give it a second because there is some latency between the chat and what we see kobe so uh feel free and post it if you're in the session feel free to post any questions you have in there or raise your hand and we'll just pause here for a few seconds and let that let those come in right so i see another question uh again because so can the coordinator verify uh a chunk is correct before a round is completed

all right so that's a very good question and i realized it didn't touch on it before so you can do partial verification and what it means is that all right when you work on a single chunk then you get like a contribution on this chunk then you can verify that points are on the infinity point and you can verify that they are include the correct subgroup but what you cannot reliably do is verify the correct ratios because the ratios need to be verified across all the chunks together and if you don't have all of the contributions from all of the participants then you cannot reliably verify what

happens in the intersection of charge and what this means is that you delay the verification of ratios up until the end of a round and only after you have all the contributions from the different participants in this round then only then you have you can do the verification operations reliably so that's what the coordinator can do yeah all right so i think um yeah okay yeah two comments uh so coming from there i don't quite understand this splitting into rounds

okay yeah that makes sense because i went over it really fast um but it's simpler than probably how i described it so let me try again so let's assume that i only had 10 participants in the entire setup and they all work in this optimistic manner and they work on different channels and then it all finishes all the different 10 participants contributed to all the different chunks and we got our final srs and we can verify ratios and we can do anything all right we can take that srs and continue from it and or we can continue building on top of

that sos and start another round that has 10 other different participants so if you imagine how it worked in the mailing list of sapling then instead of one person being scheduled at each slot then you have 10 people scheduled at each slot that's what i mean by wrong i hope that's more clear uh okay cool i say that there is uh oh i see that's good light bulbs flickering on yeah yeah so like it it applies to any setup like it doesn't apply only to setups that already use multiple problems yeah uh

maybe like some terminology like the different phases in a setup we call phases and rounds is groups of participants um and chances are like slices of desserts yeah okay cool um great does anyone have any other quote we probably have time for one more question uh if anyone has any so we'll pause for 10 seconds and let let that come in if there is one yeah maybe i can just say that um all this is already open source like you can already try it out and besides contributing to diploma ceremony you can just

use it for your own systems so feel free to to check it out i'll send some links awesome okay thanks kobe i think uh i think that may have been our last question so with that i just want to say a big thank you to you and to everyone who attended the session and just quickly plug uh we have one more talk and one more session actually the next talk on the main stage is lightning talks and then the next session is going to be we're going to change gears a little bit and talk about optimizing some of these uh operations and hardware these cryptographic operations and so be a little bit of a change but i think some very interesting and important work that's going to be presented by the folks at chain reaction so stick

around for that and then of course for those of you who hung out at gather earlier we're going to do that again and then we have a special surprise uh for this time around so don't miss it um so with that i'll i'll see you all hopefully in the next session or or at the after party in in gather thanks again kobe thanks everyone for attending see you later