ZK12: Discover collaborative-SNARKs: Circom & Noir meets MPC - Franco Nieddu

Transcript

[Music] so yeah hi um I'm pretty happy that a lot of people showed up I was a little bit scared because it's the after lunch session and there are some quite also said some nice talks at the moment so pretty happy that all of you are here so my name is Franco I'm from too and at too we like to talk a lot about MPC and collaborative snacks of course also and that's what we that what we going to do about the next hour so to participate in the workshop I prepared a GitHub repository um scan the co a code if you want to participate with your laptop um I'll keep it there for one minute or so

um in the meantime I'll tell you and maybe also if you if you want to check it out um there's like the a read me with instru installation instructions that you need to do um I also prepared the docker image so you can also just run it with do where everything is already set up because I also usually don't like if I have to install seven tools for a workshop and then remove them afterwards anyway so you can just uh build the docker image um if you do so I'll uh I suggest that you build it now because it will take a little bit so it should be done when we at the at the Hands-On um session so the this this hour will look like um I'll start with some basic theoretical background so

what are collaborative snacks why we need them and what is our tooling doing um afterwards if everyone is set up we'll uh get some into some more practical stuff and I'll show you how to build a collaborative snug based on circum and afterwards we'll build one on Noir um I see how much I think the presentation will take about approximately 20 minutes and afterwards again 20 minutes so we see how F how fast we can uh push the hour but um yeah maybe we have some 10 minutes or so at the end of it um to to chat a little bit or if you have any more questions so um is everyone everyone seen it okay I think the K code will show up later once more so uh it's not it's not off the

word but yeah I I suggest to build the docker now so in the mean time um I've dropped the word collaborative snugs or Co snugs now um once or twice so maybe some of you need to get some um introductions what this actually means and for that I'll borrow a really basic example that's used usually in the MPC setting so I don't know if you're familiar that's a yeah as I said a really old problem to um explain how what MPC can do it's called the millionaires problem um imagine you have two people Ellis and Bob and Ellis and Bob are in a crypto business I think since the 70s or so um and they got uh some money over over this time and they now want to know who of them is richer um so yeah what what

are the things they can do the first triv solution would be Ellis just tell tells Bob I have X amount of years and Bob tells her I have y amount of years so of course they can then check who has more money but um yeah as the Privacy as the crypto people that Ellis and Bob are and they're pretty um influ by privacy they don't want to do that of course so they don't want to dis disclose how much money they have so that's not really an option um another trival solution would be to ask their friend Chet how much uh uh to to help them um they would just ask tell her how much money Ellis has and how much money Bob has and at the end of it charlette can just tell them yeah Ellis is richer but also this is of

course not really a solution because they need to tell the Networth to somebody to some trusted party and they also don't want to do that so that's private information that they want to keep secret so what can we do incomes multiparty computation um I'll give you a small WRA up about MPC could be a little bit boring for some of you if you're already familiar but still I think it's we at the SEC Summit not the NBC Summit so I think I I should do that um so it was MPC is based on a technology or idea it's called secret sharing um it was introduced from shamia in his famous paper how to share secret in the 70s I think and um the problem that it wants to solve is imagine you

have a secret X and you want to share it to some parties uh how you do that with Shamir secret Chang is you take a polinomial um of degree D where you set F from zero to your secret okay so um from that polinomial that you then have you sample n points and send them to n parties to n different parties um from high school math we know that if you want to reproduce a polinomial um of degree D you need D+ one points which is usually called a threshold T then so to in order to reconstruct the polinomial um you need to get T points so D plus1 points then you can reconstruct the polinomial set it to zero and get your X

back this threshold T um is also in MPC protocols usually the number of parties that are allowed to collude so that's also higher the degree is the more secure it is so the more people need to collude um really basic idea um the other thing that's another secret sharing um idea protocol that's usually used is called aditive secret sharing um we can even go back to grad school Maia um you have your secret X and split it in N Parts um such that the sum of those shares is again your secret so um you have to split as you can you send end the shares to end parties and we can also trivially see that if you want to

reconstruct the the secret you have to gather all your points again so uh for sh secret sharing you can split it up to t uh to you can you only need T points out of n and for additive secret sharing you need our parts again so now that we know how we can share a secret can we also compute on Secrets um the answer is yes and for the remaining talk I usually talk about um additive secret sharing because I think it's a little bit easier to grasp it's just basic Edition and I'm also using free parties because it's a very common use case a very common setup that you have free parties so that's for the for the rest of the slides so if we want to add add to Secrets X and Y um we split

