MPC Framework Online Talk

Transcript

All right, welcome to my online talk on NPC framework. So my goal, welcome. Uh my goal with you today is that you should learn, what NPC is, uh some interesting ideas about what it's used for, um how it works, like what what is the cryptography that's really going on, uh and also how you can implement it yourselves. So that may seem pretty ambitious but we are going to that is I mean I think I'm so excited about this project because I think we can deliver that much easier than you might think.

So let's get into it and I will all will be revealed. I'm going to start by explaining MPC with a story. If you've been to my talks before may know that this is a thing that I like to do. So hopefully this slide makes you feel a little bit uncomfortable. Uh that's the idea. So money is taboo. Taboo things is one of the motivations for using NPC because it allows us to have privacy over things that we actually really care about being private. So how much money people make, you know, uh people don't share this information freely, but there is extraordinary value hidden in there.

And so, you know, we don't talk about it because it's taboo. So your conversations may look a little bit more like this. Um because money is taboo for a reason. I think it's important to the social fabric that uh we don't necessarily know. I don't know maybe this could change in an alternate universe and maybe one day people will be more open about different amounts of money that they earn. But um in the current society it you are well advised to not talk about money completely openly. So think about what you're missing out on though. If you could see all of the money, this would be a superpower.

Does the pay stink where you work or is it just you? Um, should you ask for a raise or should you look elsewhere? You know, on the other hand, you may also find out that your pay is actually pretty good, and that would be nice to know as well. But what's the right answer? It's too bad that crystal balls don't exist. So we have to talk to each other instead. But you know money is taboo for a reason as I was discussing. So what are we going to do?

So this if we really think about it is a math problem. We don't necessarily need to know each other's numbers. What we really want to know is is there information here that I can act upon? And I think that the most important thing is, you know, uh this kind of applies if you have a peer that uh you feel does very similar uh work to you. And so if you're in that situation, you would both like to know, do you earn about the same or is there some uh discrepancy here? If there was a big discrepancy, then the person who earns less, you know, would be in a very good position to ask for a raise and that would be super useful for them to know.

And so whether you're the person who has the the lower uh salary, you would like to know that. But also if you have the higher salary, you would have uh hopefully a motivation if you're friends with this person that you would like for them to know that they would be in that position uh where they could ask for a raise. So there's a math problem. Is there a way that we could figure that out without having to disclose anything else? And yes, the answer is yes. And we could do it with NPC. It's exactly what NPC allows us to do. It allows us to make calculations over private data and extract whatever information that we want out of that data. We can do any kind of calculation that we like. Not

just this kind of example, not just this kind of pattern, not some subset of functions. We can do any function as I will get into. So yeah, I think it's pretty cool. For this particular use case, I created an app called Ballpark. So I'll just go through how it works. You press the start button. Uh one of you presses host and you get to configure what about the same means because this app if you own about the same, it's just going to say about the same. And otherwise, you know, if you find out that it's less or more, you will know that it is a significant difference because they will differ by at least this amount. So, uh, curious what people think is a good percentage to put in here. I think 15% is about the sweet spot, but curious what people

think. So, you put in that 15%. You get the other person to join, you put in your compensation, and then you get this result. And yeah, that's pretty much it. So, there's no servers, there's no signups, there's no fees, there's no I think there was something else. There's not anything, but it's just cryptography. There's no server in the middle that can see it. There's your phones actually do the cryptography. It's end there's an endto-end encrypted uh tunnel. So nobody can see uh nobody else can see anything and your peer that you're doing this with can only see this output. Uh and that holds true even if they run a different client. They modify the

software. They know all the MPC things and they you know say oh yes this bit here if this is flipped then we know this. No, you can't figure out you can't it is impossible to extract anything except the uh output that we get and that is what's magic about this. So back in our story we get this outcome that I think is really good. So this guy finds out that you should ask for a raise. Your ego may still be bruised but I think it is worth it in this example if you have this actionable uh information.

So Ballpark is a real app. So if you want to scan this QR code, hopefully it'll be there on the recording and uh yeah, you can give it a go. But we're going to talk about some other NPC apps today. So I'll leave further discussion of ballpark for another time. Uh unless people want to ask questions, that's fine too. Cool. Uh so welcome. Right. This talk is divided into three parts and uh there's two big ones. How to make an NPC app and NPC cryptography. We're also going to have a shorter section about NPC auctions in the middle.

So how do we do this sorcery? The short answer is that there is this API that I think is pretty simple and you use that API and you can do it the so yeah so we have this circuit language called summon and you write the calculation that you want to do uh in that language looks a bit like this. We'll get into it in a bit more detail later. And so you compile your circuit, you instantiate a protocol with that circuit and with the MPC backend that you want to use, which EMP wom backend is uh kind of oh it's called EMP wom engine. Now by the way um is really the only one that we have at the moment. There's technically another

one, but yeah, use EMP wom engine. You write this function. So you get to define how bytes are sent between participants. So you say you have to write this function that you know if you're told to send these bytes to this party then you do that you join the protocol providing this send function you say who you are what your inputs are and then when you get a message from somebody else you tell the protocol that you received that message from that person and then you can just await a promise and you get the output and yeah the whole point of this is that it handles all of the complicated details for you. This also works in all of the major JavaScript runtimes and

they talk to each other as well. So you can totally have a client that's running in Firefox um and a server that's running in bun or in dino and they'll talk to each other just fine uh just like we have you know browsers will be talking to each other in the demos that I show today. So the so you can use the API uh integrate that into an existing app or if you know if you want to do your own thing but we also have this template called MPC hello that comes in a few variations so there's a client client one which we will look at and it's a template repository just about 250 lines of code very simple comes with dev server there's no assumptions about the front end so you can add react later if

