Using Randomness to give privacy to users moves
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md
file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the newline's Introduction to Privacy on Ethereum course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to newline's Introduction to Privacy on Ethereum, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:17] Okay, so now this is where it gets very interesting where we actually find out how to do this in a way which is more consistent. So what is the problem? Well, the problem is that this rock, paper, scissors, no matter what you do, are always going to be the same.
[00:18 - 00:39] So what we need to do is introduce a source of randomness, which only the player knows and no one else finds out until the evaluation function is called. So we can now think things a little bit simpler. Well, we can now just say that it's just going to be a rock.
[00:40 - 01:02] And we can do this by using a public constant. And so now we are just removing the hash function from here. And you can kind of guess where I'm going to go with this. So the idea is every player, when they make a choice, it's about 32.
[01:03 - 01:32] But we're not saying what's in the by 32 just yet. What's going to be inside the by 32 choice is of course going to be one of these rock, paper, or scissors. But it's also going to have a random source. So this by 32 is completely random, like only the player who's played the move knows what random thing they chose.
[01:33 - 02:04] And they can pick anything random and by 32 will be entirely random. We'll define how to do this. So basically, I'm just going to update the rest in the same way. So we have people. And of course, we're going to make it constant making it constant so it doesn't actually take up any more space and it's actually stored in the bytecode of the contract.
[02:05 - 02:21] So these are just replaced with the actual values where they used instead of them taking up a storage. So we can just go through this thing across. And I'm going to make this again constant.
[02:22 - 02:55] And we can now replace this entire thing with scissors. And of course I need to put that in basic and double quotes. So now we're not doing hashing here. We're not really changing anything here, but we have to do something. So we can't really say that the choice has to patch one of the three because the choice could be anything. And we're not going to find out what that is until a later point in time.
[02:56 - 03:23] The other thing is because now we are checking for what's 32, we should be checking with slightly more type. So we can just say that's equal to that. So they've not played a move before and we allow them to play with any move now . Of course, if they play a move that we can't recognize they fail anyway.
[03:24 - 04:13] So now this whole thing is great, but we are going to go. We're going to have to change the interface slightly. So address of Alice is fine and address of Bob is fine, but we need a few other parameters. So what we need is a by 32, which is going to be Alice's choice. So the actual choice they made, which is going to be comparable to the ones that we have above stored in the two. And also the second thing that we need, which is very important is the randomness. So this is the randomness that Alice, Alice chose.
[04:14 - 04:35] Again, the same thing, we have the address bar for Bob, and we need the bar 32 choice for Bob. So what choice they made. And we also need the device 32 random ness. And we're going to see in a second on how we use this randomness.
[04:36 - 05:03] So again, Bob has some randomness and Alice has some randomness. And now we must verify that these randomness match up. So we are going to have a require. And in that require, we are going to check that what they claim is what they committed to. So this is where it actually becomes a commitment.
[05:04 - 05:22] And for this, we have to do some hashing. So what we are going to say is that the Kekekk 256 hash of the Alice choice. And so to do basically two arguments, you have to do API encode back.
[05:23 - 05:39] All you can do is API encode as well, just using fact. So you can do API encode back, and you would have to pass in the Alice choice. And the Alice randomness.
[05:40 - 05:51] And that should be equal to. And now we are going to compare this and say that it should be equal to what they committed to.
[05:52 - 05:59] So they have committed to say Alice, right. And this should matter.
[06:00 - 06:16] Now, if this doesn't matter, the problem is that they are not doing things right. So the reason that this choice is now not able to determine what's inside is because the two things are hash together.
[06:17 - 06:28] So the Alice choice is essentially just rock paper or scissors, but there is some randomness. And that randomness makes the hash actually just by looking at it.
[06:29 - 06:42] Now you can't just say, oh, they must have played rock or they must have played scissors. Of course, if they pick not very good randomness, just like they always pick zero, and you do a brute force attack, then you can find out.
[06:43 - 06:51] So the randomness that someone picks must be completely random. And if it's not random, then you know, you can break it.
[06:52 - 07:05] So the same thing we're going to do with the bomb. So just to make sure that they have not, they're not trying to cheat the system and they are trying.
[07:06 - 07:12] They are using the right thing. So again, we can do both choice and both randomness.
[07:13 - 07:29] So they're going to say that it's bomb and Bob actually committed to the things that they are saying that they committed to. So once these checks are done, now we know that whatever they committed to is what they are playing.
[07:30 - 07:50] So no one's trying to say that they play rock and now they're changing their mind so they can't do that. And we've verified that because we've verified that the hash of the choice and the randomness is actually equal to this, which means if they try to change their choice, this would not match up.
[07:51 - 08:02] So the hash function has this property that if you, if you have to do things together and the order also matters. And if you do that, then it will match up.
[08:03 - 08:12] If you change the ordering, you change capital letters, you change anything, this will fail. So this is, this will protect us for these things.
[08:13 - 08:22] Now, we have to also see again the same thing. So we can now just see, well, we can't do this anymore.
[08:23 - 08:26] So the choices, we cannot use them anymore. Why?
[08:27 - 08:41] Because the choices have this randomness inside and we can't really compare with randomness. So now that we've actually verified that Alice choice and both choice are correct, we can just replace wherever there is like choices.
[08:42 - 08:53] And we can replace it with Alice choice. And wherever there's the choices with form, you can now replace it with what choice.
[08:54 - 09:10] And it's as simple as that. And now, although we're not looking in the mapping, we are confirming that it actually works because we did, we reconstructed the hash from the hash.
[09:11 - 09:17] From its original arguments. And we matched it against the one that that was played with.
[09:18 - 09:25] And this is just to demonstrate that how important like randomness is. And we didn't, we didn't do any fancy cryptography.
[09:26 - 09:31] We were still using just hash functions. All we've done is just added some randomness.
[09:32 - 09:39] And just by adding the randomness, we've changed everything. And we've changed the entire privacy model.
[09:40 - 10:02] And this is what, this is the main aim of this module to show you that just by adding, just by thinking slightly different and trying to break the system, you can improve it. And maybe there's some things that I missed out here and I would love to be pointed out and shown how to improve this further.
[10:03 - 10:18] So go ahead and update your code to match this and also see, also see if you can find anything else. And this is, this is now in a way where it's completely private.
[10:19 - 10:23] Two players can play this game. Of course, you can add more things in there.
[10:24 - 10:35] Such as you can add that they get, they get some money now. And but the, the main point is that now it's completely private after this.
[10:36 - 10:43] So when two players play, one player cannot decide, one player cannot say, oh, you've played this. So I'm going to play that.
[10:44 - 10:52] They both have to commit to something and then it reveals in the evaluation phase. So Alice only has to reveal it.
[10:53 - 11:07] In general, since this assumes, because we only have one function, this assumes that both of them are in the same place or they've shared. I mean, the thing is that they can actually share this information because once it's committed, it's no longer.
[11:08 - 11:16] It no longer matters. You can now reveal it freely because they can't steal anything because it's already committed in the Alice choice and Bob choice.
[11:17 - 11:37] The problem would be that if they're actually able to update this later on, which they can't do because of the check we have, which essentially ensures that one player can only play once. Of course, you can add more functions such as preset and expand this further and go for that and you'll find the full code down below.
[11:38 - 11:58] Hello. [ Silence ]