Staking Nerd Talk - Episode 1

Transcript

Intro

[Music] All right, welcome everyone. Um, I'm Remy. I'm joined by Yoro. We are today um in this new format, the staking uh nerd talk where we're going to be talking about different um sticking questions and topics. But first, I'd like to um introduce um Yoro. Hey, Yoric. How are you doing? I'm doing great today. It's lovely here in Portugal. How are you? I'm doing awesome. And I'd like to give you credits for this idea that you came up with um this uh sticking nerd talk. Um what's your idea behind this?

Basically, I'm a I'm going to shill something here. It's not crypto. I'm a big Trunas user. That's my home. And they have something called the TTT, the Trunas tech talk. They do it um once a week. And that's two guys just talking nerdy things. And I thought something like this would be good for homestakers, right? Let's just talk about what's going on with steak. Definitely not doing it weekly, maybe monthly. Let's see how this goes and then see what we want to do. Um I I love your idea. That's why I join and let's just go towards our first topic. Uh let's talk about um history expiry. Um what's your what's the big idea behind this and like what's um what's EIP444?

History Expiry

So let's why don't we start with the problem statement right so you got a two terabyte uh NVME and it's getting a little tight we've seen this in discord people are going ohoo you know do I have to buy a new one soon what should I do I'm pruning it's not coming down many people are struggling with handling like usage yeah so if you upgrade to 4 tabyte you're fine you know just keep trucking if you didn't well two terabyte is getting tight.

Um broader picture you know that some of the core devs like to look out you know decades ahead. They said if Ethereum is going to be here in 50 years we cannot keep all of history on all nodes exactly and require pabytes of storage. That's you know insanity. So we need a way and that's EIP44s. We need a way to just keep some history locally and keep the state and eventually maybe even only keep some of the state but we'll get to that in a bit. Um so for now just history and so that a smaller drive you know a two terbte drive will suffice

maybe eventually 1 TB or less will suffice. Um all the clients have just kept everything so far on the execution uh side right on the execution layer exactly like you get your never mind your basu your ref your aragon you know um so now this first step towards EIP44s is to just expire narrowly pre-age his merge history so expire the blocks and receipts this is why this is the nerd talk expire the blocks and receipts that are premerged that are proof of work and keep everything proof of stake. This is a first step. Um we've tried it on GU

and never mind works great. Um brings you down to about 50% disc used which kicks the can down the road for another year. Isn't the idea of like uh keeping like just one year back of receipts? Yeah. Yeah. Eventually one year. Vitilik is even talking 38 days, right? So, um and that begs the question like who's going to be keeping the remaining of the full history. It does and uh that's not clear yet. Uh one idea is that the portal network will do that, right? So, right now this is a first step towards it. Um we expect that the clients will have something production ready in June

July maybe you know um people who want to seek this now can do so we've got instructions in the discord but it's not a widely deployed idea yet and there's still time still people still have disk space to let this run for a few more months before they it gets really really really tight and there's like two clients right now that have some kind of implementation with this, right? We've got GE and we've got Nettoine. Correct. Yes. And it works great for both. Right. Have you tried this config? I've personally done that. Um my little orchestration framework, ETH Docker, has an ED prune history command that does that automatically for users. Um we've

got a couple very enterprising users in the Discord who've already used that in production on mainet. That's a little yolo, but okay, it works. So, I guess like if you wanted to try this today, you'd have to just add a flag to your config if you're not using f Docker for instance, and then just restart the client. Yeah, resync the client. Yeah. Oh, you have to resync from from the original. Yeah, Nethermine needs to be resynced from scratch. Guess can be pruned and then restarted with a flag. I see. It depends really on the client.

Most clients will probably require reync, right? Basu has a poll request open. Aragon has a poll request open. Reth doesn't yet. So, this is still early as of, you know, late May. I haven't tried it myself, but I'm I'm wondering like where should they be starting then? Like how how will they compute the point where they should be starting from? They start at the first POS block. Oh, I see. first proof ofstake block is what they start to keep um from there they keep block and receipts so that's why I'm saying it's a first step towards um for force right this isn't rolling expiry of we keep one year or we keep 38 days or

