ZKBoo - Implementing and benchmarking MPC in the head - Andrija Novakovic & Ying Tong

Transcript

hi everyone uh here for the L session we have Andrea novakovich and Y Tong from geometry who are going to present uh the paper Z and some of the work on on it uh uh yeah perfect sharing and I'm unmuting so thanks Rafael hi everyone um yeah today we'll be walking through um this Paradigm called NPC in the head um as

well as an implementation of it that we did uh for one of the protocols zaboo and yeah feel free to ask questions at any time so yeah this is the agenda for today the first part of the talk will be high level and introducing NPC in the hit to most of us who might be more familiar with snarks so NPC in the head um is a way to get a zero knowledge proof from an MPC protocol but it is not a snark because um it does not produce SU synct

Pro um but it has lots of other desirable qualities um as we'll see later on um n uh the the most desirable quality is a linear Time pro um and then yeah Andrea will walk us through the implementation of zik zaboo that we did at geometry research um and that includes uh um a benchmark of sha 256 and we'll see where that stands compared to the snarks and Starks that we're familiar with so firstly NPC in the head is was

introduced in 2007 um and it's a way to construct a Zer knowledge proof using an NPC protocol so really it makes use of the privacy and correctness property of the NPC protocol to derive the zero knowledge and soundness properties that we need in a ZK proof so how it does this is it Associates a relation so this is the NP relation that goes into our that that the ZK snar prover is trying to prove that they can satisfy so relation with some instance and

witness um so MPC and the head Associates this relation r with some function f um that is jointly computed in an NPC protocol so over here um the approver actually emulates um multiple parties in an MPC protocol um by secret sharing the witness to each of them and Performing the MPC protocol in her head and then afterwards the prover um commits to the view of each party and then um opens some random subset of the views

um and we can begin to see already how we derive zero knowledge and soundness from this so the zero knowledge property comes from the fact that we only open a subset of the views and we want to set up our protocol such that um below this subset size um the verifier is unable to reconstruct the whole witness so from there we get zero knowledges and um the other fact that we will make use of is um if the MPC

protocols views are inconsistent so if the if the NPC protocols results are not correct that means one of its views at least one of its views is inconsistent so in other words the malicious Prov Must Have Cheated for at least one of the parties and because each time we open um a random subset of views if we repeat um this um simulated NPC enough times um with high probability the verifier will pick um an incorrect view so are there any questions so far uh I don't see any questions

now thank you so now this sort of might seem intuitive like why would we emulate multiple parties talking in our own head um sounds actually inefficient um but the fact is um many NPC Protocols are very simple um and can run in linear time um of the circuit so yeah basically you're just running the program itself and you don't need to do expensive operations such as just ffts or msms that are the bottleneck for snark provs and so it's easy to achieve a linear

time PR using MPC in the head and this very recent um paper um used M used the MPC and the hit protocol called kkw um in order to uh sorry I should have highlighted some of this so in order to prove some kind of exploit um in the program so uh in a processor so their priority was to reduce the concrete PR time um and this allows them to prove statements about larger

programs um and exploits and so over here um they are the TR trade off here as always is pro speed versus proof size and they um came down heavily in favor of prover speed because they want to be able to um prove statements about large programs and complicated complex exploits um and then later on they deal with the larger proof size by streaming the proof to the verifier another attractive um property is that

most of these protocols only use standard symmetric cryptographic assumptions um and these are most of the time Quantum resistant and it also means that many of these protocols can work over any field you don't need to be in a cryptographic group and and yeah you can you can work in um binary field for your bullan functions you can work in a finite field for arithmetic functions um yeah you can pick any field you like you don't need to incur and overhead

um and something to point out as well is that NPC in the headit does not incur um the inefficiencies from actual NPC protocols so uh namely the parties don't do not need to um communicate using oblivious transfer like they don't need to keep secrets from each other um and yeah we don't need to work in the malicious PR setting we can work in the semi honest setting and in fact later works um have identified um even simpler NPC protoc OLS that uh are good enough for NPC in