you like or use you know Vue or one of the other ones Excuse me. The it comes with an implementation of this peer-to-peer end to-end encrypted communication and the circuit code. So back in this uh example here, so we've just sort of like inlined the code here, which is not very nice. So a nice way to do it is to have ordinary project files and do your build system and get it in that way. So this template comes with an example of how to do that. Uh there's also GitHub pages deployment and it looks like this. So, uh, I'm going to show you how to do this with some live coding. I'm going to all pray to the demo gods hopefully and this should work just fine, right?

Okay. So, uh, oh, sorry. Let me just explain what we're going to do. So, uh, in this example, this we're going to make this other app which is like a sort ofuling thing. So imagine that Alice and Bob would like to meet at some time, but they don't want to disclose all of the details of their calendar. But without doing that, they would still like to know what's the optimal time to meet. So to simplify things, we're just going to say like the earliest day is the simplest is the is the best one. But you could define best some other way you like. Uh and you can also obviously do, you know, different times of day and all sorts of stuff. So, this is the app that we're going to to make. And so, yeah, uh

Alice doesn't have to learn that Bob is like, you know, really keen. Uh and Bob doesn't have to learn that Alice is also available on Thursday because we just get, hey, you're both available on Tuesday. All right. So github.com. Yeah. privacy and scaling exploration/npc hello. So you go and you do the use this template thing here. And I'm going to accept cautious octo couscous which sounds great.

All right. So that's our brand new repo. So I'm just going to copy the HTTP thing here. So in the terminal get clone that repo. It's done. So then we can open that in VS code. Cautious octave couscous. Okay. You trust me, right? And yeah. Oh, so what we're going to do as well is so this comes in a few variations, right? So we want the client client one uh because you know two browsers are going to talk to each other. So what I'm going to do is I'm going to remove all the other ones.

server dino dino. Next uh server server and cool and move everything from client client into the current directory and get rid of the empty directory. Cool. So now we just have this and we can Why are there 148 files? Oh yeah, 148 changes because we deleted a bunch of stuff. That's fine. Just call that in.

Uh right. Uh I'm using a uh demo account. So we don't have this set up. And now I can commit that. All right. So we're going to start this by just defining our new circuit. So this is the circuit that comes with the example. Oh, and let's run the example by the way. So if we go npm install and npm rundev, then we get this local server. So we can

open that up. We get the NPC hello app. One person presses host. similar to ballpark but like you know we don't have the creature comforts like uh QR codes. So instead we just have this thing join paste and so this app it will calculate which number is larger which number is smaller and won't reveal anything else. It's actually very similar to ballpark uh except it doesn't have that about the same threshold in the middle. we'll just do you know even a very small number uh will be considered different. So from our example, we have like Alice, if you

saw that on the um the the example code of how to use the API, we have Alice uh has the number three. Bob provides the number of five. And we're going to calculate which one's larger, which one's smaller. And so this is the correct result that we get. So remember Alice was three, Bob was five. This is the correct output. So let's write our new circuit. Uh, this circuit is a bit verbose on purpose because to showcase that we can split up into multiple files, but we're just going to write in one file instead.

I'm just going to comment all of that out. So, in our app, we want to take inputs from both Alice and Bob. We want to know for Sunday, Monday, Tuesday, etc. for each of those days, uh, is it good for them or not? And so we're going to represent this using arrays of booleans. So Alice references array of booleans. Same thing for Bob. And so we can just do let I equals Z I less than 7 I ++ Alice.

IO dot. So we do IO.input when we want to get input from somebody. And we get this IntelliSense, right? So we can say from Alice and give it a name Alice weekday I and the type is summon number like I did this in the rehearsal as well. So summon.bool and so it's nice that we get that type. So remember so this is not TypeScript by the way. It looks like typescript is the same syntax which is why we're able to get this nice intellisense but it's actually summon but it's sim it's similar enough that you can get real useful intellisense

like that. So we just do the same thing for Bob. So input from Bob and Bob weekday I saw. So now that we have those, we can say our results. Let's say if there's no match, we're going to output 255. Otherwise, we're going to output like 0 1 2 3 4 5 6 to indicate which sorry, excuse me. Um to indicate which day that we want. So what we do is we need to iterate over those days in reverse order because what we're going to do is we're going to say

if a particular day works for both of them then just overwrite the result with that answer. And so what we want to do is we want the last overwrite to be the most uh preferable match and the most preferable match is the day at the start. You know the earliest possible mutual convenience. So this time we're going to do I = 6 I greater than or equal to Z I - let here >> question.

>> Yeah. >> Sorry, Andrew. I'm going to speak up for Ally. He wants you to go full screen. >> Uh oh, sure. Um like that. >> Yeah, that looks good. Thank you. >> Sweet. All right. No worries. Yeah, feel free to uh speak up and ask questions through the presentation. H and yeah. All right. So, yeah. So, now we just say so if this day is good for Alice and this day is good for Bob, then we overwrite the result with this particular day. And so now at the end of the loop, the most recent overwrite will

be the best day. And but if there's no matches, it's going to be 255. So that tells us what we need to know. So we just oh sorry, don't we return do io.output public. Uh so we can call this result and we provide result like that. And that's our circuit. So that's our circuit. And so the next thing we need to do is we need to define we need to update our UI so that Alice and Bob can you know use the app to indicate what they want to do instead of just a number. So if we go to index.html because we just have like a really flat you know app here. As I said there's no