whatever it's just let's throw away premerge history and be done and then see how it goes and then people can lay a portal on top and we get used to this and then hopefully by next year this time when we're running out of space again um we either get more expiry or we get the full EIP 44s and it's just one year rolling and this bring me to this whole discussions where there might be more roles for people in the features especially in terms of like how you run your own node like like today we have this role where you can run an archive right um an archive node um in order to have like transaction history from like the past but then you're not required to

do this you can just run a regular node and be um and be just fine. And then in in the future we might have even more roles for like do do you want to have this whole history of the past? Do you want to have like all the transactions as well? Um like like in order to support different use cases and especially um keep having homestakers and and like um people who run their own uh node at home. Um it's it's very interesting to have different solutions together.

So why don't we shelf that for a second so we can get into pectra features that you can tell us all about and then we'll revisit this question because we had a we had a a question come in on Reddit about that as well. Sure. All right. Um let's move on to the petra. Well, we just had on mainet. Um it went fine for the most part. Um we've had a lot of issues um enabling Pectra or implanting the fork on the various uh test net. It failed on Holski. It failed well I mean when I say it it failed it didn't go as planned initially.

Pectra

Correct. Um it failed also on Sepia in some ways. Um and then it was uh recovered and then now we have hoodie this new test net where um we kind of recovered the whole whole ski uh use case for staking um by just creating a new test net which that's right which just worked right it it eventually worked uh for everyone um and I know that you are a big fan of new test nets you reset yours what every month your test nets run ephememory which resets every months. Um, which is another one you could use. Um, but yeah, uh, yeah, so so petra worked fine on mainet, but a

lot of users that we've been replying to are kind of confused still with all of the the new features. Um, we have we have a few guides and there's a lot of documentation, but sometimes people just are having issues finding them. The main thing that Pekra brings is this new compounding um validator where you can have way more than 32 E on your validator balance to um enable you to u produce more rewards. Um we won't go into um all of these details, but um there's a lot of guides on how to do this. If you want to migrate to this new uh validator type, you can use the official Launchpad, right? So, we've

been working on the launchpad to improve it in order to make it um easier for anyone to do these additional actions that you can uh now do on your validator through the withdrawal address for instance, right? So, the withdrawal address is the the address that is really controlling now um the the validator. um you can still use all of the previous um consensus uh features if you want to exit for instance, but now you can also exit through um sending just a transaction. You can um add more uh uh founds on your type 2 validator, your compounding validator. you can um consolidate multiple validators into one, potentially lowering your own uh

burden as a um validator, but also through the network. Um with the the lower amount of validator, it gets easier for everyone, right? And what else? There's a bunch of different tools that you could use. There's a petrify.com uh which is a a different tool uh for um converting your type one validator to a type two the compounding one. Um there's the eaker deposit CLI that they use now to just deposit a new validator and create one that is u compounding from the get-go. Um what else? We we got a bunch of guides that I can't remember now. Um I see a lot of

links coming in the in the description here. We should we should add a few links in the video descriptions. You could just look down there and and see a bunch of these guide uh there. Do you have any other resources tool or elements that I miss from um what happened? Not so much. I just I'd like to hear your thought on um consolidating a validator or or using this new compounding type. How should people think about whether to even do this? like what's what's the pros and cons of staying on the old or going with the new? Well, that's a good question.

Like if you are committed for the long term and you just want to have your reward compound over time, just convert your validator to type two. Um and then um you will still need to deposit the execution rewards because those will still come through the the address that you configured for that in your clients. But then all the consensus rewards will automatically acrue on your balance and you as the balance increases um it's in one E increment um potentially um you will get more reward cuz now the amount of reward is really based on the amount of E that