the head and so for example there's a protocol called Limbo um their NPC model involves a single sender who knows the whole witness ahead of time and this is exactly um what's happening in NPC in the head so with these sort of adaptations you you can get a lot of um you can get a very eff NPC protocol um and still get the benefit from the Simplicity um of the of the NPC protocol um also this is a nice modular structure because you can think

of the zero knowledge proof as kind of a wrapper protocol outside of whatever NPC protocol you chose and yeah the zero knowledge proof when you're reasoning about a security you need only um make blackbox use of the MPC protocol and its underlying cryptographic Primitives such as hash functions or uh commitment schemes and lastly um MPC the head is public coin so using the Fiat shamier transform you can make it non-interactive are there any questions yeah a few questions um so uh the first question is you said it

cannot you said uh the adversary cannot reconstruct the whole witness but security wise it it should be that the adversary cannot learn anything about the witness isn't it yes yes that's what I meant to say by when I say cannot reconstruct witness I meant to say it cannot learn anything about the witness yeah a second question is about how MPC and how do you turn the MPC into zp uh I think it's more question about how you split your witness uh so I will read the question directly hi I couldn't catch intuition of how multiple NPC resulted in zero knowledge proof are there multiple

witness or just one proof and what witness doing NPC multiple times yeah so if you explain this a bit more would be fun very good question so there is still one witness but now it's secret shared um to multiple emulated parties so for example you could use additive secret sharing you could use shamier secret sharing you could use linear secret sharing which are commonly used in real NPC protocols um and then but the point is um so on each of these secret shared Witnesses you perform the this the

computation of the function f and you output some transcript of the computation um but the trick here is that you only output a commitment to each party's transcript or each party's View and then you could think of um this set of views as uh zero knowledge PCP where each element of the PCP is some party's View and now the verifier has Oracle access to this PCP um and can query it at um random subset so yeah basically the committed

views and um their openings are your zero knowledge proof so I think this will become even clearer when we get into a concrete example um for us that's going to be Zabo um and it's going to be at Point number six but yes thank you for the questions are there any more questions so there's no more questions uh but I had one uh so you say that you

could use stand cryptography uh potentially hash functions uh but I do not really see how you would use hash functions for the secret sharing so it might be in another uh parts of the protocol yeah uh for example you could use hash functions to commit to your view yeah yeah yeah I see and so secret sharing uh yeah you you talked about a few such as uh sham sham I guess for Quantum resistance you would have to use uh ltis space secret sharing uh or additive secret sharing as well

yeah thank you thank you um so yeah these are the interesting properties of MPC in the head and um that makes it suitable for a range of applications so as we discussed it's postquantum and um there was actually a signature scheme picnic um that was built on top of zik zaboo um that made it to n round three alternative candidate um there was a recent paper that instantiated efficient set membership proofs using NPC in the head

and then the the same paper they showed how to construct postquantum ring CT this is the protocol used in Monero ring signature um and for Boolean circuits um for NPC protocols that work over Boolean circuits um they provide a very natural way um to represent bullan hash functions um yeah because we're working in the field F2 um and we don't incur the overhead of a large field as we do

in most snarks um and we saw earlier that um this proof of software exploitability paper made use of a MPC in the head protocol called kkw and they said here that specifically what they found it useful for Wasing between bullan and arithmetic representations I haven't looked into how they did this um but yeah this is a very useful um primitive um so

yeah some to to get you to speak to um about the current state of MPC the head um so yeah we can like like we saw just now um different schemes can use different um secret sharing schemes so yeah additive linear or any um yeah and they also have different um parameters MERS for privacy robustness and soundness and different kinds of communications and their protocols so perhaps worth mentioning

here so zaboo we will look at in detail later um Zabo was um published in 2016 so that was almost 10 years after the original EOS 07 paper that introduce this Paradigm so up until zaboo people thought that this was a purely theoretical construction um so what Zabo did was to actually show that it's practically efficient and how they did it was they realized that a lot of the um properties of

