Hashing It Out
Hashing It Out

Episode 93 · 1 year ago

Hashing It Out #93 - Sigma Prime Mehdi Zerouali

ABOUT THIS EPISODE

Corey and John speak with Mahdi Zerouali of Sigma Prime on how ETH 2 is going to look like for users of Ethereum.

Links: Sigma Prime

Sponsor Links

The Hashing It Out Social Media

Hey, everybody, got an awesome episode for you today, but first gonna do a word from our sponsors as well as give you a little more administrative stuff going on in the back end of hashing it out and things are involved in that you can you can become a part of. So first off, like to thank you, thank our sponsors, avalanche. Avalanche labs, the highly scalable open source platform for launching to centralized financial applications, recently raised about forty two million dollars through a public sale and now gearing up for its next milestone next week, the launch of its main net on September twenty one. That's right, they're launching their main net September twenty one. So get prepared also to strap their ecosystem. Avalanche opened up a bunch of new grants for developers who want to build high performance defy that's decentralized financed applications and infrastructure. They have open calls for projects like a decentralized exchange learning daps, step cooins, with more at it every week. So they also accept applications for other decentralized projects to join the avalanche ECO system. So go bill and avalanche build it. Out Limits and you go learn more at Avel labs dot org. That's a VA labs dot org. As for what we're doing it hashing it out. There's two things I want to talk about. First is hashing out is a part of the Pan Vala League. If you don't know what Panvala is, look back a few episodes and we did an episode mode with Neuron about what Painvala is held works, so on and so forth. It's really awesome project that we're happy to be a part of. So this round Pan Vala is donating about, I think current pan prices, about a hundred and Seventyzeros to the etherium community. How does it donate those things? Where does it figure out how to donate them? Well, the Pan Vala League has geitcoin grants and hashing it out as part of the Pan Vala League. So we have a geitcoin grant that basically is a multi sick and if you donate to that geitcoin grant with Pan it will get matched not only by the clr matching of typical getcoin grants but also additionally by the hundred, Seventy Tho that Pan Vala is giving out. And then we're going to use that money that's raised through that grant, with the advice and decisions hold from the etherium security community, to fund security and infrastructure projects. I we believe that hashing it out, that security infrastructure is a very underfunded but incredibly vitally important part of the ecosystem that needs more funds. So we're going to try and do that and you can help by donating pan or whatever to the good coin grant, the getcoin grant. That's going to be in the description of this episode. So get your pan donated to us. Will full fund a good place for it to help SUC MELP the security and infrastructure of the theorem ecosystem. And other big news that I don't think I've mentioned on the podcast yet is hashing it out is leaving the Bitcoin podcast network because the Bitcoin podcast network is no longer in network. It's just a Bitcoin podcast. So over the next maybe ten or so episodes we're going to be continuing on this this feed that you're subscribed to now, but in the process there's going to be a new feed that's only going to be hashing it out. You'll need to resubscribe to because at the end you're not going to be able to get it on the feed you're on now the Bitcoin podcast. So we're gonna have their own thing. We're going use new branding, try and odd of some more resources and so on and so forth to the show so that you can be a little more stable. I don't know, we'll see, but we're going to have own feed. Check out, listen up for it, check the twitter, see whenever we are published. That, but at least you get to just listen to us and no one else. It's going to be great. Bitcoin podcast is going where. I'm still doing that. It's just two different feeds now and onto the show. No, joy past work. Welcome to hashing it...

...out, a podcast where we talked to the tech innovators behind blocked in infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Welcome back to hash out on your host today, Dr Corey Petty, with John and today's episode we're going to talk with many Zer Ali. Think us at that right. Let's say I said that right from sincer prime and the main focus today's episode is going to be around kind of a theoryum too, how it works, kind of a couple Gotcha's, what to expect as a user and kind of the time wine around there. So I started off John, which say hello real quick, hello, hello, real quick. Let's get out, you know, let's get hashed. And some of these have cheesy tagline for the show. I'm working on it and about new ones on and Maddie, give us an introduction. I don't think you've been on the show before, but we talk quite a bit. So tell us about yourself and sicker part. Sure. Hey everyone, my name is Meddie. I'm a cool founder and director of Seema Prime. We are and information security consultancy mostly based out of Australia. We've been hiring a bunch of people all over the world lately. We've been around for about four years providing security assessment services to a lot of block chain projects, working all most exclusively lately on etherium, providing security assessment on smart contracts, on a lot of protocol layer developments, and I guess we are here to that. Talk about Eve to, because we are also the founders and maintainers of Lighthouse, a rust implementation of the etherium. To point of specification. Thanks for having me. Yeah, sure, real quick. What would you say the guess technical advantage or differentiator a White House has over other ether or two hip implementations? That's a good question, question that we get quite often. We because of, I guess, the DNA of the company. We're an information security consultancy. We take security very seriously. We'd like to think that we've incorporated security into our development life cycle very early on. So would like to think that our clients is probably one of the, hopefully the safest, was secure clients out there. It's written in Rust and Rust is particularly fast. So the focus has also been on performance, speed and, as I mentioned, security. So that's probably what the friend shakes us from the rest of the other teams. Want to give you a moment to pitch chill out to comprime of the process that tell people wise like lighthouse is good. Nail's offended. Yeah, so I guess that the approach here is the kind of breakdown the concept of a theorem to and what's going on and what you just can expect. So I'm not exactly sure how I want to do this. The conversation is going to naturally evolved, I think. But like if you had to give the highest of high over level overviews of the transition from F one and F two, or would you say, okay, let's have a crack at this. So F one is the proof of work chain that we all love and use and, as...

