Fusaka, Rocket Pool and Lido, Hardware Requirements and Clients News - Staking Nerd Talk - Episode 3

Transcript

Intro

[Music] All right. Hello everyone. Um, welcome to Sticking Nerd, um, episode 3. Uh, my name is Remy. I'm glad to welcome Yoro. Hello, Yoro. >> Hello, Remy. >> How you doing? >> Good to see you. >> I'm doing great. How are you? You're you're you're doing exciting things in your life, I hear. >> Yes, I'm doing a bunch of uh exciting things, including building a house. um if you guys can uh can believe this which is uh quite involving uh but today we're we're here to talk about staking in general and we have a few interesting topic to talk today. The first one is going to be Fusaka and potentially the timeline around the next uh fork for um

test net and mainet. Um the second one is going to be the few different changes that are coming on rocketpool and lido. um they're more like evolutions of their um protocols, but we'll we'll dive more into those later on. And uh we have uh some mentions about the hardware requirements for uh staking and running a node in general. And finally, we'll talk about some of the news with clients and the last few issues that we've been seeing uh with with with some of them.

Fusaka

But first first, let's dive with um Fusaka. What's what's going on with Fusaka? Have you been following the ACD uh discussion about this? >> You know, I have um and I've done this uh we we we should probably link um I've done this and I'm going to chill her here by following Christine Kim. Um she is no longer with Galaxy and now she has her own Substack and she does a lovely ACD writeup. She does writeups for all three calls. So if you're not following all cordfs obsessively um you might not be aware there are actually three all cordf calls that are um happening uh you have all cordf consensus layer so that's your

lighthouse prism nimbus grandin etc those guys right then you have your all cordfs execution layer um get never mind bizu um actually probably know all the others ref um nimbus eel We're going to talk about that in a minute. >> Yes. >> Um and then you have um all codep testing which is a new call which happens every week and where they're talking about how the implementation is going. So this is part of the revamping of being able to ship faster that on the all cordex consensus and execution which um happen on a Thursday and they uh switch back and forth right so one week it's execution and next week it's

consensus and back and forth. They also have one testing call on Monday every week um to just talk about how the implementation is going so they can ship faster and not spend so much time during the other calls on uh how it's going and they can talk more about where they want to be with the next hard fork. So all that said, um yes, Fusaka is coming. The next hard fork, um Fooler and Osaka, I think is is what Fusaka is made up of. Um >> yeah, the name for each of the layers, right? One for execution.

>> That's right. Fooler is the is the is the star. So that's consensus. And then Osaka is a town in Japan and that's execution. Together they make Susaka. Uh the big thing here well is more blobs layer 2 scaling >> pas right >> with yes pas. So with Ethereum um having a new north star now um for all its hard forks um might as well mention that as well. the three things that Ethereum Foundation says they'd really like to see um cordfs um focusing on which of course this is completely just soft power right they can recommend they can't

>> agree >> state it will be so right um codfs still do whatever codevs want to do but um the three north stars or the the three leads here are scale layer one scale layer 2 and user experience experience. >> So, >> I mean, part of the whole scaling has been there for quite a while, right? We we've been talking about scaling for forever, but maybe this is more detailed or precise in terms of like exactly what I want to do >> with >> I'm seeing more velocity and focus, I think. Um, you know, sure there's lots of detail and there always has been, but now it it is also with the idea of headliners that says every hardfork has

one big change, one headliner change on the consensus layer, one big change on the execution layer, and then a couple of smaller ones further. Um, that's to avoid what happened to us with Tectra. So, a little bit of history here. If you remember half a year ago, that's long ago, Petra shipped and uh the last hot fork and pectra was going to have teas in it. Pusaka is actually Pectra B, you know, if you so will cut it in two because it got too big.

>> Pectra part two. Yeah, >> part two or Okay, so Pas is one of the big things. Um blob target will be increased. We don't quite know yet to what, but possibly 48 blobs. Um, >> we are currently at a target of six and a maximum of nine. Right. >> That's right. Yes, that's where we are. Um, they also introduced something called a blob parameter only fork with Fusaka. >> So don't expect that Fusaka will immediately jump, you know, by like five x more blobs. um instead they will have that BPO change they'll bump it a little bit and then they

