Shuffling Cards with MPC

Transcript

[Applause] [Music] [Applause] [Music] Okay. Um, hi guys. Uh, nice meeting you all. Unfortunately, as Luca said, uh, it was not planned for me to give this workshop. So, I'm not in Berlin, but let's still make the the best out of it. And hopefully we can show off some uh nice things about our building and also we all have some fun here. So this workshop is structured that I will first give a little bit of a longer introduction. Uh so little bit we'll go over my slides and then there is a show off of some code and you can find this code here in this GitHub repository and uh if you want to play along also want

to execute it on your local machine a little bit with the code. I recommend that you clone it now because there's also a docker image in there and the docker image takes a little bit of stuff in the build. So um you can build it while I'm giving the rest of the talk and then we can go over the code together and I can show off little bit of the capabilities of our tooling. But now I want to start with uh with the uh introduction the long introduction to the topic and uh what I want to show here is how we can use our dueling to build a cobb app that um based Noah and um with the concrete example that I'm showing off is staffling deck cards using our coach dueling and I first want

to motivate why we need a snark to actually be shuffling um of these cards. So let's assume we have two parties here Alice and B and they want to um play some card game. If they are um locally together there is actually no issue. They can just shuffle the cards themselves and the other party can see that they actually doing a great job shuffling. But the big problems come when we want to do this shuffling over the internet or even on a blockchain. And the main issue is just trust here. So Bob will here be saying I don't trust you at all Ellis. So I will be doing the shuffling because you will cheat and Ellis will essentially be with the the same name. I I cannot trust you Bob. So I will shuffle myself. So they won't get

to an agreement here. A simple solution to that would be that they just ask a different party. In our case here, this is Shadowbot. Um please shuffle the deck of card for us. But uh if you think about it, this also doesn't solve the problem because Charlotte actually prefer Ellis and might shuffle the deck in such a way that Ellis actually have his advantage or Bob is a really sneaky guy and he knows that they're going to play poker and he will be like if you are on shuffle in a way that I win, you get half of my earnings. So definitely there's a lot of trust issues here and it doesn't solve our problems. And when you continue thinking about it um uh with technologies like private state that we have now on the adefrastructure

cannot really solve this problem here but you can use MPC and coax to actually solve the shing problem and create something that we call private shared state but one step at let's just uh start with an introduction on what the technology behind um NPC how this actually works. So um MPC um I'm usually playing with a specific type of MPC called secret sharing MPC. What we usually have here is that we have a set of um multiple computing nodes. In our case here on the slide, we have three. And what the data holders um do is that when they have some data, this is cat here on the top.

When they want to uh put this into an NPC, they seek to prepare this data to this MVPC nodes. And the what the secret shares are are essentially are um random looking data. And each of the MPC parties gets one of these shares. And this share alone is completely random looking to them. doesn't leak any information about the data. But the BIX as a collective can use their shares to compute functions on only the private data and the the output of the function is again uh secret shared which are completed and looking which are do not leak any information about the intermediate results and once they combine the shares together they get the

correct output of the computation here the the super cat here down there. So and there MPC is a very big topic with tons of different protocols and tons of different techniques and uh I I just want to give you some ideas on how the secret sharing actually could look like. So here on the slides we have two different examples on the left there is a so-cal chamia secret sharing is one of the oldest forms this was already invented in 79 and here here is when I have a secret value I want to build a polomial a random polomial and then code this private data as the constant of the polomial and the secret share that sent out to computing part actually points on

this polomial and we do this because this nice property that um uh one point does not leak anything about the polomial itself also not on the data encoded in a constant term. You can still reconstruct the polinomial and thus also the data if you have enough points with lanch interpolation for example and polomials have this very nice property that if you have the the points you can compute function on these points and you get points of value polomials. So you can do computations on that. Another very common uh way to do this secret sharing is called additive secret sharing. And this is arguably uh one of the most simple things you can do. Let's say we have three computing