...you all probably know, the plan was always to transition to a proof of steak and sensus mechanism, so namely Casper FFG. So the research team has been working on this, the your and foundation research you have been working on this for the past four or five, perhaps six years, and the implementors have been developing the specification, turning it into actual usable software, for the past two, two and a half years. The main difference, as mentioned, is the consensus mechanism, so moving away from proof of work, which is quite a wasteful way of coming to consensus, if you ask me. I know this can be quite polarizing in our community, but this is basically how Paul, my co founder, got started on lighthouse. I think eitherium currently uses as much electricity as Costa Rica, if I'm not mistaken, and we think at signal prime that there's, you know, much better ways of coming to consensus and casper a fifty is one of them. So super excited about the environmental impact of the transition from proof of work to proof of steak. And this transition will happen gradually. will be shipping, if to, in various phases. So phase zero is the first phase. That will be introduced, hopefully in a few weeks time, a couple months the latest, certainly DC here's what we're aiming for. And this introduces the Consensus Change Right. This introduces the proof of steak consensus mechanism, CASPAR FIFG, and we essentially call this chain the beacon chain, and you can see it as this orchestrator that gives sort of the pulse of the network to value dators, giving them tasks, rewarding them when they do their job correctly, penalizing them when they don't, etc. Etc. So That's phase zero. That's what I guess all client teams are working on at the moment, and phase one will hopefully come shortly after. And Phase one introduces charts, the concept of shards. So eitherium to pointer will be a shattered block chain, meaning that will have sixty four sub block chains. You can see them, as you know, so independent block chains that are all linked and tied with each other through by that consensus mechanism in the beacon chain. So once we have that, will be effectively using those shards just as data availability layers. So we won't effectively have state transitions or user sort of smart contracts or transactions, as we are all familiar within eath one. That will come in layout. So there's talks about a phase one point five, which hopefully will get, if one, into eath two and have that as a separate, dedicated shot, and then phase two will introduce, I guess, proper state execution and smart contracts, and this is when will actually have a blockchain, a usable blockchain for developers, as will well familiar with with with you here in one. That makes sense. Yeah, yeah, I guess we're done here. Then let's drop up gas. Maybe can you can tell us a bit more about how Phay Ero like? What do you mean when you say be chain? What does it do? It's like the base functionality that we get. Then cool. Something I forgot to mention is that to transition from Eth etherre in one...

...to etherium to we're going to have a deposit contract on etherium one. I think that's quite important to mention for our listeners. The way you're going to become a valid dator is by depositing thirty two ether into the deposit contract on the etherium one proof of work chain. As a result, you will become a value data on the beacon chain, and the beacon chain is effectively a set of comprise, a set of validators that are there to propose blocks and vote on what the canonical sort of chain would be. The way it works is by leveraging Tas for FFG, which is the consensus mechanism that we use on you too, and allowing us to, yeah, just sorry, allowing us to essentially coordinate the work of these valid dators. So Valui dators are incentivized to be online to perform their duties. So there's effectively two types of duties, perhaps three, but let's just talk about these two proposing blocks. So the beacon chain had as a schedule that we call slots. So a slot is happens every twelve seconds. It's just a time window, right, and within that time window you have a value data that is expected to propose a block as you can imagine, if that value there is offline, well, that's loot. Won't have a block. So I think it's quite important to try to distinguish and understand the difference between slots and blocks. Slots are just the time window. Blocks fit in one slot, potentially if the proposal is doing their job correct. So that's one of the duties. What's in a block, in a home, is what phaserrect great question, as a whole heap of stuff in a block. So we don't have transactions per see, as mentioned, but we do have information that available from the etherium one chain. Remember I mentioned there's that deposit contract. We need a way to effectively translate some of that information from fone to F to, and there is an f one data field in each block and validators are responsible for effectively processing deposit logs from the F one chain and translating that information into the beacon chain, and that happens using that particular field. Another interesting, I guess, message or field that's in a beacon block is what we call at the stations, at the station's you can basically see them as votes. So remember how I mentioned the first type of duties, the production pose proposal of blocks. is another type of duties, which is the at the stations and having validators tests to what the their view of the chain is, and those votes or at the station's are effectively aggregated and put in beacon blocks, if that makes sense. What else is in there? We have the rand out, so a great way. So one usual sort of question is, well, how do I know which block am I supposed to vote for or which slot am I supposed to propose on? And this comes with the should. This is usually explained by referring to the Shuffling Algorithm. So shuffling is spectively, you take a set of validators, you shuffle them and that gives you their roles...