MPC a real MPC are just unnecessary in the NPC the heads setting like oblivious transfer don't need it um they also realized um an efficient um they call it decomposition so uh they called it a two three decomposition that allowed you to compute a gate um using just two parties um views and we'll see we'll see how they do this later on so um so the thing is with zaboo um is that it has a linear size

proof um and therefore linear verifier whereas liero um which came one year after um actually achieved this square root n size to proof where n is the size of your circuit uh so that's still not not quite as good as most snarks that we're used to but I believe legero is the smallest proof size um of all the NPC and the head protocols um the trade-off here is that the concrete PR time for liero is slower um

yeah and then limbo which was more recent um is an improvement um on Lio um and it introduces this well yeah it takes it it improves on Liar's sort of idea to um instead of having the verifier rerun um the whole computation it gets the verifier to Simply verify the correctness of some trace of the protocol um and also limbo introduces like a simpler NPC model whereby there exists a

single sender or client who already knows all the inputs so this allows them to save a lot in in terms of um communication are there any questions uh yeah so there was a question about the choice of the Primitive used for secret sharing and more particularly uh whether it's important uh since aover does all of the work locally uh so if you could use anything uh as you send to theier uh the commitments

you uh it doesn't really matter what you are doing since only the commitments needs to be postquantum resistance oh uh yeah I guess yeah go on I was just going to sum up uh uh is the Primitive use for secret sharing important when designing the protocol since the pro does only uses K yeah yeah so I think the choice of secret sharing is mostly informed by efficiency you you can see um some of

these protocols allow any secret sharing like inde they don't really care um but yeah I think some protocols make direct use of like linear secret sharing to for efficiency purposes thank you yeah um so this another comparison table from the same paper over here um and it shows you like some some more parameters so uh I guess yeah you can you can observe here that a bunch of these protocols they naturally work over any ring or any

field which is very nice um and some are specified specific to Boolean fields and and so on um and this diagram also um um Compares signature schemes in particular so yeah I think the by far the most common use case for NPC and the hit is signature schemes so they are showing you yeah the signature sizes produc by NPC in the hit um I don't I don't have that much more to say about this diagram but I

wanted to make a special mention of kkw here which was used in the proof of exploit um paper that we saw earlier so yeah kkw is the most efficient in terms of computation in terms of pro proving proving time um and yeah basically a lot of the work in kkw is mve to some pre-processing step um so basically in the pre-processing step um we can generate all the correlated Randomness that we'll need later on um

and we can do this independent of uh the actual inputs to the Circuit so why does this very nice is um this reduces the interaction um that is needed between the parties and which in turn means that you can have many parties like arbitrarily many parties and so instead of running the same protocol many times you can run one run it one time with many parties so we actually implemented zaboo

we'll see later um we benched shot 256 on it um this graph I just got from seller networks Pantheon I think is the latest version and you can see here that start is like in a league of its own 5.5 seconds the last time I that we look at the starky implementation it didn't have padding for shot 256 so that might add some overhead to the starky Prov um but still it's by far the fastest and then Bim which I think is

plish proof system that uses fry um had 11 seconds 10 11 is that 11 yeah something like that um I couldn't find the implementation though in sellers repository so and then when we benched ZK Buu um we got a 20 second period time for a 64 kilobyte pre-image um yeah so this was like we're still trying to make sense of this um in

theory we we had expected Zabo to be really competitive with starky um because it is a linear time PR it doesn't need to the ffts um but yeah this was what our Benchmark was when we implemented it are there questions yeah I I will just add to um that Yeah we actually lose a lot of time to construct the padding um which takes sometime and you need to prove that you correctly padded which is not too cheap and and I think we also

didn't um we didn't go for a huge parallelized provs and stuff like that um so we we can probably invest more time to do the so the biggest strength for Zabo PR is it's very parallelizable in the sense that you're running the same program many times and each time is independent uh and therefore you can run them in parallel um so yeah maybe we didn't fully parallelize um I think I I was asking in our Discord like does anyone have a

