Okay, this is part four in a series, hopefully there's an annotation on the screen that will bring you to the full playlist. I recommend watching the previous videos. I have wiped out all the changes we've made and and downloaded the fresh codes working with the with the original source code from the PR boom plus project. And today we're going to be just again messing with the code making the game doom a little bit more fun. And one of the things we're going to do is something better than God mode.  So what's better than that? How about when you get hit, you get more health, you get more powerful. So again, I'm using Vim as my text editor, you can use whatever text editor you prefer, as long as again, as long as it's a text editor and not a word processor. And I'm using them, I'm jumping straight to line 911 in this source file. And again, the lines might change if the code is updated, you know, from the project, it might bump the line, but should be around this line. In the pinter.c file. And here is the line of code where the player gets hurt. So when the player gets gets shot by somebody, we're going to take the player, we're going to point at itself, what's its health, we're going to say, take its health and subtract from it, whatever the damage the bad guy is placing on you.  And with explosions, it's based on a radius. But it says this is the damage that you're getting hit with. So we're taking the player's health and subtracting that health from it, that amount of damage from it. So what we want to do here is change that minus to a plus. So now, let's say you get shot, and it's supposed to do 5% damage, it's actually going to give you 5% health. So we're going to say, make that. And then we're going to source PR boom plus. And now I go into the game, I go, hey buddy, shoot me. And you see, my health is already going up. So it sounds like I'm getting hurt. And my, the screen turns red when I get shot, and my face gets all mad, but my health is actually going up.  Every time they get hit by a certain weapon, if you want, you can put an if then statement, if this, then that, you know.  So that's one thing you can do here. Another thing we want to look at, okay, so in a previous video, we changed the player's default health. So if we go into that same file, line 62, this is where we set our initial health. So let me set this to 999. So we'll make that and we'll run doom.  Let's just change this back to a negative. While I'm in here, I might as well mention what these next two lines are just so you know. So this is the player getting hit. We're subtracting damage from it. But then we say if the player's health is less than zero, set the player's health to zero. So let's say my health is at 5% and someone hits me with 10% damage. The health bar is not going to show negative five. It could, but this function stopping that it's saying, yeah, if it goes below zero, just set the health to zero. That way it doesn't keep going down in the negative numbers. So yeah, just wanted to point that out real quick. So we're putting this back to how it was. Now if I get shot, I get hurt. But our initial health when we, oh, let's make that, our initial health when we're playing the game here is set to 999. That's what we set the initial health to. And if I get shot, it goes down a little bit. If anyone will shoot me, there we go. But you see the blue vials. The blue vials, if I get it, it goes to 200%. And as I mentioned, that's because the max health set for the vials is 200. So when you pick it up, it's changing it to 200. Let's go ahead and change that. So we're going to go into a file. We'll use a Vim and we'll jump to line. Let me look at my notes here. 671 of our source Pinter C. And that's not right. That's the wrong line. Line 300 and 36. And again, the lines might change if you download an updated version of the source code. Things might move, but should be around that area. So here, we're listing all things. What happens when you pick something up? So you can pick up the first type of armor. Armor 2, a health bonus. This is a health bonus. This looks like the armor bonus, as you can see right here. And each time we pick one up, it's saying health plus plus. So it's saying it can go over 100%. But as we saw, it maxes out at 200%. That's because here, we're saying, okay, every time we pick one up, add one. So if you've ever done any type of C, or most programming languages, you know, if you have a value and you say plus plus, that means add one to whatever it's equal. So if you did minus minus, it would subtract one. So we're saying that, and we're saying, yeah, if the player's health is greater than whatever the max health bonus is, well, then set the player's health to the max health bonus. Just like we're saying, if it's under zero, set it to zero, we're saying, if it's over the max, set it to the max. So what we can do is we can find out where this variable sets. That's one thing we can do. I can go grep from all the files in this folder. I should put this here. Look for this, and we can see a few places, and we can see where it's defined. It actually looks like it's defined two different places. One, it's finding your max health and multiplying it by two. And then another place it's using another equation. So I'm not sure really which one of these is being used. I can go look at the code, it's probably an if then statement. If this then use this, if that then use that. But for what we're doing, we're going to go back into our code here. And we can just say, oh, you know what, let's set the max bonus to 1000. So now, if I save that, make and run it, now I should be able to go up to 1000. Should be once or twice. Okay. So are there enough files over here for me to, I don't need just 25 files over there. Let me go grab a health pack real quick. Oh, that health pack won't work because I'm over 100 and that health pack sets up. Okay, so show you it's not dropping down to 200, which is what it was dropping down to before. It will cap out at 1000. Now, let me start this level over again. And just get rid of these guys. So when you get to 1000, I'm still not getting to it because I did get shot. I wanted to show you that 1000 looks like 0000 because anything more than three digits is going to go off the side there. So let me try that one more time. IDK, IDKFA, there we go. Seven. So now if I pick up one of these, my health goes to 1000. It looks like 0000. You see it's not going up any higher than that. So that's another thing that's one thing we can do. We can change the value of that variable or as we just did, just completely replace the variable or we can just delete these two lines and there is no max. So now the health will continue going up above that infinitely until the game hits some sort of physical limit.  I got hit once. I was trying not to. Yeah, let's try that again. IDKFA, seven. Man, you'd think that the BFG like this. Okay. So now you can see it looks like 004, but it's actually 1000 and for 1007 now. So you've removed the cap for those little blue vials. So that's pretty cool. So what else do I want to show you? Is there anything else I want to show you today? Let me look at my notes here real quick. Let's go. Okay. So right there, it says the monsters you've killed. I see seven out of 19. I don't think that was in the original game, these messages. Again, there's been a lot of updates to do. For example, the map is also much more advanced than it was in the original game. And there's other versions other than PR boom that give you some other features, kind of like, I think it's chocolate doom. As your life goes down, your health goes down and your arm goes down, it changes color. So anyway, it's showing the number of monsters that happened, their left and the number of monsters you have killed. Let's just quickly look at where that is in the source code. So according to my notes, it's saying it's online 671 of this file. So let's go there.   So let's go ahead and change that. I haven't actually done this way to change that to 10. So every time I kill one bad guy, it's going to add 10 to that total number of kills. So in theory, again, I haven't tried this yet. So zero out of 19. Let me go ahead, kill both these guys, and then go hide. Nope. Obviously, I wrote something wrong. And it's not showing is not adding up at all. So what we can do to error check something. So as you can see, I'm running this in the shell and there is output here. So let me go in here. And what I'm going to do is wonder if it was, is this one? Well, no, because obviously something I did change it. So it was still at zero. Let's go ahead and change or do an output. So if you've done your very first C programming tutorial, you did a Hello World. So you know what the print F command does it print stuff to the shell. So what I'm going to do here is I'm going to print a message you have killed percent I because it's an integer enemies, exclamation mark, and then new line there. And then here we're going to want to put what the variable is, which is our source kill count here. So we do that. And now I wonder if there just has to be spaces in here. So let's just add spaces. So every time I kill somebody theoretically, we should get a message out to the terminal, the shell saying this message and giving us a value there. So let's go ahead and make that and source PR boom plus. I'm going to do is I'm going to unmaximize this. Oh, and jump towards my second monitor there. So let's go ahead and there we go. So yeah, my math is not working. But my output message, it's telling me, oh, now it says I've killed one. Now it says I've killed one. Interesting. Interesting. So let's see. Let's go back out into our source code here. Let's just change this back to plus plus, looking around the sea. So source player, machine flags kill. Again, I hadn't tried this before. Oh, it's this player kill count down here. Counts all monsters death, even those caused by other monsters. Okay. So that might be something we can change. I set this back to what it was, which was adding one each time. So let's just make that. So we haven't changed how it works, but we're displaying an output. So if you ever want to check something that's not working, you can always print F out to the shell. There you go. One enemy, two enemies. Again, in this particular version of Doom, I can go into the maps and see the number of monsters killed. And of course, if I get to the end here, tells me the percentage killed. So yeah, my goal of changing that number didn't work. But printing it out to the shell does work. So I just wanted to show you that in case you wanted to try to figure out why something is wrong. So anyway, I thank you for watching. There's more to come again. And in a few tutorials, we'll start hitting up hex editors to modify the game, the Doom game, which we don't have to do since we have the source code. But I just wanted to give you an overview of changing something I've done simple stuff in the past by changing strings, we're actually going to change some numeric values in those hex editor tutorials. So anyway, I thank you for watching. Please visit filmsbychrist.com. That's Chris the K. There should be a link in the description. There's also a link in the description to the notes for everything I've done in this video and all the previous videos. So go ahead and check that link out. And I hope that you have a great day. Okay, this is an introduction to filmsbychrist.com. I'm Chris. That's Chris the K. That's me right there. My daughter Ember. And my wife, Jennifer. We pretty much live in the swamps of Florida. I'm a firefighter by day, as well as by night. We work long hours. But that's not why you're here. You're here about the videos I put up on YouTube. These videos are mainly about computers and programming, which means most of my videos look something like this. And if that's what you're interested in, great. If not, that's all right. I do videos on other topics too, such as video editing, special effects, photo editing, 3D design, and music creation.  So I ask that you take the time to go to my Patreon page and look at different levels of rewards you can receive for different levels of backing. There should be a link in the description of this video if you're watching it on YouTube. Otherwise, you can visit patreon.com forward slash metalx1000. And I thank you for your time and your support. Have a great day.