...and responsibilities for each one of them per slot. So in order for us to do so, we need some sort of entropy, right, and the entropy is basically a rend out type of entropy mechanism. So Randa is whereby is where you have a group, selected group of participants that each proposed but each give come up with a random number and then the actual random number used by the system is a result of sometimes just exshore an exclusive or of all the inputs from each one of the participants and that's how we get our randomness and we then use that randomness to essentially get assign validators to various duties, including block position and at the station, to give what, if I signment of what shards a particular validator will be validating, also to sign at the point yea. So that's coming into play a bit light up, as mentioned. That's that's phase one, phase one, point five, phase Jo. But yes, the idea is to use that entropy, that source of entropy, to assign people to what we call committees, and committees are responsible for validating transactions happening on specific shots. Were absolutely CANNA. Can any any one validator be assigned to multiple thing, like multiple slots or shards at the same time. So each validator is guaranteed to a test at least once, or I think exactly wants per epoch right. So any park is thirty two slots. One Slot is twelve seconds, so an e park is roughly six point three, six point four minutes, and within that time frame you are guaranteed to attest to what you see is the canonical chain at a certain slot. So an in terms of block proposals, there can only be one block proposal or slot, and this this probably you know. Might start talking about slashings and how we police the network and make sure that the validators are doing their job correctly if you see someone proposing so of twice. Right, if I'nd the block proposal and that particular slot and I'm caught proposing two separate blocks on that same slot, that is a slashable offense. Right. We can't have that. We can't have people proposing blocks are right, left and Santa. So if someone catches you doing this, they can simply submit a proof of you doing so, which is kind of trivial. Right, you've been signing to conflicting messages at the same slot, you don't deserve to be part of this anymore. We will slash you and kick you out of this great network. So we can perhaps talk about slashings a bit, a bit later. But yeah, so we can't have two separate two different value theators on the same slot. But what we do have multiple validators net sort of securing and validating transactions on each shard. Good. That's kind of curious about that in terms of the kind of a committee selection around the different tasks at hand. So this will be hardened with what we call vdfs. Oh Dear vidf stay for Oh my God, I'm sorry, verifiable thank you. Verifiable play functions.

So because the rend out sort of entropy mechanism is kind of gamable, right, like if you're the last person, you can essentially say, well, because I'm the last person, I can see what everyone else produced and then decide to reveal my vote according to my own interest, right, and we can't have that at all. It's obviously extremely difficult to actually pull out. Like this attack is not sort of trivial but satis flashable offense. To cannot reveal not really okay, yeah, but well, it's just like it will. It will kind of come into an off lines of penalty. So yeah, because, like, by the way, you're like, oh no, I'm not interested in producing this particular block and revealing my rend out. If I'm the block people was are we can't really tell whether that was that was the maliciously or if you were just offline. So isn't it? Isn't that? Let like, I thought that's part of the job of validating. Is Being offline, right, he's been online, right? Is Online? Yeah, totally. Yeah, so you want in you you incentivize people for being online and you penalize them for being offline, and the penalties of being offline are basically kind of the same as the reward of doing your job correctly. So you obviously lose the you know, there's the optionity cost the winnings that you don't make, plus an actual penalty. That makes sense. So I think we should at some point try to clarify slashings versus penalties for being offline. A slashable offense is essentially triggered when you can prove that there has been equivocation. Right, there has been malicious activity. Well, to me, to be perfectly fair, it does not have to be malicious. It can result in a software bug, right, if you're running sub software that's, you know, having difficulties keeping track of the head of the chain and has been sort of a testing letting you attest to, you know, separate sort of chains at the same time. This and you you're not even knowing. That's not really malicious, is it? That's probably just, you know, result of a software bug. But this is provably an equivocable sort of message. As per the Casper FFG, slashing conditions, whereas if you're a fly, well, you're offline. You're not. It's not software bug, you're not being malicious, it's just kind of tough luck. I don't know, your Internet connection went down or you write out of disk space or for some reason you're electricity in your house went down. So we need a way to insensivized people to keep their nodes online, but at the same time we don't want to penalize them too much if they're missing at the station's or missing blocks proposing blocks for various reasons. So that's kind of the tradeoff, and this is where I think we should be careful when we communicate with the broader community around penalties. In the eat to space. Is Two types of penalties, I'd say slashing shall offenses and then the offline penalties, the provable cheating and like unprovable non participation. kind of that's right. That's right. Yeah, and you also have care of carrots too. It's not just all sticks. So like, yeah, what are you? What do you get on the beacon chain in terms of carrots? Like why would, why would someone be the centifized to do this and that will? That's going to shrinkboard me in sort of conversation later that I would like to talk about around kind of use your expectations. But like one of the carrots, why don't? Why would potem I want to do this? Because you would get some sweet, sweet rewards. It's go to pot strap the Beacon Shain. We need some ether right to be locked in this depolit contract and sort of turned into either into the beacon chain, and the way we incentivize people to do so is by giving them rewards, and those rewards are effectively if I recall correctly,...