you stake. So um well it it still it it still was previously right you could have multiple validators multiple 32 E um being used as your stake and creating rewards but now it's much much more easier to have like 33 or 34 E uh working for you in increments of one E. And how does liquidity work in that case if somebody wants like their monthly typed from the validator? That's a good question. So if you have a type two validator a compounding one you uh won't have those automatic withdrawals right.

So um as as you know the type one the original um validator with a withdrawal address as soon as as soon as you had more than 32 E on balance it would get automatically withdraw um withdrawn on your um withdrawal address but now the max amount for the type two the new type is uh 248 and so if you want to withdraw any amount of that um you can still do it but now there's a manual process where you can choose the amount you want to withdraw at any time. You will still have to incure some fees um cuz this is now an execution um side transaction. So you you perform this um special

transaction, you you say how much you want to withdraw. You still have to keep at least 32 E on balance. Um but um as long as you do, you can redraw any amount and um at any time um assuming you pay the gas fees and there's a small um rate limiting uh fee as well, right? Yeah. So when I think about this, right? So if you like liquidity, then maybe the old style is better. If you like compounding rewards, and I think Jim from a test said you can get up to 0.1 points more. So if you previously made 3% now it's 3.1% maybe if you have enough ETH in there right so it's a it's

a little bit of an uplift it's not a huge uplift um and maybe it's type two I'm also thinking about this withdrawal from the execution layer now I don't know about you Remy but my plan for my life is to just stay young forever unfortunately reality gets in the way right so I have to think about my airs. I have to think what happens when I die and to leave an instruction that says take this hardware wallet, go here to Launchpad, you know, um connect with that um there's one validator, hit the exit button, and the monies will be with you shortly is a lot easier than to go,

you know, here's all the public keys and here's how you use F2. Well, I mean, it's all going to be complex no matter what, I think. So, if you're in this situation and and like this is another uh whole discussions about like how do you how you should be managing your um inheritance and like your your estate. Um but yeah, I I feel I feel like you you just have to find a good tech guy to help you with this. Like someone else who will not rub who will not rug your airs. Yes, exactly.

I I feel like that's that's one of the best solution potentially, but yeah, I don't know. There's no easy there's no easy path there. There's a sort of easy pass. I still kind of like the idea of pre-signing an exit message the old way. Yeah. Um leaving that file. Yeah, that still works. Uh leaving that file for your descendants and just saying drag and drop this into beacon chain. Yep. And the monies will show up over here in this hardware wallet. That's maybe the easiest, you know, probably. Yeah. And we managed to shill beacon chain. Hyper.

Should should we move on to the next topic? Um, we had a few questions from um you you posted on Reddit um asking the community what kind of uh question we should be answering. And we had a good one um yeah we had a good one from Super Fizz um asking how do you see um the Ethereum protocol valuing or devaluing solo and homestakers over time and do you think there's a trend in one direction or the other? Um I'll I'll let you have um a quick take on that one. You you want me to have a a stab at that? Okay.

Valuing home stakers

Um I think the Ethereum protocol as such so that's all the researchers who work on the Ethereum protocol and all cordives and all that right it's not it's not one unified thing the Ethereum protocol as such has or some researchers that work on the Ethereum protocol have some values such as censorship resistance right and in order to get that um you need uh more than just one honest um party to be censorship resistant. So there this is an example of where uh decentralization comes in, right? So why decentralization? It's for things like

censorship resistance, capture resistance and so on. So it's not just one entity and you know um some some nation state could come and say you must censor this or you know you must now change these these parameters and they can't much do about it. So in that way I think the Ethereum protocol values solo and homestakers. Um and we have seen this uh if you go onto the the Ethereum magicians and we should link this vital just recently posted something that said as we scale the layer 1 Ethereum itself and also scale the layer 2s with it all

the the various rollups that connect to Ethereum how can we keep um homestaking in mind so that we're not um excluding people right I think and that's that's not just homestaking that's also home nodes so for the sticking part obviously space is a concern we we talked about that earlier so all these um bandwidth is a big one for some people bandwidth is another big one right space and bandwidth are probably the the two biggest ones the thinking about that how to keep that under control um the deta details are way too technical to go into in detail