already have planned that afterwards they do small hard forks but only change the block parameters nothing else >> right and so that they can up the blob numbers without needing to go through the entire hard fork um all over again and and everything that comes with doing a hard fork >> I want to come back to pier for for a minute here because I I believe the idea behind it is instead of having everyone broadcast all the blobs, >> you'll only be sampling or broadcasting like part of them, right? So nodes will only have like part of all the blobs and then there'll be some kind of way to uh confirm that at least you have a sample

of all of them and then they can all be recovered or found from from the whole network. This is absolutely true and it also depends on how much um ETH you have staked on your node. So um what they do is uh they'll have what they call data columns right all all the blob data is split up into columns and you will um send so many depending on what kind of node you are. Um we just before this selected a whole bunch of links and you know Remy will stick them into YouTube so you can you can follow along with

this and and see these uh this discussion. So if you are a nonvalidating node not a staker you'll have at least four data columns. If you have one attached validator of say 32 ETH that's eight data columns. Then for each addition for each additional 32 E staked and that can be an extra validator or it can be the same validator compounding with just like a 64 E validator and so on right uh for each additional 32 stake you will handle one more extra data column so once you have 1,824 E staked that would be 57 32 ELators

or uh one rather beefy um compounding one, you are handling 64 columns which enables reconstruction of the entire set. >> And this is in line with like if you're a small um sticking node, you won't be totally like fully impacted with the increased amount of like bandwidth that you're required for all Yeah, we're expecting that the bandwidth requirements for homestakers will remain about the same as what they are now. >> And that's the the goal in the future, right? We we kind of want to keep the bandwidth requirement lowers stay viable. That's right. Yes, that's very important. Um and it it gets even

more important with Glamsterdam, which we're not going to go in detail here. That's the next fork after that. >> Yeah. um where we have for sale um uh fork choice and forced inclusion lists and we really need home stakers for that right and then um there is also such a thing as a super node which must handle all 128 column um now requirements for that we'll get back to that but um initial back of the napkin math shows that a super node has about 10x the bandwidth requirements of a regular node interesting.

>> Um but if you have you know that kind of ETH staked then uh you can probably afford the bad >> probably. Yeah, this is a a rich problem. >> Yeah, you're not going to do it at whole way, right? Um >> exactly. >> Okay, let's let's uh talk about the timeline of like Fusaka. Yeah, I believe the official timeline is Q4 2025, but maybe we could dive slightly deeper into like what we can expect.

>> Yes, the sort of official timeline is Q4. Um, there are still voices that say, why are we trying to break this over the knee knee? Q126 is also fine, but they wanted to ship faster. So, Q4 is the idea. Um there's currently a um suggestion in front of uh all cords to have client releases for mainet ready on November 3rd and then ship on December 3rd. Um they have to have a 30-day in there so that layer 2s have a chance to get ready >> and as usual they will phase this out throughout the test net first. So we can expect this to go through sepoleia hoodie uh epheme might might do it

>> and too. Yeah. >> One last one last thing on >> which is going to be the final one because hleski is is getting phased out as well. Um it is >> after is going to be gone after Faka. Two weeks after Faka finalizes on Hleshki Hleski gets shut down. So uh timeline watch this space. Um, currently Fusaka is in DevNets. DevNet 3 um still has some stability issues. Um, >> I believe they want to do another DevNet after that one, right?

>> Yes, DevNet 5 should start for for reasons that I haven't followed that closely. Definite 5 is the next one. Four, I guess, was done and shut down. Three was kept alive um to figure out what's going on with these uh sync issues. And DevNet 5 comes, I think, next week. So it is entirely possible that this timeline of cut releases midepptember then two weeks later you know at the end of September um for Kleski that this timeline doesn't happen and if that timeline doesn't happen um then uh mainet might get pushed. So with the shall we say somewhat chaotic

release uh process around pectra all cordfs gave themselves all kinds of rules to follow which they are now already breaking around how releases are supposed to work right so that's okay though they I mean it's their rules they can debate them and and and figure out what they want which is what they're doing but if they're sticking to their current plan then um There's two weeks between initial release and first test net um fork and then there's two weeks between each test net fork. So we have two weeks to sepia, two weeks to hoodie. That's the that's the order hoodie. Hoodie as being the last one.