Okay, hello everyone. Last day of DevCon thanks you a lot for coming and yeah we hope this is like a fun workshop for everyone and we can actually get to see how these technology works and you might be able to like run your own hopefully by the end. Yeah, do we want to introduce ourselves? Hi, my name is Jennifer. I'm a software engineer at Corson. Corson is a staking provider. We run that data on several, lots of different networks actually, but of course the Corson being a few and this is what we're going to talk about today. Yeah, my name is Gabriela. I part of like the research team at Corson, I focus on if they are many and yeah definitely the coolest team, they don't matter. So the the title of this is spin-off, spin-off of all the data on testnet and yeah the way I think we want to structure this is basically in the beginning I'm going to be giving you like an essential outline of like the different parts that we're going to be looking at when we will move to a second part which is the demo. When Jennifer is going to actually demonstrate how to spin out this ballerator and well then I think you'll get the time to do it yourself with the people that we're going to be sharing with you, the information on like the wifi is over there if you need it and yeah then maybe this kind of like we want to cooperate with you, we can continue to like the steps on the ballerator, so exiting ballerator or we want to like more bounce things that we think could be fun like going more into like the block spoilers for the ballerator that you created and maybe like even understanding a little bit more like in Ida's community like the different parts that we mentioned during the essential like and talk about the demo to you. So yeah I think one thing I'd like to mention like feel free to like just interrupt this, ask any questions, this is your workshop and this is why we also leave it kind of like very flexible for you what kind of like exercises you want to do and then we'll see who's interested in exiting a ballerator, we have some keys that you can use that we've already deposited so and they will only be available during this workshop, so if you want to play around to it during the workshop and after that they won't be available anymore. All of these of course powered by Kordsman who gave us this key for our company. So yeah I think we're ready, yeah let's go into like the essential like talk that I want to give. Do we, yeah let's give some context actually, maybe about how this workshop actually came about, mainly the past few months we were like working really hard on an API to automatically spin a ballerator, I'm super proud that this week we like released it so I can publicly talk about it. So basically, obviously before you automate something you have to do it all like manually, so I found myself running like lots of Docker containers and like running validators just to test it and with Opus API you can actually just call our API and it will spin up a ballerator automatically for you. Yeah, very cool and yeah we have like announcements on our Twitter and everything if you want to read more about it but yeah I think you're here to do the practical part, let's heal in, so okay let's go to this. And yeah I wanted to start with like kind of like a big picture looking to like the Ethereum network and what Vitalik gave like this very good talk during the opening ceremony but I guess I wanted to take a little bit from that and also make it like more pertinent to like the topic of staking and validators and what they do inside like the network that yeah we are creating here, no? So yeah, this is again a quote by Vitalik and I'm not going to read everything to you but this is like a cool I think look into what is blockchain and the different parts that we are going to be seeing today are mentioned there. But I guess one of the most important parts to I guess pick out of this definition is when it says like car is very strong crypto economically secured guarantee. And well crypto economically is basically a made up word that we have here at crypto but yeah it has a lot of meaning specifically when it comes to like the security of the Ethereum network. It has two parts the crypto which makes you think of math and then like the economic part which makes you think of money and it's like math and money has a lot to do with like the things we do here but yeah. And specifically like the role of validators here in the network so that is essentially like the idea that we have behind these blockchains and there's like quite a few of very like interesting things that they can do. And for example for me I do find that like the guarantees that they have to continue running even if people like are not interested in them that they are basically like infinite and they continue even like beyond hopefully beyond the ages of everyone here present. They have like very high availability like uptime and everything that we try to keep here on the network. And basically all of these blockchains that we kind of hear about they're part of this call the part of this thing called like consensus protocols right. And when we think about consensus what we're basically talking about is trying to keep like a huge number of different computers in sync. And one of like all of the challenges that you could find to keep like a number of distributed computers like always in think in sync which could be like network outages or even like a denial of service like attacks. And we know of those here is in here in a thing. Yes. But basically when we try to think about like this definition we are basically conflicting like two different things or two things that are kind of conceptually different. And especially when it comes to like smart contract platforms like Ethereum. And for example when you're running like an Ethereum full node and yeah by the end of this workshop I hope everyone here is like doing that. Then it is true that you're running like a consensus protocol. So on that side you're working hard like connecting to other nodes and trying to bring like all of them in sync like I said. But at the same time what you are staying in sync on is like the set of instructions. And these instructions are in themselves like updates to the state the state of the machine that we are running right. And these instructions could be like as simple as like transferring money to one side to the other. Ethereum is good at that. But also much more complex things and well I think this talk would have been better at the beginning of Devgon but we've seen like so many of those applications during the week. All the things that can be done. No. So if you're running like that full node in Ethereum then you are also like responsible for like the compute and the computation of all this instructions that we con on consensus. And those are very two like two very distinct responsibilities that are worse worth like separating. And when we see that well what I'm talking about is obviously like the separation between what we call like the execution layer and the consensus layer in the protocol. No. That is like kind of like the main architecture behind the nodes that you'll be you'll be developing. So we want to dive just tiny bit deeper into these two things. On one side. Well you can see the architecture there. But yeah on one side we have the consensus. And this consensus mechanism. So you might be wondering like OK how does Ethereum keep like this X number of validators in sync. And well nowadays or by the time like I was preparing this presentation then that number was like X correspondent to four hundred forty one thousand seven hundred forty seven active validators. But there is a world right where there could be like millions of this or we hope that there's millions of those running. And we can actually like cap the amount of notes that the Ethereum network can handle because it is a function on like the total supply of a theorem that is currently like on the network. But yeah to understand like a little bit more about the relationship between like supply and if then I recommend like a talk that was given here called ultrasound money and won't go very deep into that. But yeah to go back into our topic. Ethereum today uses something that is called the Gaspers Gaspers consensus algorithm that too long didn't read is the is not really like a single algorithm that controls the network. It's like two different and very complex algorithms one bringing like the block finality and the other bringing like a fourth choice. And I do love talking about this so I will go a little bit deeper. Hope I don't lose you. Let's see. Casper FFG is the name of the finality algorithm. So basically and yeah I want to relate it more to like the validating process. So during the block proposing process like one of basically randomly like one of the validators of the whole set of validator active validators that I mentioned is selected from the pool. However, what is expected is that the network will grow like in a single blockchain one block at a time one by one. But sometimes the network like I said could fall out of sync. And produce or broadcast or to blow through validators might broadcast like two valid blocks that could be potentially added to the network. And when that happens that creates something that is called a decision or like a fork and even like small forks are very like existential threats to like the protocol or different distributed systems. Because there should always be like one true blockchain or one canonical block chains. So Casper the idea and not going to detail details is to like give certainty to like this one true blockchain. And the fourth choice will be like it's called LMD ghost helps to complement this Casper protocol. And like I said most of the time it grows one by one but sometimes like the choice appears okay which one of these four choices should we choose. So this is like a function that takes like all the different paths that are in the chain and speeds out like the one canonical chain that is going to be a theorem. And together like both of these things try to keep like the network and sync at all times. I think that that's a pretty cool description. Going into like the execution part like I mentioned. Basically a theorem is definitely more interested in like being a consensus protocol and the IBM is interesting but in my opinion is something that can be changed in the protocol. But yeah, a theorem exists in a network that has like thousands of computers and each of them is currently running like a local version of the Ethereum virtual machine. And basically the IBM is like the place where all of these decentralized computation happens or smart contracts and all the transactions that we know. And that is a place where all of those contracts live. And this is the same environment like it doesn't matter what kind of computer you have or what kind of client you're running. It basically is like the same environment all across the network. Within the IBM there lives like a number of entities are called accounts and like contracts, objects and the ETH which feels like everything within the network. And basically what the IBM has to do is basically follow like a set of rules. And the main rules there are that everything should be recorded in blocks. Everything that happens inside the IBM and should be added to like the public blockchain. Anything recorded in the blockchain cannot be undone. And all objects should have like an owner and they cannot be altered without the permission of the owner. This is very basic. Some of these things are changed depending on like different applications and different things that are going in the protocol but this is like the basic rules I think. Going pretty quickly in this and I think interesting thing are like the different clients. So today in the workshop we'll be using two I guess minority clients. I mean it's difficult to still say that Lighthouse is minority but yeah we'll be using that at some points. And also like Techoo for what you've been doing, what you've been doing. And also in the execution side we'll be using Vesu which yeah I think we could say is pretty minority. And yeah like we said we have like this execution part and this consensus part and we have execution clients and consensus clients. The execution clients will listen to the different transactions, they change the state of the IBM and they hold like the current copy of the state. And the consensus client will they keep all the machines in sync so that the proof-of-stake consensus algorithm can work. And well Ethereum having like different implementations is actually like a great asset. I think we all know it. And yeah the important part there is keeping like each of these implementations under like a security threshold so that the network can stay online at all times. Yeah I think we're all aware of the importance of client diversity so yeah we wanted to use minority clients today. So yeah a little bit more into like the validation process. And it's basically what keeps Ethereum secure you know. And sticking on Ethereum can take many views but let's take like the more canonical like idea of what staking is. Definitely a lot of changes going on in the industry yeah but okay canonically what it means to stake is to secure the Ethereum network by making a deposit which has like a transaction of a financial bond which is 32 ETH. That you have to like deposit into like what is called the deposit contract of Ethereum. And the idea there is that if you validate transactions honestly then you get like a certain payment.  Because Ethereum does not have like a native delegation model. Then you either go through like running your full node or you could have like a few options. For example like the most decentralized of the liquid-staking solutions are probably better. And yeah maybe other options that we don't want to encourage. And yeah going a little bit further into like those rewards and slashing conditions. Basically here I just want to quickly mention like the incentives and like the design solutions that the protocol has had but like very quickly. So in the same sense that you have like an execution layer and a consensus layer then you also have like execution rewards and consensus rewards. So the consensus rewards make like the biggest like piece of the pie of the rewards at Ethereum. And they basically come from like doing like the attestations and proposing the blocks. Attestation means voting inside the system, okay? Voting for the different blocks and voting for them to be included. And very rarely then producing blocks. I mean you probably will be producing blocks but it is kind of more random than doing like the attestations. And in the same way that you can earn those rewards then the exact amount that you earn is what is detracted from like your balance when you are offline for example. You fall into like what's called an activity leak. And that isn't like really slashing. Slashing is a completely different thing. Hopefully today we'll have enough people to like try that and see if we can get a slash. And in our testnet just to see how it is. But yeah, and slashing can go like from like one if to losing like the complete one. So the 32 if that you have in your balance. And yes, finally, okay, you have a question. Yeah, exactly. Basically this penalty that you can get usually comes from being online. And it is the exact amount that you would have earned in the same period. Like you said, like you said, a slashing come from things that directly attack like the consensus of a theorem. So that is usually like either double signing, putting like the same keys onto different machines is very common. If you like forget, I don't know, probably shouldn't is money after all. And I know so like the basically trying to do like surround voting, which is difficult to explain, but basically you're trying to change like they can only go changed back like the historical data that has already been added to the blockchain in the future. But yeah, I can explain later if you want. Yeah, I guess that the last thing I wanted to mention because it's very important for what we're going to do is. Yeah, you can pass. I think we talk about it. He's in signatures. So today we'll be actually going through like the process of generating keys and everything here in front of you. And keys and signatures are like the main crypto cryptographic like primitives that allow all the communication that is going on in the network. When you look at the most like base level. You can definitely look into like the different block explorers and you see like all the different keys that are interacting with each other. All the contracts which also have like these different signatures and everything. And yeah, hopefully we have the time to look that in in the block splutter. And they work through something called hashing, which is basically have a cryptographic term. And it's more like a more efficient way to like securely store data inside of the blockchain, which is like the entire basis of the protocol, I think. And basically you have like this digital signature that represents like the validator and you get it from like a key generation algorithm that will will go through in here. Like I said, and there's also like a sign in algorithm and a verification algorithm that go behind like the scenes to to really verify that everything that is getting added is well correct. Hopefully we have like the time to see all of those things. And yeah, I think I hope this wasn't very boring to you. Like I think this may bear side view on what the protocol is. It's important to like understand what we'll be seeing. So yeah, I think it's time for for the demo. Nice. Okay. Then I'll take over. And I will just work from this GitHub repo that you can try and find. So basically, the way I kind of thought might be helpful for you is like, I'm going to walk through the demo. I would kind of like recommend you kind of then in the self study time retrace my steps you can just do the same. And then yeah, and the Wi-Fi, I think it's best to connect to the DevCon workshop. Yeah, I think so. It's not working. It's working for you. Are you guys okay with the internet, you think? You're good. It's working on mine. Where's cause you can borrow my laptop? Cool. Yeah. All right. Not my NFTs. Yeah. Okay. What was I saying? Yes. I'm going to walk through the demo. I think it'd be best if you then kind of like retrace my steps. I'm going to do some exercises. Like first we're going to try the Lighthouse client. Then you can try the Tecocline yourself. And then number three is like fairly challenging. But obviously if you're feeling adventurous, you can walk through these steps too. And then I think we'll kind of like reconvene and then see what people are interested in. Either we like exit our validators or we, I don't know, explore the block. But let's get, let's get into it. Cool. Okay. Actually, let me just, let me just kind of like describe the tests, the steps. That's a brilliant question actually. So generally on a higher level, like what you need to actually like become a validator on Ethereum is you need to generate your keys. That's like step one. You need to set up your infrastructure. And then like make a deposit of like 32 Eve. We're going to use test Eve, by the way. And then it takes a while for the validator to be activated. And because of kind of like, we have to take a shortcut because also like girly Eve is pretty sparse. And also like this, like waiting for the validator to be active. I don't think it would be feasible in this workshop. So basically what I've done is I already generated keys for a test net. And we, we do have like some of the infrastructure already kind of like set up. We have like an execution client and a beacon notes, which is already synced provide the course one. And basically we will set up the validator client and connect to that. And this will be on test net. So no, like private net. Any more questions before I jump into the demo. Thanks so much. There's like a, seems like it's a market. It's a real market. Cool. We can do an auction later. All right. Got this weird setup because my screen is broken, but this works actually really, really well. All right. Let's start. I have steps. Step number one, what we want to do, we want to generate our keys. And the way I do this. Actually, if you go into the repo, you want to open this link, which takes you to the staking deposit CLI. It's an open source project. But if you're in foundation, when you open link, just download the state, the CLI for your operating system. Probably best if you just, I've already downloaded it. So you don't need to watch me do that. So basically what the deposit CLI will generate, like two important artifacts. Number one is the information. It's called the deposit data. The information I need to make my deposit. And number two, actually probably the most important, it's going to generate your private signing key. So it's like Gabriella was saying before, whenever a validator like basically does makes any attestations or like propose a block, they need to sign it. They need to sign them so they can be hold accountable. So is there anything else I want to say there? No, I'm just going to like run the CLI to show you what's how this works. There's this command called new mnemonic, which will like generate a mnemonic for you. Anyone wants to know what a mnemonic is? Or is everyone aware? Basically mnemonic is like a list of words you will see in a bit because it will generate it for me, which represent the seeds. And from this kind of like seeds, I can generate my private keys. And the cool thing about this is that it's like deterministic. So the same mnemonic will always generate the same key. So in case you lose your key, you need your mnemonic to regenerate them. Okay, the CLI is asking me a few questions. I'm going to pick English. I'm going to pick English. I want to run one validator. Oh, yeah, of course. Does that work? Cool. This is an important bit. Let's we're going to do this for girly test net. Oh, yeah. And then what the deposit CLI will do is, as I said, like generates my private signing key and it will decrypt it. And the file is kind of like called a key store file. So here in this point, I'm going to select a password, which I can then use to encrypt my private signing key. I'm going to type it in again. Oh, yeah, this is my mnemonic. This is the thing I was talking about. Need to copy it and put it somewhere. Don't show it to anyone. And this... Oh, cool. So now it should have generated my keys in here. Let's have a look. The first thing is the deposit data. As I said, like this is the information we need to activate our validator. Because when I generate my keys, no one knows that my keys exist, right? So basically, I need to submit this information to the beacon chain until it's like, hey, this is my information. I want to become a validator basically. But I will go into this in the next step. I just wanted to show you what is generated here. Actually, let's look into the key store file. So this is my encrypted private signing key. It looks a bit scary, but actually, if we decrypted with the password that I've typed in before, it would just be like classic private key, not scary looking at all. So yay, we generated a key. Really important things just to remember. Actually, the most important, if you remember anything from this section, like this is the private signing key. And we're going to use it later to start our validator client. Go on. Okay. They use the same hashing algorithm and yeah, the same, the keys and the accounts basically look the same. Like if we look at the Explorer, you could see like they all start with like OX. And because they use like the same hashing algorithm basically. No, because they're different like entities inside Ethereum. Like a wallet is recognized as like an account and this is recognized as like a key. Testing, testing, testing, testing. All right, there it is. Any more questions? Because I'm going to jump into the next step. Because now that we have a keys, the next thing I want to do is make it a deposit. Also, oh yeah, I've added lots of like reading materials so you can depth first search your way into the demo. And if you, if you want to make a deposit, the best thing to do is go to this like staking launch pad. And you're going to walk, it's going to take you through kind of like some questions.  But it's actually like, if you want to click through this, it's actually gives a really good information like what like about deposit about uptime and general information. And once you get to the end of this checklist, it will ask you to upload the JSON file that we saw earlier, namely the deposit data. And then you connect with your wallet. And if you're super lucky, you're 32 if and then you can just make the deposit early. That's quite important actually to use the correct network. Okay, actually, this is pretty, pretty neat graph I found on the prison documentation. So again, as I said, like when we generate a keys, no one really knows about them. So we have to make a deposit. Then kind of the validator comes into this deposited state. And it in the end it joins a queue. This is actually by design. I can talk about this probably later on. But then the most important thing is like it joins a queue and it takes a while from to become active.  But it could also be that like your validator, I don't know, like you like make a mistake and validate misbehaves and then you would get slashed. And then it could even get to a point where you get forcefully exited from the network. Also, like if you, if your validator has been like nine days active, then you can also voluntarily exit your validator, although there's no there's no turning back. If you exit your validator, it's done. And at some point you will also some point after the Shanghai fork, we will also be able to finally withdraw a reef. Okay, I think that's everything I wanted to say here. So we generate our keys. We made a deposit. And now we're actually ready to set up our infrastructure. Can you repeat? Okay, I see your point. Okay. I mean, in this workshop, I guess we are showing you how to run your own notes. So you will be your own staker. We do have or their excess like liquid staking solutions because to be to run your own node, you would need like 32, which can be alimentation to some people. There are like other liquid staking solutions where they ask you either like a smaller bond or you can do like just deposit the stake in in a different protocol. You can deposit like, I don't know, one if that's everything, all that you have. And you get the staking rewards without having to run your own, your own validator like at home, like the entire setup. And, okay, then there's also other solutions. We have like this API that you can do these steps easier with. But yeah, I guess you can be a solo staker. You can stake with like a liquid staking solution or like a staking pool or yeah, stake with centralized entities. Gabriella actually gave like a really good overview before of like the infrastructure involved and I just want to repeat that because I think it's like, I'm really, really important to note. And what we need is we need our execution client, which is responsible obviously for executing the consensus. We actually already have like, we will have a bezel note setup. And then you also need the consensus client. And this kind of consists of two parts. One is like the beacon node, which connects to the P2P network, and then the validator client, which, which, which you're going to run locally, which actually manages, which, which manages the validators. And again, here we have to take a shortcut, because both the execution client and the beacon note, they actually take a while to sync. So it is like workarounds, but I still thought it's like easiest we already connect to an sync execution client, a bezel note, and a synced beacon note. I believe that's a techno note. Again, both provided by chorus one. The first thing we should do is just make sure that the beacon nodes, we can connect to it. I would actually be tragic if not, but let's have a look. I was trying it before. So that's, that's okay. Seems, seems fine. We can connect it. I had it. I also like included a link for like the whole like beacon node API. So if you feeling like you want to explore like what the beacon note looks like, you can actually, again, in the demo, you see the URL from the beacon note that we provided and you can play around and send some requests if you fancy it. Okay, so summary, we have an exit, we have a beacon note synced connected to an execution client already synced. So all we have to do is we pick a validator client. And the one I'm going to show in a demo right now is light house. So light house is a validator client, written in Rust. They have really cool documentation. Actually, I think, I think when I started looking into this, there was still fairly minorities and they really caught up. Okay, so we're going to pick light house. And what you do is you pull the Docker container. Sorry. Okay, I can talk again. I've already I've already like pulled the Docker image. So let me just try and see this if this works. Yeah. So you don't have to watch me download a Docker image. And once we have this set up, actually, let's let me now jump into this code because it's going to be much easier. I think to show you all this configuration. Okay, so I'm going to jump into demo and then light house config. And light house has like a neat thing. This validation validator definitions YAML where you can configure all the validators you want to run in this client instance. And I'm just going to walk you through this. So you can actually like run multiple multiple validators in one instance. And you can like, here's a flag to enable or disable. And here comes the voting public key like that would be from the key that we like generated. So here you basically want to say, okay, I'm running this validator. And this is how it will kind of identify you. Since the merge, we also like have to or want to configure as suggested, like a few recipient. Yeah, actually, let me go into this. So before proof of work, the miners would like receive some kind of tip in the transaction when you put them in a block. And now with now after the merge, actually, these kind of tips go to the validators. So with the fee recipient, you just kind of like specify which address this should be sent to. I just put a burner address in there because if I don't light house will like start complaining and logging some mornings. And then actually, most importantly, here we actually want to configure our keys now that we've generated before. There's other ways to configure them just for simplicity. We're going to go for local key store. And then you just kind of show the voting key store path. So basically, and remember are the key store are encrypted private signing key. This is where you point to. So you point light house to the path and then you give it the description password because obviously needs a signing key to like sign whatever other stations you make. So this is all the configuration. And just to show you here is my voting key store and light house is just want to mention this. That does this very opinionated about how you name kind of these folders and files. So if you run into errors, then it could also just be like, maybe you had like a typo in the name or something. But now I have any questions. So basically what I meant is like, I could actually have like two or three validators just in this client instance running. Yeah, I think it's important to say you have to have like one execution client connected to one beacon client. Okay. But inside the beacon client, you could have several validators. It's like a one to one relationship between the beacon client and the execution client, but many validators and it's fine. Yeah, any of those works as long as you're having like a one to one relationship between the beacon and the execution part. Thanks for mentioning that. Yeah, it's actually important. Thanks. Cool. Any more questions? I mean, the idea there is to have like a more of an opportunity, I guess, to end like their rewards and propose more blocks. And I guess on the other side, like to keep like more secure the network like the amount of validators is like a measure of security. Okay. Yeah. That is what I meant when I said that this is like the canonical way of running it. But there are a lot of things going on in like the sticking like part of the world. Well, like she said, if you want to learn more about distributed validators, go ahead. We had several great talks about it here at DEF CON. Yeah. We actually had a conversation about yesterday, Fred. It didn't take too long for someone to bring up distributed validators. I like it. Okay. I mean, keep the questions coming. It's really important. So now like we finished the configuration of our lighthouse client, we can actually jump into like running our docker container. So basically I, I need to, you know, do the current expose the port. And then I mount, I mount my configuration into the docker image. So it's accessible within, within docker. And then here, this command is fairly important, like validator client because lighthouse offers. It actually offers also to run the beacon node and the validator client in one process. But here, obviously we want to kind of like split it up, run it separately because we want to connect to a synced beacon node. Lighthouse also has this like argument in its session protection. So what it will do is it will kind of like set up a session protection database. I would have to point out though, is that this only works within your client that you have running. So if you have like two lighthouse clients running, then this slash in protection, this internal one doesn't help you. We specify the network. We specify the beacon node that we want to connect to. And then I need just this validator steer argument to tell it, okay, this is where my configuration lives. So then see, I'm pretty sure I've done this before. So if I have this command in my history, I don't have to type it all in. This looks good actually from my point of view. So I'm going to try and run this and hope it works. Okay, so what's interesting here in the logs. Okay, yeah, we want to run this for Prata. That's really important. Oh, now it's going quick. This is my, yeah, it found an enabled validator in my configuration. This is the voting public key. We can quickly check if that's true. Okay, this is the one we configured. What else is interesting? Oh yeah, this is really important. It connected to the beacon node. If the beacon node wasn't sync, then you would see this in here. It would tell you like the beacon node is out of sync. And now, yes, this is also very good news. So the validator that are running, that are running is known to the beacon chain. So that means we actually made the deposit already and it's active. Yeah, and this is a validator running. Now to show you kind of like a proof of this. We're going to go to beacon chain. Probably like one of the very famous tools to kind of like analyze your validators. I'm going to copy paste my public key. And now, okay, now it shows me some information. Here you can actually see like the statuses I was talking about. So when we made the deposit, it was in the deposited state. Then when it was like queuing, it was like in the pending state and now it's active. And the reason why it's red was, is because I wasn't, I wasn't, the key wasn't running anywhere. So I only just started the validator client with this, with this key. And this is why it's leaking.  Yeah, I think you can show like the attestations. Yes, exactly. You would see that we were missing attestations because we were offline. Oh, look, it's already attestations. Since started running. But yeah, you can see we had like a lot of missing attestations because we were offline. But yeah, cool. That worked out perfectly. We are attesting. Is there anything else interesting we can show in here? Maybe. I don't know. Yeah. Can you pass him the microphone? Yeah, no, since you guys had asked anything interesting. So one thing that we pay more attention to, I guess most validators probably pay attention to it to some degree, is the effectiveness rating. I don't know if you guys have already talked about that, but that can affect the, the degree to which you receive like a full amount of a reward for attesting or producing a block. Just kind of measures how like latency or how late you are in terms of being able to attest. Yeah. I can't see what it is right now because I'm like kind of blind. What is it? It should be at the top. Yeah. Effective. Effective in this rating. Okay. Yeah. I think it's 90 percent. No. Is it this one? No. 50, 50. Yeah. I actually don't see it. We can look for it. Maybe we'll find it. Yeah. Give us a minute and we'll find it. Yeah. But I think this is like, this kind of concludes the demo. If you want to kind of clone the repo. Absolutely. Don't be sorry. Actually, this is what a workshop is for. Like if you want to interrupt us. Absolutely. Okay. Yeah. Yeah. I guess I forgot to mention also something that is kind of important when I mentioned like the four choice rule when I went into that point. So basically what you're attesting to is the blocks. So you have proposed a block very rarely, but everyone should be attesting to like the blocks probably all the time. Like you would want to have like a hundred percent attestation rate. Like it's a little bit common in, in now improved stake. It is like the analytics show that it is a little bit more common to miss attestations. But yeah, you should be attesting each block and voting. And the reason I mentioned like the four choice rule is because a theorem is, has this rule of not like, for example, something like Bitcoin, which is like the longest chain, but it is the chain with the most weight and the weight is measured in attestations. So for example, if you had like a different choice between like two forks and one of them, then weights more like has more attestations added or yeah, there are like cryptographically added, I guess. Then that is the chain that it would choose you. Is there a way to withdraw the stake and rewards? Or is that also locked still the Shanghai update? Yeah, so like I mentioned, there's two kind of rewards like the execution rewards. You get them in your wallet and you can withdraw them like immediately from the free recipient address that you decide. So those come from like the different like transactions. So the transactions that you add inside the block, they have like a tip and you get those tips. And also maybe something more complex like MEV, like that also goes into that. And then the consensus one are the ones that are locked and cannot be moved. And those are added to like the balance. So for example, you can see there, can you see? Yeah, the balance left like 32 points something if, but you, what you added, what you deposited is 32. So you already earned something there, but you cannot move it yet. And eventually when withdrawals are enabled, there will be like probably two options like do like the full withdrawal. So like all the, all the basically either you have or like just the remaining like what is above 32 because you should always have like the 32. Okay. So specify. So the wallet address you entered earlier where you had it in the editor. That's the one where it received. You will receive the execution rewards there. Yeah. And you can move the frequency. How often they're paid out. I mean, it really depends because it is like determined by when you propose a block and that is basically random. So very hard to, I mean, you could like analytically say that, for example, you propose a block like once a year or something. But yeah, that would be like a curve like, yeah, you, you propose basically randomly, randomly chosen. Thank you. You're welcome. Okay. Okay. You first. Okay. Okay. Because you have the microphone at one point you said, like the, you are mentioning the difference between like the beacon node and the validator, the validator client. You do need a validator client to like sync with the rest of the, of the, of the consensus B2B, right? Yeah. The client needs to be connected to the beacon node. Yeah. And this is what I actually configured when I, let me show the command again. When you went to the YAML. Yeah. No, actually when I started the Docker container, I had to specify the beacon node that I want to connect to. Let me, if I can pull this up again, I can show you. And this is really important because other, like, if we don't have this, the validator client come, come run. So it's actually this bit where I specified a beacon nodes. And otherwise you wouldn't be able to start. I mean, could you have like one beacon node and run like different validator clients inside it? Yeah. You can connect multiple validator clients to one beacon nodes. Yeah. I think most clients allow for that. But yeah, definitely check the documentation. But I think most of them allow for a different beacon chain and a beacon and a validator client. At this point, like doing this workshop within and spin out the beacon node like you had it before. Exactly. Yeah. Because it just takes a while to sync. Yeah. Gotcha. Okay. Thank you. So two points. I believe you were asking about syncing, right? Between, so I think the execution client and the consensus client need to be synced. But like the validator client need to be connected. Yeah. Yeah. And the second thing regarding at this station. Sorry. And to add to that, yeah, they are synced because they are the parts that are actually connected to the peer-to-peer networks. So they have to sync to all the blocks. Just to add. Yeah. And regarding at the station, as to what I know, each validator need to attest once each epoch, right? Like each 32 slots. Each slot, yeah. Each 32 slots the validator has to attest only once. No, no. Right? Each epoch, you say? Yeah. I think, well, I think that they have these things called committees. And yeah, basically, yeah, to get a little bit more complicated. Yeah. 128 validators are chosen each slot to attest. And these committees are like rotating. So they rotate between, you know, because it would be, it would actually, it is already kind of hard to reach consensus in time with the amount of validators that exist. So there needs to be, like, other models to, like, aggregate the different signatures. And one of them is, like, the sync committees that it is what she's mentioning. Yeah. You are right. Hi. I just got a quick question. Sure. Quick question. Where's the execution client running? I mean, is it running with the, together with the node in this setup? Yeah. Like the execution client, we have, we have running somewhere. You wouldn't, you wouldn't see it because, like, the beacon nodes is connected to this execution client. And the beacon node is basically what we make available here. Okay. It is running on the corresponding one. Yes, exactly. Corresponding infrastructure. Thank you. I think you can show him the picture in this slide so they can have, like, the full, full look at the architecture of a node. That is what a node looks like. Okay. Like a full node. You have the beacon node execution engine. They connect. They talk to each other. So we have, yeah, we have both of them currently running on course infrastructure and we just connect to the beacon node with the validator client. You would be then talking about things like latency. For example, if they are, like, two separate you could fall into a situation where they don't communicate in time.  It definitely would depend on, like, the capabilities of your machine to do so. But yeah, you definitely have to, like, take into consideration, like, things like latency and, yeah, the capabilities. I think, actually, you're also one point. Let me go back to this, how to run this Docker command. You can actually connect to multiple beacon nodes. And this is sometimes recommended just to have some kind of, like, failover to make sure you're, like, connected, definitely connected to a beacon node. That was nice. That was, like, really nice questions. Yeah, thank you. What are we going to do? I think so, yeah, actually. Oh, maybe, maybe one point. The material is in conversation. Maybe, like, having walked through this demo, maybe you're noticing some kind of, like, limitations with this, like, setup. A few of them kind of, I think, are obvious, like, we have, you know, we, like, configure the local key storage can be maybe a bit dangerous if you just have, like, your key store locally with the decryption password. What you could do to kind of, like, improve this, you could actually store them in bold. In that case, they're also usually backed up. Also, because we're just running, like, one validator client, we are really dependent on the Lighthouse software. And this is exactly what Gabriella showed before. We saw this, actually, with Prism, like a few months ago. Like, they had, like, a lot of validator clients were, like, Prism was kind of, like, represented. And the problem is just, like, if there's really, like, a bug in the software, it can become really tragic for Ethereum, for the network, because it could be that, like, the chain can't finalize. And this is why kind diversity is so important. Just so if there's any errors, the network can survive. And then something you can explore in the exercises is, I already talked about the slashing protection that Lighthouse has. If you're actually running, like, multiple instances or multiple clients, this won't serve you. So there's one exercise. If you're, like, again, if you're feeling adventurous, you can actually use a remote signer. And if you have, like, multiple clients, you connect the remote signer that would also enable, like, slashing protection. Yeah. You just mentioned the, like, the key management part. If you could elaborate a little bit on, like, what do you see people actually do with their keys and, like, the good and the bad. And then the second part is from what I understood is basically these two JSON files, it's all you would need in case your computer that you're running a node will be stolen or burns down or whatever. So it's really, as long as you have those two files, the hardware doesn't really matter. Is that correct? You mean, like, the deposit data and the key store JSON, right? Yeah, these two JSON files. So the deposit data, essentially, you just basically need it, kind of, like, to make the deposit. And the keys, as long as you have your mnemonic, you can regenerate them. That's true. So if you're, like, hardware is broken, then keep your mnemonic and you can regenerate from there. And then spin up the node again, because as long as it's offline, you can spin it up again and then you should be good. Exactly, yeah. Okay. Yeah. And on your first question, one of the things that I guess is not an issue, but it is important to note is that you always need to have, like, your private key online. So you cannot have, like, offline, like, store securely in, like, a bolt. You need to keep it, like, online so that they actually add a network and connect, and you can actually sign. But like she said, there's these solutions, like the remote signer and, yeah, other, like, different kind of solutions where you can have it, like, remotely or store somewhere or, yeah, they... There are, like, a lot of things you can do in terms of, like, key management, and it is definitely important. I mean, I've known of people who have, like, their key freely on their computer, like, just signing like that. And, yeah, it's definitely, like, a security risk, even if you do have to keep it online at all times. Okay. Thanks again so much for the questions. Go on. So, um, piggybacking on what you were just saying about, like, best key practices, like, where could we, like, do you recommend any sources where we could read more about this and, like, those best practices? Security? I'll find those out for you. Okay. Thank you. There's, like, there's one section here which goes into, like, remote signers. Yeah. And if you, like, open this up, like, one example that I gave is Web PreSigner, which is fairly, like, it's, um, kind of a famous product actually. So if you go into this link, there's also, like, good documentation, because with this remote signer, I don't want to go too much into it because, like, you can, like, read through this like now. But there you can... I think it supports storing your keys on either HSM or in a vault or locally. Okay. And let's say that for some reason, like, those keys were compromised. Is there anything I can do or I go direct? What do you mean compromised? Compromised as in... You gave them to someone? Please don't. No, like, I connected my laptop to the HDMI and the New York Times Square screen. You connected the same computer where you're storing your keys on the... No, like, let's say, I don't know, like, everyone in DevCon had those keys. Like, they are completely compromised. Yeah, I mean, if they're compromised, I'm sorry, you just got wrecked, yeah. Okay. And, um, last question was, now that we went through all of these, like, this is the manual setup, right? Let's say I have my own hardware, I have myself... What are, like, the pros and cons versus using something like a stereo, more DAB node, or any other, like, simple UI, I'd say? I mean, yeah, those solutions are pretty cool. Like, they already come with, like, the pre-installed software, so you don't actually have to do, like, anything of these that I've just shown you. And, yeah, I personally think that they are good solutions for, like, first time stakers or anything. But, yeah, I think you get a lot more customization through your setup by doing it yourself and configuring everything. And, yeah, that gives you, like, a lot more flexibility into what you can do with the node. Yeah. I mean, the purpose of this is really to, like, share the knowledge, because this trend, I think this trend is, like, good to, like, make sure, like, a lot of people can run nodes, but they also oversimplify, which can also be a bit dangerous. So I think it's, like, definitely worth learning, worth understanding, like, the underlying kind of infrastructure. And with this, if we, if, like, more people actually customize their setup, then we would have more diversity. Because why we end up with no diversity is because everyone runs the same product and they run the same nodes. I would say on, like, the key management stuff, like at Coinbase, what we would do is we would import the key into, like, an in-memory embedded database. So that way you don't have to have it, like, you don't have to store it, like, on your disk so you could import it from, like, a vault, like, I don't know, like HashiCorp or something like that. If you set up the remote signer with Web3, stuff that Consensus has, you need to set up a Postgres database. One of the ways that they manage risk around key, like, let's say you lose your key, what they would do is that we have pre-signed messages with the ability to exit. If things got compromised, you would have a pre-signed message that you can just submit to the smart contract to exit, so you could also take that approach. Yeah, that is a good approach. I think it's always, like, a good thing to have, like, a database when you store what is happening with your node. So I think these are the signer keys, right? That is separate from the withdrawal key? Correct, yeah. So the risk that he would have if his keys were compromised is someone signing and then at risk being slashed. Okay, that part I have correct. What would the withdrawal... I know it's not available yet, but what would the withdrawal process look like when we're ready to withdraw some of our... That's an excellent question. I mean, that is to be specified by the Ethereum Foundation and they did, like, this whole discussion. I think it was day one or day two where they went into, like, the different possibilities for specifying that, but yeah. That's spec. He's not ready yet. Waiting, waiting. Any more questions? Honestly, I'm really enjoying this. It's been really nice conversations. I guess the idea, like, if you go to the repo and you unzip these key stores, we have, like, 16 keys pre-generated, already deposited and active. I would say you just choose randomly whatever which one you like and then if we're really lucky, maybe we get slashed. The worst thing that could happen is that we get, like, slashed heavily because you're using probably people will use the same keys. But I think that would be quite exciting to explore, actually. And you'll have these, right? You'll have access to it? Yeah. Everyone has access to the repo. Then again, unzip the key stores and you can pick one of them which you can run. You can run a demo and just continue. If you have any questions, just give me a shout. Happy to help. I think, okay, you have a question. Okay, yeah. But this is, like, the time for you to, like, do what we just showed you and see what happens.  I was going through that and everything was going fine and then I saw that they wanted me to, like, do port routing on my home router which was, like, opening ports on my computer to the general internet and that freaked me out. I wasn't comfortable with that. Is that necessary What did you say was that, sorry? In the, not yours, but the, like, how to set up your own validator website. I decide taking Launchpad when you click through it. So in that, one of the steps is to go into your, like, home router and open ports on your computer to the general internet and... Is it? So the only way is it somewhere here? Is it somewhere here? The only way where this kind of, like, would make sense is, like, for the beacon nodes to sync.  It just makes it easier for them to find more peers? Yeah. Okay. I'll say so. Okay, but it is not necessary. So there it is, the third check. I forwarded the necessary ports to the correct machines. So, I guess, yeah. So it's not necessary to become a validator. It just makes it easier to find peers?  No, I think that means, like, opening the ports for, like, the connection between the EL and the CL, like, between themselves. Does it sense, like, connecting to the internet? I don't see it. Okay, so if I am running my EL and CL on the same computer, then that is not necessary. That would make sense, because then you don't have to open a port, right? Yeah. Okay. Only for... Okay. Oh, can you answer the question? Yeah, okay. He has the answer. Let's see. So, it's not technically necessary, but we've run many different types of nodes over the years, and you will fall behind in synchronization. Yeah. So, it's meant for simply that the peer-to-peer network works. You need lots and lots of connections, and if you don't have any incoming port, means you will have outgoing connections. That will bootstrap, and you will sync the chain at some point. But the incoming connection pools is, like, a scarce resource on the network, and the longer you stay online, you sometimes get blacklisted by other nodes, and there are many different things that can happen. So, usually, what happens is that you see, like, you have... start with eight connections, and then it goes down, down, down, and you have one, and then you have maybe zero, then it tries to bootstrap again, and then you fall behind, and then you will miss some at the station. So, it will perform worse. And I don't think it's that critical. I think the most... Yeah, the 3.0, 3.0, 3. That is the majority of the data that needs to get pushed through. The other ones, the 9.000, is sort of... less... I'm not sure, I always open both, but I think the 3.0, 3.0, 3.0 is the most important one. Good answer. Thanks so much. That's exactly right. Those peer-to-peer ports are necessary for finding other beacons to communicate to. You need those to broadcast your messages, to sync as well. And the way that communication happens to your clients is it's going to reject something that doesn't match the spec. Even Coinbase has those ports open, so you should feel comfortable having them exposed. Yeah. I get your concern, but yeah. Let's start talking about network configuration. If you are in a hosted environment, what you absolutely must do is set up a local firewall for outgoing connections, okay? Because if you are in any sort of Hetsna or AWS or other environment that monitors for a network attacks, you will get your service contract canceled if you just leave it open like that. Because in the payload of the peer-to-peer network, people are injecting weird stuff, like not assigned IP addresses and so on. Your node will try to connect to those and that will be seen as an attack. And actually, I had to do that multiple times to restore my service contract with them. This guy runs out. Yeah. That's why I invited him to the talk. Okay, so I couldn't answer any questions. Thanks so much. So to continue what was being said about the ports, I'm actually a Lighthouse developer. I handle networking. The thing is that when you start your node, you connect to some peers. But on time, you're going to be dropped because you're going to prefer some other peers or, I know, maybe they're going offline, doesn't matter. You need incoming connections. And since in networking we are forwarding, let's say like, information about one peer to other peers so that they can connect between themselves, it's likely that information, if you don't have ports open, it's not going to be forwarded to other peers. And even if it is because I don't know, maybe it's wrong, and you are claiming to be reachable from the outside, they're going to try to reach you and it's going to fail. So yeah, it actually makes you vulnerable to attacks, not having ports open in that way. Because you need to have pure diversity. Exactly. Thanks a lot. Nice to see your letters. Cool. Who is trying? Who is going to see you? Are you guys trying? Do you find it difficult or what is going on? Wait, we have a question. Okay, we have a question. Is there some place, I know for the shortcut, you didn't show how to do the execution client in the different node. Is there some place where I could see that part of the process? Did you make a video of it by chance? Like how we set up the execution client. Yeah, I would like to see that. No, sorry. No. Slayer clients, they have documentation on how to go through the entire flow. It's setting up the execution layer, as well as the consensus layer client. In case you're trying to find a reference. Lots of documentation. There's a bunch of resources. Can you tell us more information about slashing? The two main things that, well, the two really big rules you have to follow are no, like you said, double signing. So if you have these keys running on a certain infrastructure, make sure to exit that infrastructure before you decide to deploy it somewhere else. And the second one is called surrounded boating. And this is like an attack tactic towards like trying to change the historical data in Ethereum. Basically trying to change the path of the network. And those are regarded as like attacks on their consensus. Like they affect that part. So that is why they are regarded as slashing conditions. I mean, you can have that. You can set up like, do we have like a database for like? The slashing database basically kind of like records who's currently proposing. And also like with this web-free signup product, if you have like multiple instances of it running, it would usually connect to like one kind of like global database. And by database locking it will always kind of like update like who's currently like, you know, signing which are the stations to avoid double signing. So like if one key is like currently like doing something then a second key, like actually the same key running somewhere else can't access it. Sorry? A small? No.  I mean, it's like this is like how you like, you know, record the state and make sure like kind of like lock someone else's to like make sure that you have like a current process. Yes, we mostly pretty much 100% tested and operated with running the same client type for both the beacon and the validator node.  Those different combinations. I know the EF Foundation they have, they test different combinations but mainly between the execution layer client and the content layer client, not between the two execution layer client component. Yeah, like yeah, we totally, we totally tested that. I think we still I've heard from a few clients like still preference to like kind of like lighthouse beacon node with lighthouse client. Sometimes we like just to ensure kind of like uptime you want to configure multiple beacon nodes there like you have the option like generally like so far it's worked, it's worked fine. Actually, I think I'm pretty sure that this beacon node is a technical beacon node and we just connected to it with a lighthouse client. So that's that's one test we run just now. Do the ones that are trying if you go into any errors or you find something cool to show definitely sure. Maybe now it's time to start some elevator music some launch background. So they play music at some of these things. Yeah, like that's exactly awesome. Thanks a lot for coming. I hope this was like really informative.  You can also run like just a full node without that does not validate and those just keep like the consensus going. So, yeah. I think that is possible even if you don't have like the 32. So yeah.