machine with 20 cores so yeah maybe that is good to note like what setup this is suitable for all of the other yeah this seller did everything on a MacBook Pro M1 um we have a question about the proving size how does it compare between the different systems so yeah so for Zabo is the largest um of all this it's not a snark everything else here is a snark or Stark yeah zika is linear proof size uh start with poog yeah uh about the implementations

on uh on the snars this time uh do you know if any lookups or any optimizations were made or it was a naive implementation of uh of shop I do believe that uh lookups were used for the systems that had lookups but yeah you can see very clearly like these slower ones these are either grth 16 or kzg like these are really tiny proofs up here yeah yeah whereas these three are huge proofs so that is my overview and now we

will go into we will zoom in on zika um so Andrea do you want to take cover uh yeah um yeah yeah uh I can take cover would you mind uh leaving the share the screen and then I can start sharing the code okay [Music] um wait uh can you then send me just the link uh I cannot yeah I was about to ask okay I have it I have it wait uh why we doing this transition there's another question so I am trying to figure out

the motivation for using MPC style zkp I think they exist faster in term of proving time Ro based interactive zkp protocol to prove Budan secet such as Sha yeah I I am not familiar with v i yeah but I did see a very compelling benchmarks for sha for AES as well like yeah actually I would be very happy to learn like how V differs from NPC in the head can we unmute people participants uh

yeah if you tell me whom I can unmute uh unless you everyone no yeah uh everyone can unmute themselves now okay we go cool Shang you can talk if you want to hello yeah we can hear you oh can hear me oh yeah yeah thank you for uh let me speaking uh so yeah actually um I'm currently working on this or we call V based i k which means using this vector vector overv linear function evaluation things to you

know to to to construct the Zer knowledge proofs but uh yeah they're more I think they're more efficient to prove uh building circuits or ar C but it's not SN it's not a SN it's not and the proof size is proof size is also linear but concretely is much more efficient improving time and uh we have a few papers on doing that and actually we are contributing to a PSC about how to implement everything so uh so actually so the the the the main question of of of me is that I'm trying to figure out yeah the the basic the motivation of

using MPC in the head I think one of the U the the advantage is that is it's not interactive and can make it uh a sub linear improve time but if we're considering proving time I think we have another Choice maybe so I can share with you a few papers here okay that would be great yeah thank you should I start now also uh are we like bounded do we have like 1 hour uh how long does this

in general take because if we want to go to code I need to maybe optimize the uh my part a little bit um I don't know sorry I needed to unmute myself uh so the call was scheduled to be an hour but uh people can leave any time so don't feel too constrained about it do okay I guess a lot of people allocated one hour so so I'll go a little bit faster to show you the library and uh the generic concept and then if somebody wants to stay more dive into specific parts of the code I'm I'm up

for uh but yeah okay so um just to finish what we started so I'll uh try to explain how this uh like zkb ziku and later z++ works uh where Ying Tong stopped and to make this more concrete than um to now see more concretely how this stuff works so as we said one there is like one prover one verifier and we are doing this all in our head which means what we have one witness that we

split we'll see it's very easy to split but how the the generic protocol looks so you have uh some vitness X you uh do a split sharing of it now you can look into these vertical lines as a parties through the protocol so you will see uh that party let's say one communicates where part communicates with party two such as party two sends a message to party one then party three sends a message to party two and finally like imagine that

we are like wrapping around with modula where party one sends the messages to party three so what do we mean by when we send a message so uh now okay let me actually I can show you in the ziko paper orig just to show you where this is so this is kind of the same mental model that y Tong showed uh any circuit as I guess everybody knows here you can do it with like addition and multiplication Gates so the the model for ziku how you do NPC and we can write this down but I guess

uh we will do this faster now uh is that if you're doing addition gate so just a step back so every party has their own a share of the witness so now at this moment like from this line we're actually pretending that we're executing this uh real MPC protocol where each party has some um a share of the global witness that nobody knows but here the prover actually knows it so it starts with this and you can show that if the gate is like addition or