Um, and yeah, >> I'm expecting like this to be released on mainet between like the end of November and maybe the the start of January, something along. >> Yeah. So, the earliest that it would activate on mainet is December 3rd with client releases November 3rd. Right. It they're not going to get it done any faster. It could slip. >> Yeah. So, so I guess that's there's a few other EIPs that we haven't talked about that are included in in Fusaka, but they're mostly minor compared to to Pier Das and and the increase of blobs.

Um, we don't know exactly how much they want to increase blobs, but I guess um that will be uh discovered through testing um and and seeing it will be indeed >> like how much uh bandwidth this is uh incuring for everyone. Yeah, and that's the part of that that's the point of BPOS's right block blob parameter only how it works so that they can observe this on mainet see how it does then increase it observe see how it does so they can always change their mind as to how far they want to go 48 has been bandied about but literally it's up to um discovery uh we could also um

maybe shill here fork cast.org. >> Yes, we will. >> Something that EF has built. >> Yeah. >> And Nixo has worked on which is an amazing great new resources exactly what's going into a uh into a hard fork. it is putting uh visibility on all of the hard fork and the the process um into selecting which IPs are being included, which which ones are being declined, >> uh which ones are headliners and so um if you want to check this out, this is like one of the best resources around, >> right? There is one more thing that we should probably mention which is gas pricing. So, um, Ethereum has a layer 1 and many layer twos. If you, um, follow

crypto Twitter, by the way, don't. You will have seen that the Ethereum network is currently uh, quote unquote unusable because you pay 20 bucks for a transaction. Um, that's uh, how it's supposed to work and layer 2 are still cheap. That's why they exist. Um, that said, we're currently at 45 million gas limit. Half of that is the target. 45 is the is the max. And um after Fusaka, this should go to 100 million. We currently have two clients. I want to say guess and BSU. I hope I'm not um getting this wrong. Uh that aren't quite fast enough to do 60 million um before

Fusaka. So they're working on that. We might see 60 million gas before Fusaka ships. Then with Fusaka, one of those EIPs we mentioned is a couple of them are going to be gas repricings which allows them to safely go to 100 million, not run into a um corner case that might make the blobs the blocks I mean the blocks too too large to handle. Right? So as you increase the amount of gas included in in a block uh you get more work to be done by the clients in order to validate everything and and make sure that uh the the client can still follow the chain as the blocks are coming in >> and I fully expect that 100 million is where we will stick until glamsterdam

and then we can raise bit by bit to 300 million. We'll discuss that when we have a glam call, not today. But that would allow Ethereum to go to 300 million gas, which given that we started at 30 million at the beginning of the year is pretty cool. 10x in, you know, uh yeah, like a year and a half or so at the end onceam ships. That's pretty cool. >> And this is also part of the scaling road map where we we try to absolutely to scale not only through the L2s but also through L1.

>> That's right. scale L1, scale L2, improve user experience or UX. Those are the things that Ethereum wants to really focus on. >> Awesome. I believe that's pretty much all that we can say about Fusaka for right now. So, let's switch to our next topic, which is going to be Rocketpool and Lido. So, Rocket Pole has this um Saturn uh road map that was started with Saturn Zero where they I believe they that's where they added the new mini pools where you could um create like your own pool with only uh eight E right >> with Ethereum and no RPL. So, we should maybe for people who aren't that deep into the ecosystem, Rocket Pool is a liquid staking protocol. Anybody can run

Rocket Pool updates

nodes for them permissionlessly. And it takes eight ETH of your own ETH and then the other 24 from, you know, these stakers that get the the Rocket Pool uh liquid staking token to do a valid. Exactly. In the past, it took some RPL, their own token. Now, >> now you can only use EH as your uh collateral for the mini pools. Uh but now they're um pushing this new evolution of this uh Saturn protocol with with Saturn one where um they'll have a a few new features including the ability to to stake with only four E I believe.