parties. What we do is you simply two random values and fix a third value such that the sum is the original data. That is all you have to do and every MPC party gets one of these three values. Now they are um obviously random. um do not tweak anything about the data and reconstruction is also very simil simple because you can just compute the sum over it and as we will see on the next slides you can do computations with secret shares. So um as an example if you want to do addition let's say have two share values X and Y. So um what you would have here is that um computing part has the share x1 and y1 computing party two has the share x2 and y2 and

the third party has x3 and y3 and you can see if you add together your shares. So as a computing party one I add x1 + y1 then this is already a valid additative share of the desired result. The addition is actually very simple to do in MPC because you just local no need to communicate with other parties and everything is fine. And this extends to every linear function like um adding a constant value multiplying a secret share by a publicly known value and so on. These are very simple doing in NPC and u um you just put something locally no communication involved becomes more complicated with nonlinear functions like multiplying two secret shared

values and uh again there are tons of different methods on how we do that. I will just mention two of them so you have a little bit of an idea on how you can um put that in MPC. And um one technique this is very well known also very old is um called the pivot technique. It's common. Yes. We have a question. Yeah. Uh sorry for interrupting. Can you scroll back to the previous slide? Yeah. Uh I have a skip question. Who does the addition? Like uh we assume that we have two counterparties. They have parts but who does the addition? Like who owns the result and who does the Lucas.

Yeah, I can like uh because like the mic is here like the question is like who owns the result like x + y in the end. Who executes the operation and first like who executes the operation x y + y1 and x2 + y2 and then who like holds the sum x + y. Yeah. So, so um the the MPC part is on a circuit in in the beginning that defines what they actually want to compute. So the addition is uh uh embedded in there and then each party has the the shares. So party one is x1 and y1. So party one will compute an addition. Party two will also do an addition. It will do x2 + y2.

Party 3 will also do an addition. It's x3 + y3. And uh these are intermediate results then. And these are also secret share. And uh so that the result of this operation is not yet known to anyone only in a secret share form. And uh once the full computation let's say a boson head whatever is done um it it depends on what they actually want to compute if the output will be known to everyone it will be known to a specific party it will be known kept secret but only a commitment to the output will be published. So this is fully up to um whatever you want to contribute. So in the case where we have uh one of the parties to uh own the result we we send

all the intermediate results to this party and he finishes the computation and owns the result right. Exactly. Exactly. Okay. Or this party can be a nonchain entity smart contract for example. Exactly. Okay. Yes. Then it would be basically public like if we like roll the the end result on chain like if it's not Aztec or some private chain like it will be like as you would publish it to the world. Okay. Thank you. Let's explain it. Good. Then uh let's continue with the multiplication.

So how be string works works is that you you generate somehow these helper triples here A B C and these are in secret form. And how to generate this is a a completely different topic. There are tons of subprotocols for doing that. But uh it will be too much for this workshop. So let's just assume we have this help. So these are secret shared. Nobody knows the data only the MPC nodes as a collective no A B and C and C has this extra condition that is the the result of the multiplication of A and B. So and if you have those you can use um these secret shared uh A and E to mask the inputs for the multiplication. So A + X and you compute B plus Y and you publish those values. So you reconstruct

them on all MPC nodes. You can do this because no one knows the real value A. They only have shares. No one knows the real value B. They also only have shares. So that the result big A so capital A and capital B are completely random and do not leak anything about X and Y. And once you have done that you can compute this uh formula formula on the bottom here and it will give you the desired result of the Mation. And uh um so if you do the math you will see that it checks out. But you can immediately see this has a disad compared to do the linear operations like an addition because um this uh step in the middle where you bubble capital B this requires the computing parties to communicate to

each other. So they they want to get this value in clear. So they have to send their shares to the other parties and it is a common uh thing that you will see in MPC for everything nonlinear like multiplications bigger protocols like bit de compositions etc etc there you always have communication involved is the main thing I want to tell you here with these trips there's another technique on how you can do multiplication for example and that is uh one that we tend to use a lot because it has a lot of advantages and that is when you have additive sharing you um um send your share to the next party. So each party has a two out of the three shares and uh what this allows you to do is um compute this formula here and this