here, but we'll link the magicians post where you can see Vitalik talking about this. Uh so my take is um the researchers are trying to thread the needle between um scale the protocol, have it do more and still make it possible to run nodes. Um I even see some efforts that go towards the idea to say you can have a tiny tiny lightweight node right in your wallet in your phone so that you are no longer relying on infuro or something like that um to submit a transaction or verify the chain you can do that yourself with zk proofs exactly um

that's that's way future talk right let's not now how do you see it I think I I think you pretty much spelled it out. Um I I think the values um that Ethereums are is trying to promote um especially uh decentralization is is really the the base there. Um I don't see any kind of special rewards given to solo stakers or like home stakers because it would be so hard to implement in in like in in any kind of protocol. Um, in terms of like how many solo stickers or home stickers are on the network, I don't believe it's much. The the last few stats that I've seen are like around 5%. Um, which is a lot

honestly. I think that's a lot. It is. It is not nothing. Um but um yeah uh I I feel like there's no special attention given to home or soul stakers but like the values um behind Ethereum is really what promotes um everyone to be able to run a node at home and and we've seen this with the discussion you've we've talked about like there's very um there's there's a lot of concerns in trying to keep this um low in terms of resources.

and trying to better defines the role um that we will have in the futures in terms of like who's having to run this whole stack or who's having to build block or like um who's having to keep this history um for the long term, right? Yeah, absolutely. And I think you know if you if you look at portal for example where all of the nodes keep a little bit of history, right? Or you look at block building. Block building is now very centralized. It will probably stay that or become even more so. The same is true for proving, right?

That's a very heavy activity. Um the point here though with block building is okay, why do we what do we want decentralized? Well, censorship resistance. So if we can have inclusion lists that are with homestakers and decentralized and so force a centralized builder to follow that then you know the the goal has been reached. I think always to keep in mind is to look at why decentralization. What is it achieving?

It's a means to an end. It's not an end in and of itself. It's a means to an end. But we do need it, right? We without it, if we just put everything into um a data center, we could just have an SQL database again and be a bank. Exactly. That's that's not the idea, right? And we've seen this happening with um some other chains we won't be mentioning here. Um where brings a lot of um of downsides. Um yeah. Uh I mean we ultimately why we're doing this is is to provide people with uh the means to own their own assets and be able to transaction um on their own um on their own rules and like follow

just follow the change uh with with the chain, right? the the whole point of the blockchain is is not to rebuild those uh big banks that we uh we all know uh caused a lot of hate. So I think my closing comment on this question is it's nuanced, it's complex. Do read the Ethereum magicians posts and other posts about it. It does not lend itself to a Twitter sound bite. Exactly. All right. Um let's move to the next one. Uh from Maximus Lora um is having a backup node good practice um i.e. having another instance that can be used as a fallback for your validator to avoid

Backup node for staking

downtime if netamine becomes corrupted or others issues like that. Um I think it's a good idea. Uh it depends on your your setup, right? Um we we've had people trying to build fancy fallback setups in the past uh with automatic fallbacks that failed and caused uh slashing events which were bad um essentially but but like slashing is very uncommon these days. We haven't seen much of it.

So, I'm guessing not many people are trying these, but having just a running node um as a potential like quick way to get back online with your validator is not a bad idea. Um I know there's like a lot of different complex setups um uh that you could use. Um but like one easy one, like one of the easiest one you could use um is just running your own validator client that points to two different uh consensus uh node, right? Exactly. So my take on this is um it really depends on why you want that backup node, right? Um it could be you're such a whale that it just makes sense. Well, in that case, your

