 All right, let's start Welcome everybody to the last session of today. We will have two more interesting talks The first paper is by Aglos Kyayas Hongsheng Zhu and Vasilis Zikas and Vasilis will give the talk Thank you very so This is about fair and robust MPC using a global transaction ledger or An alternative title using cryptocurrency blockchains So this is joint work with Aglos and Hongsheng and The main question I will try to so address here is what is the functionality that we get from such a ledger-based cryptocurrency from a blockchain So what can blockchain give us that we can use in crypto and in this talk I will use Bitcoin and ledger-based cryptocurrency and blockchain all interchangeably So whatever statement I make whenever you see Bitcoin it applies also to any ledger-based cryptocurrency So the two main functions of such a cryptocurrency are a public transaction ledger Which can be thought of as a bulletin board with a filter of what can go in and some economic stuff that we understand way less than the transaction ledger and they mainly have to do with the fact that in there is some monetary value in contents of the ledger and People whether good or bad whether good or adversarial want to make money So this is based on a on a on a basic principle of the economic theory that when it comes to money people are rational Of course, there are exceptions in this rule but this in general is a good rule and by the way Disclaimer, I'm not you know making any statement here since I want to go back to the US after Europe Okay So let's start with the public transaction ledger. I Claim that the core security goal of Bitcoin is to ensure that all parties can establish a common and irreversible view of the sequence of transactions, so if you have that we have a cryptocurrency and This is what in a recent paper by Garay Kiyas and Leonardo's was called the backbone property of Bitcoin and Again, whenever I say Bitcoin, I mean arbitrary cryptocurrencies So our first contribution is to capture this security goal by means of an ideal UC functionality a transaction ledger functionality. So How does this look like? What is a transaction ledger? It's a functionality that has an internal state That can be queried. So anyone can ask for the state and it gets back the value the current value of the state And it can be updated anyone can submit transactions when a transaction gets submitted it gets added to the state So this would be sufficient for any cryptocurrency actually the existing cryptocurrencies have slightly more functionality than that They even implement a filter. So they have a Validation predicate says that when a transaction comes in it goes to this predicate this predicate takes the value the current value of the State and decides whether this is indeed a valid transaction or not if it decides that it is then the transaction gets added to the state the state gets updated So that would be the dream goal of any cryptocurrency. Unfortunately, we don't know if Any cryptocurrency that satisfies exactly this goal. There is some adversarial influence in existing Conductions and this has to do with the fact that there is a guy There is an attacker that can reorder recently inserted transactions. So how can we kind of incorporate this into the model? Note that the way we have it there recently inserted we cannot decide whether it's recent or not So what we do is we add to the model a global clock this is just kind of something that gives us a counter gives us a causality of events and To distinguish recently inserted from Older in certain sections we split the state to two parts This is what we now will call the state is a part that cannot be changed The adversary does not have any influence on and if you know something about Bitcoin this Corresponds to transactions that are deep enough in the blockchain. So they cannot be changed and The other component is the buffer Which can be influenced by the adversary now when a transaction comes in it goes again through the validation predicate the validation predicate Takes both the state and the contents of the buffer and Decides whether it's a valid transaction or not if it decides it is it sends the transaction to the buffer not the state Right the transactions this gets the adversary gets informed about this or the adversary knows both the state via the standard querying Sequence and the contents of the buffer and now he's allowed to permute the contents of the buffer So now the natural question is how do? Transaction get from the buffer to the state What happens is that periodically in our modeling with every activation? The ledger queries the clock to see you know what time it currently is it gets back the value of time and Every let's say t steps it invokes a special predicate which we call blockify So the role of this predicate is to go and fetch the contents of the buffer Massage them a little bit so that you know different cryptocurrencies have different ways that things Getting started the state maybe throw some back in the others are flashed and they're put into the state so this is our abstraction of a transaction ledger and Having sets an abstraction we can now start discussing about cryptographic protocols that use the blockchain and in particular use this ledger functionality of the blockchain and those are simply Protocols that are in the g ledger g clock hybrid model. They have hybrid access to those two functionalities the ledger and the clock So this allows us to immediately get the composition theorem because now we're working on a well-established composable model But looking at it you might be wondering, you know Why is that more useful than just having a broadcast channel, right? I could do whatever the ledger gives me just by having stateful protocols in a broadcast channel whenever some transaction I wanted whenever I wanted to put some transaction in I broadcast it to the network and You know the validation is done locally by the parties Actually, what makes Bitcoin? more interesting for the for crypto is this economic stuff and based on this economic stuff, we actually have some better notions of Secure function evaluation in this case. So what is secure function evaluation? I will just go briefly because there were already some NPC SFE talks We have n parties Each party has its own private input and they want to compute some function f in an ideal world The parties send their inputs to f f performs a computation and returns the outputs now in the real world the parties do not have such a trusted party do not have such a functionality and They but they could communicate over some network and The goal of an SFV protocol is to emulate the behavior of this trusted party So we want the protocol to have the same output of the parties even when some of the parties misbehave and Cheating parties should not get more information than what they would get by the evaluation of the function namely no more than the output Okay, so now when do we say that such a protocol is fair? intuitively when the following holds if the adversary gets any information from the computation More than what he can deduce by his own inputs than every honest party should get the output and To give you some intuition of what this means. This means that this situation Cannot cannot occur so it cannot be that the adversary gets the output and the honest parties do not get it So this we would call an unfair situation From early results from 86 cleaves result We know that if we want to have security against arbitrary corrupted majorities Then fairness goes out of the window. We cannot have fairness for crowded majorities So because we do want to have protocols for crowded majorities What we usually do is we consider a discounted security notion, which is the so-called security with a board And in this security notion the adversary is explicitly allowed to provoke this situation there So he can get the output and make the honest parties a board. How can we use this? Monetary this connection of the of the of the transaction with actual money to Make this a better get a better solution for this problem. This idea comes from Driechowitz, I think et al And we hope it's I was close, okay And we hope it's et al and the idea is that we can actually Use coins we can use money to leverage this discount that we do on security And this leads naturally the notion of SFE with fair compensation Which says that as before if the adversary learns something more than his inputs then Every honest party should learn the output Or he should get money from the adversary So if we think of the scenario had before The motivation is as follows So why is that situation unfair because if the adversary gets the output and the honest parties do not get the output then? Obviously the honest parties are unhappy and the adversary is happy like very simplistically If we add coins to this picture Suddenly the adversary transfers coins to the honest parties when this happens and now the next parties Provided that they value coin a lot. They are happy and the adversary is you know at least skeptic He's given away money and this situation will call fair Now if you think of the adversary kind of having some incentive not to give away money Then you can easily see that this situation is a deterrence factor for the adversary to provoke and unfair abort right because he's losing money So actually under assumptions on the adversary being rational this will yield a fair solution because adversary will not abort so How can we get a protocol which has this guarantee? This was described in the generality of SFE for any function by bent of encomaresan in two consecutive papers 2014 and 15 and I will just give you the high-level idea here the protocol proceeds in two stages in the first stage the parties compute a sharing an authenticated sharing of the output of the function that is every they compute the following functionality functionality takes inputs from The parties computes the function but doesn't out with the function it outputs a sharing of the function Which is authenticated so every party receives a share this air has no information on the output But he also receives a signature for which he doesn't know the signing key So he cannot lie about his share It's easy to see that when this is a situation then if we abort at this point we haven't violated fairness, right? Why because the adversary has received nothing. It just has a share which gives him no information So now the tricky part is to reconstruct the share in a way which is fair with compensation as we described before so either the output will be constructed or parties will get compensated and There is the block that's where the blockchain will help The idea is to proceed in two steps in a first step Every party PI Makes a transaction towards every other party PJ All other parties PJ Which is as follows PJ can claim can spend this transaction can spend the coins that are transferred to him Only up to a fixed round Remember like Bitcoin gives us time we have time with the ledger so we can put a timestamp there only up to some time and Only by announcing his valid share announcing a share and a valid signature on it if The receiver PJ does not announce his share by round Roy J Then the money get the money get refunded to the sender in other words after this time the sender can spend the money unconditionally no need to announce So having done these transactions The protocol procedures fellows every party claims the coin that were addressed to him by just announcing his share Right by by the round Roy J each day will just broadcast like put on the ledger a transaction Which includes his share in the signature and this way we collect all the money from all parties So it's relatively just to see that this protocol achieves Security with fair compensation just by kind of following the money if the adversary Announces all his shares right if he collects all the money then what happens is that in the first step of this Reconstruction process everyone transfers and coins one to each party and in the second step Everyone collects and coins one from each party that's sending to him and Therefore he has zero balance and since the adversary has announced everything. He has the output Now if the adversary does not announce a share Then what happens is that he doesn't collect the coins corresponding to the share These coins go back to the sender and the senders now the honest senders have a positive balance So they won't have their output because the adversary did not announce his share But they will have more coins that what they started with So this is the underlying idea of these protocols and it does indeed get Security with fair compensation, but it has an issue and to see the issue It's it's it's constructive to see kind of the timeline of this protocol So here's how the protocol proceeds with time At some point the protocol start let's say a time zero And it starts computing the sharing of the output of the function, right? Depending on the protocol we're using this might take a few seconds after a few seconds Maybe minutes depending on what we're using but after just a little bit of time the sharing is computed Everyone has his share and now they start making the Transactions of the first step that can be then claimed by announcing in the end they make the transactions They can act upon these transactions only when these transactions are actually solid They cannot be changed so only after they're in the state, which is roughly one hour later and at that point they can start claiming their transactions and Several hours later, they will have the output or they will be compensated several is a constant in the is a linear in the number of parties in the first papers and Constantly this in the in the letter papers so This is good. Looks like we have everything that we want but notice the following What happens if the adversary at this point simply doesn't make any transaction? Right, we compute the sharing and now we're about to make transaction the adversary doesn't speak The parties can only act upon this behavior After it's steady and agreed upon which is only after an hour. So I have to wait for an hour to be sure that everyone has recognized this behavior and You know they can actually reclaim everything after several hours We could bootstrap this to reclaim already after two hours or something, but still what have we gotten the adversary? Just aborted with a single party the parties have wasted all honest parties have wasted two hours of their life doing nothing No compensation. No output and if we try to kind of bootstrap this You know what we could trivially do would be you know detect Who was the party that aborted and restart? But since we want to tolerate corrupted majorities in the worst case we will restart linear number of Hours linear number of times each time we restart we need to spend an hour. So linear number of hours Which is way more than parties would be willing to take so if we look again at the motivation of fairness with compensation Now we're in a scenario where parties not only don't get their coins But they wait for no reason and they wait really long if they really want their output and They're pissed for that On the other hand the adversary has succeeded right he has done what adversaries do they has disrupted the computation He has done a successful denial of service attack and he's more happy than before even so This situation is not clear whether we would call fair. So it definitely is not a clear deterrence factor for the adversary. So in this work we introduce SFV with robust compensation where the idea is Just strike out the conditional statement from SFV with very compensation. We want Independent of whether the party the adversary gets his out or not every party learns the output or gets money No matter what? Once the protocol starts the protocol will terminate either with output or with money from the adversary to honest parties Now the question is can we get this robustness fast? I said just before that we can get it by rewinding like in a linear number of hours Can we get it a constant number of hours or just as fast as we would we would need to run any semi-honest protocol the answer is yes, and I will demonstrate so what we have is a compiler that takes any semi-honest protocol pi and Transforms it into a protocol with robust compensation, which satisfies the the property I described before so our compiler Kind of imitates the GMW compiler if you don't know what the GMW compiler is doesn't matter I will explain what the compiler does here. So what we do is we start with a pre-processing phase Does not have any bitcoins and there's no fairness included there and in that phase we compute a setup Which includes coin flipping essentially it includes parties being committed to the randomness for running the protocol pi and then in the first round of the protocol Every party for every round of the protocol pi makes a transaction towards all other parties and PJ can spend his corresponding coin that is That should be for round R by first of all posting something in round R and by this something including a valid Pi message and Non-interactive general let's prove that this is a valid pi message So this is the first step So now what parties can do is similarly to the solution that we had before they can Start claiming the coins that were addressed to them by simply playing the protocol on the ledger Just post their next message on the ledger and this way they get back the coins that they send So it's easy to see that the validation predicate actually what it does It just checks that the that the parties that post transactions follow the protocol So it's either you can think of it as a party running the GMW protocol with no input Or just as an observer of the GMW protocol that looks that the general is proofs are correct Okay, so now why is that protocol? Why does that protocol achieve security with robust compensation? I will start with it with the easy case So Let's assume for a moment. So I'm now kind of swiping away the problem But let's assume for a moment that the adversary Correctly makes all the committing transactions in round one all those conditional transactions that can be claimed by parties make Running the protocol in that case again security follows this by you know following the money What happens is that every party for every round makes a transaction to every to all other parties where each party can claim by playing his protocol So if everyone now Plays his protocol everyone claims back the same number of coins that he He transferred in the beginning and if the adversary doesn't play the protocol He won't claim his coins for the round that he doesn't play they will be refunded to the actual sender. So now the trickiest Scenario is the one in which Some corrupted party does not Make the transactions as he's supposed to and that was kind of the similar scenario we had before right where the adversary Just aborted before making the transaction And it might kind of look that we have a similar issue as before but we don't And the reason we don't is that we can tweak the validation predicate so that it does the following it looks at the transactions that were posted in round one and Splits the parties into islands that made consistent transactions mainly that made mainly that they made transactions For the same setup and for the same protocol continuation So now all honest parties will post consistent transactions So they will be on the same island and now what the validation predicate will do is it will run as a fee And it will observe as a fee independently on each island Right, so now the other side has two options either he can go play with the cool kids right with the honest parties and get the Output or he can just play with his own parties and get nothing because if he's on the island of the onus of the honest parties The output will depend on his value if he's not the output will depend then just on the values of the corrupted party and Therefore it's fully simulatable so this is a very rough intuition of the protocol security and I don't have too much time or so I will summarize What we what we did here is we gave a generic description of a transaction ledger as a GUC functionality Because it's a GUC functionality We have the first composable model for security with fair and with robust compensation and ocean that we introduced We describe a compiler that compiles any semi-honest protocol to a protocol Which is secure with robust compensation and has the same number of rounds as the semi-honest protocol But now on chain so the same number of hours as rounds in the semi-honest protocol And of independent interest actually we we have a full-fledged Synchronous model in the GUC setting with a global clock Which could be very useful for designing synchronous protocol that all have the share the same clock and With that I'd like to thank you Any questions quick questions So in in the drawing in the first version In your in your diagram of the first version that the previous work And it looked as if as if each round in this revealing of the shares took a long time because you had to wait for the transactions to become stable So in your solution now when you do the speech one of the actual protocol Does this mean now now we each round in the compile protocol takes an hour? Yes It's round takes an hour, but the trick is that At the end of the round I can look at what's on the ledger I meaning the validation predicate and split the parties into parties that did executed this round and parts that didn't so I can go on So the whole point is that I don't I never need to restart As soon as I start making transactions, I will go until the end Yeah, is there anything that prevents the islanding solution from being applied only on the last round to to essentially get Get your recovery on the previous scheme. Yes The the of course there is the thing is that what do the previous things schemes have they have a sharing of the output So as long as someone drops off Whatever the other parties have has no information on the output anymore So there's no way to bootstrap and go on from that. You need actually to make the entire computation at the beginning Right, what did you have you had a sharing of the output? That's all you have unless you use your inputs again, which means running again the protocol you cannot do anything Okay, no more questions and let's thank the speaker again and and we move on to the last talk