>> That's correct. >> Yes. Um yes. Um so what they're trying to do is um improve well one improve capital efficiency for node operators right so that you can um come in with four ETH instead of eight and then also they're trying to kind of rescue their token RPL um and they do that here by saying you can still stake RPL to your node and what it does to you is eventually I don't think even this is sat one. This might be Saturn 2. Um, you are going to get a higher portion of ETH rewards when you have RPL staked versus when you

don't. >> Interesting. >> Whether that makes sense for you is going to be a huge debate and probably spreadsheet nery. Um, and there's lots of people who are happy to debate that in the procable discord as well. I believe there's a lot of new features that I'm not fully aware of uh because I'm I'm not closely following the Rocket Pole development. Um but one interesting thing is uh I believe they're targeting the end of October for their mainet uh release of this new um evolution the Saturn one >> 29th. Yes. And one really important feature for this is um they are going to have the ability to force an exit. So

Rocketpole is, you know, they had this wonderful idea that everybody would stake with Rocket and ETH would flow in. Um well, right now ETH is going up in price versus fiat and people want to unstake, come out and sell. Perfectly normal thing to do, right? Take some profits. >> absolutely. Unfortunately, in for that to work, Rocket has to close some validators and they have no way to do that um and force that. They can say, you know, uh, hey, Mr. Node operator, you can make some money if there's a if there's an arbitrage opportunity. Why don't you, you know, close and ARB? But, uh, yeah, um, other than that, um,

there's really no way of incentivizing that. So they're going to with Saturn one, they're going to have the ability to just go and say, "We need some ETH for liquidity. We're going to close some mini pools." >> And I guess they will leverage the EIP72 features of like the >> They will exactly >> exit request that you can perform now with the withdrawal address. >> What they're going to do? Yes. Um in order to be able to do that, that's where it gets in a little nitty-gritty. they will have to so they call their validators mini poolools and if you have two of them you have two mini pools um so they're going to introduce also something called maxipools where multiple validators are in one thing

>> I guess they're called mega pool right >> mega pool right so not maxi poolool mega pool that's what they call them they're still 32 eth validators they're not compounding validators that's a whole another discussion which we're not getting into here um And it it's more gas efficient, right? If you have a number of of validators running or what used to be mini pools. So if you have a mega pool and you have multiple validators running and you want to, you know, get rewards or whatever it is, you don't have to send a transaction for each one.

It's just one transaction. Um it's much more gas efficient if you have a bunch of E to deploy. >> Let's switch to Lido. Lido has uh its own evolution of their community staking module. um the CSM V2 uh which is coming up um soon as well. I believe it's coming up in September on mainet um which is their target. Maybe maybe that'll slip, but um what's what's new there? Um do you have more insight than I do? >> Um I don't know that I have more insight than you do, but I have a couple things to mention here. So um Lido currently have a limit of 4% of their stake in the um permissionless community module. They

Lido updates

want to bump that to 10%. And in order to do so um they want to be sure that they don't get sibbled um to Helen back with people saying I'm totally a homestaker and they're not right. Um and you just have the big guys coming in there into community staking. So, what they're going to do is they're still going to allow anybody to come in without saying who they are, but they're also going to have something called the uh verified community stakeholder. Let me just see what this thing is called exactly. Um, >> I believe that's part of their ability to create different node types uh as part of the CSM um evolution.

>> Yeah, identified community staker is what they call this. So, the first round of applications for ICS is open now. Um, it will close October 1st and as an identified community staker, and I think they're going to do this a number of different ways that you can prove that you're indeed a community staker, like a home staker or a small staker. That's the idea, right? Um, you'll get um you'll get additional rewards. you'll get the ability to have a smaller bond.

>> Do you know if >> there might even be a bigger bigger payout, that kind of stuff. >> Do you know if that involves any form of KYC or um >> I think it can I think there's a the idea I haven't actually looked deeply into how they're doing that. So they could do something like a ZK passport. Know whether you're familiar with that idea. That protocol allows you to prove that you have a passport uh with a zero knowledge proof without showing what it is. So you don't have to expose um any detail of the passport. Um, all of that is kept on your phone, but a ZK proof is generated from it. Um, which is