like constant multiplication uh or add by a constant whatever uh party itself can compute this output so um if you look into how the circuit works now for a second imagine that this is all addition gug the whole circuit is just addition uh every party can actually compute everything without any interaction uh in the end each party will uh have some output and then we will again instead of splitting merging this outputs and this is going to be the final output of the

circuit so now uh the problem occurs when we have a multiplication gate so when we have multiplication Gates parties actually have to communicate so party two will be sending something to party one party three to party two and party one to party three um so now as I'm saying we can walk through this but uh this is like the simple algebra you can see uh with the cylic and if you index it correctly that uh if you compute uh the multiplication as this formula it will

give the correct output so the trick now is that when parties communicate they actually have to additionally send some Randomness they have to mask their uh their like parts of their secret shares because we want to have this to be zero knowledge so each party actually has its own r tape from which it like sample Randomness and with each multiplication gate it like reads the that uh reads from that tape and sends it as uh a message to the next party uh so that they can together compute multiplication gate

now as y Ying Tong said given this views this uh execution traces uh how we can verify this so the simplest would be if we just send everything to the verifier right but then we lose zero knowledge so what you can actually do verifier will actually sample a threat which is like zero one or two so let's say that verifier samples zero okay prover will have to open the whole View of this party and the party that is sending messages to this party

so in this case for challenge zero it will be parties one and two for challenge one it will be two and three and for Challenge three it will be three and one okay so this is very important what we know about this thing so do you agree that and now like stop me at any moment that if the whole protocol was executed correctly everything will be fine so we have this like completeness part so let's say and it's very intuitive to ask what if prover actually does not know witness what if he since it has control of

everything what if he just like randomly splits stuff or sends some wrong messages and in the end makes this like it fits this stuff to work to give why so from what we know about this MPC protocol and this um we know that unless prover actually had a correct witness that he splitted uh it cannot be true that all these Protocols are that all these views all these traces are correct so at least at one part one party which is like one two or

three sent or computed something wrong so let's say that party two sent one wrong message to party one while doing one of the multiplication Gates so if the party if the verifier asks to open views two and three it will not catch that this party played wrongly uh if it asks one and three it will again not ask so it has to ask one and two part like it has to ask for opening one

and uh it will see that actually party two played wrongly in the execution with party one so um from the interaction of uh party two and three you may be cannot conclude that party two is malicious party so we have like a huge soundness error and the main need I don't know drawback of this approach we can say is that we have actually to do a lot of repetitions and this is where in Tong said that like proof size will be bigger so you have actually to repeat this uh like aund and something times to get to some uh nice

security and then you have to commit to it and then you have to open um a view for each repetition okay so two main things to remember uh that the complexity is measured in multiplication Gates and this mental model of how you can catch malicious proverb so you have to uh query like the opening of the view of the party that did something incorrectly so party may have done all the computations correctly but maybe

some message was incorrect and stuff like that so um this is kind of maybe unintuitive first time when you see this so I will use then this 10 minutes to go through uh how our implement looks like so uh we try to make something very generic probably it can be more tested more error handled and stuff like that but what we were able to achieve as inong showed is to actually build the full sha circuit with our framework so I guess it's not that bad um so we have this trade circuit which

is like uh very abstract and you can do a few times with it a few things with it you can compute the circuit so this is how would you just compute it to get the output to do whatever like to verify it's like more like local testing method these two methods are the most interesting methods for us so as we showed for each circuit you have to be able to compute these two 3D composition that we just showed this thing and uh later as in as Yong said uh and how zibo works is that party uh verifier asks for

opening of two of these views and then it actually reruns them to see if everything was correct okay so uh these are like the two main uh two main um uh functions that each circuit has to implement so uh before we get into the how maybe some circuit can work um you can very easily stack gadgets as you can see like uh we have all the uh small stuff that you need for sha uh you have like

compression circuit you have final digest uh okay here are the and you have the message schedule CC so you can just like append them all to get this but here I think it's like we don't need to go to the full example of sh uh but yeah you have like a lot of these uh circuits in ad mode in gadgets if you I don't know want to use our library and try to do AES or maybe something like that um so so as we saw each party while running it starts with a random tape and it has its execution view so what the view means