them up in three in uh in three parts and send them to two different parties so if we want to add uh X and Y we can trivially add so each party just adds their um shares so if we party one adds X1 and y1 Party 2 X2 and Y2 and so on and from there we can also trivially see from basic red school math that then if you reconstruct those Ed added shares you get the share of x x y so um that's super cool so this means for additions we actually don't need to perform any more work as you would do on a single machine it's like if when you if you if you want to add X and Y you just add them and that's the same for the uh MPC of the Computing parties they

just need to perform a s a simple addition and they get a secret shed value of X and Y so that's super cool um now about multiplications we can see here that we can't simply multiply X1 * y1 because then with don't get the secret jet value of x * y it doesn't work so we need to think about something uh different so um usually how to do it there are multiple approaches I give to you two of them the one uh that's common very commonly used this C is based on beava Trippers where you generate some helper Trippers usually in some offline phase uh where the do have three values where from which you know that um a * b

equals to C and um a B and C are secret shared for all parties um as some small notation also if you see a value in the brackets it means this value is secret shared um what you're doing now is engage in some protocol it's a really simple thing if you want to write it down on paper you see that after you did those two steps I won't get into detail about the formula uh that's not so important uh you see that you get a secret value the secret jet value of x * y uh the important part is you have to open some points of the um of as some values when we talk about open this means we send the shares around that all parties can reconstruct the point so there is some communication involved the other thing that we also have use uh are

replicated secret Jank protocols um for the free party setting this is then called a two out of three sharing where you uh So based on EDI eddi of secret sharing again and this means if um at the beginning of the protocol every party gets uh the three parties each gets their share and then send their share to the next party so party two has the share of party one and party two and so on um this doesn't break security uh doesn't break anything doesn't break privacy because of course we know that we have to get all nend shares to reconstruct the secret and then they engage in this um as they compute this small formula down there and afterwards as they need to send the as as everyone has to have two shares we have to shend

send our share that we just computed with this formula to the um to the next party so what is the takeaway you don't need to memorize all this uh formula I just wanted to show that for nonlinear operations there is some form of networking involved so if you have a linear operation think addition part is compute locally under shares there's no additional overhead involved it's just like for a single uh single party just a single machine and for nonlinear operations parties needs to communicate so there is some networking award that are the key takeaways you don't have to remember all the other stuff actually so okay now we know we can do additions and multiplications and to borrow some lingo from uh CK you can build with then you can build arithmetic circuits with

additions and multiplications and as soon as you can build something as an arithmetic circuit you can also do an MPC uh about it as can engage an NBC protocol that evaluates that circuit um and we know from CK we can actually do quite a lot with arithmetic circuits so back to our problem um now Ellis and Bob they know about MPC of course um and they engaged now in an NPC protocol where they share their values X and Y to some MPC Network sub machines um they can be part of the computation but they don't have to be necessarily depends on the use case but they can also compute but they don't have to send that to the NPC protocol to the NPC machines and the uh Computing nodes then tell us okay Lis

is richer so everything is fine nobody learned anything and we're good to go um to sum things up Ellis and Bob are two distrusting parties they have a private information which is their netw worth and they won't tell they don't want to tell this to anyone so they engage in NBC protocol to see his richer everything Miss right but if you think about it what is the problem here so imagine there is another person again Chalet and she also wants to know who is richer so now the NPC protocol tells her okay Alis is richer and she asked is this really true and she can't really know that so um I'm leaving a little bit stuff out here it's like really condensed but only usually parties in involved know what they computed and

whether they behaved honestly so if Chalet also wants to know if Ellis is richer she has to trust Ellis and Bob or the Computing Network so she can't just verify that um so yeah what now can we do we can think about uh Ser knowledge proofs as we at the CK Summit um what can we do with CK uh CK snacks CK SN marks um usually are used to uh prove to um Ellis to Chalet sorry that um some competition was done correctly but um I won't get into details about s SS as we are in a s Summit I think everyone of you is very familiar with how they work um but yeah if you want to think about the problem um it's does not work to

solve it with see because we are back at square one again right because you have to compute the CK proof again so you have to have the access to X and Y as to the net worth of Ellis and Bob so yeah who computes the proof you can Outsource it but then again the person Computing the proof knows the values they yeah so there's we back at square one um but I wanted to know uh keep in mind if you were talk about c s they can do succinct uh a suin proof for computational integrity so it can verify some computation um that that was done in a very easy succinct way and potentially keep um secret input hidden I say potentially because um everyone is