Does the narcissist know your worth? Many people are confused about if the narcissist recognises their worth. The narcissist often treats their victims with contempt, as though they are worthless or beneath their consideration. But just because they treat you this way, it doesn't mean that it's how they feel about you. It doesn't mean that they don't recognise your worth. When the narcissist first met you, they treated you well. They made an effort to appreciate and respect you. They treated you in this way because they recognised your value. They recognised what you had to offer. And they knew that they had to love bomb you to lure you in and secure you as their source of supply. They knew that they had to emotionally manipulate you with excessive amount of attention, admiration, affection, flattery, gifts and praise. They knew that they had to do this to win over your attention for the purpose of being able to control you. But it was never about sharing anything with you. It was never about appreciating everything that you possessed or had to offer. It was all about extracting everything good about you. That was the only reason why they wanted to be around you, because they knew that you would benefit them in some way. You had what they wanted, but as time went by, they began to realise that you weren't going to willingly hand it over to them. They began to realise that your qualities, abilities and resources were never going to be theirs. And in their minds, that made you selfish. That meant that you lacked consideration for them, or that you were only concerned with your own personal profit or pleasure. Even if you did support them financially or emotionally, it was never enough. They could never be satisfied with anything you provided to them. But they didn't see that as a fault that they had made. They saw it as though there was something wrong with you. As though you had made a fault and a mistake. As though you were being too selfish or greedy. They expected you to save them. They expected you to make their lives a lot easier and make them feel good about themselves. They held you responsible for their health and well-being. And you caved into their demands. And did everything you could to please them, to the point where you began to neglect yourself. But it was never enough. They were never satisfied with anything you did for them. This then made you feel as though you weren't enough. And the narcissist was quick to make you feel that way. They may have even told you that you're not good enough or that you can't do anything right. It made you feel worthless and insignificant. It made you feel like there's no point in trying. But the truth is it wasn't you. It's not that you weren't good enough. It's just that it's impossible to satisfy the insatiable desires of a narcissist. The narcissist feels as though they are not enough. And nothing you do can change that. Only they can change that by going within themselves. But whenever you are a rounding narcissist, they will quickly make you feel as though you are not enough. They have to protect their feelings about themselves on to you. Because it's too painful for them to deal with. It also makes them feel better about themselves by putting you beneath them. But you're not really beneath them. They are fully aware of your worth. And that is why they have to do this. That is why they have to put you down. And make you doubt your value and significance. Because if you really knew how great you are, you would wonder what you're even doing around them. You would be more focused on how they're not about anything. While you're doing all of the work. And that is why they have to keep you constantly looking at yourself. Doubting yourself. Questioning if what you're doing and who you are is enough. When the only reason that they targeted you is because they knew you were more than enough. They knew that you had something to offer. But they only got with you to take that from you. And when they realized that you weren't going to give it up that easily. They became resentful. They began to feel bitterness or indignation. And I haven't been treated unfairly. Because in their minds, it is unfair. They feel entitled to everything you have without putting any of the work in. While making you believe that you're not worth anything. Because if you knew what you were worth, you would never share anything with them. Because you would realize that they don't even know how to trick something out of value. They don't know how to take care of it. And they don't understand that they need to invest something into it for it to grow and become even more valuable. But they can't do that. Because they don't have anything to offer. They weren't expected to get everything they need from you. The narcissist recognizes your worth. That is what made you stand out among everyone else. That is why they targeted you. That is why they became so bitter and resentful towards the end. And that is why they cannot stand to see you move on.  You're not going to care if you don't have it anymore.  Because it's worthless. It has no use to you. But when it's something of value. When it's something that you know is really worth something. Something really rare. Like a diamond that you might not find anywhere else. You might travel to the ends of the earth to get that thing back. You might never stop thinking about that diamond. You might try to track it. You might keep tabs on it. You might observe it carefully and keep a record of it. Because you know you're never going to find anything like that ever again. Thank you for watching. I hope this video raised it with you. Please like, comment, share and subscribe. Click the bell icon to receive notifications for my future videos. If you were like to donate, my PayPal link is in the video description. Coaching and Chirings, you can email me at narksevercoaching at gmail.com. Thank you for watching and I'll talk to you soon.