so it can it it like just captures the whole computation Trace all the messages everything that this party has in their memory while they're doing this computation okay so um as jingong said this can work on any fields we were targeting like bullan fields and source and stuff like that so you have like a lot of utils here but the main kind of uh the main uh uh type that we're working around is this gf2 word so this is like some small abstraction that you can actually work with like booleans with u with u32 U 64s U 12 128s it will

work everywhere the same um so it's just like kind a uh abstract type that will that share the same interface for everything um so okay given the party let's see how the party is being used in the protocol and I think you will have the nice uh overview so maybe we should start with approver um so prover given the input we said it sh it split shares it so what's the easiest way to split shares you just random sample two uh two Vector of elements and then you compute

the third one as aore of them so when you sore them back they give you the actual input but if you see any any two of these three they look completely in distin isable and random so uh yeah it's that simple so okay what every prover has to do so first we set up number of repetitions where you add what the bit security you want then we have this structure called key manager it like samples the randomness for the whole protocol it's much faster than to call RNG each time uh as you need it so you given the number of repetitions you

sample enough Randomness that you can feed all parties and everything that you will need uh okay uh and now you initialize a few vectors so each party will have their output their views and we will have to commit to everything as we saw okay so uh here as you can see uh what we didn't do and why I think our sha implementation is not that fast is that actually we can make this parallel but yeah this is maybe this was more for like learning purposes so uh for each repetition you take some Randomness from this huge Randomness

that we computed and you call this function prove repetition we'll go there so imagine now somehow we proved that we executed the circuit once we store the outputs and we store all the views like all party views okay now we make this party executions which is um like a simpler structure that will be enough to recreate everything so for each party you need uh the initial key they start with because the whole random tape of party is Compu Ed from this key

so you don't need to send the whole random tape it's enough to send just a key and uh you commit to them okay you also have public input uh okay we have some hardcode that's it not a big deal uh so you again I'm saying you repeat you repeat this 100 times to get to some reasonable bit security and then you commit to all of that and now you start sampling this treat challenges as I said so you have to be careful here a bit I'm not going to go into too many details like um to make sure that you're doing

correct rejection sampling and stuff like that but based on this trits you actually have to open some stuff so as you can see here you have to open some views okay so that's going to be party one party two party two party three or Party 3 party one based on the challenge that you got you also need to push their keys so that the verifier can recreate everything and you also have to put the commitment to the unopened view so that prover can also verify that you hashed

correctly everything so this is the high level and what the prove repetition does now when we have all of this it's very easy so it just initialized the parties where we said each party has starts with their uh key and tap plan so it just starts empty party and then we compute this uh circuit computes to 3D composition which gets the mtip references to parties and as you compute this you actually uh compute the party views so this is what we get from the repetition output here okay now we are

going to go and look into a specific circuit how it does all of this but from the high level perspective now what the verifier will do so verifier will do something very similar uh it will us take these two open views and it will call um let me show you uh okay so given the open two parties it will first initialize those parties with like their keys and everything and then it will call this simulate two parties so this is just running the same protocol for these two parties assuming

that the messages they got were correct so you don't know anything about that maybe you caught the party maybe you didn't you just have to run it and see it yourself then you uh have to like pack it all back commit and also you run the Fiat Shamir to see that everything that was um sent was actually corresponding to what prover sent so um this should be it okay now here uh if you look into ziku you will see that we have some uh different stuff not how it explained here actually we are the

implementation of us our implementation is this zqb uh Plus+ which uh is the paper Ying Tong also mentioned and here uh you will see uh few like five uh six yeah it was uh six different optimizations that you can make to original zibu to make the proof uh smaller we can go into any of them as I'm saying given the time bound I'm just going to give I'm just trying to give a very high level of the uh Library infrastructure and then if there are interested people we can go directly and

look into something okay um so yeah uh now how the circuit will look so for example we have this uh add mod sorry uh even easier uh so let me show you a few uh gadgets so we have MPC sord Gadget MPC end Gadget and NPC uh and verify Gadget okay so as I said because when the gate is addition which isor in this uh field of characteristic too uh you don't need any messages from