react or anything in here. So down here on where is it not joining code? It's I know it's step three. Yeah, here we go. This enter your number thing. So, instead of that, we want and I'm going to use this thing over here. Try 4.1 this time. So, right. So, this UI currently takes a number, right? So uh so instead of inputting a number replace this UI um so the so the user can indicate

which weekdays are uh suitable for them for them. use checkboxes and hopefully that will work. That looks pretty good. Yeah. So, got rid of the old one. And we have checkboxes for each weekday. Oh, I wanted it to start with Sunday. So, I'm just going to do that.

And then Oops. this line break one up there. Cool. That's what we need. All right. So, that's our UI. So, before we hook this up, let's just have a look and see whether that worked. So, if I host join, paste. Perfect. So, could definitely be prettier, but um you know, that's fine for now. So, back in our IDE. So, let's like stage those changes and head over to in

this main.ts. Sorry, these uh files are the same name. This is the main uh file for for the app itself. So, we're dealing with like these, you know, HTML elements and stuff like that. So where we take so here this code right where we're getting the number input out of the DOM instead of this we're going to need to get those preferences. So I'm going to comment out this part. Whoops. Comment out that part. And instead I will say uh checkboxes equals. So remember step three was our like if I jump to this one, step three comes out of the DOM which is

like this step three here. So we can just ask for what are all of the inputs uh inside of this div that will give us our checkboxes. So yeah here. So query selector all input like that. And so now we can do we can say our preferences is equal to checkboxes.m map uh you know is the checkbox oops checked like that call this um I can call this checkbox.

So that's a bit clearer. So we have this uh array of booleans. This will be the same array of booleans that we get uh in our circuit up here. Alice is going to provide one and Bob will provide one like that. So how do we do that? So we go down here. So in the original app, it's called NPC largest. I won't rename this, but you know, this is where the NPC happens. So instead of providing the number, we're going to Oh, um I'm sorry if that's a little bit creepy. Um one second. Let me turn on the Okay.

So, I was getting a flicker before when I tested this, but um cool. All right. So, yes. So, for the NPC, instead of providing the number, we're going to provide our preferences. And we get a TypeScript error. That's because it's, you know, it's expecting to take number, which is fine. We can change that. So in our MPC uh before I go in there though actually I know I need to do this. So this result that we get a string that kind of interprets the result that comes back and instead of saying your number is result we're just going to put this result directly into the DOM.

Cool. So now in this NPC largest we need to update that so that it takes this preferences instead of the uh the number. So I'm going to jump to that definition. So we take refs which is an array of bullets and then this input here instead of it being you know the A number or the B number we're going to so this by the way this matches in our circuit this like Alice weekday I or Bob weekday I so we can say input let's make it a record string to make it unknown like that and go from

i 0 to 7 input uh so party weekday I so like Alice weekday 3 or Bob weekday 6 whatever it is is equal to prefs of that index it's going to be true these true false flags So that's our input that goes into the circuit. So we um create the protocol uh as I said. So this kind of does some stuff in here. It's not very complicated. Calls summon.compile passes it to a protocol.

Um the sessions we join the protocol. We tell it how to send bytes. We tell it when we get bytes from other parties. And then we can just await this output. And let's see down here we're just interpreting the result. Yeah. So output that we get we're going to get this object where each key gives us the name of the different fields. So in our circuit we have this one output called result. So output result will be the thing that we get back from the API.

So yeah here so I called it main before but now it's result. So it is a number again. So it's like 255 if there's no match or it's 0 1 2 3 4 5 6 if we get a match. And uh we need to convert that to a string so that it's meaningful for the user. So we say weekdays equals Sunday, Monday Tuesday Wednesday Thursday Friday Saturday Saturday.

And so our weekday, our result as a weekday is weekdays index output. And then if we got that sort of 255 special value for output.res result then this will be undefined. So let's check for that. If weekday results undefined then return no match. Make sure we get the right emoji.

And otherwise we return um with a result and just put exclamation oops and get rid of this previous interpolation here. And that should be it. That should be our app. So we go back here. We can go host join like that. And so remember in our example we have Alice is available on Tuesday and Thursday and Bob Whoops.

You know Bob is uh keen but doesn't want Alice to know that. So we go submit Alice goes submit and then we calculate Tuesday as we expected. So it's the earliest day that they both overlap. Nothing else was revealed. So that's creating MPC apps. So it be slides from here on out. All right.

So one last thing about making NPC apps actually is that you might wonder you know how do I do something onchain with this because at the moment we're just kind of like learning something interesting and so the this is a mechanism that uh that I've proposed for making this on onchain I'm in the process of um uh building something with this but so what we do is we get Alice and Bob to stake into a contract so that we can then you know require them to do the things that they say that they will do basically and then we do a variation of the NPC. So in instead of calculating f ofx and y we have so the NPC uh so I haven't covered this but it's possible to get the NPC to output

different things to different parties rather than outputting it to everybody. So we arrange for Alice and Bob to get shares over the input. So they look random to them but if you exor them together then you would be able to reconstruct the output. And so from there you just do a commit and reveal scheme so that the output uh can be reconstructed on chain. And so then you know you write your solidity code so that you can interpret that and make you know whatever uh that you want to make that happen on chain.

So that's that. Um wish I could cover this in a bit more detail. Uh but I have a lot a lot of things to get through. So feel free to ask questions about it at the end and uh maybe we can uh clarify some of the rough edges on this idea. So uh I want to talk about NPC auctions. Uh so I think this is a pretty good example of kind of like a more meaty interesting valuable thing that we can do with NPC. Uh and it's something that I am actually working on at the moment and uh but yeah I'll cover it sort of more conceptually. So firstly I want to quickly cover you know uh the fact that you know we do second price auctions and you know what is the idea behind second price auctions because a lot of people