So, with that, I just want to conclude my thought process here in terms of this thing. So the top most item which you think about it, which needs consideration from the NPD angle is the right pricing and some blueprint of framework of how the right pricing should be and it has to have considerations across the verticals and across the data domain as well. There are two aspects. Data domain is a horizontal aspect and the vertical is like your finance data or people centric data or say weather centric data or car centric data. So that is the vertical centric item. So how you're going to achieve it? So this might be a, I'll say it is a hard problem to solve. So this is something that needs to be thought about. Then the second is, as I told you, what is the protection for the data provider himself in terms of, of course, there are myriad of laws across, say, finance data. Now, suppose a company is having user centric data as well as the finance data. Now, what is the protection when they give out these data, when they do some aggregation using both these data sets because they have user dimensions as well as the finance dimensions and the NPD is forcing them to give a dimension which is blending these two. So how does, what is the liability protection available for that person? So for that data provider of the source. And the thing is, if you think about PDP, there is a usage. You need to get explicit consent for usage of a data from a customer. Now that usage, would you be able to enforce across your ecosystem, right? We talked about the tree, the federated tree, how it is going out. So what if some algorithm runs and tweaks the usage in terms of this thing? So what happens there, right? So the who has the honors of audit, whether it's going to be a government authority or who has the honors of audit or should I spend my own rupees on going and auditing each time the whole ecosystem is using it the right way or not. So that is another, another, another concern which has to be addressed there. And if you think about it, anonymization itself is a technical challenge. If you look at latest technical literature and all these things, truly anonymized data set is something very hard to achieve. It is achievable within a contained ecosystem, within your company. But say if a person is collecting aggregate sets from your company and 10 other companies and he's able to add some intelligence with this to the sum of the parts, you can get, you may not be able to get the exact name and the identity of the individual, but you still know or you have the digital persona of that person, right? So there is a problem there in anonymization itself. So the whole non-personal concept here, non-personal concept as well as data democratization, in the sense all the data sets available from all the companies outside, that sounds a bit oxymoronic to me in terms of how to achieve both together. And the last thing which we talked about in terms of the IP rights is if data is the USP of your organization, data or its derivative or its inference is the USP or the IP of your organization, pretty much I believe this commoditization, which the NPD is bringing about and scrutiny by public domain of all the assets which you are having, it can pretty much nuke that IP or USP of yours. So that is another thing, how it can be addressed with the data as a business, especially from a startup perspective, probably a group tech company who has trillions and petabytes of data points can still survive and go ahead and do new creation. But if you are a data oriented startup, which you're doing that, whether you have a viable business at all comes into question with this particular aspect.