I haven't seen the calculations in a long time, but with the threshold, the very minimum that we require to put strap the beacon chain, I think we're looking at about twenty to twenty two percent return the yield per year, which is pretty decent. Obviously there's a lot of risks sociated to we this and we can we can talk about it, but this is how this is the carrot that you're referring to. Corry, the quite juicy returns for early adopters, early participants that are willing to sort of risk or commit to securing the beacon chain. was that a function of what does that return percentage of function of it's a function of the total number of Validators, Aka the total number of ether locked into this new system. So the more ether we have, the less yield will get, if that makes sense. So you really want to incentivize people to do so, to to actually lock in their eath. So the very first people to to to have done that will effectively get a very, very high yield. But that yield will slowly decrease as we get more and more or validators onto the beacon chain. So there's a there's a fixed budget like say, like block reward. Maybe not fix but like it doesn't go up if there's more validators, right. So in the first week the plan is to issue some amount of eath to and reward the validators. And so the more validators there are, the less ye, the less exactly exactly, and we can't really predict how many validators will get right. We can only we can only be sure that will only bootstrap and kick off the beacon chain if we have more than a certain number. I can't remember the number of the top of my head, but it is obviously public information and it's on the two spects. Repot on light will definitely put that spects repot on the subscribe the show. Where does that? You've come from? That's brand new East and if so, what does that mean about issuance on the main chain? The interesting question. That is brand new eath and that would, I believe, be part of the total inflation of the etherium currency or cryptocurrency and whatever you want to call it these days. So for a while we'll be running two parallel chains. Right, we'll be running you're in one point Oh, the proof of work chain that we all know and love and used today. Any theorem to point out theorim one point Oh has a block reward. Right. This is how we incentivized minors to do that job. Spend a lot of electricity validating transactions, on top of obviously transaction fees, which I think these days account for the vast majority of the actual as. I think the first time we've actually had a blockchain that has equivalent transaction for use to district to two issuance. Wow, on a public network. That's that's Hexy, which I was talks for users that aren't doing defy stuff. But yeah, it's pretty neat, I guess. I suppose. I guess it's kind of working as it intended. But yeah, so that there's the inflation of the proof of work chain, which is I believe to ether per block, if I'm not mistaken. Keeps changing every now and then, but should be tweetter per block article correctly, and on top of that will be adding the inflation of the beacon chain, so that issuance that we were referring to will effectively come out of the inflation or the issuance the total overall issuance budget of the theory. Maybe when the next phase happens we'll do this again. I talk about how transaction fees and cross SHARD transactions plan to rewards,...

...because that's really going to be something, but maybe not all the details are hammered down yet. So I agree it's probably for another conversation. All right, cool, let's see. Where do we want to go from here? I can change this stuff entirely and less on. You have something you'd like to continue here and I don't have anything on the tip of my tone. Okay, I kind of want to transition and like now that we have I think that's a maybe the best verbal overview of kind of what you can expect the how that be, can chained to work and what its functions are in terms of phase zero and within the context of all the the larger phases. What I don't think is very good public knowledge is expectations from a user standpoint. What's the process of me getting a validator, submitting my money into the fone deposit contract and then being prepared correctly for when the chest that's start, for when the main chain starts? We've seen from previous test nets is that people love looking up test not either. We have the GALIVATORS, but they hate having notes that are ready. When? When? When the live? Totally how do we? How do we? How can we get users to understand what they need to be doing and the associated resources that are required from them and like yeah, what the optimizing for in order to do that? There's a few things here, I think, in your question, Cory, the first one is probably the challenge of running and incentivized test nets. So people are Super Keet help and you know they're they've got girly at, then they're key into looking their girly at into the deposit contract, but when it comes to actually running their nose, well, you know someone else is going to do that. It's okay, I don't really need to, because there's if I end up losing my girly at well, it's not worth anything. So doesn't mean we don't really get so I think that's what we've been facing, as in we, the two development community, is that problem of like incentivizing people to actually know help and run their nose when when we launch these test nets. One of the one of the great, I guess, incensive mechanisms that are out there is the popes pull ups. I never know how to pronounce that, but it's a great it's the proof of attendance protocol. So if you do your job correctly on a test net, you get a nice and ft which is sort of a badge that shows that, hey, I was one of the people that sort of helped boots trap the eath to network by testing, by running valid dators on certain test nets. This is not necessarily enough, as we've seen with da Ya, dashaw and Spadina. So SPADINA is the latest, was the lattest test net called or described as a dress rehearsal for valid dators to, you know, essentially play with the deposit contract and generate their keys and run their clients accordingly. We know a bunch of people that took these very seriously, a lot lot of people that are planning on running a bunch of validators were super keen on trying these things out. But for the chain to come to finality, and that's the concept that we haven't actually spoken about yet, but we need at least two thirds of the network to be doing their job correctly. And if you have, you know, more than one third of the network not doing their job correctly or being offline, then your you have this chain that sort of lingering and not finalizing. And finality is this beautiful concept that we have any to that allows us that that that is responsible for so many optimizations in eat through clients. So if you have to keep track of all the potential forks and reorgs and heads and of the multiple chains that are out there, it's a...