never heard of it and it's like why would you take the second price? So the idea is to kind of eliminate the game theory from auctions uh sorry from from auctions and because second price auctions do this beautiful thing where because it's a second price when you're bidding on the item you know we want to get the item so you bid you know sort of higher or whatever it is. Um you have no control over the price that you'll get which is kind of a weird uh thing to think about. And so the only thing you get to control is like you know there is this sort of hidden price based on everybody else's bid that you know you can either get the item for that price or not get the item. And so you're incentivized to bid as high as you are willing to go because the yeah like this

is the only uh outcome that comes from from bidding. If you bid any higher, the only difference that it might make is you might end up paying more than you wanted for the item, which is unconditionally bad by definition. Uh, and if you bid lower, then the only difference that it might make is that you might miss out on the item for a price that you would have liked to pay for it. So, there's no incentive to do anything except bid the price that you actually want to pay. Except it becomes a bit tricky when you think about, well, how do we actually calculate this? how you run it in practice. You know, someone like right needs to figure out like what what is the correct result here? And so there's two obvious answers to this problem. One is that you reveal it to everybody and

so people can get like upset about that information that comes out. And also like the uh like trade secret information like because you're actually bidding your bid is a lot more sensitive than it would be in a normal auction because you're actually kind of saying this is how much it's worth to me. not just like today this is how much I will pay for it. Right? So that reveals can reveal very sensitive information. And the other option is to trust somebody um in particular like the auction house, the auctioneer. And so the auctioneer probably earns some commission. And so they're incentivized to say, well, hey, if you're willing to pay 120, I might as well say the second bid was 110. You know, by definition, no one's going to

know. So that's not acceptable, right? So of course, our solution to this is to use NPC. So we can calculate this. The most obvious solution is just to say well you know we just do one big NPC with everybody which is something that we can do and so with eight bismates like you would be fine and so but the problem is that this isn't really scalable. Uh it's slow the more participants you have so you know age is fine but 800 it's like it's not going to happen. Um so that's that's not fun. Uh it also has this requirement that everyone needs to be simultaneously online. If somebody drops out, you kind of have to go back to the start and do it again. So with lots of participants, that's a big problem. So

what do we do instead? Instead, we do a series of two PCs so that we can do a tournament. And so we can do this kind of thing where, you know, each step of the way like people are only learning whether their bids are lower or higher. And so we can use this to determine the overall winner of the auction. So in this example, we find out that C is going to win this auction. uh but there a bid of 120 is kept secret but we learn this information that C is going to win right and so from here we need to know what is the second price and we do that by looking at what all of the uh everybody who lost to C um it must have been one of those people because they would have won if they're the second

highest then they would have won against everybody else that they played so they must have lost against C at some point so to solve this we just run a second uh mini tournament with our D, A, and H. It looks like this. So then we can determine that A is comes in second. And so their bid uh we get them to open their bid because we're supposed to know that A equals 80. We're not supposed to know who it is though. So we can add an anonym to say this anonymization layer to this so that you don't know who A is. And so that way, you know, you only learn the thing that you're supposed to know, which is that their bid, their second bid, they're the

second highest and that bid is 80. So you can get this verdict, right, that C wins with their secret bid of 120 uh and they pay 80 for the item. So, but there's a problem which is that you know we're doing these two PCs and when you do the 2PC the parties that are actively participating in that NPC they get to be cryptographically satisfied that they got the correct result out of it. But that doesn't satisfy anybody else. So what if uh people colluded with each other and they lied about these two PC interactions? That could it could mess things up. So in this example, if A and H lie and say that A that H was

higher out of the two, then H is only 70 and so C will only have to pay 70 instead. So that's no good. We can solve this problem though because when you complete a round of 2PC, you in order to progress the auction forward, you sign that your number is uh less than or greater than the other number, whichever one it is. And so at this point, you know, where A and H lied, we find out that H is equal to 70 and we have a signature from A saying that their bid is less than or equal to that. So now that we know what that number is, we can require A to provide a ZK proof that A is less than or equal to 70.

Um, and because if A is honest, uh, they should have no problem delivering that ZK proof. And you know in this example we said that a lied so they'll get slashed instead. So they don't want that to happen. So they're going to tell the truth. And so instead uh you know the A is revealed as 80. And instead we don't get to learn what H is, but we can require H to deliver a ZK proof that their bid is less than or equal to 80. And then when you do this, this propagates all the way through the tree.

And so we can require everybody else to deliver a zk proof that their bid is less than or equal to this winning price and uh with the exception of C our winner. And we require them to provide a ZQ proof that their bid is greater than or equal to the winning price. And so overall we get these artifacts out of the auction and together they prove that this is the correct result of the auction and nobody has to rely on the 2PC results that happened. they were just kind of stepping stones which got us to this point and that way we can do auctions and yeah we can do them onchain because we can use that onchain mechanism that I talked about before

um and uh yeah we can do second price options uh with this with this privacy and this secrecy. Cool. Which brings me to NPC cryptography. So how does this stuff actually work? Um, hopefully this is uh exciting and something that I've neglected in previous presentations, but I'm going to have a go at it. I think I think it's actually I was quite surprised with this when I first learned how this works that um it's a lot less complicated than I thought. I still actually don't really know how ZK works, but I know how this works.