talking about ckps but for scalability we actually don't need a CK part so um we want potentially want to to have some Secrets hidden but for our case we we wanted also so now we have this two cool Technologies zero knowledge that can prove uh some computation and MBC where you can engage in a protocol where you don't disclose your priv information so what happens if we combine them we get collaborative snugs so um I've been told this should be an interactive uh Workshop so I talked a lot now has anyone any questions so far okay perfect um so what are collaborative scks now um if we combine the two technologies it now allows

multiple distrusting par parties to jointly comput the proof so basically we verify that an MPC computation was done correctly and how we do that is execute the CK approv in an MPC circuit if you remember we can if we can do an arithmetic circuit out of it we can also do an NPC program um so this does this also includes of course um zero knowledge proof systems like R 16 or whatever so how does this transform the problem now we have um again a millon problem Ellis and Bob secret share their values send it to the Computing Network and now the Computing Network says Ellis is richer and here's a proof that Ellis is richer so Chalet just takes the proof verifies it locally in her machine and

knows okay wow Lis is in fact richer um so as we doing CK inside MPC you may think about some performance penalties because doing some so doing a CK proof about the statement is already quite complex and also if we transform a problem with MPC it's um also it usually rises in complexity so um the cool thing about this is that most uh uh CK proof systems heavily rely on fast Transformations and multiscalar multiplications it's the bunch of the work it's a whole lot of the work that is usually done and those operations are highly linear and if you remember from the introduction linear operation doesn't uh impose additional overhead if we do MPC so the ffts and

msms you're doing for in a collaborative snacks are take actually take the the same time as you would do in a singular machine you can just use just um compute your fft and the msms on your local shares and at the end of it you get the secret Jed value of the ffts and msms so that's super cool you don't have to do anything additional there's just you do the same thing as a sing approver um what's also cool is then if sometimes CK Hardware comes around soon TM then you can use those technology you can use the hardware to uh run ffts and MSM also there so we actually in collaborative snacks we also profit from the hardware acceleration um what about nonlinear operations um remember for um

multiplications and stuff like that we need to communicate so what's not so nice are large multiplications and a lot of um proof systems there is sometimes we have to perform this really large Vector multiplications sometimes uh to to to the to the main size which sometimes get two to the^ of X which is yeah quite yeah there's some limitations here we need to send those around you can do some tricks but at the end of the day there is some uh uh overhead involved there and also they have hash based um St as a hash based polinomial commitment schemes are not so nice so the Stars usually people call them like all these fry based stuff because um it's B based on hashers and hashers are

inherently non India that's their whole point so um it's actually not so nice for collaborative snacks for collaborative Stacks so to build an efficient collaborative Stacks I'd say still an open topic there are some tricks you can do also here but it usually comes with the cost of the verifier performance and so yeah it's it's another rabitor but um everything that's based on elliptic curve as like kcg commitment schemes that's super nice um I'm getting ahead of myself a little bit here but I didn't talk about our tooling so far but there's just some um benchmarks that we did from our tooling so that there I don't know if you're familiar with circum but there's like these two provs from circum s and rabbit

snar and if you see the the blue line that's the um performance of our tooling so you can see that our tooling is actually faster than the snack S1 even though we are doing MPC so there are multiple reasons for that first one we using rust and they're using JavaScript and rust is blazingly fast so we just um are a little bit faster than them the other one is rabbit snug which is based on C++ um yeah that's you see it's just rabbit snug is still a lot faster than than all tooling but yeah we see how how fast we can actually get how close we can get to Rabbit snug because this um this this was the first iteration of all tooling um we rewrote everything over the last couple of weeks so actually

there are no new performance numbers so far but I think we'll we'll close the gap a little bit but yeah we will see but at the moment also yeah sorry are you are you multi party where there single proofs as well or are you like three Xing or something the the singles yeah as so the question was if we are using if they're using single parties and multiple parties yes we are doing this is based on a replicated secret sharing model on free um free notes with networking involved and they are using a single appr in in JavaScript yeah um I suppose that in Co you said you you reot everything in R so you also rot the gross 16 uh snar it would be maybe interesting to see in the in this

graph what would take just your CK snar Pro how much it would take because then you could see what is the the cab overhead for example because maybe maybe your is also slower than rapid snar you know so I mean then you would get a clean overview of like what is the overhead um I won't com won't repeat that question because it was rather long sorry but um what what we yeah it's just different benchmarks we can there's also uh we tried to do some benchmarks on a single Pro that we see how much our implementation takes actually and uh some because it's really hard to bench Mark MPC usually because