gives you a valid additive share of the multiplication. Uh so there is a very very simple multiplication protocol but again what you need to do here is you need to send the share to the other party. So there's communication involved and this is something you cannot get rid of in MPC for um um more advanced functions you always have this communication in there and this is also in practice a lot of the limitations that you have NPC it's a communication all right that was uh intro to MPC I don't want to talk more about it right now a bit too much for but let's now see how we can use it to solve the shuffling problem so first you all are familiar with your knowledge and I want to

quickly mention what the the properties you get from a zero knowledge proof and that is um as you all know when you have a zero knowledge proof computation you can prove that the computation was done uh um correctly and um when you have this knowledge property you can also do this while not leaking anything about the the inputs of the comput also about intermediate results NPC on the other hand as we have seen is not a tool where you can prove something. It is a tool where we actually do some computations and the computation is done in a distributed fashion on multiple computing parties and the nice thing about MPC is that same as for your knowledge input and intermediate results

stay private. So what we did to do ato is combine zowledge with MPC get the coach and the coach gives you the best of both worlds. On one hand, you can compute on private data without leaking the the inputs and intermediate results. You can also prove that the correct circuit was uh computed and this all without leaking any inputs or intermediate values. So that is uh essentially why we do a cos. So how can we now do a cos solve the shuffling problem? So here you can see now on the slides on the right side this three VPCs these are standing for the NBC network.

So in practice each of these VCs is an NBC node that should be hosted by a different uh entity. For example one is hosted by EDS one is hosted by that and maybe one is even hosted by you. And what um Alice and Bob now do when to shuffle a deck is they sample a random value. So Ellie samples R1, Bob samples with R2 and a secret cherries to the NPC network. The MPC network then computes a circuit that shuffles the the deck and also creates a SE knowledge proof that they have used the inputs provided by Ellis and Bob to do this shuffling here.

And this um solves the issue. So um what they have now is um a shuffle deck. it is uh ideally still secretly checked out and managed by the MPC network so that um Alice and Bob do do not know the shuffle deck but they get this knowledge group everything was done correctly and then in a um further in the future they use this shuffle deck to give out cards to maybe other players or also do this shuffling um for for some data on the blockchain and use the shuffle deck to to play a game on let's say on sec chain so this is pretty nice So are we done already? Unfortunately, not really. We will mention this in some slides what is still missing. But let's

think what we have done right now. So we we want to play a game of cards. We have shuffled the deck and created a deck that no one actually knows um the order in. Only the MPC network as a collective know the order of the deck. But uh um no individual uh not even an uh computing of the MP secret does know the order of the deck. We can give out this uh cards to new players. This is really simple because you can just encrypt it um a new card in NPC and then that approve uh on it that the correct uh card was encrypted and send it to the to the uh recipient of the card.

So and um we further think about it u um what we did was not just composing state of Alice and Bob but we essentially created a new bracket state that is not not known to anyone and that is managed by the MPC network. So this is we call private shared state. This is a state that is not managed by just one uh single party or is known to anyone. It's a an unknown state but is still usable in computations later on. But the issue that we have so far is that we have any input verification. So we'll talk in the next slide what the issue is but it's essentially the same issue that we all have on a a blockchain that just has shared state like ade you need to

somehow verify input because um if you think about it when I'm now this uh note pro by onst and pop come to me we have a shuffle deck and nobody knows the cards blockchain will be like are you sure really how can you uh verify that and the issue is when uh The MPC network proves that they have shuffled the cards with random inputs. They just prove that some random input was used for the computation. So it could have just uh used a different input from a different party. So what you always have have to do this is the same for any shared state also for edstack is that you have to bind that input data of the computation