validator client is probably in a cloud somewhere and then maybe you have some home distributed uh as you say Ethereum nodes and you can have multiple that you point to. But often it's also just, you know, I like to play with it. In which case, go for it. But if the concern is, well, how much am I losing if I'm down? I'm I'm nervous, right? Don't be nervous. One, the rescue node exists. So if you're saying, you know, my nether mind is down. What do I do? Well, um, if you only have a handful of violators, first relax, breathe. This costs less than your your your uh uh latte at Trader Joe's or wherever you get your latte, right?

Um, I don't think Trader Joe's sells lots. I'm thinking of somebody else. Um, and then secondly, Nevermind in particular will resync in one to two hours to where you can test. So, you can just do nothing, right? If it takes you a little longer because you're like, I'm not sure what I'm doing. I need help. This is going to I I'm busy right now. This will take days. Well, take a little bit of time out. Go to rescue node, register with it, point your val client at rescue node. Now you have time to figure out what happened to your consensus layer client and execution layer client and get those up and running again, right? And then swing back off rescue node. That's what it's for. Um, we have a rescue node channel

in the Discord. It's super easy to use. Patches and team are doing an amazing job. This is originally a rocketpool idea. It still is a rocket pool idea, but they allow use by solo stakers. Um, which is very gracious of them and I'm grateful the tool exists. It's amazing. Um, so my answer is from a purely math perspective, you really have to have a massive amount of stake before having a backup node. Even just the second node that your client points to makes any kinds of dollars and cents, right? like the cost of running that bandwidth um capex the the and what you pay for the machine, right? the the

power your effort in maintaining it greatly outweighs the uh couple capucci many many of these questions it's often like um risk management that you have to do in the end, right? What's the risk? What's the cost of that risk? And like what are you willing to assume in terms of like insurance policy? Exactly. But then there's the other part of that which is but I just need a good excuse to run a second Linux machine.

Listen, don't let me stop you. If you like it, just go for it. Right. This is right. And this reminds me of like um some of the um earlier support requests that we've been doing in in terms of like um people concerned with their hardware uh specs. Um, initially when we were trying to figure out what kind of specs and hardware you should be running, people were throwing different kinds of numbers around and then people would just ask us like, "Can I run this like on on a four disk um RAID setup with like uh this beefy machine server um with like 128 gig of RAMs and like like like if you just like it, just go

for it. Um but maybe that's not required initially. That's right. So there was a similar question in the discord actually and that that was uh from somebody who had been running their stuff with a um with a provider and went to solo staking and um it goes a little bit towards this backup node question. Right. So the first thing they were unaware of and what I want everybody to be aware of your validator client the thing that has the key it can point to more than one Ethereum node and it will fail over round robin etc. All of them can do that, right? So you can just have your one validated client. That's where the keys are. Never move your keys

because that means slashing risk. And the validator client is a very light process, right? So you can be running super light, super lightweight, right? And then if you want two or three Ethereum nodes for that to point to so that if say your netherite corrupts, you need to resank it, you can do that. And then the second node takes over. So that's a that's a really easy thing. The other thing they wanted to know was you know when I restart my client I'm at slashing risk. Uh the answer is no. There's a slashing protection database in the valid client or in the web3 signer if that's what you're using on that node. Um specifically so that doesn't happen right it if you restart it'll look at that database and say did I already sign this duty? Yes. Okay. I'm

not doing anything. Good point. Yeah. Yep. I think that brings us anything else you want to add. I think that just brings us to the end of our first episode here. Um, lovely. Before I let you go, I just want to remind everyone that if you have any questions, if you need support for any of the topic that we've mentioned or just sticking in general, we're happy to help you and Yori does a great job every day. If you just go on our Discord, the East Taker Discord, um you'll see uh we we try to answer everyone's questions um whenever we see them um almost 24/7 um when when we are just awake and we have a lot of great people that are

Outro

answering the questions there. Uh you could also find us on the Estaker um subreddit um on Reddit on Eastaker. Um, so if you have any question, just go there and we will be happy to help you. Exactly. Thank you, Remy. This was fun. Thank you, Roy. And we'll see you next