you're on distributed machines so you have just only the timing so that's not as easy you can't just take chunks out of it and then I mean I could say yeah our fft implementation is way faster than than the the one from snjs I could say that but it's still relevant how much the the whole steps with the communication involved is is how much this takes and that's usually quite hard to do it's NPC because yeah as you're in a distributed setting but yeah I mean yeah we will we will think as there will be new performance numbers rather shortly and yeah I mean there's this we based on the gro 16 Pro an aqu works I don't know if you're familiar with that so we based on that one so there are benchmarks for there on the single

machine but usually the overhead involved is for GR 16 it's actually quite nice there's just one round of communication so it's not that hard okay um so what are the use cases um we usually think about two big use cases the first one we talked about already it's we call it compute on private shared State um we want to um like the example from Ellis and pop they if you remember if you know privacy blockchains like Alo and ettech they want to Pro they want to um allow people to compute on private state in contrast to ethereum where everything is public but what you can do is compute on multiple private States you can compute you can write D

apps that are running on that are based on your PR private state but they can't write an application that is based on multiple private States so that's the first use case um we have all benefits of sixing proofs um because from the point from the view of the verifier the verifier doesn't realize that there is a coll that is a collaborative snug or as as ordinary CK KN because the proof at the end of the end of it is just the same so the verifier doesn't know so we get all benefits of the SE proofs and the other one is a private proof delegation um where imagine you have a limited piece of Hardware like um your mobile phone and you want to computer proof um yeah that's usually for if it's proof gets rather large it's really hard

so um you can use MPC or like to the collaborative snugs to build uh uh you secret share your witness send it to the to an impr Network to a network that computes the proof for you and send it back to you so you don't have to uh uh you lose no privacy because you secret your private input and um just compute the the the proof outside of your of your machine so that are the two use cases that we are looking into at the moment and um so that's it for the theoretical thing here's again the qu code I think nobody joined so far so I think we are good to go um so I talked a lot about of the

theoretical stuff now so what we we building so T over the last couple of months we buil we start started with building collaborative snars based on circum um it was circum is a very well suited language for that because it's really small and also the snack CHS um is as snack CHS is not that Fe rich I mean it has crop 16 plon and flun but um yeah it was a a really good starting point but now we also uh started now that we are pretty done with circum we went on with Koo so it's still called circum but this will change in in the future so what is circum circum as I already said is a you can build collaborative

snugs based on circum circuits and Noir we have support for GR 16 and plong for circum and we are using the honk prover for for ette e no and the really cool thing is with this with this approach um as I said the verifier cannot distinguish between a coll a collaborative snug and a secret snag so we can utilize the whole tool chain that is already written for circum and Noir which means we also get an evm verifier for free so to say that's nothing that we have to do have to work with so it just works it's just a if you if you verify snjs if you verify your proof with snjs it works if you verify the proof with our that works so there's no difference so that's really cool and um it's also already usable we uh showed

this at UTC I think we had this demonstration uh project we called it a Max Pi challenge where we wanted to show that we can actually build tools now with collaborative circum with Co circum the idea was we make a a game where everyone that wants to participate has to guess a number between 1 and 1,000 and the highest unique guess wins so this means if I um bet 999 and some other people also said 999 it cancels each other out and the gas is disabled so of course we can do that with uh usual blockchains because if you write it on chain everything is you see every result so you could just cheat see what's the highest value or someone could just snipe your reside so that

that obviously doesn't work so we built this with collaborative circum where we then have the the uh guesses are where keep kept private and then you um compute at the end of it compute a big uh circuit and then you roll it on chain and it's fully deployed on optimism we used the snar JS verifier and everything worked quite well that was really cool um once more I think we we don't need that but I wanted to make sure that everyone can can scan it um so again any questions so far did the did yeah a very detail n question about the problem you just mentioned uh can you copy inputs are you protecting against Alice and Bob

and and other people from voting the same way guessing from in in the max PE challenge cancel somebody else out by guessing they're going to get 911 and then use uh use an identity and then throw a 999 and then push the result down and the question was if we if we protected for some replay attacks I think uh in this in this uh scenario um there's like we in this specific setting we also broke a little bit with the idea of MPC because every note was hosted at all place so it was like a for demonstration but there was actually quite involved how to protect the guesses you have to commit to the guest in the beginning so then write the commit on train with some secret Randomness that you um chose on your