So yeah, so what we do is we boil the computation down into boolean gates. This is what summon does by the way. So we take this summon program and what it's doing is it's compiling that all the way down into boolean gates. And so this way you know you don't have to do this by hand. Um but you can imagine you know we can do any computation that we like uh if we can build that with boolean uh gates. So just to make it very clear this is an endgate and the sort of traditional computation is if I tell you that a is zero and b is one then you can easily calculate that c is equal to zero.

That's an ANDgate. Okay. So, but I'm going to go through I think what is the most mystical part of NPC, which is that you're able to do a computation without looking at it. Uh, you know, that's kind of I think the one of the best ways to understand MPC is think about being able to analyze data without looking at it. And so, how does that work? Like somebody has to do the computation and so how can they possibly do that without seeing what they're doing? And so the way we do this is so in this example I'm going to be what's called the gobbler. So I'm going to construct this table on the right for you so that you can evaluate something in this case this endgate. You can

evaluate this endgate on my behalf because you're going to see values on these wires like you know this is a wire this is a wire. you're going to see values for here and but so you're going to need these kind of substitutes for zero and one so that you don't know what value it actually corresponds to. So instead of you know this really simple logic table we're going to have this logic table instead and so I as the gobler will know what these values mean but when you get like kind of one of these two values on each wire you won't know what that number actually corresponds to.

So for example, we could have numbers uh like this. So they're really small for the sake of example, but to make it secure, you need like 40digit numbers. Excuse me. All right. So the going to go through a little example. So I have these grayed out. This means that you don't know anything yet. So before I tell you, you know, you don't know anything. So I'll start by providing you know a= 67 and b= 36 so that you have these two values and so the question is you know how are you going to calculate this c equals 80. So it's a very simple idea and that is that I'm going to encrypt all of the correct answers uh for this gate and the key for

each answer is the input that would get you to that answer. So we can see for our gate here, you know, 67 and 36 which you get, you're going to be able to reconstruct this key and you're going to be able to decrypt 80, but you won't be able to decrypt any of these other values. And by figuring out which one you can successfully decrypt, that allows you to compute your correct answer of 80, but you won't know what 80 means. So I provide that. And oh yes, so like you know keep in mind you know you don't see this syntax of course you just see some like random looking numbers.

So you calculate you know your key you just join those two numbers together 6736 and you try decrypting each cipher text with that key and so it's going to be correct for just one of them. So you're going to outputs that look like this. And what we do to signal a correct decryption is we put the first half of the digits are zeros. And so all of the other decryptions are just going to get like some random nonsense. And so you won't have zeros in all of those first um first digits. And this is one of the reasons why we need more than two digits per you know per element um because you know you might get zero by random in this case but if you have 40 it's not

going to happen. Okay. So yeah, so these three you know wrong key in you get random nonsense out which means that these leading digits are not going to be zero and you can see this one is your correct answer and you can say 80 is our value for C and hey presto you just evaluated an AND gate um but you don't know what the inputs were you don't know what the output is but somehow you calculated it uh so minor problem that I want to cover very quickly is that in this example you can sort of see that you success uccessfully decrypted the second row.

And if we go back to our tables, you can say, oh, well, second row, that implies, you know, this only happens when A is zero and B is one and C is zero. Uh, so that's that's not good. The whole point was you not knowing that. So, but there's a very simple fix to that and that is that we shuffle uh that I shuffle these values before I provide them to you. And so, now in this example, so you'll get this on row four. uh but that row four is now uh meaningless to you but you'll still you know all of these won't work this one will work you'll get 80 but you don't know what 80 means so to to recap and to illustrate it in a different way when I garble an ANDgate I produce something that looks like this

so I pick arbitrary values A 0 A1 and the same for B and C uh and also do these encryptions welcome more people um I do these encryptions and so that allows anyone who has a pair of inputs they can decrypt what the output is supposed to be. So this is an endgate. Uh doing other gates is very simple. So to do an or we would want C1 uh to be here and here because here like you know if we had C1's there then you know the answer is going to be C1 for anything except when we have zero. So one or two of them are one then we get a one which is an

orgate. So uh I would just encrypt C1 in those positions and now this is an orgate. Cool. So what do we do with this? So we can join these together. Uh so in this example you know one and zero or one and one. Obviously calculate this very easily but the whole point is I want you to do this for some reason. I want you to do this calculation for me. So we can just join these together so that the in the outputs of these gates uh feed into the inputs of this orgate here. And that way I can provide you with A1, B 0, C1 and D1 corresponding to you know 1 0 1 there. And then that allows you to

decrypt these entries of these garbled gates which you provide you with these values and those values allow you to decrypt this row of this gate which means you can decrypt G1 and again G1's just a random number. You don't know what it means but then you can send that back to me and I can say ah I know that the answer is one even though I had you calculate this for me. So you might say that's cool, but what's the point? I could have just calculated this expression so much easier. You know, this is just a really inefficient way of doing this very simple calculation. So yes, 100% this is not useful yet. Uh but

I think it does answer that mystery of how you're able to compute something without looking at it. This is kind of the heart of how how that works. Hm. Um, but to make this useful, we're going to have you provide B and C somehow. So, I'm still going to provide A and D, but you provide B and C. So, how do we do that? So, back in our garbled circuit, you know, I can just provide A1 and D1. As before, I garbled the circuit. So, I know what these values are. I can just give them to you.

