 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. And if you are dishonest then you basically can you lose this bond. 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. I'm not going to do it all in front of you. 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. And then as the as Gabrielle already said, like you, I mean, if you're validator like participating in consensus and everything's going great, you're getting rewards. 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. So if you're, if you're like, like, this is why validator uptime is so important, because if you don't ensure that your validator is like running, you will lose some of your deposit. 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. So when you are, like, trying to, I don't know, propose a log and you go into the consensus, you missed a slot. 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. Yeah, specifically, but you mentioned you showed the, like, set up your own validator demo site that they have set up. 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. Because usually what they do is I mean, either, like, you configure it that you have, like, checkpoints, but usually they, like, really, like, try to, like, you know, find other, like, nodes. 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? I mean, to be honest, like, now I'm not so confident anymore. 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, I guess, yeah. 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. Have you guys tested running like a prism validator against like a lighthouse beacon 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. We definitely want to promote everyone that if you're supposed to run a node you don't even have to run like a validator node. 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.