machine so you if you chose 99991 you also computed some random values in your browser computed the posidon hash send that on chain and then um we only store the the posidon n and then yeah so you you are pretty nobody learned anything about what you were guessing so you can't because there is the randomness involved you can't just guess from the commitments what was guessing there already and I can't commit to somebody else's yeah you can't because there's you you have no idea yeah MH so um we go now pretty shortly to the um to the technical thing um just I think that's also good to know what the

workflow looks like when you build a collaborative snugs it's easy to see it in in the beginning so um this necessary steps to build a collaborative snugs imagine we have Ellis and Bob again the first thing they need to do is secret share their uh values so again they're split it up in three parties for with additive additive shares so secret share your input then you send the your shares and the circum value or the circum circuit or whatever that you want to compute you send to some Computing Network again as a party A and B could be part of it but they don't necessarily have to so you send your shares to the network so if we zoom in in network now it looks like that party zero has access to a z and b 0 and so on and so forth

what they're doing now we usually call the extended witness Generation Um this means you actually have to evaluate the circum circuit so that's the step where you when you when you look at your circum file you actually have to run through it you have to computed that you get your extended witness so they do that in a um in an NPC protocol and that's actually the step that for MPC takes the longest so the Prova is way way way faster than that and Computing the extended witness in MPC you can do that with Co circum but the um per the the imposed overhead here is really large because it's just basically a general purpose mpcm because you just write any program so you have to engage in yeah so that's that's the step that's

at the moment is the bottleneck by far but yeah you have to to engage an MPC protocol execute the circum file circum yeah circuit and you get a secret shed witness then um yeah it's like that and at the end of it um they engage again in an MPC protocol and then you get your collaborative snug so that are the steps necessary to to build anity snack okay we going now to some examples I think I on for that hope that works so I don't know is has anyone problems with the docker installation or is is everyone good to go because I had once a problem I it didn't it didn't reappear so I was scared that it will

happen now but I think okay Aron good okay you you can see my screen right so I'll also check out the the project so the idea what what I will do now is um there's this read me also I don't know if you have read through it a little bit but um I'll show you how to build uh your collaborative uh snack now first with a circum example and then with the no one oh wow um yeah okay the first thing we're doing is we go to the circum folder and check out what um problem we want to

solve actually I'll show you the circuit um it's here um so if you're in the docker now um there's no Vim or Nano installed if you want to check out the uh the the um the circum file I've installed B so you can just write B millionaires problem. circum it's a really cool tool I recommend it um but yeah if you yeah but it's so can inspect it um we can see it also on the screen it's again this Millionaire's problem also this is not a circum introduction so um if you're not familiar with circum you have to believe me that this is doing what I say it does because I don't want to get into details too much because it's yeah as I said not there are a lot of cool circum and no um

examples out there introductions that are way better than whatever I could come up with in this next 20 minutes um also if you have any question if something doesn't work just raise your hand maybe we can we can figure it out but what we doing okay we're doing we have two inputs Alis and pop that are um public that are private inputs for the for the problem and one output which is the result and we want that if uh they have the same money we get a zero result if they have the same if Alis is richer we get one and if Bob is richer we get two we do that by first including some utility functionality from the circum Library standard Library inofficial I guess but yeah some uh cool utility functions there first is to check if the

values are equal so we get um in this value we get one if the values are equal and we inverse the result as remember we want the result to be zero if they have the same money afterwards we check whether Ellis has less money than pop and increment the result by one so if Ellis has less money then um this value is um zero okay I'm getting confused now and then we increase it so uh we get one for Ellis and two for Bob and then we multiply the the pro the two things this is zero if um the the equal amount of money so it just avalid to zero and one if um if the same amount and then we get the um the

value from the less than operation so nothing really complex going on here um so read me ah it was in the wrong wrong folder okay um okay um we go again in this um in this in this folder with the millionair problem and the first thing we need to do is compile the comp the circum file we do that by it's in the

readme um there's uh in the readme there is you can copy this command I also prepared a just file I don't know if it's a command Runner that's also already installed in the in the docker um because later the um commands are actually quite convoluted because we have to engage an MPC protocol so there is usually fre processes involved and it's rather it's not so nice to start them in a Docker so I just prepare just file um that you that you can run the commands if you if you want to check them out so the first thing is we compile the circum you get some uh information that's we use the circum compiler for that so that's not a tool from us it's from from Iden 3 and it's