Item number SCP-727-J Object Class Keeter Special Containment Procedures Due to SCP-727-J's size and presence, it has become increasingly difficult to contain. Currently a 1,500,000 km by 1,500,000 km by 1,500,000 km Carbon Steel Containment Cube is being constructed. However, current estimates predict construction with current foundation resources will take 150 million years. Until such time as SCP-727-J is contained, personnel are recommended to not look upwards during daytime hours, in case of any psychic attack from SCP-727-J. Description SCP-727-J is a large celestial object positioned approximately 149,600,000 km from the Earth, and is 1,391,000 km in diameter. SCP-727-J was originally considered to be of considerably smaller volume. However, examination by Foundation personnel led to the discovery of its large size and classification of the SCP object. SCP-727-J breaks several known physical laws. It does not fall into the Earth, but instead remains suspended above it. As well, it appears to be able to generate flame in the absence of oxygen, studying to how this has accomplished has been unsuccessful. SCP-727-J appears to have some form of psychic influence on the Earth, causing the Earth to rotate in a circular path around SCP-727-J. SCP-727-J also has a memetic effect of causing itself to appear to rotate around the Earth. This is suspected as a mechanism to make itself appear more harmless. SCP-727-J is capable of reaching extremely high temperatures. During testing, several D-class personnel were ejected into SCP-727-J. It all were found to be incinerated. Subtle exposure to the rays emitted by SCP-727-J causes radiation burns. Malevolence of SCP-727-J is suspected. Addendum 727-J-A During routine examination of Foundation airspace, Foundation personnel discovered several thousand possible instances of SCP-727-J. Construction of containment chambers for each instance is currently underway. Addendum 727-J-B Due to the increasing threat imposed by SCP-727-J, SCP-1543-J02 was commissioned and built for the purpose of attempting to destroy SCP-727-J with different objects. Addendum 727-J-C SCP-1960-J has been observed to temporarily disable SCP-727 periodically. Research into harnessing this technology is currently underway. Experiment Log 727-J Object Used Standard Class B Fire Extinguisher Observations The fire extinguisher failed to activate and spray SCP-727-J. Recommendation to use a handler of the fire extinguisher next time. Object Used Standard Class B Fire Extinguisher D-Class Handler Observations D-5673 failed to activate the fire extinguisher before being incinerated by SCP-727-J. Recommendation for handler to be wearing an airtight suit. Object Used Standard Class B Fire Extinguisher D-Class Handler in Airtight Suit Observations Amount of foam generated by the fire extinguisher insufficient to extinguish SCP-727-J. Recommendation to build Jupiter-sized fire extinguisher. Note Jupiter-sized fire extinguisher currently under consideration. Object Used 150 km long fire hose connected to the Pacific Ocean. Observations failed to make any noticeable change. Project abandoned after five days. Object Used 1435 D-Class personnel instructed to stop, drop, and roll. Observations SCP-727-J failed to be smothered. All personnel incinerated.