...heavy load on each through clients, on the actual blockchain nodes. But when we finalize an Ebok or a slot, we basically come to the conclusion where we say hey, network, everyone here agrees that up to this particular slot, number those transactions cannot be reverted. This is now the canonical chain and will forever will be. So then clients can go like, okay, sweet, once we all agree to this, I don't need to keep track of all this information. That's, you know, exhausting my resources. I can then use, or at least lighthouse uses, two types of database, as a hot butt of it in a cold database. The hot database is where we put all the non finalized type stuff and once we hit finality we can be like, okay, sweet, I'm going to transfer, I'm going to move a bunch of that information to the cold that of it. So I think what we've seen on those tests nets is long periods without finality because we don't have a wet incentivized people to actually do their jobs correctly on these mark networks. There's been chats about having incentivized test nets and whatnot. I think after even said that. Well, phase zero is the INSENSIVIZED dest neet for each to yeah, because it's it's an interesting way to look at it. But to sorry to go back and been derailing a bit, but I thought it was quite important to to mention that. But you did that. That's in a very important aspect that I think people in understand is that if you don't have the right amount of participation across all of elevators that are registered, then the chain doesn't come to finality, and that's right. It causes a tremendous amount of havoc. This was probably the best thing that could have happened to those destinets through Natasha, because, as a result, every single client team has been pushing a hard to optimize their software to handle these particular case and I think that by having that very low obsipation level closing havoc on the test net, client teams have been working really, really hard to make sure that if this ever happens on my net, which is, if you ask me, quite unlikely. Going back to the carrots, people like carrots, people like working towards rewards and people will most likely keep their body data is online. But if, for some reason this happens on my net, we now have a set of pretty hard and clients to face this situation. So, yeah, sorry, you go Jo. I wanted I want to just slee. I do want to be sure. This is clearly people are so people are signing up, their depositing their eath, so they are register as validators, but then they're just like they're turning off their laptops and walking away like that's basically what's going on and they're getting and they just don't care. So we would you even would it be better if there were fewer people signing up? are like ruction validators and that's and they work they were that's more dedicateally. Totally, totally. That's a great question. So to do that, we've been running private sort of test nets just amongst ourselves, like the each team would have a bunch of private networks or we spin up like one thousand tenzero body dators just to see how just basically testim optimizations and you features and whatnot, when having a large number of validators is very interesting and important to test. Is Basically try to replicate the actual load that those clients will be facing in my net it. You know, chances are this will be quite a popular in new network. A lot of people will be willing to actually lock their their eath. And what happens is the more so the actual resource consumptions of for each client is effectively scales literally with the amount of value...