to some public commitments. So as you know on ade everything every private state that you own it has a commitment on chain and even with the you cannot get away with not having commitments you need this commitment still so that the proof needs to be um there is a random data as an input where alis also has the corresponding commitment on chain and then everything works out nicely. Okay. So that is in general how we can use coax to to solve this problem and in the future that we want to have that we integrate the coax on some uh um private blockchains like adst how you can do this right now is that um we have

written this uh kona tool we'll see then with the the code demo and there you can write your code in and create the so-called ultra honk proof and if you want to um use this proof system to create private state on EDSC. Right now, um you can use the um standard verify proof command in the EDC smart contract language which will essentially um verify the validity of a proof on chain. What is happening in the background is essentially a reversive verification of the the proof to make it compatible with the the proof system that they are currently using in the in the um onchain infrastructure

which is called client ABC. But with that you can uh interrupt uh the ultra honk proof system also with the uh adex smarter. In the future, what we would like to have is also have an MPC variant of the full band IC system. But we are currently only starting investigating the physical ability of um right now if you want interconnect our coaping with ultra honk you have to do that um with the left side here. So so far about the introductions are there any questions so far? And then uh other than that we will uh jump directly into the demo and then we go over uh how you can uh write some

coite code and do the bell coing uh for for the shuffling here. Lucas, are there any questions in the audience? Not that I see. Um I wonder just yeah I'm curious like how feasible it is to do coco as like transaction because it's super composed. Yeah. Uh so the question was how feasible it is to do a coark over the Aztec transaction. So you mean like uh and transaction like uh spending some money sending some money.

Yeah. Yeah. For them. Yeah. Yeah. Exactly. I think that's like what uh like if you go one slide back like he alluded to with this client I see that's what we're currently working on. And yeah you can give more. Yeah. So we are currently investigating what we need to build for that to to work but uh in the end we have seen so far it will be definitely feasible to to to build a coach on that but um uh the concrete performance I cannot give you any numbers so far the for that we are too far but uh we would see that it's definitely uh will be feasible in the future. So maybe to sum up like it's a huge engineering effort but we don't see

any research that we have still to do but like just a lot of research and even more research to get it performant but yeah other than that we couldn't find any like blocker than that it shouldn't work out like exactly the same like with old drunk. Mhm. Yes. Exactly. Great. Um then let's uh continue. So one last slide before I go to code and this is essentially the setup that we now will be simulating on on our machine. So um uh in the middle what you can see I don't know if you see my mouse uh Lucas they see the mouse okay you see the mouse good in the

middle there is this MPC network so in practice I I've said this should be uh each node should be hosted on a by a different entity in a different machine for example Edstack let's say maybe you even uh but in our uh demo right now we will manage all of these MPC nodes on the on the same machine to just show that it is going to Um what we then also have here on the left side we have Ellis which is one of the input providers and on the right side we have both the other input provider and the third thing that we have is um a normal no program that you at noon all love I also love it and uh you can write the normal no program and use this as an input for the combination. So we'll also show off the

code where we do shuffling with no. So this will be the third input. Uh and um so that the the workflow that we will do then is that Ellis will use our dueling to secret share her input and this will be the secret shares here. She does this locally on her machine and then sends each share to one of the computing parties. Bob essentially does the same has to input um uses our dueling creates secret shares and sends one share to each of the computing parties. They then perform the MPC computation and also creating the co snack and uh they can then output these uh recycling secret shares to um the desired recipient. In

in our example, this will be uh essentially Charlie will be a blockchain which gets the the the knowledge proof and the commitment to the data and they will keep the secret chest of the traffic deck by themselves. But this is essentially what we will do with our dueling and then we have this proof you can either use our dueling to verify it or also the parent verify that is uh coming standard in the ad safe infrastructure. So the proofs are compatible with each other. So in this workflow we will now show in an example.

So um here I have this repository um cloned um that I have shown off on the slides and you can find here um Lucas is it big enough or should I make it bigger? That's fine. It's good. It's fine. Okay. So then here you can also find a big read which essentially describes what I will be telling you right now and all the steps that are involved to to run the example but I will go over it anyways. So what you can also find here is the slides that I'm using used for this uh small introduction here and and we have two folders in here the doppeler deer. So we want to shuffle a deck here in Berlin. So we use twin cards the