But then, what do we do for B and C? Right? Uh like before, there's two obvious answers to this question that both stink. Uh one is that, you know, you could just tell me what you know, whether B and C, whether they're supposed to be zero or one, and then I could tell you the corresponding value. The whole point is I'm not supposed to know what B or C are. So that's no good. And the other one that doesn't work is I could provide both B1, sorry, both B 0 and B1 and C 0 and C1 to you. And then you could just I could just trust you that you're going to forget about the other one and only use the one that you're supposed to use and evaluate the circuit that way. And uh that's no good because you know if I gave both of them

to you then you can decrypt multiple rows. Uh you can decrypt uh all of the intermediate values which means you can decrypt everything in the answer. You can choose whatever output uh you would like it to be and you can also like infer what my inputs are in many cases as well. Uh so this is a non-starter as well. So that leaves us uh with this head scratcher of a problem which is that so if we zoom in on wire B you know I know uh these B 0 and B1 labels and you know which one that you want and but I'm not allowed to know which one you want and somehow you need to get that without me

knowing which one you picked and without you getting the other one. So this is actually like an NPC problem in itself and but we have to solve it some other way obviously because otherwise it'll be circular and that just doesn't work. So this is a specialized NPC. We need some other solution for it. So uh yeah so we call this so the solution this is called oblivious transfer. So we represent the protocol like this where I'm feeding this in you're feeding that in you get this value out. Uh and I I learn nothing. I'm not able to learn anything from this protocol and you're only able to learn this.

So the way this is implemented is very similar to diffy helman key exchange. So I'll cover that first briefly. So there's a bit of assume knowledge here. I'm not going to cover how finite fields work. Um so but they're not too difficult I think. So I encourage you to have a look at that. Um but uh yeah the you can think of this as like ordinary arithmetic. The algebra kind of works the same. It wouldn't be secure to do it just with ordinary integers. You need these like finite fields. But the whole point is that we can do the same algebra over finite fields and uh get these sort of nice cryptographic properties.

So anyway, defy helman key exchange. So I pick a random secret X, you pick a random secret Y. And the point of the protocol by the way is to get the same uh secret out so that we can then do encryption. And so yeah uh we just um this special value g which is just part of the protocol. I raise g to the^ x give it to you. You raise g to ^ y give it to me. And then we both just like raise that result to our exponent again.

And that allows us to get s uh sorry g to the^ of xy and we get the same answer because of this uh commutativity of multiplication like this. And so we get the same secret out and that allows me to encrypt the message using that key. And then you can decrypt it like this. And somebody who saw this transcript, it's impossible for them to calculate S cuz you need either X or Y and only we have, you know, either X or Y. And you know, you're not you're not able to calculate X. I'm not able to calculate Y. This satisfies all the properties that we we need. So Olivia's transfer very similar. It looks like this. Um, so

you might not fully digest this today, but hopefully you can like stare at this a little bit. Uh, and it should make sense. I think it's not too complicated. So it's a twist on Diffy Helman. So uh, I'm going to present this in two like slightly different variations. One where uh, your value for B, your bit is zero and the other one where you're choosing B equals 1. So when you choose B equals Z, it's like pretty much identical to Diffy Helman key exchange. I provide G to the X, you provide G to the Y, we both calculate G to the^ of XY again.

Uh, and I calculate this other thing. Um, there's just kind of like nonsense. It's not useful for anything. And the point is you're not able to calculate that. So, but we both have this G to the^ of XY same secret that we would have gotten from Diffy Helmet. And I can now encrypt two messages, one with each of those keys. And you're only able to decrypt this one because this is our diffy helman secret. And uh so yeah, in this variation you can decrypt B 0 out of this message and you don't know this key. So you can't decrypt this one. So what do you do if B equals 1?

Pretty simple variation. So what you do is you provide this twist on your response. So instead of so you still raise g to the^ of y but then you also multiply by g to the^ of x which is the thing that I provide you which is equal to g the^ of x + y and when I get that like I can't tell that it's g to the^ of x + y I just see like a random number right so I raise that to the power of x and so but now this value is random nonsense I don't know that like I just do exactly the same thing as before but you're incapable of calculating this value and so but for s1 one, what I do is I just I basically like I undo the twist that you did because I divide what you gave me by g to the^ of x which

obviously I know because I know x uh and then raise that result to the power of x. So again I undo the twist and then do the same thing as before. So we end up with this diffy helman uh shared secret key again. And so you know you're also able to calculate that can't calculate this one. And so now you're able to decrypt B1. And the point is I can't tell what you did, right? Because I can't when I see this G to the^ of X + Y, I don't see this exponent. I just see random value. As far as I know, your value was X plus Y. And I don't know what happened. All I know is that you have the power to decrypt one of these. and I don't know which one which gives us exactly what we needed. So again,

it's probably a bit fast to like fully gro and digest that. Um, but not too much is going on. The point is that we achieve this functionality. So you can think of this as a black box where I put these two numbers in and then I learn nothing and you select which one that you want by saying B equals 0 or B equals 1 and then you get that thing and you have no idea what the other value is. So that's exactly what we need to solve this problem. So now you can get B 0 and C1 via this oblivious transfer protocol.

And so now you can evaluate the circuit as before but this time you got to provide some of the bits and I don't know what those bits were but still you could calculate it without me. And so now you can uh still decrypt this G1 value because I I picked like the same bits as like when I was providing all of them but obviously you could pick different ones. And again when you provide this G1 back to me I can say aha that's one. Um and that's it kind of. Um so this is our protocol diagram for MPC. So you know I provide X you provide Y uh and we both get to learn what f of X and Y is.