just a basic circum compiler and we get this R1 CS file so compile the circuit the next thing we doing is um we secret share our inputs in circum what you're usually doing if we have two inputs like Ellis and poob you give you provide the Json file with um the inputs for Alis and pop but we can't do that of course because we on two different machines we have Alis put secret shares her input and Bob secret shares his input we do that this time with the co circum um binary the circum binary if you want to check if it's installed you can just write it and there are the commands that uh that is that are

provided so what we are doing is we split our input so in in a real setting as I said this is done on two different machines first on Alys machine and once on B machine for the demo of course this is on the single machine but usually this is done on two different machines so Ellis wants to split her input for that she must Define for which circuit so it's the mil problem circum file the input you want to secret share is lellis Json the protocol is a replicated free secret sharing protocol Proto okay replicated free and the all directory um I've prepared some already

it's secret Shar inputs and we are working on BN 254 so we do that and then uh the the input is secret CH in a correct way maybe also if you want to check in the the inputs it's just a basic CH Json file where just Ellis and some some value and the same goes for the same goes for Bob just some random values I put in there so we do the same for Bob I just use the um just command for that so that's a little bit easier um so now in the Out secret inputs you should have six files here it's input from the secret

Shar input of Ellis and the secret Shar input of Bob it's like the zero indicates that's the secret Shar for party zero remember it's the all the Ellis stuff is on Ellis machine and all the Bob stuff Bob machine so any has anyone any problems can we go on yeah we don't need to don't okay can you do can you try the with the just file okay has anyone asked this okay perfect all good good um okay yeah

we have this six output fires uh and then we can go on in a real setting Ellis would send the shares to the respective parties and Bob would do the same um what we have to do now is maybe a little bit counterintuitive in the F if you think about it in the first point but as we are using the circum tool chain we using the circum compiler also so they need to um to get their input in a specific way such that usually you have Ellis and Bob in the same Json file but now they get it from different sources so we have to merge this input together but this merge is not the Reconstruction of the so there's no opening word it's just party zero takes

the input from Ellis and the input from B and merges it in a single file so there is no necessary ining it's just like copying the files together so there's one single input um we do this with the merge input shares command um the inputs are then um the secret J input and for l z CH that's a little bit so secret shared and then the input from Bob we again use this replicated free secret sharing

and inputs and the same curve I hope I didn't do it typo we see yeah sounds good so as again that's uh done on uh three different machines now on the three MPC machines and um yeah that's just something you need to do it's it's not um any complex stuff it just merges the two files using that just command again that I don't have to type everything so now we have um input we have three merged inputs one for each party now we have to actually engage in

an MPC protocol as we have to compute the extended witness so we have set up uh every party knows the circuit that we want to evaluate and it has there secret shared value so that was for that there is um now um if you want to compute that you need free processes for that as if you started there will be um uh the network the one the one process that you're starting will open a TLS connection a server and want Waits that someone connects there so if you want to actually run this program you either have to copy all of those commands and concatenate them with an end sign or you use the just command where it's already done so I hope this is clear because this is actually where people where the

process are sending stuff around so they communicate with other we wech other by Tails connection um so maybe have that yeah maybe I just show you because there is also a configuration involved a TS configuration um maybe just very briefly um you have to uh provide some form of network configuration here um where said which on which address you're waiting for a connection and also what are the um certificates of the other parties and what is your private key and stuff like that so um as said the communication is all uh secured with with TLS so you have to provide some form of um um yeah TLS configuration so we'll do also that just

okay what I don't remember actually what it's called just run witness generation and as you see this takes once as 700 milliseconds approximately which is rather longish for this program but yeah that's the that's the bottleneck that we are actually facing at the moment so this witness Generation Um did it work for everyone anyone has any problems yeah yeah problem with the all Shar inut about not and they deny to mer it they deny to merge it you also use the trust commands and and okay I need to check that out I don't actually know what but if you you went through the CH commands from top to bottom yeah like I

you yeah maybe we can check it out afterwards so um now we have this generated witness in out um witness so again some witness for each party and the last step of course is the actual proving um again this is an NPC protocol you can reuse the configuration you had earlier it's basically the same it just tells every every note where it should wait for communication income and where they should connect to um I also I think I need to hurry up a bit so I also run the chust command um we using gra 16 proof I think I didn't say that earlier um so we run it and we see that was it

was pretty fast we can also inspect the proof um there is the proof uh from party zero they're all the same it's just was cross wrong um we see it's just some basic Json file it does it's not very formed really really nice but it's just the Bas the same Json file you would get if you have done it in a on a local machine um what you also can see is the public output of the um of the of the proof in our case it was two which we can check uh C input lis so that seems right Bob is richer in this scenario so the output of the proof