doper deer cards. Um so here essentially is the full code in there that is uh um that we will going to be executing. And here in the doer dodge to-do this is essentially the same code but the main functions are missing. So if you want to try out yourself if you can write the main function so it's not that much lines of codes but still um you can uh try it out here you can use this repository here but uh I will now go over there the the full um full example here. So the the um most important fun is um here this uh shuffle function. So let's to go just into it. It gets us an input this unshuffled deck. So our deck

here has now 32 cards and each card is represented as a number from 1 to 30 from 0 to 31 and this shuffle function is the core of our computation is what we want to compute and this one we implemented this shuffle based on a so-called ponic sorting network. So and uh this is a a normal sorting oblivious sorting network that can use to to sort some stuff in NBC uh and CKV as well. And uh how you can translate this to a shuffle network is is by um whenever you do a compare and swap instead of comparing two elements you just flip a random coin. So that is the essentially the way on how to get from a sorting

network to a shuffle network. So whenever we want to compare something we don't compare we just flip a coin whether we should actually swap two elements or not. But in the end it is a very very simple way of doing shuffling in MPC CK. So um the randomness here comes from this shuffle randomiz and uh it is actually fed by the inputs from the Dubati. So Ellis random element and box random element. And what we do here is essentially we hash them together uh produce an output field element and do a bit of decomposition uh which gives us uh with the the used field and 254 bits and these are the random coins that we

then use um to decide whether we want to solve or not. And so you see whenever we call this coin function the next bit is going to be. So in our example these 254 bits are already enough in um if you need more you will just have to patch more here. But that is essentially the the whole shuffling protocol. And um now let's have a look at the the main function here. And what you can see is that I actually split the main function to a main inner and uh um which I call from main and then there's extra commit. And then eventually want to to split these two functions because uh the main inner function has the computation that we actually want to do like first

verifying the commitments of the inputs and then shuffling the the card deck here. What was that question Lucas? No, it was me drinking a cola. That's what something. Sorry. That's fine. Right. So, and you can see this main function returns the shuffle deck. But um this happening in in um in no when you return something from the main function and this becomes an public input to to the the proof. So we don't want to return this after deck of cards from the main function. We actually just want to return ament to it. This will I said be a public input to the proof. So it

really needs to be published here. Um we just establish a commitment to respect and uh yeah uh what are the asserts that what are the what is the semantics of the searchs that resigns in line 41 and 42 like yes um so there are public input I said in the in the beginning of the so in the introduction that it to verify that the correct inputs were used in the in the computation and usually what we have in a blockchain like cat stack is that onchain there are commitments to data. So that this uh player one uh randomness is only known to Ellis and

this player two randomness is only known to Bob and here the NPC setting the NPC nodes only have secret shares to those. But what is uh no um onchain commitment to these values and whenever you do uh acquidation in private shared state you need to verify that the inputs actually match the commitments on chain. So the commitment here you can see it in the main function a public inputs to our no and what we do is we commit again to the the real um uh to the to the input and we do assert that the that the output of this commitment matches the one that we get as an input function. So this binds the input that we actually get for the

comput computation to the commitment obtain and this assert here is a constraint in the serial knowledge proof. So if I let's say I have the random value five and I have the commitment to that on chain but I use the the random value six then the the knowledge proof will fail. So this gives us the public auditability of the that the correct input values and the same also goes for the I'm still missing the point uh the commitment that is supplied by a user from the outside it is produced locally before you uh take the input from the side from one of the users and uh produce the

the produce their share out of it. Right? It was the R1. Yeah. So the that the commitment is on and when the user uh secret shares his input to the network, it also provides the commitment. But then the critical part is that since this is a public input here in the file, it is required for the verification of the proof. So whenever someone let's say a smart contract verifies the proof, it also needs to provide the commitment and uh that gives the verifiability that the commitment was good. So the if the user would provide another commitment as the input and the verify that this should be the private state of the chain. So I use this commitment and the user did use a