different parties so what you can do they simply compute all on their own so given the party that has like some inputs A and B it simply just sores them and that's the output complication begins when when the parties have to uh compute multiplication Gates which is in our case end when we look binary so now you will see that this really corresponds to the formula that was written in z kibu um here uh so each party has to read this Randomness from their tape and

see how confusing this is like you are the one prover who does all of this and you're like doing this actually in your head right this is where where this comes from and you're Computing outputs of each party given this Randomness so as you can see uh the output P1 is computed from party one and party two P2 is from party two and party three and party three and output three is from three and party one and this corresponds to this arrows here who sends the messages to whom okay now we got this outputs and what we have to do so we have to

register this outputs in the views of the parties as we said each party has its execution Trace that in the end is used to reconstruct the final output and you will have to commit and open two of these views so each of these uh messages that is uh um computers as an output gate you have to register in view so why you don't need to do it here because simply you did everything locally so you don't need assistance from other parties so given the verifier who has uh the just the output messages it can actually

on their own also compute all the uh addition Gates themselves so you don't need to register that in a view and how would you do what are you going to do when you want to verify it when you call it simulate two parties so you will uh know this is very connected how we do with this C++ uh optimizations but um roughly you're just going to compute to one output so um given the party let's say one and and party two after you got the message of party two you're going to compute the party the output of this

party and you're going to register this in their view um we're going to see in the optimization why this works but I'm not going to go into this right now so this is how like given this many gates this is what you do if the gate has end like multiplication you have to send all parties you have they have to have Randomness for this gate and you will register something in the view and now I don't know we can also look how uh the whole shatu circuit can look you you

call a lot of these gadgets um for example here this is the verifier which uh checks the compression so it calls uh all the May function the choice function MPC functions in the end it calls add mod functions and etc etc here for example you can see so you can literally just we build this framework such that you can just as you would expect in building any circuit just to stack a lot of gadgets and it should work um so here while Lon was speaking I ran the benchmarks for

different uh pre-image sizes of like two repetitions so you saw that like this unparalyzed version it takes about um two milliseconds to run two repetitions for uh one sha uh round like one sorry one block how you call it after one chunk of shot of the preimage and this is all being run with uh provable padding which actually took a lot of time because we had to convert stuff and prove that we did some stuff correctly

um where we lost a lot of time uh in the proving size uh yes and now uh here you can also see the proof so you have to send you open two-party inputs you send uh some commitments you send some views you send some keys and you send some like claim challenges from which the verifier recomputes everything and reconstructs so um yeah I think this is the this is like just gener generic version how to

compute the commitments to stuff and yeah yeah okay I also see it's already 35 I hope not a lot of people left but they are they left so yeah uh for those who who are still here let's see if we can look into something specific do you have any specific questions Etc yeah there's a question but I will just remind everyone that you can unmute yourself for now uh is there any reason you secret share to three and reveal two instead of secret sharing to more and revealing more in feel yes you reveal if you reveal

more anybody who sees that will reconstruct the whole private input yeah uh so it was not about revealing three out of three but for instance doing four out of five or thing like this to increase your probability yes so you can actually see uh at the beginning of the paper uh it's not that hard computation that the best thing you will get for two out of three you can definitely have more but um when you look the best numbers will like the best soundness you will get from two out of three and I guess this might also have an effect on uh the proof size or competition of course of course you will also have to

open more views to do more computation um when you include all of that in a in a equation two of three is the best yeah uh see uh I do not see any other questions I just called for one for some but yeah uh thanks a lot for the talk then I think we can end things here great to have you here uh and yeah uh maybe we'll have you later for Sigma bu or something

different we've been interested in this paper uh for a while so I might contact you again yeah yeah uh yeah of course um see you see you around thanks for having us and uh sorry that we had this misunder understanding and that this should have happened much much before no no problem at all I hope yeah thank you uh see you guys goodbye goodbye