then unique to your passport to say, "Yep, this is a individual passport that was just scanned and all the details." You know, the the thing of course is in our wonderfully trustless environment, you have to trust that it really keeps all that on the phone and just transmits the ZK proof and not everything about you. Yeah. you know, I don't I know Aztec is using this. I don't know whether lighter, but they'll also have other ways of proving that, you know, you're a community staker. I think including did I run a solo node? Did I engage in the forum? Those kind of things, right?

So, uh by all means check it out. Um I think this is a first where we're saying good things about light on East wash our mouths out with soap. I mean, they're still a great like product overall. Um, and their initiative to try to include more of a permissionless >> absolutely >> way of staking is is awesome to me. Yeah. >> Yes, we do like that. Um, so I think they have not sure how many they have, but I think they have um 450 operators they had registered at one point.

>> as part of the CSM um >> as as part of CSM originally and now they have this identified community ster thing and they want to you know get to 10% of their stake running permissionlessly. >> Awesome. I can only applaud this. >> I'm all I'm all for it. Right. And >> uh yeah, I did have another thought, but um we can come back to it and that was um why even consider this versus solo staking and it is very simply if I make quick back of the napkin math here. Okay. Um so we always say solo staking is the gold standard. Um, and I think that's a a really good comparison because one valator is now worth more than a

kilogram of gold. Um, 144,000 US dollars or thereabouts. Think kilogram of gold once I looked, last I looked was like a little under 120,000. So calling it the gold standard is absolutely correct. But not everybody had the ability to deploy the equivalent of a kilogram of gold into their staking. when we started like in 2020 um with the beacon chain it was much cheaper right >> yeah I remember I bought I bought at the time it was like under 13,000 bucks right and I thought it was a lot like that much into a validator should I >> which is why we need all of these new options where you can stake with a lower

amount >> yes so the idea is that if the gold standard is just a bit too much for you but you love the idea of being a node operator and staking and decentralizing Ethereum and getting paid for it, you know, then Rocketpool and also lighter CSM allow you to do that with a much lower amount of capital that you need to put in from your own and the rest comes then from stakers that get the LST the liquid staking token. >> Let's talk about uh hardware requirements. So um there was a few um discussions about like what should be like exactly the hardware requirements for running a node and we we've had the help of Kev uh Kev which uh wrote this

Hardware requirements

initial document where he was trying to really uh set in stone what are the hardware requirements because we we've been talking about this forever like since we started doing staking and we've had our own like Eve staker requirements uh that we've been uh publishing in a few different places including on our website and and it's somewhat different but what I like about this and they they've also launched this new EIP um 7870 um if you want to have a look we'll put the link in the description too but um they've they've launched this approach where they're trying to also think about the roles of uh people running nodes right

>> exactly no Are you are you running a full node? Are you running are you running a validating node? You know u potentially maybe we'll see in there are you running a super node uh for pas I think they're still debating whether it should be in this EIP or somewhere else but you know personally I'm saying this is the EIP for hardware requirements put it in here. >> Are you also like uh trying to do local um block building as well? >> Local block building is another one. Yes. Um so there are requirements for that and they are different than that what you will see on e staker and they're different from what you will see um on other um sites like the e docker I maintain we still have lower

requirements there so if we want to get concrete right now I think ego says four cores 32 gig of RAM and 4 terabyte of NVME right yeah >> is that our current yeah that's also what it docker Exactly. And this EIP says 64 gig of RAM. Um, eight cores, 16 threads. >> Eight cores, 16 threads. They specifically call out threads. We'll get back to that in a minute. >> And also 4 terabyte of NVMe. So what's going on here? Um, what they're doing is basically saying if you buy this, then we think that no matter what the protocol does next, you're going to be

fine for the next two to three plus years. Right? So this is kind of a future proofing in a way right? >> It is absolutely. So today um you can absolutely without any issue run on four cores and 32 gig of RAM you know even less CPU and even less >> if you want to tweak a few things >> you can tweak a few things you can run you can fit into 16 gig and some rock 5B ARM thing people still do that right it's still possible but it's um you know so the uh and sorry I want to also talk about the storage here for terabyte basically allows you to just run a full node and not think about it. Um, but we