wrong commitment proof will fail. Okay. Thank you. And this is also the same on the out as I said we don't want to return the deck because the deck should stay secret but you want to return a commitment to the deck and this will then be also public input to the verification. Okay. So that that the code is uh one more question simple just is there any reason to use positation instead of just uh like if there's any reason to use Poseidon 2 because like likes Poseidon 2 more than Poseidon no no sorry

instead of two as well uh why permutation I just don't know about permutation one why you using Prooseidon 2 so the permutation instead of only Poseidon Uh um yes but I'm a photographer so I know what I do. I do not recommend others to to play games with you. Uh but yeah I could have used standard hash pos but um the the nice advantage why use do in the first place is that um there is a blackbox function in Noah and that speeds up the the proof generator but also the computation. So that's the reason why I use in uh in general. Yeah.

And the specific function. Yeah. I tend to use the modation itself because control over but uh yeah you can use whatever you have as long as you produce a secure commit there. Also in a replication you would need randomness as well for the commitment but I thought for this is up to over produces much more inputs and outputs. Does this answer the question? Yeah. Yeah. Thanks. Okay. So, um what we have as inputs here as I said is um the the secret share from Ellie, secret share from Bob and also the um the commitment and reproduce

another commitment and this is um I can show this off right now. We go this u repository and this is just a normal um Noah repository. So I use execute for example and it executes this uh um this whole set I can test which executes the test that I have down here and uh to get the circuits I can use compile and I actually need to um compile it here because our also gets compiled circuit as an input and this uh compiled circuit is now here in the bucket folder here and um our dueling which I show later will automatically at least come directly from here. So for the remaining

executions so I I have told you that we need simulate now three parties on our laptop and they need to run in parallel. This can get a little bit cumbers. So we have uh written here a just file which takes care of doing this uh simultaneously. So you can see for example here for proof generation we have three commands and these commands actually is one command for each uh MPC node. And I will use this as well now to uh do all of these executions here. So the inputs the first in is from Elliot.

So it has um the the the one and the the commitment and the second from Bob which has the value two and also the commitment to this value. And so the first step that we have to do um that each party um secretes the inputs and sends them to that NPC network. So I do this with the command just split input. And you can see here it gets executed twice once for Ellis and once for Bob. So um Ellis here seeks the input and writes it into this file here. You can also see um each out secret shell inputs that the files are produced and uh so that this uh input l shared

indicates that this is the secret chat input that should go to party uh zero. This the second file here should go to uh MPC body one and the third file indicates that it should go to the NPC party 3. The same for the for B. And in a real setting they now need to communicate these shares to the cor correct sea party. In our setting since we simulate everything locally we just have everything there. And uh the next step what we do is more of a convenient step and that is uh since uh each MBC has two input files.

We need to merge them into just one file for further computation. And that is a just merge input and that produced um the files in here which are the inputs of each party for the um remaining steps of creating the coach. So is the input for party zero, input file for party one and the input file for party two. The next step is actually the code and this is uh so that is just computing the um no code. I just need to get a com from the yeah witness generation uh run witness generation. So what we do here executing the code in MPC to get the output

shares. So and this a little bit longer there only one second and what this produced is here now in the w folder each part has a secret share of the full witness and this witness is then the input is your knowledge generation and this is the the next step we can write run proof and this generates u uh ultra hon proof NTC and um boots the output here into proofs.

And it also produces this public put file like is also done by which essentially has all the commitments in there that you also need to verify proof. So then the proof zero, proof one and proof two these are now all the same and these are your knowledge proof the computation done correctly and you can now use either our tooling or the parames and uh I can show you that it will verify with our tooling. So first it will create um um the verification key and then I can just um run verify and it will tell you that the proof was correct. These proofs you actually bubble it on ch on chain and everyone can actually verify that the

