 Hello, guys. Good morning. Is it okay? Everybody can hear me back there? Okay, good. Well, my name is Mario. Some of you know me, some don't. Well, my name is Mario. And this talk is about our work with gambling protocols. More specifically, I will talk about the kaleidoscope and Royale. There are two card games. One for poker, one for more general ones. And I was talking to Petra about the layout of the main slide. By the way, this is the work with Bernard David and Raphael Gosly. They are over there. They are co-authors of the protocols. And this is kind of a rehearsal, actually, because it's a good thing, it's a bad thing for you guys. Since I will be presenting this next week in Japan, this is kind of the practice. That explains the Japanese title. And also, that's the bad thing. We are giving you a peek of this presentation. But also, this is the chance to get the more raw content and eventually some mistake. But I hope not. So the presentation is kaleidoscope and Royale, poker, and general card games, card game blockchain protocols. In Japanese, it's kaleidoscope, Royale, poker, and general card game blockchain protocols. So this is the official name for the next week's presentation. And just to explain the logos, this is our research group, which we are related in Tokiotec. And this is the Tokiotec logo. And this, of course, is our logo. Okay, so let's get started. The roadmap of this talk. I was asked if it would be highly technical. That's the dilemma that I was when I was writing it. So there will be a taste of some technicality. But I hope that you guys, by the end of this talk, just get a sense of what exactly is the scope of the kaleidoscope and also the Royale with a little bit of crypto in it. So, but first, we'll talk about this area called mental poker, which started back in the early 80s, late 70s, I guess. So in the last summit, last year, actually, we did a survey and a presentation on that. So I'll get back on that. Then it's a long area, or research, over 40 years. So, but we'll focus on the last works. Why it matters, why it is important, and more directly why we are doing it. And then an overview of the two protocols. And kind of a crash course on poker because after all, this was part of our research. We had to go to the rules of the poker and one kind of specifically. And then, so I'll review it so it makes sense why we did some stuff that we did. Then we go a little bit deeper in the kaleidoscope protocol. And then the oil. Okay. So I hope you guys like it. I'll try to make a little bit technical but a little bit over an overview. And so just take a sit and relax. And please, if you have any questions, I think we have plenty of time. I think one hour, the time is lies. I don't plan to talk the whole time. So if you guys are curious about something, feel free to just ask. All right, so the mental poker history, as I said, it started in the early 80s by the Eversay guys, Shamir, Edamon, and Rivest. I guess this is their original paper or one of the earliest versions. You can see that the layout is not exactly what we see today. And it's a little bit funny. So this idea of... Usually the proper way or the way people do it is to play cards physically in the same room, the same table. So the idea here is that what it's not possible so people are far away from each other, how they would manage to do by, for example, playing over the phone. So this idea of you not seeing your partner, the other people playing with you, how you're gonna do it, for example, how you're gonna shovel cards and if nobody's looking at you or checking what you're doing. And if you receive a cover card, how you're gonna do it to open it and you are distributing cards for someone else, the dealer, for example, how you manage to do it because you are playing alone over some long distance with someone else. And this kind of a challenging thing and it captures some protocols, some tools of how you're gonna do it. So that explains why people are taking a look at this and trying to do it since the 80s. And the early attempts, some of them got some kind of formalization, so what you need to do and collect some properties, for example, in the 86, Kripo tried to list some properties, what you need, what you don't need in order to succeed in these tasks. And it's kind of a long list, but not that long, but it was the first attempt, but it's not actually a formal definition in the modern sense of it. A little bit later, not so bit like early 2000, some different problems which were not considered. For example, if you're playing and, for example, you receive a card, a hand of cards that is not good and you just leave, what happened with the others who were playing, what happened to the game. So this is a kind of a problem which was addressed by Castella Roca. I think we have some problems in there. So in the sense, there's a lot of gaps in the security formalization of such protocols. And also efficiency problems. So there were some attempts in the beginning to try to get those early protocols and implement it, and there are some reports that the processing of the shuffling of the cards will take forever. So that's where the problems that they were having back then. Well, above this history, as I said in the beginning, there was this survey we did in the last summit in Malta, and I believe there is a video on that deep in our channel. So it's internal channel, so I guess you guys have access if you want to pick in the details of it in the list. So here is the video. Okay, so that was the really old papers about this area. More recently, the ones that we are most more focused is about the... especially in this case, is the problem that I mentioned that if a player just leave the game in the middle of the playing, what happened? This idea is not exactly about poker, it's about protocols. Zimbosk introduced this idea of penalties, which means basically that it does not directly address the problem of leaving it early, but it kind of makes you not very profitable to just stop the execution of protocol. And it proposed the idea of penalizing the players. Basically, you put someone there, if you stop it, you lose it. So that's the main idea here. And now a little bit more related to poker protocol is that we have this presentation on Asia Crypt last month, which kind of have this... Both of them introduced... this idea of moving funds and the one in Asia Crypt has this suggestion of using it for poker, but also it's not exactly... there are some security issues there. So these are the ones that we kind of focused more in our work, so just recalling. The first one introduced this idea of penalties and those two works below here. They did have some progress regarding implementation, but still they have... they lack some kind of strong security model. So there is... they build a framework but when it comes to the poker, for example, there is a little bit of gaps in terms of formalization and security. So, okay. So there are a lot of work on that but why it matters, why it is important for us because, for example, now we have this starting appearing casinos online, for example. And it has been noticed that it's a huge market. And we start seeing this kind of articles in financial magazines and I have one here in the Economist magazine. This is, I think, it's from 2007 and describes this trend. And the problem with this right now is that you have this institution, this company over the internet that you have to trust in order to play along. And this is something that we are trying to avoid. It would be nice if we could do it without this... just relying on the protocol and security guarantees, not trust. And why is that? Because there were some reports of incidents like flaw in security or redness, this kind of thing. Or just cheating. So what about the other protocols? I mean the previous ones. As I said, we need more strong, the stronger security guarantees and models for that and we don't see that in the old protocols. And another problem that I didn't mention is that for example, before the advent of the blockchain the mental poker was just a game. So what do I mean by that? For example, there is no stake. You just play along and if you don't like it, you just stop it and you don't lose anything. There is no... You are just kidding. But when you play along with the blockchain then you have some financial consequences of your playing. It's a little bit more serious. So... So then we have our two protocols and I'll give overview of them here. Then I'll go separately. So the first one is the kaleidoscope. It's basically... It's a protocol only for poker. And it is... And here I would like to thank Agatas because I'll just keep the terminology but you have already introduced what a simulation-based security in the previous one. So I will skip it. We didn't plan it but yeah, thank you. And... So the security has a strong guarantee than the previous one because it's a simulation-based proof of security. And recalling the Zimboski work, we also rely on rewards and penalties. So why is that? Because we don't... We want that when you're playing and for example, you receive your cards and it's not a good card, it's not a good hand you will think twice to just leave the game because you have consequences if you do that. So... And then this is kaleidoscope and then we have Royale not only for poker. There's a few more good things, qualities, properties but I will first recapitulate the kaleidoscope. So one more thing is that we... It's a simulation-based security which requires a strong definition of what is a secure game. And this work in comparison to the other the literature is that we introduce a secure definition for poker. Again, I'd like to thank Aguilos because he started mentioning functionalities, ideal functionalities. So technically we introduce the first ideal functionality for poker. So that's what it means. I'm skipping a lot of details here but yeah, we got the first definition for poker. And the setback is that the kaleidoscope is only for poker. It's tailor-made only for poker. That's why it's fairly efficient in comparison to others. And here again another concept that we... I'll just skip but the details just mentioned but it was already mentioned in the previous talk which it's not universally composable. Because what it means is that the protocol for poker actually is a set of sub-protocols. So you have this protocol to shuffle the cards and then the game starts. You have to have this sub-protocol to open the cards and make the bets. So actually it's several steps in sub-protocols. I'm calling it sub-protocols. And since we have this monolithic definition for poker we don't foresee how to compose them. It has to do with order because of the definition. So we do not address the composition of it and the combinations of them except for the one that described in the definition. So this is a limitation where Indemy Royal actually addresses it and it is universally composable. Because it's more general because it's kind of a modular because it has to be general for several card games. So we need it to be universally composable. So this is the difference between them. And the similarities that they are they can be officially deployed, implemented. Okay, yes. So it sounds like Royal is just better than kaleidoscope. Because we did it first. Actually the idea of the Royal cable. I don't care about kaleidoscope. I just want to learn about Royal. Okay, yeah. Actually they are very similar. They are very similar. In the end we realize that we could do better using a lot of the bases for the kaleidoscope. But we'll get that, but yeah, you were right. We can go directly for the Royal. But we did it first, the kaleidoscope. I think yesterday the brain exploded. I won't actually make a statement. But it's going to be easy to study. It's going to be something that is very specific. The modeling is easier for the kaleidoscope because the rules are very well defined. It's not general. If you go to the proofs and the definitions, it's more straightforward. It's a bit simpler. It's not mental paper scissors. If you look at mental rock paper scissors, does that leave out anything important? Well, I didn't think about it. But it seems easier for the Japanese mental rock paper scissors. Because you have to commit to something and then open it later. So it seems much simpler actually. Because you have to shuffle cards, for example. You have a lot of cards and you have to shuffle them. And you have multipliers as well. We'll get into that later actually. And also, because in Japanese, the name of the game, you have to play just two people. Right? So in terms, in poker, you can bet then also. But in poker, you have several people and you have cards in the case of the Texas holding version of it. The community cards, you have to open it and you have to do it jointly because you cannot open arbitrarily because you can cheat then. It's different from the consensus thing because you don't have this half of the people to trust. Actually, you cannot trust anybody in the case of mental poker. So there are these differences that I remember now. That's really helpful. Because once we've done rock paper scissors, we must do poker holes. I guess Bernardo has something to say about it. Additionally, there's a very important difference between rock paper scissors not only poker, but many card games in that you need to prove that you won't but you don't want to reveal your strategy. So the way you represent cards and you prove that you have one or more specific cards without revealing your other cards is a significant complication in relation to rock paper scissors where basically you reveal all your randomness by doing the protocol. Because we think like lotteries we just have the problem of sampling some randomness doing something with it and then revealing the whole thing. In card games, you don't reveal all your randomness only parts of it. You need to prove that it's consistent. So that's a very important complication that brings the... We need to use many different techniques to actually deal with this than just for something where you need commitments only. So that would be a fundamental difference in the protocol. Another card game that we are looking into which seems to be much simpler than poker is Blackjack. And it's maybe more close related to lottery and just to relate to randomness. And actually this about the strategy, there was some previous protocols which in the end of the game you're supposed to reveal your randomness and you used. So this is a bad thing because as he said because in the real poker sometimes you don't want to open your cards because you don't want to show them that you're bluffing or not. So people can start grinning their face or something. There was a problem. Some of them I don't recall which one but in the end to make sure everybody played fairly you have to open it then you end up revealing. What do you mean? Show it what my face looks like. Guess I'm bad at it. Yeah, no, you don't need. Okay. So, well, this is an overview of them. So now it's time for a crash course and I don't know if everybody is aware of it and there are several details that I'm skipping here and don't remember it actually myself. This is, the kaleidoscope is based for the Texas Holden version. I think there are several of them and they differ in the number of cards and I think you can adjust it. So, you have this diller which is one of the players they rotate in the table, they shuffle the cards then each player receives two cards and then the, maybe the order is a little bit different but the next two people to the diller they'll make like blind bets they'll usually they differ by half of the value which they'll put the money in the table and then the diller will put like three cards in the table like they are open so everybody see it and then all the players start doing actions, their actions accordingly in order so they can increase the bet or do nothing or just redraw and they are out of the hand. The idea is that every round everybody who's continue playing put the same amount of money in the pot and after we set this round the diller will up an extra card up to five. So after all these rounds and five cards on the table if there's one player he, she will won but if not they will show down and compare the results is there anything okay so far it's basically that is the rule if everything is okay then congratulations we are expert poker players and we are ready to go to the kaleidoscope okay so first of all something that sometimes some question that sometimes shows up is that where the name comes from it is actually from a movie from the Sixties and it's a movie about poker there's this guy like I think the actor is there Orham Beatty he kind of go to the factory of the all the cards in the city Monaco I don't know the remembered city and he like marks the mattress the metal one that the machine that make the card so he can after that he can all the casinos in the city he can read the cards from the back so that's the plot of the movie and I will not tell the rest of it so the idea here for the kaleidoscope is that on each of those rounds that I mentioned in the last slide is that all the the players they generate witnesses proves of what they did so they will work as checkpoints for the game and in the beginning also in relation to the Zimboski at all paper the players are supposed to put the money in the beginning as a collateral so this is the guarantee that they will behave because if they don't they will lose this amount of money the disputes and in the end is actually this is the first when they start with the money is they interact with the blockchain and then they don't need if everything goes well they don't need to interact with the chain unless there is a problem so if there is a problem they can go back to the chain and resolve the dispute via smart contract so as I said each action drawing a card shuffling is what I mentioned here as a sub-protocol of the kaleidoscope so what I mean by that is that when you need to turn a card you need to interact with everybody else to help open the card ok so here is I will try to just give an overview of the building blocks the crypto building blocks of the protocol one is the Elgamal threshold encryption and this is what I was saying in the beginning that I was a little bit in dilemma how deep I should I first put this straight forward from the paper the definition and I think it's a little bit dry to do it so I will just give a description like overview description brief description of it so here it is so we have this players they have the secret key and they and this public information H1 here is the public information and the secret keys they will just release those H values and approve knowledge that they do know the value which generates the H values it's basically a G like to the secret key so this guarantees that they do know the value ok so the public key actually is generated by multiplying all the H values and then if you want to encrypt a message which will be used for each card you get a message use the public key and some fresh randomness the so ok so how you decrypt the message you will compute some shared information from this part of the ciphertext using your secret key which everybody has and you also provide every player provide proof of equality of the discrete log which means that you are like proving that this exponent is the same of these two exponents without revealing it that's the important part so you can decrypt it so this will be equivalent later to open the card one nice feature of this scheme is that you can re-randomize the card this is also crucial so with fresh randomness R prime you just reshuffle it ok so that was the Elgamal threshold scheme here is also an important block which is from Bayer and Grove from Eurocrypt 2012 so this is actually how we do the shuffle of the cards so for example a deck of cards will be represented by like a set of ciphertext 52 cards and then this actually seems a simple problem but there are some details so you have to take a closer look because simply you just need to shuffle change the positions but you choose a permutation and you just do the the permutation you executed but the problem is you have to also as I mentioned re-randomize it because otherwise you just compare and you guess the permutation so you have to re-randomize and change the positions but that's actually not enough bad values and since it's randomized nobody will see it, it's spotted so that's why we need this machinery to do it properly so we need to everybody who is shuffling the card needs to provide this proof of correctness of shuffle so that's why we need it seems a simple problem but actually it's kind of technical we need it properly otherwise you'll just mess up the game and nobody will spot it who did it so how is the shuffle for this using this tool so we have the people the first one will do the shuffling and provide this is the proof of correctness that I mean from here so and then it will shuffle it, give this proof and then the others the second one will receive the shuffling for example the first one here and then do its own part of the shuffling so it will do it again and again until the end so everybody has to do its own shuffling so each one of them will be assured that it's done properly so basically that is the shuffling part so another part which is important is that we have to guarantee that nobody will for example leave the game so as I mentioned before the idea is that you put your money as a collateral so you have this contract in the beginning so all the players all the people who wants to play they'll put some coins in it the contract describes the checkpoints required for the game to progress and then as the game goes along or the people will keep those witnesses and checkpoints and if needed they will use it to resolve a dispute or in the end or when people are leaving they will show it that the game was done properly and they will receive their coins with a new balance because some people lose so it's done by the contract ok so here is just an overview of the sub-protocols so we have this check-in check-out which will require the contract then we have the hand execution which is basically the game itself which will shuffle the decks place blinds and draw a private card or open the community cards and it will require the other two blocks that I mentioned here is where they are used and in the end the pot distribution I mean the rearrange of the balance and an eventual recovery phase also requires the contract so far so good so this is an outline of the whole protocol I'm not getting into each one of them it's just the overview there is a whiteboard presentation which is available in our YouTube channel Bernardo gave it in our office it's available in our YouTube channel so if you want to take a look please do so so this is for the kaleidoscope then we can go to the royale again a very important piece of information maybe that's easier to know the spot is where the name came from is from the James Bond book and movie it's casting royale I hope the colors are good and it's what's the difference is that the secret definition is not monolithic for poker it gives more general actions card actions so for example because in poker we have this open the fourth community card which has a specific name and also you don't need to shuffle your own card because for example one thing that in poker you don't do it but some other card game you will do it is pass cards between players so if you do it for example you have to reshuffle your own cards otherwise people spot can track down where the card is if you pass another time so you have to receive and reshuffle you don't have that in poker for example so here we need this kind of operation is one example the design is more modularized so for example the rules of the game is embedded in the kaleidoscope definition here no because it's more general so we have to set apart the rule because we don't know actually which game is going to be played and maybe the feature that sets royale apart is that it's universally composable secure as I mentioned because we don't know the order we don't know how many instance so we need that so that's basically I think sets the differences from the kaleidoscope so what are the building blocks that's your first question they are similar so okay so what is what is the trick right that the proof definition of proof technique is different because Bernardo and Rafael they noticed that if we generate the values in the beginning differently this is a technicality of the proof the simulation based proof we have to construct the simulator and if we do it differently from the beginning we are able to construct a better simulation for our proof so that's why we are able to prove Bernardo so there's another main difference in the proof technique is that we realize those people who are familiar with zero knowledge proof realize that we don't need to extract the witnesses we only need to generate zero knowledge proofs using the simulator of the niche that we are actually using so that allows us to get rid of rewinding in the simulation and that helps us of course construct the UC proof just to make it clear that we cannot rewind this algorithm and if you can extract it without it then it will become UC compatible that's the main trick that's why I don't know actually we are talking with Vincent about the implementation but I'm not sure Bernardo do you? we just generate the CRS which is basically the parameters of a Pearson commitment so it's a bunch of random group elements such that you don't know the discrete log of one in relation to the other so that's very easily generated by basically coin tossing which we can implement very cheaply in the random model so we do a setup phase where these parameters are generated and then it can be used for a number of executions of course it's part of the checking and the parties playing the game will be doing it okay so as I mentioned the building blocks are similar but the sub-protocols are different because we have to be more general but we do have the checking checkout phase we have to create cards with a specific value so if you want to do it we have it and the kaleidoscope is not needed we need to open we can open a private card so you have a card in your hand you can open it or a public card some card which is covered in the table then you want to open it you also can do it that it's not needed actually in poker for example because the community cards are open in the table so this is an example that's some kind of generality that we need but we didn't do we didn't need it in the kaleidoscope for the shuffle there's also two kinds of it because as I was mentioning in poker you don't need to shuffle your own cards but in some other game that you pass the card between the players you might need it so we have to build this protocol here execute actions like open the card like put bets this kind of thing the compensation is in the end of the game you have to if you win or if you lose so if you're going to receive money or more money or lose money and of course the recovery if something goes wrong we have to go to this state of recovery and go to the blockchain and check if everything is okay so this is the paper I think we released an old version in our internal slack we are working to openly distribute it but it's not quite done yet I think well the paper is mostly done with just some one or two paragraphs we need to rewrite and that's it okay so here are the publications it was already mentioned the kaleidoscope is going to be presented in financial cryptography in 2010 but it's available in the e-print for quite a long time already and well we are working to release a version for the e-print in the IOHK website library section we have been promoting these protocols Bernardo it's not very good to see it unfortunately but believe me this is a ramp session presentation in Asia Crypt last month Bernardo gave a small talk Shamir was in the front line and it was nice to see his reaction and so it was in December and next week I'll be making again this more or less different presentation in Niigata Japan so yeah I guess that's it I hope you guys had a good idea of what kaleidoscope and royal mean and stay tuned maybe we have some other things to present in the future that's it