...dators. So the more value dators you have on the network, the more cryptographic operations you have to perform, to validate at the station's etc. Etc. So, BUT ESSENTIALLY BE LA signature verification. That number of operation will, you know, go will follow linearly the number of nodes or, sorry, value dators on the network. So it is it is quite important for us to have a trial run with a very large number of value dators so we can effectively see whether we can handle that load. What we've been doing, as I mentioned, is, you know, run a few nodes with a bunch of Valuy dators on top of them. It's also great to have a greater distribution whereby we only have perhaps, you know, a couple of Vodiy dators for each node on average, if that makes sense. Okay. Then, continuing on to the resources that a user can expect to have, what's the thing that first act of the minimum requirements that someone should have for running a validator, if pleas for phase zero mean, for one thing like well, we'll talk about this first. What are the requirements that someone should make, a reasonable requirement so much, to have when trying to run validator for phase euro? That's a great question and it's a tricky question as well. I don't want people to think that the requirements for phase zero will be the requirements on wards. Oh, I, I'm that was we're going to talk about that. Yeah, it's probably this misconception that I'm just going to buy a raspberry pie and all the Raspberry Pie with, you know, two or four gigs of Ram and that will be it is going to run my body. That are is gonna, you know, do its job on the the beacon Shin and also, you know, validate shot transactions, etc. Etc. Please don't if you do end up running your value, that is, on a Raspberry Pie, it is certainly doable. Right. We've been running lighthouse on raspberry pies. It's been running smoothly for a bunch of people have been doing so, including Paul, my cofounder, but do expect to have to upgrade your hardware at some stage. So back to your question, Corey, I can only talk about lighthouse. I'm not entirely sure about the other clients. Perhaps you could chime in with status. On a status, Nimbus is working hard for making a light, or not a like client, but a Cli light that can operate under sort of type conditions in terms of definitely more focused on resource constricted devices. That's right. So in our guys, you know, a standard, as I said, a Raspberry Pie. Eight gigs of Ram is kind of enough. Your storage is quite important as well, like your this storage. I mentioned the cold and hot databases. So having, you know, an SSD that's connected to it, that's, you know, up two hundred gigs of storage is is plenty and I think as a general rule of thumb, any recent hardware will be will be more than enough for phase zero, or at least for a lighthouse. The memory footprint of lighthouse is very low, at least compared to a lot of other clients. We really try to make it optimized memory for print and the CPU consumption as much as possible, because at the end of the day, that's like it's say you're running your value dators on a cloud infrastructor. If you can have your resource consumption in terms of ram and CPU usage, well your kind of almost doubling your Roy right. That means that you don't need a such a large instance on say, aws or GCPRS you or whatever cloud platform...

...you use these days, and it's obviously very appealing for people to not spend as much on their valley data set up. So it's been a focus of hours since day one really trying to minimize that foot brink and as a result, yeah, we can run comfortably on a tea to instance, on a WUS teacher medium, instance, on a Wus for about bandwidth and power like uptime is incredibly important here, and so is consistent Internet connection. What type of bandwidth consumption do we have and what are they like? We're the what's the uptime expectation of this, of this device? You can you're not running on your laptop you're using for work. I would recommend I mean I would recommend that because if you end up, I don't know if you end up switching off your laptop or restarting because you need to to apply security patch or or whatever you you're basically going to be offline for a bit and probably be penotized for a bit of at least losing the opportunity of making ethop during that time. So I would personally not recommend using the same hardware as you use for your daytoday lives. Would certainly try to use a dedicated piece of hardware. Obviously we kind of want people not to use cloud services as much. The whole purpose of this thing is to be very decentralized. So if we all end up running those on and w a W S, sorry, well, yeah, let me. It's sad. So certainly uptime is quite important, but got to be we got to be careful there. A lot of people have been thinking about backup plans and redundancies and having, you know, some sort of two, let's say, two or three nodes getting fired up in case the primary node is offline. Keep in mind that if you're offline, you're not actually slashed. Right back to that explanation that we gave earlier, it's two types of penalties, slashings and offline penalties. So if you're offline it's actually not that bad. Right, like if if you're a fling for a whole year, think pulled the map last time and it like, I think you're losing like ten percent of your steak. That's if you're offline the whole year. So it's really not that bad. But as a result, if you start having all these complex backup plans and redundancy setups, what can happen, and what actually happened on, I believe, Cosmos was that you have this complex set of redundancy set up whereby the two nodes actually went online at the same time and started producing the same message and started producing the same blocks. Remember the proposer slashing that I was explaining earlier? Well, we can't have someone the same value there submit to different blocks at the same slot. Chances are if you use a redundancy set up that you know is not perfectly finally tuned well, you will end up at some points either a testing wrongly or submitting blocks wrongly. So really I think we should really be careful here about about those tradeoffs. Obviously, up timis critical, but what's, I think, even more important is not producing slashable messages, because if you get not only you lose ether but you also have now this this what the remaining of your balance that stuck in a state that you can't actually sort of we draw or get access to. That's now stuck until we endtil everyone in this new chain has access to their eeth, which should happen in phase one, phase one, point five. So again, be careful out there.