correct commitments were used and that the correct computation was done. So this was essenti um the show of of our tooling. What they want to highlight again is that we have just normal no code and without our dueling you can actually execute that in MPC get the MPC computation and this knowledge proof um without dueling directly no need to modify anything else and what you need care of in uh in practice when you um interact use our tooling for operability with the blockchains is that you always output commitments and verify in commitments. rest and should uh be normal micro.

So are there any cracks uh from I have a question uh about this merging step uh merging inputs. Um so maybe I missed before in the in the whole setup but how uh could you repeat maybe how MPC nodes kind of are they waiting for some both inputs from both users or when maybe one input comes from one user how this works kind of in a blockchain setup. Uh yes in a block h would be there would be somewhere this MPC network and then one user of the user to tell the NPC network we want to engage in a computation and

then the net will wait for inputs for so will provide the input Bob will provide the input but at some point all of them have the inputs and then uh they just tell the network start with the computation and the the network will then deliver the result to the uh required parties here. So, uh that um you could probably build also something like uh where the NPC network watches on day in the web, it should uh wait for inputs and it should um start anation. But there will also since um only Ellis knows her secret data is not on chain.

There's only on chain there's always some step involved where Ellis needs to secret share the data to them with so you cannot get it. Yeah. Thanks. So if the computation and uh in the network will tamper with the data the final colono on the resulting node will find it out right. Um Lucas I I cannot understand that well please. Yeah. So like if like some of the MPC nodes tamper with the computation the final result like will you will find out in the final result was the question.

Yeah, we'll find out as the the coach will not verify. How many nodes in the NPC network must be uh honest? Yeah, not honest to actually bypass the verification on the final com. So, so what they never can do is produce a wrong because the will always fail. That is the same as if we I would produce a a group by computationally that is totally the same but if um uh enough collute and extra shares they can infringe privacy that's what they can get but they can never produce wrong

knowledge proof that is the same as without MPC thank you I have another quick question about this shared inputs can you just quickly show in the code how big they are the documents themselves. Um so that the inputs uh I can go in there they should not be uh they have does is it listed here? Yes. So that you see that they are very small that the thing is we use this additative secret sharing here and what they share is essentially just one field element and with additive secret sharing

each secret share is the same size as the um as the original data. So this is very very small. What is bigger is uh obviously that the uh output of the uh MPC computation the the witness the signature witness because this is the whole witness that you have as an input for the youth generation then but the in general input to the computation is in this case very very small. Yeah I have a question. So like like do we have the flexibility of instead of secret sharing shares we secret share encryptions of those shares? I mean does that involve lots of engineering or so?

So so you mean instead of secret sharing the data we secret share cipher text and then decrypt it in FDC or something like that? No no we we so the parties they seek they send to each other encryptions of the shares of their inputs. So instead though um yeah you can obviously put something like DLS on top of it when if you just want to protect the the transmission uh itself that that you can definitely do and uh there's also when we use the dueling in practice we will always use DLS as a intermediary for communicating between the parties. So we send encryption of the shares and the other but the decrypts and has the share

now in in blank it answers the question. Yeah I see I see but maybe like what's your thinking about like why would you encrypt the secret shares like what were your Yeah. So like for example use cases where you want to have like extra properties from the NPC like uh robustness and like verifiable secretary. Basically we want first to check the shares of the the parties and once we like some like checks go through then we can uh open the sh like the shares to everyone but first we we need them to be encrypted. So we encrypt first, we do the checks. Okay, the shares are correct. Then yeah, the

parties decrypt. Yeah, you can definitely do something like that and also um produce a cipher text, send it to the parties and uh only secret share the key once the checks were done and then they can decrypt the date also in the NPC to directly get the shares. There are also MPC friendly ciphers like you have CK friendly hash functions in there and you can use those for for these example use cases. Yes. Okay. Okay. Thanks. All right. If there are no more questions then uh thank you for your attention. I hope you learned something.

I hope you will use our tooling in the future and uh thanks for having me. Yeah. Thank you very much. [Applause]