And so there's a bit of a problem though uh just briefly. So when I the garbler when I garble all of these gates you know this function f that we're supposed to be calculating it is composed of very particular and and or gates and and whatever right but when I provide this garbled gate to you there's no way for you to know that you know this is an endgate or this is an orgate or whatever it's supposed to be so you're going to evaluate this without knowing what it actually does. Uh, and that means that as the gobbler, I have the opportunity if I am malicious, uh, I can have us calculate this other function G instead.

Uh, and that function G might just like, for example, reveal what your input was. Uh, and so that's really really bad. Uh, so don't do MPC like this. Um, but the the good news is that we we can fix this problem. I don't have time to cover it today. That's kind of like the advanced MPC cryptography thing that I alluded to in the survey. Um, but so I hope to cover that some other time. And uh, but the good thing is like you know this uh, it wasn't to waste. This is still kind of the foundation that we use uh, in order to solve this problem. And uh, yeah, there is a fix. So yeah, stay tuned for some other time hopefully.

And that's the end of my talk. Um, I feel a bit nervous because I just like talked to you all for an hour. Uh, but I hope you enjoyed and I am very happy to to take questions. I'll be here kind of all night. Um, but I understand it's been a long time. So, if you want to drop off, I totally understand that as well. And, uh, yeah, open the floor to, uh, to everybody. checking a random question. Um >> yeah, so yeah, no it was really good. Uh yeah, that was really really useful. Um

it was just a small thing I noticed with the oblivious transfer. Is it possible that um yeah, if you bring that slide back. Thanks. That um someone can pro Oh, it's actually probably even a lesser question. It's just like if someone um has the uh I guess the function to do the oblivious transfer, can they uh have like multiple rounds on it? So even just looking at the simpler diagram um I think you had just just one after this maybe or before um just the black box as a black box. Can the person uh say the u on the right hand side can they uh give zero and then give one because they're in possession of the oblivious transfer or is it iterative between you

two between diagram? >> Yeah. Um so yeah it's not a problem because this is an interactive protocol. So you require my participation each time you do this. So I will only allow you to do this once. >> Perfect. Thanks. Hey Andrew.

>> Hey, >> I can see you, by the way. I I'm joined on my phone as well. >> Okay, cool. Cool. I um I I did appreciate especially the start the maths went a little bit over my head. Um but the other I have a confession. I also thought you were talking about uh the AI pro. >> Yeah, the AI protocol. >> Yeah. Oh, like before you joined. >> Yeah. Yeah.

>> Oh, I'm sorry about that. >> Oh, no. That's all right. It's another acronym thing. >> Yeah. Yeah. >> Cuz Yeah, I was Yeah, I've heard a bit about um model context protocol, >> but this is interesting like the especially the medical application and the auctions. >> I think the medical is probably more most interesting because the uh andy >> um Yeah. So, you would have got that from the website, I'm guessing. >> Yeah. Yeah. >> Yeah. Let's just bring that up for context.

Um yeah, so like you can have, you know, hospitals have this really sensitive information and so that's something that could be really valuable to analyze that data without looking at it. Um >> yeah, I think that's pretty compelling. >> Yeah, definitely. And um and then I didn't find the ballpark demo. I missed the URL. Uh so if you go to the website it's in showcase here >> and then we have a bunch of them as well and so ballpark is well it randomizes them but it's in here somewhere >> and then you can get it like that on screen.

>> I'll check that out. >> Yeah. Do you know much about um the other MCP? >> Not too much. I know like we did use it during the presentation because that was the the co-pilot the chat thing uh used MCP to talk to um what was it uh GPT 4.1 or something and then also like talk to the codebase and interact with that and >> do all of that but no I don't know a lot about it unfortunately it's MC uh MPC has consumed too much of my my memory bandwidth.

>> Yeah. I know that's fair enough cuz um >> yeah and PC and M CP but the um >> sorry >> you go James >> oh I was just going to say there's a couple of questions in the chat um yeah oh you got it there I was kind of curious about the first one too David >> um yeah so Ali's gone was there anything else no okay can you speak to the approximate years when these techniques were discover covered. Um, so I think so the the garbled circuit uh scheme that I described is um uh it's attributed to uh this guy Yao. Um I believe it was Andrew

Yao and I think that was from the 80s. Um but the like this the fixes to make that secure are a bit more recent. There were ways to to fix it and make it secure uh in the past but they were like not very fast. Um but the technique that we use which is a lot more um reasonable is I think in the last 5 10 years. Oh, and so we had another question.

Approximate computational overhead to implement things in MPC currently. Yeah. So the the implementation that I provide with MPC framework um is a bit slower than state-of-the-art um partly because we compile to web assembly and run it in JavaScript. Uh and the other but I think that's like it should only be a minor overhead. Um the other is like there's something in the like way that I've done that which is I'm pretty sure is not quite optimal. We can get it better. Um so we can do about four or five times faster but yeah sorry beating around the bush in MPC framework we can do about 20,000 end gates per second. Sorry 10,000 yeah 10,000 and

gates per second. Um and there's also a latency penalty on top of that. So the good news is that there's a fixed number of communication rounds. Like even if you do a circuit that's a 100 times uh your latency penalty due to latency is not going to be 100 times larger. It's just like the same latencies penalty which is uh 20 ping times. So you look at the number of AND gates in your circuit uh and say okay I can do 10,000 per second and then add um 20 ping times. And to give you a sense of how many and gates you need. Um so we can do SHA 256 in MPC. Uh it takes a couple of seconds on a fast network. Uh because a SH 256 circuit to do one block um is