I understand that people want to maximize their profits on its sid that people really want to be online as much as possible. This is great, but when it comes to actually having redundancy plans. Think about it twice. What if? What if I screw up on accident? Something happens, I've a bug my software in IT, suppit's the wrong at that station or something. Two questions here. Can I migrate? Is it easy to migrate to a different client if I don't like the one that I'm using? And can I top up my my eath account so that I can get back to the right threshold so I continue participating like a good validator? First question. We have been working. Michael from our team actually has been putting together and interoperable format for slashing database protection, so that if you move safe from Nimbus to lighthouse or from lighthouse to prison, then we are all using the same database Schema and we can import our slashing protection database. So pretty much every client nowadays has a slashing protection database which is effectively checked before your validator is allowed to sign messages. So each time there's a message to be signed, the process goes okay, I'm going to check in this database whether this message is going to be an slashable offense based on what I've submitted previously. So the problem here is that if you start changing clients, then you potentially lose that information, right and if we start running, as I said, a validator on lighthouse that used to be on Nimbus, well, we can't. We now don't have access to that information anymore, so we can't protect our users against it. So now, thanks to that EIP, I think it's in the Ip now Michael put together, every single client team is now building the same slashing protection data, a Schema so that we can easily import, board them and export them. So yes, we will be able to migrate from a client to another in a relatively safe way. So if you do your job correctly, if the slashing database protection is up and running correctly, you shouldn't be producing any slashable offenses. This is something that we should be perhaps broadcasting a bit more. Slashing is quite scary, but if you do, if you follow the recommendations from the various client teams, if you do run the software that client teams provide with the slashing protection, then you should be fine. We will check those messages for you before submitting them and broadcasting them on the network and, effectively, before even signing them in the first place. So that's the first question and I think what's left for the community to do. As you know, there's a lot of work going on. So but this should, in my opinion, kind of be a priority of the next few weeks. Is Right, easy to follow guides to migrate from a client to another? I think there's a couple of resources out there. People have been asking US questions on this chord, but we haven't so put together up a comprehensive guide on how to import and export your your validators. If that makes sense. Can you remind me where your second question was top up my other account? Why would you need to do so? Even if we got splashed flash, my friend is kind of game over. Okay, so, like if I could slash that, Bundy's gone, I can't top up my other account and continue to participate. Back to the network. That's it. Thanks for plum much. How much does the slash lashing bell? He's a pretty tee. No, no, no, thank God. More than thirty two Weeth, or is it like no, one validator? Three, that's right, one body, dat or thirty two week that is all. If...

...you want to stake a lot more than that, say you want to stake three hundred, three hundred twenty ei though, making simple. Then you have to run ten body dators. Okay, and back to your question. Glory. If you get slashed, then you enter your introduce state, lingering state, where your ether is locked in the beacon chain and not accessible until again. Phase One, phase one, point five, and your you can participate in the consensus anymore. You just alredy validate or completely. Thanks for playing. Yes, like deposited again because you think to eat again on the under one chin. And so, like I was in an assumption that there's like a small slashes so that what you hit under the threshold of thirty two, you can no longer participate and you can then top it up. So that's not that's not the case. That is not the case. Okay, good to enough. There's only there's only, there's goods multiple types of slashings, right, but there's only one slashed state, if that makes sense. Okay, okay, it's a flag. It's not yes, how much money you have, or how many no, if you have, it's exactly it's a flag. This guy's been slashed. Sorry, can't have you around anymore doing, doing stuff. But even if the penalty, even if what we actually slashed, what the protocol took away from you is minor. So it depends on the offense too. Back to your question. Some would be like a third of your balance and some would be much smaller than that. So it is we're dry. If I say I start with thirty two, eat and I'm on, like I'm around like. If I just if I start with thirty tweet or up my computer, I'm going to start losing money right away and I'm done all bay. Or I got in. I can valid out for I have some positive balance. Yeah, and then you can go off and the I've earned some vacation time and I can turn off. I knowed. Yeah, remember difference between slashable offenses and offline penalties. If you're a Flyne, you're not slashed. What you said. That flag right. If I've been a flying for a bit, let's say I've missed for some reason. I was too busy drinking base with my friends. I was too I missed the actual genesis time, right, forgot to turn on my computer. Well, you're not slashed. It's fine. You can. My balance can go below through too, as long don't this exactly. And actually it went below thirty two for pretty much every one on me DA show. MMM, because we couldn't reach finality. And what happens when we can't reach finalities that everyone, everyone, including people that actually are doing their job correctly, have their balances decreased. This is to basically force people to come to come online, and also there's this concept of the inactivity leak that kind of forces people that are offline. They it's kicking them out of the actual Valuy dator set, or the active Valuy dator set, if that makes sense. Good to know. Kind of curious about that was. That's good clarification, I think, for a lot of users. Running low on time, so I don't want to buy too far into this. This is something that I've been relatively knipicky about over the past cup weeks. Key Management. What can users expect about the safety of their keys and what keys they have and we're keeping them? HMM, interesting, interesting question. Perhaps worth mentioning that there are two types of keys in eat to your hot keys or signing keys, that's the keys that I effectively used by your Valuy dators to sign consensus messages, blocks at the station's etc. And Your Withdrawal Keys, which the keys that you will send your ether too, once you exit the beacon chain, or what's...