Hi everyone, Sean with jaspyscasebreaks.com here doing 2021 tops tribute baseball six box case break pick a team number eight where all card ship and almost sold out straight up. We had one random number lock you'll see here's the list of customers respective teams from Joel Almindo and the Diamondbacks down to Gregory, Judge Kowski and the Nationals two teams in random block including the Phillies and the Orioles and there's the random number block results there that randomizer and everything is all done in a separate video that's already been uploaded and here is our finalists here's that finalist from Joel and the Diamondbacks down to Greg, Judge Kowski and the Nationals and our final random number lock randomizer there and here's our case our six boxes starting off with Jacob DeGrom out of 99 for the Mets Steven Silivasi, Walker Bueller for the Dodgers and Kyle Seager, Triple Relic 72 out of 150 for the Mariners, Chris Walker Letterman, have a good day man, got a redemption it looks like on the bottom of this one Cal Ripken Jr for the Orioles and Willie Stargel for the Pirates and our redemption is blue parallel autograph of Joe Adele for the Angels Joe Kroll nice one there Justin Verlander for the Astros and Johnny Bench for the Reds we've got Ronald Acuna Jr 15 out of 50 stamp of approval relic for the Braves and Joe Kroll Paul Goldschmidt for the Cardinals and Francisco Lindore for the Indians and Dennis Eckersley 14 out of 199 auto for the A's and Greg Mathenia, Tom Siever for the Mets and Albert Pujols for the Angels and we've got a dual relic of Ion Moncada and Frank Thomas 25 out of 50 for the Chicago White Sox and Mike Schlecht and Alex Bregman for the Astros Ken Griffey Jr for the Mariners our final auto is Jorge Saler 71 out of 99 for the Kansas City Royals and Ben Murasek nice first box with that redemption especially this is everything good luck sander Bogarch for the Red Sox Mike Trout for the Angels and triple relic and Glaber Torres 111 out of 150 for the Yankees and Gordon Phillips Ty Cobb for the Tigers and Jackie Robinson for the Dodgers and for the Red Sox 91 out of 199 Michael Chavis that is Jonathan Kent Cody Belanger for the Dodgers and Kettle Martay for the Diamondbacks and dual relic Marcus Simeon and Matt Chapman 75 out of 150 for the Oakland A's and Greg Mathenia Boba Shet for the Blue Jays and Bryce Harper for the Phillies and we've got Jim Rice 11 out of 150 for the Red Sox Jonathan Kent Max Scherter for the Nationals and Hank Aaron for the Braves and we've got Miguel Cabrera 21 out of 25 for the Tigers Jeremy Rezzer and Mike Schmidt 98 out of 99 for the Phillies part of the Random Number Block going to spot eight PJ McNeely Tatis for the Padres Yvonne Rodriguez 32 out of 50 for the Rangers and John Gotti box number three want to see some Cleveland Steve says we can do that still got half the break left as well as this box want to see a trout and a book that'd be pretty cool I'd be okay with that Stephen Strasberg for the Nationals and Lubab for the White Sox and we've got a dual relic Miguel Cabrera and Yvonne Rodriguez both Tigers versions 65 out of 99 you don't expect to see that Pudge Tigers edition no randomized Roger Maris for the Yankees and Anthony Rendon for the Angels took a leg AJ Puck 4 out of 25 for the A's Greg Bathenia Kyle Lewis for the Mariners and Wade Boggs for the Rays and Andy Young rookie Otto 117 out of 199 for the Diamondbacks and Joel Almondo nice Joey Votto Red 5 out of 10 for the Reds Jeremy Rezzer Ronald Acuna Jr. for the Braves and Dylan Carlson rookie for the Cardinals PJ McMillan Evan White rookie Otto Blue to 150 for the Mariners Chris Walker the Joe Adele was a blue parallel so that should be numbered out of 150 just like this one here Babe Ruth for the Yankees and Tony Gwyn for the Pods and Austin Meadows Relic 85 out of 150 for the Rays Joshua Grebel Josh Bell with the Pirates and Vlad Guerrero Jr. for the Blue Jays and 42 out of 50 Raphael Devers for the Red Sox Jonathan Kent I like these old school looking ones yeah very dirty very dirty on the Austin Meadows a little down and dirty yeah the old school the the retro looking autos those things are super cool halfway down Eordon Alvarez for the Astros and Christian Yelich for the Brewers and nice triple relic 88 out of 99 for the Phillies JT Rial Muto part of the Random Number Block Spot 8 PJ McNeely Walker Bueller out of 50 for the Dodgers PJ McNeely Juan Soto for the Nationals and Austin Meadows 15 out of 50 for the Rays Joshua Grebel Jacob DeGramme for the Mets Roger Clemens for the Red Sox and dual relic Michael Conforto 79 out of 150 for the Mets little pinstripe on the left Mets is Steven Spill Lazy Mike Schmidt for the Phillies and Miguel Cabrera for the Tigers and William Condreras 152 out of 199 for the Braves and Joseph Kroll Hugh Darvish for the Cubs Aaron Judge for the Yankees and Jesus Lizardo 73 out of 150 I believe was scratched from his pitching yesterday because he hurt his hand playing video games or something like that Oakland A's that's Greg Mathemia and Whitmerefield for the Royals Carly Stremsky for the Red Sox and we got another one Adrian Beltray 15 out of 25 for the Texas Rangers that's awesome looking Rangers John Gotti Jesus Lizard yeah same guy I think he was playing video games before the game and literally like strained his thumb or like something in his hand strained a muscle in his hand Aaron Nola for the Phillies stack them first Johnny come on guy he's going straight into look mode fractured his pinky Steve says okay bumped his hand against the desk okay that's understandable Honus Wagner for the Pirates Javi Baez for the Cubs and Carlton Fisk triple relic 51 out of 99 for the White Sox White Sox Mike Schlecht Blake Snell for the Rays Duke Snyder for the Dodgers Eloy Jimenez 19 out of 99 for the White Sox Mike Schlecht is just falling apart for the White Sox unfortunately Eloy Pectoral Lubab hip flexor right Glaber Torres for the Yankees Yadier Molina for the Cardinals and Wilson Contreras 47 out of 99 for the Cubs Jonathan Arnaldi Ted Williams for the Red Sox Mookie Betts for the Dodgers oh that's a good name Ronald Acuna Jr 41 out of 50 Otto for the Braves and Joe Crowell there you go Joe congrats man I hear that guy's pretty good Ken Gravey Jr two out of 50 for the Mariners Chris Walker Luke Gary for the Yankees and Michael Conforto pinstripe relic for the Metz Steven or Steven Spilvazi and Joey Gallo for the Rangers Aaron Nola for the Phillies Carl Yastremski Green Monster Wall Graphs 25 out of 25 for the Red Sox and Jonathan Kent that is a legit piece of the Green Monster and his auto that is cool little Yaz Yaz up your life a little bit you know I pulled a Jim Rice from this when we were when it released I would think if I remember correctly Betts that is very cool for sure you pulled you a Trevor Story it's cool but it's yeah I I don't get it I mean I could imagine like if it was people all over that like let's say crush the Red Sox like for his like historically had like great games at you know in Boston but it doesn't make any sense unless it's like all Red Sox players but whatever it's cool I like it Willie Mays for the Giants Austin Meadows for the Rays and Nick Madrigal for the White Sox Mike Schlecht Al Ripken Jr 11 out of 25 for the Orioles that's part of the random number block spot one PJ McNeely good old Cal so what you're saying Oliver is the Yastremsky is not good enough Oliver does not like the Yastremsky JD Martinez for the Red Sox and Joey Votto for the Reds and we've got Michael Conforto triple relic for the Mets 67 out of 150 Stephen Sylvazi and the Mets Josh Donaldson for the Twins and Garrett Cole for the Yankees and Josh Hader 63 out of 150 for the Brewers and Montes-Stibbett it's great real great last half of the box new Dardish 55 out of 99 for the Cubs Jonathan Arnaldi Randy Johnson Diamondbacks edition love that and Miguel Cabrera Yvonne Rodriguez Pudge again 121 out of 154 the Tigers Jeremy Rezzer why don't I remember uh you Pudge Rodriguez Tigers edition did he not just not play because of uh Miggie or I mean well no they don't even play Pudgy why don't I remember Pudge Tigers edition Charlie Blackman for the Rockies Ricky Henderson for the A's and Yon Mancada pinstripe relic 96 out of 150 for the White Sox Mike Schlett one of his last teams Freddie Freeman for the Braves Joe Kroll uh Frank Thomas for the White Sox and our last auto is Maximum Muncie 141 out of 199 for the Dodgers PJ McNeely his legal name is Maximum it his he just shortens it to Max which I think he should actually go by Maximum super cool uh for the Dodgers like I said PJ McNeely to end it and there you go guys we've got one randomizer to do which is for the random number block for the non numbered cards and since it is a random number block we're going to do it based on the numbers so zero through nine number on top after uh one and one two times gets the non numbered cards for the Phillies and the Orioles one two spot two which is Joe Kroll you're going to get all non numbered cards for the Orioles and the Phillies from the random number lock and there you go guys that's the break that was 2021 tops tribute baseball six box case break pick your team number eight from Jasper's case breaks dot com I'm Sean Jasper's case breaks dot com thanks for hanging out I'll see you next time