was two so the result of the whole circuit evaluation was two we get a proof of that just a naming thing that the file is called public input yeah because usually there is no touch thing as an output actually in a in a in a c in a CK setting because if you want to verify it you have to provide the output as public input to the verifier so it's usually it's another input yeah it's it's another input so it's like if you say output it makes sense to about it if you execute the program but on the in the point of a verifier it's just another input that you need to provide so that's yeah if you would have public input it would also be written there okay follow as sorry the question was if the it's just a naming convention that's if it's an uh that we call this input

Jason um okay last step is to verify the the proof we can do that either with Co circum can again write it uh Co circum verify we want to prove the proof zero CH with this verification key that is already prepared um in the in the docker hopefully and the public input is out proves public input zero Chason we want to prove a gr 16 proof and we verify gr 16 roof and then the curve again okay it uh said it prove verified successfully

and we can do the same with snag chess snack CH also says this Pro is okay as you can see from the point of the verifier there is no there's no distinguish between a collaborative snack and the the one from for if you building on a single machine any questions I worked okay so uh so as I said the circum tooling the form it's pretty done so there is of course as a feature it's feature complete from our point of view we could also add this flun Prov and verifier but I think that's as it's not on the road map so

far what we are working on at the moment is uh especially improve the gr 16 performance so that we can actually catch up to Rapid snug and also we investigating how we can speed up the witness extension because as I said that's the big bottleneck and at least for this private St shared State use case we need a witness extension for the proof delegation we don't need it actually because you can do the proof the witness extension locally in the machine they are usually not that comput computationally intensive so that's not a big problem there but still this witness extension that's takes too long at the moment and we are uh investigating how we can improve the performance here um okay uh the other thing I wanted to show you is the same

with Noir so I don't know if any as if people are familiar with now but uh same as far as earlier I I don't want to give you a a talk about how Noir Works um so we approving this very very small pocket example at the moment we can do with Noah um basic field arithmetic so everything that would involve additions and multiplications from fields from the Native Field Works what doesn't work are integer operations and uh stuff like that so we are um currently trying to Al we started on Kono I think two months ago so it's still very very early but you can also we just we wanted to show that it's already usable in a small

sense so you can do posidon hashes and stuff like that if you want to use integer arithmetic there's uh that's still in development but I hope we'll finish that in I mean should be done in one or two months or so but don't uh don't don't tell my my colleagues that I said that so maybe we'll see how long this will actually take but still I wanted to show that you can also do something with some things with Noah already so we go to the posidon folder um there are some files already prepared the the workflow is pretty much the same as it was for circum and we speedrun this now because everyone of you knows that already the small differences I will I will highlight of course but the the workflow is the same um first thing is we do is compile

the circuit so uh we just write Nago compile Nago is the um package manager I'd say for for Noir uh and we compile the the the circuit you should then have in the Target folder this posidon Chason just some uh artifact that they produced so we using similar earlier we use circum to compile the circuit now we use Nago um so you should have this posidon Chason file in your target folder so then with uh secret shed input again for Noir this time we are not we don't have um Json files but tommer

files so look at the Valu so we want to compute the posidon hash of X and Y so Ellis has her Ellis tommer and Bob has his Bob tommer where um their inputs are written then we sh write just split input um there's a warning there um that's from the compiler that we're using it's we're basing it on the uh from the compiler from from Noir and the compiler tells us that um the one input is missing so we we need the input X and Y and it sees that okay we only provided X so that's just just shows that it's really early in development that's no problem but it's just we using their compiler and the compiler thinks some

things are not there but as we're in an NPC setting of course you only have access to one of the files so we secret J input it should not matter um you should have the the secret jet input in this folder looks pretty similar as earlier now we merged the input so check it out could also be here similar step as earlier then we generate the witness same setup we have the same um networking configuration um engage in the witness extension that is used in the Noir setting as Noir is using uh honk approve

so they they have actually couple of provs the one that they want to use as the default Pro is the honk prover it's some variation of hyper plon but yeah we are doing the witness extension for that here um that's actually super fast because we're just doing posidon and posidon is um as we know is super fast in in CK settings um so we have the witness Witnesses here in secret chat form then we run the honk prover in an distributed setting there someb output and also here the proof uh finished successfully the computation finished success successfully and now there are some