...to exit the body dator set. So the first one the hot signing keys, their Hockys, right, but you need your computer, your valley there to actually effectively access them every least every six minutes to a test. So we can't have these or recommend thinking of having them in a cold wallet, right, like. These are hot for a reason. You really need to access them quickly and frequently, whereas the we draw keys, on the other hand, can be seen as this cold wallet, right, that you will effectively never touch. If as long as you're participating and validating on the beacon chain, you will never need them. Right. These are this is where the e though that you're using will be sent to when you exit the I guess, the consensus or the work that you're doing on the consensus mechanism side. So they're excited about ledgers upcoming support for bls. You might have heard about this. They're hopefully I'm not leaking any sense of information here, I don't think I am, but they're they're they're working hard and and they have their like it is now working and it's in the final sort of stage of testing. So that means that we will be able to use hardware wallets for those we drolly's. She's quite exciting. It's not completely fully integrated onto the clients yet, but that's certainly something that will be looking at doing before main neet. Otherwise, the way it's currently working for everyone. You've probably seen the launch pads, which is a website put together by the ear and foundation that allows you to generate keys and it's a very simple, user friendly website that sort of hooks into a python software and the steps to follow are very, very simple and you basically use that software to generate your keys and then you use the website to submit the keys or, sorry, you submit the deposit data onto the eth one s month contract, and the launch pads facilitates all that, if that makes sense. So that's what users have been playing with over the last few weeks months with both mid diarmid shot and spend, you know, and it's also expected for them to use that once we hit main neet. But hardware wallet support is coming awesome. I'm pretty happy with that. Terms of a overview or expectations of the coming launch the bee can chain. Madnet, is there something that you think I should have asked you that you would you would have liked to have put out there that I didn't. HMM, we did cover a lot. There's obviously a lot more that we can talk about. So what are you worried about? What am I worried about? It's a good it's a good one. So we're security experts at signal prime. So I think one of the things that we're extremely worried about is security incidents and obviously, you know, vulnerabilies affecting clients and people. I think one of the worst things that could probably happen is a is a fork, like clients not agreeing on the canonical heads and perhaps having a dicrepancy in their state transitions. That's pretty bad because resolving this with most likely require a fork. And you know how we know. We all know the...

API side of our community for folks. So if we convoid that, that'd be great. So we we we are taking steps to making sure that this doesn't happen, or at least reducing the likelihood of this happening. One of them is perhaps something we should mention, is that we're running this project called Beacon Fuzzz that allows us to all try to find bugs in client implementations before we hit main neet, and beacon fuzz is a set of of fuzzers perhaps worth I'm not sure how much time we have, yeah, running out of time, but fuzzing is simply a software testing technique that allows you to uncover security bugs. Are Not only security bugs but bugs in general and software, and the idea is to floud certain functions in your software with a lot of different types of inputs and monitor them for crashes right, and if it crashes well, you probably want to inspect a particular input carefully and make sure that your software is patched accordingly. What we're doing with Beacon Fuzz we're taking this one step by having what we called deferential fuzzing. So we feed that those inputs, you can think of them as like Zillion's inputs per Parawa, and we feed them into all the different client implementations and we compare the output and we want to make sure that the output is effectively the same across all the client implementations so that we can actually trigger these creeping seas and forks consensus splits on the beacon chain. Hopefully that makes sense. We'll probably getting a bit too technical here, not this audience. What think you find now? They said. That's what we shrive. We strive for audience that understands that. You just said, this episode may be broadcast a little bit more based on its more high level overview of concepts. We tend to go very technical, but I wanted something that was just gave a complete package of what people can expect and how things work. Without that and in from here, I think anyone who has questions is able to dive down in the appropriate place for more details. John, do you have any more? Given more questions, we can wrap up. Maybe I'll. Yeah, just tell us it to the wrap up. Like where can people go they want to learn more? Where can they follow you, etc. Yeah, so eth zed on tweeter. People are welcome to ask me questions there. I'm happy to answer them. We have a discord channel that's super busy these days. A lot of people are trying a lighthouse and asking questions. So please join our discord channel if you have any questions. We are SIGP lighthouse on Github and you will have a link to our discord and yeah, there's a lot of reading material out there. If you're curious about the specification that the each to spect Reepo that I believe Corey will be linking as part of this episode is a great resource. It's optimized for readably so it's written some of pytens through the code and it's fairly easy to follow. There's a bunch of other resources on that repository that will help you understand better, perhaps, the rationale of some design choices that were made for the beacon change. All right, well, thanks, you. Sorry, Betty. I appreciate that and let's cross our fingers and hope for a successful watch. Thanks for having me and yeah, I think it's crossed.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (118)