also have history expiring now. So a two terbyte will absolutely still work. If you have an existing node, right, do that. So, I think my recommendation is if you're building new and you have the money for it, you may as well go, you know, particularly if you're doing solo staking with the uh kilogram plus of gold here in your ETH, then you may as well spend that little bit extra more and make sure >> absolutely 64 gig of RAM and you have a 4 TB NVME. Why not? You know, maybe you run a second client on there or whatever. um and you have your eight cores, 16 threads in the AMD Intel world, right? Um if you have existing hardware and it

works for you and maybe you're expiring and you're in a two terabyte um NVME and you have 32 gig of RAM and you're still seeing that like half of that is free, which might well be the case depending on your client mix. Nothing that you need to do. >> Yeah, there's no there's no point in just upgrading for the for the sake of upgrading at this point. you don't need to upgrade for the sake of upgrading. I think that's the main thing I want to >> you could just wait and and as we know some of these components are very easy to source for many people and so like if if you see that like suddenly you're out of this space you can just buy one new disc on Amazon or or something. Yeah, >> you could. Um but also disk space in particular um we'll get to new expiry

options in a minute here I believe. um disk space in particular isn't such a scary thing anymore for um stakers, right? For full nodes, sure, if you're using this for an RPC full node, you better have your 4 terbte at this point. Two is not going to handle you. >> But if you don't need historical data, um so even if you just run an RPC and you just want to transact right now and all you need is the current state of the of the network, 2 terabyte is more than enough. We're using about one terabyte right now with expired nodes and I already know we can go lower and uh yeah so I I wouldn't worry about that too much at this point in time.

>> Great. Um I don't have much to say about this. Um believe you you said pretty much all of all of the things that I was thinking about. Um let's switch to some of the client news. We have a bunch of different uh news with clients. Um, one of them is the bug with ref. So, um, what happened with ref? Can you can you tell me a little more? >> Sure. Ref is an execution client. Um, written in rust and, uh, yesterday morning it lost the plot. It just stopped following the chain. Wrong state route it said and boom. Right. So, as far as bucks go, um, this is not the worst thing that can happen. uh just

Clients News

stop following the chain is actually much better than following the wrong chain. >> It is >> um which has also happened to other clients before just saying you know none of them are immune to this. Um so they have published now a way to recover a node if that happened to you if >> we'll publish a link to the instructions on how to recover as well. >> Indeed this also didn't happen to all nodes. Um there's some indication, again this is new, right? We're recording this today and this happened yesterday. Uh some indication that most people can recover and some cannot. And there's no full postmortem yet and no fixed um software yet. So that will all come um

you know, if you're watching this in in my future on September 10th, then I I really hope that by then we have all the answers. But today, September 3rd, we only have a couple of the answers. I'm sure we'll have more details as uh this is being in investigated. Um but this is why we have client diversity, right? Um we expect clients to have bugs. Uh we expect some of them to just crash and burn. Uh well, this this one didn't burn, but it it somewhat crashed >> and then uh that's how we recover. We just um fix as we find them.

>> Yeah. If you look back into the timeline, all of the clients had bugs at some point, right? um including bugs that halted them um and in some cases including bugs that had them hairing off on the wrong which is worse. Uh so have client diversity for a reason. I think it's the one of Ethereum's superpowers that doesn't get talked about a lot. It's part of the reason why the network has never been down. Um >> y >> livveness is built into the network. It doesn't mean it can't hold, but it means it's much less likely, particularly when you have a whole bunch of clients that can, if push comes to shove, you know, still keep the network up.

>> Um, talking about issues, we also had one with Tekku. Um, I believe there was some kind of dependency issues uh with their latest release. Um, but I believe it was fixed with a new one, right? >> It was it was fixed today. So this was a much um smaller impact issue because it only impacted people who updated to the latest Tekku 25.9.0 um which I think came out yesterday. And if they updated yesterday right away um and they were on a system uh on a Linux system with say a graphana installed and they weren't running this stuff in Docker containers then teo would conflict with the library on the system and stop the testing. Um they fixed this