additional steps we need to do um as we are using a plon variation we have a universal setup we have one setup for multiple circuits in contrast to to gross 16 earlier so we have to um extract the verification key from the common reference string that is uh provided by by by barenberg we do this with this command so there's a verification key um that is derived for this particular circuit but it's derived from the common reference string that we have from that we got from paren parb is the pro Sy stem of no so we extract we create the verification key for that circuit and now we can verify the

proof so also here the proof verified successfully you can also verify this proof with barettin the native proof system of Noir um I didn't want to add it here because installing bartin bag is a little bit bothersome so I just wanted I just throw it out you can do it also if some of you have baretan bag installed you can verify this proof also with Partin pack but um yeah basically um I think I pretty much end of my talk so if there's any question I think it's a five minutes left so maybe took a little bit longer than I expected so um if you have any questions any problems um please ask me we can also chat afterwards there's a break afterwards so I'm happy to to answer some more

questions if you have any and what also would be nice um that's our GitHub repository from ctive circum it really nice if you leave a start or GitHub repository and um yeah so I'm here to answer some more questions if there are any and otherwise thanks for for coming to to my workshop [Applause] yeah quick one on just try hacking in do you have plans for making this robust for the multi party protocol yeah I mean at the next step we want to do is um Al if we if we somewhat happy with our tooling the next step we want to do is

actually provide a proving Network where um people can participate and say okay we we give computation power to that to the to the network where then also get as a rewards of course if you if you want to compute it so there's that's a whole other field that will be done in the next that we need to investigate in the next couple of months so that's the the next step after our tooling for the moment the uh you can uh you can use the pro the project as as is you can just run your uh your own machines with with the with the tooling that should work it's already we've done that and um yeah afterwards we we need to investigate especially for the ction problem that you usually have in such distributed settings when you have an MPC Network

that just runs you need to think about what happens if someone with a lot of computational power a lot of machines tries to hijack the the network so there's um some research needed there how we can actually do that but yeah there that's the the the step for the day after tomorrow I'd say yeah any other questions or did anyone had problems with running through the through the thing I mean I can they're not yeah General uh uh case

analysis there's ZK and there's F and getting those like ZK be interesting so do you consider the uh the private proof delegation do something of a use case gra that verif yeah I think a verifiable f and this collaborative snar so it's also sometimes called publicly auditable MPC so it's a pretty similar use case actually um there's some distinguishing of course between between those two but um I think that's my personal opinion but I think if there will be so FH if you want to do verifiable FH at the moment you have like you rise in complexity so fast that it's not really usable in any form or means at the

moment um that you don't have this problem with collaborative snacks at the moment there so you can do gr 16 proofs and also PL proofs like this EC based stuff you can do now in a reasonable amount of time but if you want to use verifiable fhe it's like that's more of a thing for in the next couple of years I think so if you want to use it today I think you're bound to use it like that um sometimes in the future may maybe F will be fast enough everyone is talking about the the um Hardware acceleration of FH but we'll see how long this will actually take and when this will arrive but um if you want to use it at the moment you can you have you're forced to use it like that I think at least um

also on the hardware acceleration as I said uh CK proof system I think we get CK Hardware a little bit earlier than fhe Hardware I think because at least from from from what I've talked to people I don't that's not the just my what I've heard and we actually um benefit from CK Hardware also in the collaborative snar setting one thing I have to say about that um for MPC you're bound you have a upper limit of how fast you can get and that's the speed of light because at one point you have to communicate so you can't get you can't just throw Hardware on the problem because there is this limitation there will be networking involved which is not the same for fhe so theoretically if there will be fast enough F Hardware you will at some point in in the far future

maybe you are faster than the NPC setting but I think this will take a lot of time if it happens actually so yeah um so this this like this this can be used both for collaborating on a like as a Marketplace for snarks right you can use provid power I'm thinking of the more specifically and also it's useful for building applications like maybe like a dark po kind of application that requires right like this is useful for both yeah the question was in which use cases we actually thinking I forgot to uh to to restate the the questions earlier so sorry about that so the question was uh whether for the use cases but yeah actually the use cases

are exactly what you provided so um the the private dark poo setting is something Renegade is doing I think they're doing it with collaborative snar so that's one big use case and the other one is to proof delegation when you want W privacy witness so if you don't need privacy for your witness you don't have to engage in that problem you can just use any proof Market all there but if you want to keep your private witness hidden you you need to engage in this protocol yeah I think we are pretty much out of time one last question is okay okay if anyone has one question then doesn't seem like it yeah then thanks again um and yeah every want to chat I'm I will be here I'll be around

so thanks [Applause]