 So hi everyone, we're gonna speak about random numbers. So first, a small quote about the NACLUS. Random numbers should not be generated with the methods shown at random. And we've seen too much application just using the block hash or using multiple block hash while it's not secure. When you are on classical computing, you have your own computer, you can use your time, data in your computer, most movements to get a random number. I remember when I was creating my first electron address, they asked me to move them out to type random stuff on the keyboard and you generate entropy. But the problem is if you want a random number in Ethereum, which is basically the world computer, you will each end up into a different one locally. Why do we need those? So the basic use case is gambling. We need to improve work, we need to use in complex building systems. Probabilistic analysis is, in my opinion, the state of the art intermobility system. We need those for doing jurors in the project I'm working on. That's what we're doing. We need those for AI to initialize machine learning algorithm. So imagine you have an AI on the blockchain with some economic personality. If you were able to fix the initialization number, you could treat the AI into learning badly, taking bad decisions. The first method we should use is a trusted party. So you have some minister on a beacon where you could play an oracle on it. You can directly call oracleize, but the problem is it's not decentralized, you have a single pointer failure, and in case a trusted party is cheating, you have no way to detect it. We've seen a lot of the person using block hash, but that does not work. So first let's go back to basic work. You have cryptographic function. If you want to compute h of x, it's easy. But if you want to compute x, that x of x is y, it's partially infeligible. So in poor work, basically you take the block header, you start with a node, like zero, and you hash it, and if it's lower than a target, you put a block. And if not, you implement the node with n equal one, two, three, up to the point you find a block or someone else lives. So we could say, okay, at the end we have the hash and she's random. No, because when you get to find a block, you can choose not to publish it. And even worse, with smart contract, you can bribe the miner trustlessly into not publishing those blocks. And you don't even lose the war buckly wall because you publish it as a non-calculation. So okay, only the miner can do this attack, and the effect is just, quite just, re-rolling the number. So it does not allow you to fix it to a particular value, but it allows you to pay a small cost when you want to censor one and get a new one. I've seen application where saying, okay, the attack cost is higher than what I have to take in each block in my application. So I can rely on the block hash to get the right number. But no, because the block hash is the same for everyone. So perhaps if in my application it's not worth attacking, my neighbor application not worth attacking, and your application not worth attacking, but perhaps you can do an attack on all those three applications at the same time. And in this case, you may win more than the attack. One method which is really useful when you don't have a lot of parties is commitment sheets. So the ID, you generate a number locally, you publish its hash, you get tons of parties doing that, they pay a deposit. And in the second phase, they reveal the numbers. Of course, we verify that the hash corresponds. And the result is the XOR of all random numbers. And one interesting property of XOR, if you XOR something random with whatever, it's always random. So you just need to have one party inputting a random number. The problem is that parties can choose not to reveal. And if a party does not reveal, the generation is stopped. So yeah, you could destroy the deposit of the party not revealing. And for example, I want to flip a coin with you. That's a really good method. Because it's only two of us, we fix the coin and if I want to censor the flip, I get timed up by not revealing and I lose the deposit and we assume that you won the flip. So that works very well. But now imagine you have 1,000 users which are relying on the same number. And you just have one not revealing to prevent the generation. So you will need each party to have a deposit equal to what that's take for all the others. So this scale quite radically to the number of parties. So it may be perhaps okay with playing poker. But for a lot of person, it won't work. Then you have special signatures. So social signatures is a signature which is where a lot of parties get part of the key and they sign partial signature. And if you get at least the threshold of partial signature, you combine them and you get a signature. One interesting property of the signature scheme is that no matter which party are signing as long as we get a threshold, we get the same signature. So if it's A or B signing or B or C or no matter what, we always get the same signature. So that's really good if you are in the honest majority model. Because in this case, I vote the party with all and everything goes right. But the problem is if you can get attack of 50% with party refusing to reveal to sign or even worse, with parties who will collude to get to know the random number and they can censor it by making some blockage attack. The other method is sequential proof of stake. So in classical proof of stake, sequential proof of work, in the classical proof of work, you can parallelize it. So you get one computer having a nonc equal zero, one or the equal one. And the more computer you have, the faster you get to find a block. In this one, it's not the case. So you start with the blockage and you hash it and you hash it and you hash it and hash it and hash it and hash it. So at each step, you need the result of the previous step. So even if you get tons of hardware, you won't be faster. So what does it do? It's a time lock cryptography. The goal is to ensure that it takes some time to compute the random number. Such as this way, if you are minor and you want to get bribed or you want not to revolt for yourself. At the point where you have your block, if you wait to know this result, someone else will already publish one. So okay, you can censor some, but you don't know what you censor. So it's still random. But there is still some catch because if you want to compute some sequential hash, something like one million time and you do that in a smart contract, you will run into the gas limit. So to solve that, you need to use interactive verification. I guess some of you have been at a truly presentation. So that's the same concept. Except here it's quite simpler because we just hash it in the middle of a miracle tree or complicated stuff, just hash it. So you let every party post a result, a deposit, and then you have replication game which guarantees that each party is honest. So the challenger of the fake number or the defender of the right one will always win the challenge. And when someone puts fake numbers, you burn part of the deposit and give part to challengers. So on target verification, let's assume here for the sake of the example that the hash is just plus one. Don't use that as a hash, that is, for example. You compute to get 17 and some other party say 35, which is the fake answer. So you ask this party what's the value at the nine step and he says 27. So now you know that he made a mistake between zero and nine set. So you ask accept four, he says four, four is correct. So you know the mistake is between four and nine. You ask at six, he says 24, it's incorrect, you ask at five and now you show five plus one is six, not 24. So you've proven that he has made some mistake in his computation. But there are still some issues with that, which is that a party can put fake numbers, put some deposits and okay, this party won't be able to change the number, but this party will be able to delay the time. This number will be available. So also, if we implement the incentive in the challenge naively, you will challenge a number and the party put in the fake numbers will challenge his own number and make sure to lose against itself and such a way that you don't win the part of the deposit. And our goal is to design a system such that if you have even a small deposit that you can use to challenge it, to make a challenge, compare to an attacker with a large budget making tons of fake numbers. The goal is say okay, at the first one you are able to challenge one number, you win and you get half of a deposit. Now you have 1.5 deposit. In the second step you do it again. Now you get two deposits and now you get two deposits. So you can challenge two numbers at the same time. And next step you get three deposits and so over and over and your deposit is increasing exponentially, of course, up to the point where you finish to disprove all the numbers. So the other idea is to split the reward between each party challenging no matter which challenge is winning. But there is still a catch, there is still an issue where the attacker can, when you challenge one of his number, keep a huge part of his budget to also challenge it. Such as this way, you will get almost all the reward, you will get peanuts and you will never be able to challenge multiple numbers in one run of challenge. So how to avoid that? It's with commit and reveal. So you commit to challenge a particular number and in the second phase, you reveal that you wanted to challenge this one. And in such a way, the attacker, he does not know which of his number you're gonna challenge. So of course, he can try to challenge number randomly, but if he's gonna challenge a number which you haven't challenged, he will either lose the deposit as a challenger or remove the fake number. So in both cases, he's losing. Of course, in the worst case, in the worst case, you have a super lucky attacker and each time he's guessing right in the number that you're gonna challenge. But of course, that's just like in the worst case. So we can look at what will happen in the average case. And in this way, from all the strategy I searched, an attacker could have. I haven't found anyone which will not allow to have the number by a logarithmic amount of step. So that's still a conjecture. You need to prove it because you need to prove that there is no strategy allowing to do that. And if someone is interested by having this proof or if someone has insight in this proof, I would be really happy to speak about that. So for this second half of work, we've seen the problem which is that it takes time. So it's not suited for real-time application. If you want to bet, that's not a good idea. Well, oh, in a lot three, okay, but if you want to bet in real-time, that's not a good idea. If you can weigh something like one day or I guess the future, even less, that should be a really interesting method to get our numbers. Now, there will be another kind of attack which will be on hardware. If you manage to get the hardware, able to compute ashes, order of magnitude faster than the hardware of others. You could compute it super fast and know what the number will be and this way do a blockage attack. So thanks everyone. And if you have other question or insight, feel free to speak with me either there or by email.