today with 25.9.1. Um if you are in Docker in any way, shape or form, don't worry about it. This did not impact you. So that's that node and um rocketpool and node set and a steerum and e Docker and there's probably a couple more that use that technology of containerizing then this didn't hit you. Um, if you don't haven't upgraded to take yet and you're about to upgrade, then just upgrade to 25.91 >> and and you'll be fine.

>> If you upgrade and if you upgrade Exactly. And if you upgrade to 2590 and you didn't hit this bug, then you don't need to do anything. >> You're fine. >> Awesome. Um, next is uh Nimbus um, which has been working on this new execution client for a while and they're they just called for for support and people to just test it. >> They're asking for testing. So, um, we're getting a new execution layer, the Nimbus execution layer client. Uh, we already have Nimbus consensus layer client. Now there's also Nimbus execution layer client. It's been around for a couple years.

>> Yeah, for a good while. Um, >> yeah. um work on it really accelerated this year and they're now feeling confident enough in it that they're saying, you know, spin up a few nodes. Obviously, not your mainet validator node maybe, but if you have a test net node, try it on there. >> Yep. >> If you have, you know, just a machine where you just want to try mainet, maybe run it as an RPC, as a failover node, whatever, try that. You could do that. >> I believe Nimbus also has a this goal of creating this big uh monolithic uh client that would include both execution and consensus eventually.

>> Right? Yeah. >> So that is likely part of uh their effort to get there. >> I'm assuming so. Yes. Um as to how you can deploy this if Docker supports it. That's one way to do it. That should be a fairly simple and automated way of getting this up and running. Um, with any consensus layer client by the way, you can of course do a Nimbus Nimbus for the for the fun of it, but it need not be a Nimbus Nimbus. You can do a lighthouse Nimbus and that'll work. Um, and then I don't know that we have any specific systemd uh guides for it yet from >> No, I don't believe we have anything >> special for this, but um if you like tweaking um and like uh tinkering with stuff, I'm I'm sure you can get there,

>> right? And um one more client. Nothing wrong with that, you know. >> Yes. Um as as many as we can get that are of a good quality um we we can um include them in the whole ecosystem. The next one is Netamine which just had a big release um 1 uh 33.0. >> Um >> that's great >> which uh includes a bunch of different stuff. I won't go over all of the uh release notes. Um but one of them uh is a fix to a bug where you can um close it down or there was some issues with um >> just uh doing a clean shutdown. Um they

have also a few options in terms of like um history expiry. >> So if you want to save on some of this uh disk space um they have a few different options there. And they have this new UI. I don't know if you've tried it. Um, >> I have not tried it yet. No, >> I want to try it because it seems awesome. Um, I love the the the UI and and the way that it displays everything. >> It looks really cool. Yeah, it runs by default on the RPC port. They have in the release notes some ideas on how to put it on a separate port. If you um don't want to uh if you don't want to have it on RPC, maybe you want it on port 8080 or something. They have some ideas on release notes on how to expose

adjust the health endpoint and not all of RPC. Um but yeah, it runs over the RPC port on a specific endpoint. I haven't tried it yet. Um this was there before but not this nice, you know. So this is certainly something that um people are encouraged to play with and see whether they like this. Um this is basically uh a lovely health endpoint and and visualization uh dashboard without using graphana built right into the into >> I believe it displays like the amount of transactions in the mele like as it is building blocks and like >> yep it is it is it is it has all the blinking lights it looks really cool

>> um and as as you say um there's a bug fix in 133 if you had 132.3 or 2.4. You may have noticed that um Nethermind refuses to shut down and then eventually whatever system you use to run it, whether that's systemd or docker will just force reap it, kill it the hard way. Um that's been fixed. Um and then uh the expiry uh they have two new expiry options. Both of them are experimental. So uh do use it on if you like on your your failover or on your test net but don't use it on uh mainet validators please. Um those two options are one um do the normal expiry that we

have now where all premerge data is being thrown away but do it without needing to resync. So typically that might need a resync after one to two hours you can attest again with this new option. um you would just tell it go expire this in the background and you'll be back up immediately. You don't have to wait those one to two hours. That's pretty cool. The second one is yeah really aggressive. Uh and we're going to uh talk about where you need to be careful with it. They call it rolling expiry. So that is full EIP 444 or 44s 444 full EIP 444s. Um, which means that you have a rolling expiry of history