about 20,000 end gates. And so yeah, I think we can do it in like half a second in state-of-the-art. Um yeah. Cool. Cool. Plenty fast already. Yeah. Compared to some other stuff like the FHE stuff, it's um pretty fast. And like there's a thing with like FHE, I think. Um, something I'm really interested in but haven't had time to explore so far is um, we can do something similar to FHE with NPC where if you're willing to trust at least one out of N servers. So

you have like this kind of uh council of of servers and as long as you trust one of them then it's secure because what you can do is like you can have a bunch of different participants and you can use this to do like way more participants than you would otherwise be able to support. Um what you do is you provide a secret share over your inputs to those servers and then those servers can do MPC just like that with each other and then uh give you the result uh back uh when you come. So as long as one of those servers is honest then uh nobody will be able to learn anything else and it's non-interactive for the participants. It's only the the servers which is very much like FG.

So trust in what way? Like you're trusting them to do the correct computation or you're trusting them with with uh different values? >> Yeah. Um both. So because you provide a secret shares uh for your inputs to all of the servers. So if all of those servers simultaneously were malicious and willing to collude with each other, then they can reconstruct your inputs. >> Thanks. But yeah, as long as one is honest, then the rest can't do anything. Cool.

Oh, yeah. See you, Rendle. See you Tim rather. Um, cool. So, yeah, happy to take any more questions, but uh I won't uh let the silence go on for too long. So, speak now forever. hold your piece or contact me any other time. I'd be happy to help you as well. So, more to the auction WIP stuff. Uh, yeah. So, I mean, it's open source. You can have a look and follow along if you like. So, I've written the circuit um the main circuit anyway. Um for voltrio slash I need to to move this

private options. So we have circuits. So for comparing two bids there's like this light version that I have for testing where you just provide the bids um and then it's well it defers to this compare two bids function. Let me bring that up. Util uh compare two bids. Yeah. So there's a tie breaker here. So because you know what do you do if they're equal, right? So basically both provide a random number and then it switches based on that random number and that decides who wins if it's a tie. And so yeah, we just do this comparison here

uh then figure out, you know, whether party one wins like that. And so but then there is this like uh onchain linkage stuff to do. So for the full version of this circuit we have a full version which does a bunch of extra stuff. Um so for example a really important thing is that like you know in a kind of vanilla MPC you can just provide whatever you like into the circuit. So, one of the problems with an auction uh and splitting it up into these 2PC calculations is that like we need everybody to provide the same bid each time that they're taken into these different rounds of uh 2PC with different people. So, what we do is we require everybody to publish up front

the hash or rather a commitment um to what their correct bid is. So, you have a salt and then your bid and you hash it together and then that hash is public. Uh and so then when you go into these MP into these two PC interactions, uh you provide the um well the other person provides the hash and then inside of the circuit it can check that that bid with the correct salt actually does correspond to your bid because the the hashes match. Um and we have to do some more hashing stuff for the output as well when we're checking to make sure that the output is correct and uh yeah that good stuff. Um,

yeah. Is that does that answer your question? Was there something else that you would like to know? I'll bring the slide back up. Um, like this thing. Yeah. Uh, specific use cases in mind already. Um, so we're interested in taking this to like real auction houses actually. And so the idea is like we can onboard people into crypto by saying like hey you could participate in this auction uh this crypto way if you like. Um and this could uh make the settlement a bit easier because you know you can uh participate potentially like you can just kind of put up a deposit um you

know via crypto and then hey if you don't win the auction then there's no other paperwork for you to do and if you do win the auction then maybe do some more paperwork um but you know you only have to do that if you win the auction uh stuff like that. Um thought about that in terms of applications and whether like there's this sort of terrain of trust assumptions like if you're trusting some entity anyway like to operate the auction then uh well you can almost go as far as saying well if we trust them anyway just do it in a centralized in a regular way. Um but yeah, I think this is going to open up that in between to say, well, we trust him to an extent, but we also want some maybe more of verifiability or or something else.

>> Yeah. >> Like we can we can blend the two together. So some people would prefer to just like, hey, I don't want to install your app or whatever. I'll just do an auction normally. Um and but then we can mix people in who are like, oh no, I don't trust you and I am willing to do crypto stuff. then those people can interact with each other and hopefully more people will adopt crypto um because it's like oh hey this totally works you know and I could just you know not reveal my important information and reduce my paperwork and all that stuff >> and hopefully they don't have to know that it's crypto under the hood it just they sort of just get the benefit somehow >> yeah it's just a different secret box that does you know different kinds of

cool things Um, what has David got in the chat? Uh, specific use cases. Oh, it has its scale. Yeah. So, the cool thing about this auction thing is that it's like, you know, completely parallelizable, which means that it's basically just, you know, the number of rounds that you have to do these tournaments is like logarithmic in the size in the number of participants. Yeah, exactly. So yeah, you can totally do like a million participants and it only takes uh 20 uh of these layers, which means that it only takes 20 times as long uh to do it, which is uh pretty cool.

Nice. Yeah, you're never going to do a million parties in one NPC. I mean, never say never, but like I don't think so. Oh, 3:00 a.m. Oh, man. Respect. Thank you for staying up. Um, oh, that's what I want to hear. That's awesome. Um, yeah, we should jump on a call some other time that uh where you can be fully awake, can explore something. I was really interested to see your stuff. So, David, I believe so, you're doing the uh like

crypto voting stuff. Civ.org, I think it is. >> Yeah. Nice. Cool. Yeah, let's talk about that more sometime. All right. Going once. going twice. >> All right. Thank you everybody so much.

>> Uh yeah, I'm glad people could make it. I wasn't sure how many people were going to be here. So yeah. All right, I'll stop the recording.