with by default one year kept. Um, >> which I believe was the was the goal of this whole history expiry. Um, >> that is the eventual goal. Um, but it messes with some protocols. uh for example, Rocketpool, uh Stickwise, SSV, um all these protocols that rely on something called receipts where they're um smart contracts uh emit a log message uh a receipt into um the history and then you can query that and see what happened. Um RocketPool uses it for example for um for rewards. I think uh SSV uses it to know which um which

shards you need to pay attention to, which key shards have been assigned to you and you need to grab, right? So with rolling expiry, the receipts also go. So you only have receipts for the last year, which messes with these protocols. Um so that's why it's not widely deployed yet. The current plan as I understand it from Cordvs is currently we have pre-emerge expiry. They want to finalize a new format to have this data.

We currently have the ERA one format for it and then we have the ERA format for postmerge. They want to bring both of those formats together in some called era E. That's going to be the new file format to store this data. So you can always download an era file and get all the expired data in a node if that's what you want. Um once they have that they want to expire um pre Cancun data. So everything up to Denkun gets expired and then at some point after that they're looking at rolling expiry.

they're also thinking about so we have this um idea called a portal network which would be a separate client that has a portal history network and a portal state network and I think there were a couple other ideas where all this data is being kept and you can query it. The portal um team was defunded by EF has not found new funding. So portal is for all intents and purposes dead. However, portal history will live on inside um execution clients. Standalone clients are dead. Reason for that is a little

technical. The portal history network as envisioned now will not have headers. So you will need something that already has the headers. That's an execution layer client. So what that means in practice is say I go to a GU and I say hey I need a log from two years ago GU will should once it has portal built in if this happens again this is a discussion point not a this will absolutely happen >> um it would go and say oh I don't have that let me query the portal network and get that for you so at that point it would be transparent Um, in the meanwhile, you know, these uh clients should maybe or these these

protocols should maybe think about whether they can store that information in something other than receipts um and have it onchain still, but have it in a format that isn't receipts and doesn't disappear. You know, >> it seems like there's still quite a lot of details that are in flux and like everything is is up in the air still. Um but yeah, but but it's something to watch because it has a huge impact on on node operators and and stakers. Um >> it does. Um what that means is that you know once we have rolling expiry we're going to fit in under a terabyte of disk for a long long time. You know state of course will continue growing with gas increasing state will grow faster but um

history will be able to throw away and then only query when we need it. Um that's a big change. >> We've been going over our initial uh time estimate, but uh we we still have to mention at least two uh clients um that have been having updates. Uh the first one is GE. They they just had a few bug fixes, but one which you wanted to mention was this new u pathbase archive uh mode. >> Yeah, we're going to keep that brief. Um it is not important for stakers but if you're the kind of person who really wants um historical data for your you know um data crunching whatever use you have for it. Uh a GU

archive node used to take like 16 terabyte of of disk. That's it's a little crazy. Now it fits in under four with this new path based meth method with GU 116. So, um, if you have a use for archive node, try out that new path paste archive. I think it'll work really well for you. >> And we've had the loadar um having a few sync issues. Um, I've not been following this much. Uh, but maybe you have more insight of about this. >> Yeah, this this was a follow on to the ref debacle. So some people have recovered their nodes and then I have a load star as the consensus layer node and then found oh I can't actually sync

back up to head or if I do I lose sync again and load star have said yep that's on us we're working on it we're doing sync improvements so just watch this space there should be a new nodear release within I want to say a week or two that improves sync performance of loadar so you can stay synced and not fall out of sync. >> As usual, if you're running any of these uh clients, you should be watching uh the new releases and reading potentially the release note just to make sure that you're up to date and following what are the changes with um the clients that you are running at least.

Outro

>> Okay. >> Well, that's uh that's all for today. I believe we went through all the topics that we uh we planned for. Uh thanks for joining uh Yoro. Um, and >> thanks for joining, Remy. I think my final thing is to say, um, if you enjoyed this and you have topic ideas for the next one, then stick them in a comment or stick him in our Discord or stick him in our into our Reddit. >> Awesome. Well, have a good one and we'll see you next time. >> Thank you.