Rocket Pool, Fusaka, PeerDAS, BPOs, Hardware Requirements, Hoodi and Ethrex - Staking Nerd Talk - 4

Transcript

Intro

[Music] Hello everyone. Welcome to sticking uh nerd talk episode 4. Um hello uh Yor. How are you doing? >> I'm doing great. How are you Randy? >> I'm doing awesome. Today we're going to talk about a few uh topics. Um we'll come back to the rock uh rocket pole Saturn 1 update. Uh we'll talk a lot about Fusaka which is um very close to being deployed on a few test net. Uh we have a lot to talk about this including uh pardas uh BPOS and a few other things. Uh we'll come back to a subject that we've covered in the past which is

the hardware requirements for running a node and the different roles that we might have or we currently have with like the different people running those nodes. Um some of the news with regards um with the hoodie uh fork um especially with the client updates uh the deprecation of the staking deposit CLI tool which is now replaced with um the Estaker deposit um CLI uh tool and a new execution uh client called Erex. Is that the proper pronunciation?

>> I'm not sure. Uh, they have like a a Tyrannosaurus Rex as their mascot. So, interesting Rex, Eth Rex, something like that. >> All right, let's start with the Rocket Pool uh Saturn one. Um, we we talked about this in episode 3. Um, and I believe they changed their um new target for mainet launch, which is now on January uh 19. But what's the thing that we missed um or that we we spoke about that was wrong last time?

Rocket Pool Saturn One

>> Yeah. So, I talked about Saturn one having uh forced exits and I think if I recall correctly because I didn't go back and watch it and that was entirely wrong. That is not how that works. Um, I did have a description from patches on Rocketpole on what it actually does. And of course, it is now completely gone from my screen. That's always how it works. So, it's going to be from Nope, there it is. I don't want to do this from memory and get it wrong again. Um, so with Saturn one, so RocketPool right now, the way this works is it's a it's a liquid staking token protocol and you have an 8 ETH bond, right? So every val you run eight of those ether you own. Um

and when you stake RPL with their own token then you get more RPL. Well this has made people not super happy. They didn't fully understand why they should stake a token to just get more of that token. Um so with Saturn one uh two changes are coming. One is they're going from what they're currently calling a mini poolool, which is a a smart contract that handles one validator to a mega pool. So, it's the same basic idea, but now that smart contract can handle multiple validators. Makes it a lot easier for node operators, for example, to claim rewards. That's just one call instead of say you have 20 validators, 20 calls, you know. um and the bond will

be reduced to 4E per validator. Any RPL staked just means that they get a higher share of the protocol revenue in ETH. So if you have RPL and you stake it come Saturn one in January, instead of getting more RPL, you get more ETH. The hope is that this makes RPL more attractive as a way to earn ETH. >> My only main takeaway is that now people can stick with like for E. Um well they will be able to >> they will be able to as far as long as they um migrate to mega pools or create a mega pool absolutely >> and from your understanding there's a migration path for people that are currently using the

>> there will be a migration path absolutely and I would say rocketpool discord for all the nitty-gritty details but there will be a migration path from current mini pools to mega pools. Um, this does involve an exit and entry. So hopefully the queue isn't too large at that point. At least that's my understanding. Watch us come back to do another correction at SMT5. >> And and just to make this clear, the um the queue is not related to like the the regular staking Q. It's it's a different queue, right?

uh both I think they're going to have a rocket pool queue and it's the regular staking queue as well. >> So people have to have to go through the regular queue and >> I believe they will have to exit the validators and the reason is that right now these validators are all tied to the individual contract smart contracts one deployment per validator right the mini pools and with a mega pool the whole idea is that a smart contract can handle multiple validators. So these validators need a new withdrawal address which means they need to be exited and re-entered.

>> So depending on how many people are trying to join or exit um at the time that people want to do the this migration they might have to wait longer. >> Exactly. There will be there will be a queue for sure. Yeah. Um Saturn 2 uh sometime later in 2026 that's when you when they could get forced exits. Um there is currently a governance effort to pursue that for liquidity. Initially that's not for liquidity. It's just for uh defined issues like um say somebody's been offline forever and not coming back.

It's bad for the protocol. So they're going to do a forced exit to get that ETH back in and redistributed. Right. um if there have been some node operators that literally have been off for six months or longer and there's no way of getting them of of going off, >> right? >> Um so that's that's with Saturn 2. Uh currently not yet for liquidity, but they have a grant going to figure out how they could do it for liquidity, which is of course a big question mark, you know, who gets exited. Um and it also importantly though as you say I took away it took takes four ETH Saturn 2 gives them bond curves. So the initial

bond curve is going to be the first two validators are four ETH bonds and the rest have 1.5. >> Interesting. >> That's going to get interesting as we get into the next topics here because all of this stuff hangs together. This does this does have a point about how quickly you become a super node in rocket pool. Yeah, because um this ties in with our uh next subject which is Fusaka and Purdas. Pias is like the main um the main show of Fusaka. Uh, Fusaka includes a a bunch of other stuff uh, including uh, BPOS's which are the blob parameter only forks which enables uh, the

Fusaka

protocol to upgrade uh, the number of blobs on the network without having to do like the usual hard fork which is quite involving for everyone. Um, but uh, but yeah uh let's let's get started with pure das. Um let let me just give you my my own understanding of pardas. Peras is this next step in trying to scale blobs. Um right now we have six uh blob as a target on the network with a maximum of nine. So as as the network include more than six blob um uh the fees increases and and if not they decreases so that the equilibrium is is six blob per per block. Um but with pas

uh we will have some kind of distributed layer where um nodes will not be required to host or store um all the blobs all the time. uh depending on on how much EF you're staking, right? So if if you're a small staker with only like 32 E, uh you will not need to store a large amount of blobs. But if you're a very large uh staker like somebody's um institutional um staking operation, you you will need to be carrying a lot more blob, a lot more of the weight of not only storing this on disk but also uh

sharing um this on the the PTP layer. Um is that your understanding as well? >> That is my understanding as well. Yes. Um so yeah, blobs are how layer 2s um post some data to the Ethereum chain. They used to do this with call data and it stayed around forever and that was expensive and now you know since I want to say since Spectra but maybe before I I I lose track of these hard forks. Um it's very embarrassing. Um so since we introduced blobs um these things are now ephemeral they stick around for 18 days.

Layer 2s can cheaply host the data that's why we have subsent transactions on layer 2s and busaka aims to scale that further. I'm looking right now for the bo fork. Do you have that in front of you? >> Not not on that screen though. Uh well, I'll find it as we talk. So, what's your take? How did the Fusaka upgrades on Hleshki and on Seolio go? >> So, have I haven't been following the the hard fork on um Hleski or Seapoleia.

I know Hleski went well, but in my mind, Hleski is already dead, so so I didn't didn't follow that one closely, but I I've seen that it went well on uh Sepia as well. So, um hopefully everyone who's testing all of these DAPs uh can give us a a bigger idea of like is this going well? Um have the clients been updated successfully? Is there any troubles before uh we we go forward with not only the HODI uh fork but also uh the fork coming up on on mainet. Um >> right. So, as you say, right, um, a node doesn't have to carry all of the blobs

all at all the time with the caveat that we'll get to here, which is what we're working towards. Um, so a normal uh operator um shouldn't see a big problem with um with normal operation dayto-day, but it differs a little bit when we get to block production. So that's something we need to talk about. Um and it's linear as you get more ETH staked that is talking to your Ethereum node. So you have your consensus layer, your execution layer. Basically the consensus layer looks at how many

validators are using me for attestations um or how much ETH in those validators. It doesn't really count the validators, it counts the ETH. If that ETH is 4,096, that'd be 128 old school validators or two completely maxed out new ones. Type two, right? >> Yep. >> Then you are a super node, which means you have to have all of it all the time. Um, and until then, it's kind of linear. Um, so for most people, not a big deal.

If we want to get technical um like the I believe there's 128 columns uh for all of these blobs to be to be shared and each of these columns are independent as they they're being shared on the the P2P uh layer on the on the network. But if you're like um staking with one validator or like 32 E, the old uh type of validator >> um you will only need to be carrying eight of these columns like so 30 32 >> second of it. Yeah.

>> So uh you had mentioned BO forks, right? Block parameter only forks. These are scheduled in the in the software that you're running. Um they are hard forks. So um you know you do want your client to follow along. Uh BPO1 is going to increase the blob count limit from currently 69 as you said to 10:15 and then BPO2 um which might be as early as January to 1421.

Now BPO3, four and five have not been scheduled nor their size. They want to see how this behaves before they do. But there will be another client update to schedule BPOS's 3, four and five. So that's the current plan. The actual impact of like the stakers who are watching us right now is uh you might be running low on disk space as these will potentially increase your disk usage. Um remember that blobs are stored on your disk for 18 days and so if there's more blob potentially you have to store more unless you're sticking with a low amount of ETH like we mentioned you you might not need to store all these blobs. Um so

disk space is going to be an issue for some people but bandwidth might also become one right >> right absolutely so um disk space I'm looking so there is a um there is a blog post which I'm sure we're going to link from e panda ops where you can say I'm a I'm a solo staker I'm a small operator I'm a medium operator I'm a super node what does that mean for me um so the disk space isn't too bad. Even at 320 ETH, you know, which is about about I think beyond that's that's probably not a ton of solo operators for bigger than that, right?

There's some um it's under 60 gig at uh BPO2 max. What that means for BPO 5 max, we don't quite know yet because that hasn't been said. So when we say max it means when it's truly full right when BPO2 I think it was 21 maximum when when all 21 blobs are full >> and this this just to be clear this depends on like how much layer 2s are using blobs and like like if the blob is not fully used like if this capacity is not fully used the the amount of the space and the amount of bandwidth um that our people to be are expecting to

be using u might not be these values. >> Right? So I want to talk if I can about bandwidth and specifically local block building. >> Go ahead. >> So when you're building a block today, you have two ways of doing that. One, you're doing it through a relay. Um typically MV boost or commit boost. So you're going to the relay. You're saying go tell me which block blob a block which block pays the best. that the one you're going to sign just the header for and then that gets published. You don't actually need to have all the bandwidth to publish that on time. The builder takes care of that. You just need to sign the header on time. Right. Great.

Or you can build locally. This could be because you're just not convinced about me and you not running an MV uh boost or a commit boost sidecar and you're not using relays or it could be because you have a min bit set. If you recall at one point it was a recommendation set your min bit to 0.05 or because your validator client has what's known as a proposer boost setting or sometimes also build a boost setting. >> Um depends on the client what they call it which says unless the builder pays at least 10% more than local building local. Great for censorship resistance. Right?

Here's the trouble. So, we're looking at BPO2 target and BPO2 max. The bandwidth you would need for target or max. Again, your mileage will vary because you don't know how how many blobs are actually in the block you're building. Um, right now a priority. You'll find out when you're building it. So, Busaka BPO2 target 75 megabits per second. uh BPO2 max 112 megabit per second up and that's just BPO2. We're not even at BPO3 or five yet. This means that for a lot of home stakers this starts to be

out of reach. If you are the kind of guy that has symmetric gigabit available to you, more power to you. You know, use it. You can build locally. I've heard about the new settings though like the max blob settings that some consensus client might be implementing >> that is not in the protocol as far as I know >> but potentially >> made it in >> potentially like clients could decide to limit the amount of blobs that they include in in their blobs right >> could we'll see whether that happens right for now I think you should go with the theory that that doesn't exist necessarily we'll we'll see as we Oh, >> cuz that could be like one way for like small stakers with limited bandwidth to

um >> to be still be able to be local building their blocks >> and um be like in in their terms of like bandwidth consumptions uh be be there. >> Yeah. Yeah. the the the worry here is that um in some places in the US for example you don't get more than 35 megabit up you not for not for money or anything you can't just can't have it you know even in re reasonably large cities >> and that's not going to be enough to build locally anymore >> I've heard that uh Berlin in in Germany is is pretty bad as well so it's not just in the US

>> I'm sure right So, um, and and here where I am, I've got 200 megabit up, a gig down. Um, I couldn't I could narrowly still build with BPO2. I am not expecting I could still build locally with BPO5. So the the trade-off that people will have to ask themselves for maybe tweak their configuration is do they want to keep trying to local build their blocks or do they want to to externalize all the block building to the MV realize right >> correct yes if you if you always build externally then this isn't an issue

right if you don't have enough bandwidth and you're building locally you're just going to miss the block you going to get it orphaned because you're too late. That's it. Right. >> And I'm sure that there's going to be a lot of monitorings in terms of um the these BO forks um like how much the actual bandwidth uh requirements are increasing over time and like there will be a lot of discussions around these. So hopefully it won't just get pushed by right >> people right.

>> Yeah. So actual of course depends on how heavily the blobs get used right so even if you're being told oh on average it's just 20 megabit up you're fine right and you get a big block with a lot of blobs in it >> you're not fine right and so I would say planning for max is prudent um just so that no matter what comes your way you're good right >> this would mean 150 megabit upish to have some room um with BPO2 and then could be determined for three, four and five. Uh yeah, maybe there will be a way to limit blobs. Um last time I asked um

there wasn't consensus that this would be a good feature to have and I didn't see anybody talking about actually implementing it, but maybe you know more by now. >> Um no, I I don't know much about this. I I still want to talk about uh people that are running just RPC nodes or like nodes that are not validating. Um we we talked about these 128 columns uh for uh sharing uh blobs. If you're running just an RPC node, you'll only have to carry four of those. >> So it's it should still be quite light to to run um an RPC node.

>> Yes, this is true until you get into layer twos. This is where it gets fun. What everybody woke up to with Sepolia was, "Well, hold up a second. My layer 1 RPC is feeding a layer 2 RPC and the layer 2 RPC wants to see blobs and to see blobs I have to be a super node." >> Exactly. >> So, yeah. >> So, so it really depends on your use case. >> It does depend on your use case. um super nodes would need a 4 terbyte disk which they typically have if they're RPC nodes it's not a big deal um and so what these you know RPC runners

have found is I have to force the client with a consensus layer client with a parameter to be a super node so that my layer 2 RPC can connect and see the blobs >> and we can expect um all of these clients to have uh settings or configuration options to uh all have a setting to do that >> to do that. >> Well, um, they should. I I I now realize I don't actually know what the setting for Kaplan is for Aragon. Um, but I know it for all others. So, all others have it. Kaplan probably does. It just hasn't been mentioned anywhere.

>> Yeah. I mean, it'll make sense for them to to add it. So, we can expect them to to have it as well, >> right? Exactly. Yep. >> Awesome. Um, was there anything else we wanted to to talk about for Seca? >> Um, I think we'll come back to the UDI timeline later. >> Uh, well, let's let's talk about the the um hardware requirements. There's this new EIP. Well, it's not new new, but it's it's been recently um created the EIP787D uh that talks about the hardware requirements um for running a node. Uh so yes, >> if you read the EIP, you'll see that

Hardware requirements

there's actually different roles, which is great because it it it kind of like bring us into this new discussions where people should expect uh there being different kind of nodes, right, on the network. Um, initially it was just people running their execution client and then with the merge we we added the consensus client. Well, before the merge with the creation of the beacon node chain and then now we're adding even more roles. Uh, but if you read the EIP, you'll see that there's like this full node ro which is just running a node uh without any staking. uh there's this attestation uh role where you are staking and only attesting not building

block and then this third role which is attesting and locally building all your blocks and and they have requirements that are much higher than what we used to recommend. Uh what's what's your take on this? >> Uh that was going to be my question to you. So the requirements are eight cores, 16 threads, 64 gig of RAM, and a 4 TBTE NVME disc. So what's your take? If somebody is running now happily with two or four cores and 32 gig and a two TB disc, should they run out and buy new hardware?

>> That's a very good question. I mean, if you want to futureproof your device or like if you're building a new one, you should probably follow exactly what they're recommending there. Um, but like today, if you're running a lower powered device with like 32 gig of RAM or even a two terbyte SSD, you might still be fine and you might still be able to wait a little longer cuz cuz as we know these um hardware components like they just get uh cheaper over time. Uh but eventually you should prepare yourself that you'll have to to migrate if you haven't migrated to like a four terbyte SSD. Um you should definitely look into doing that sooner rather than later. Um

in terms of like CPU, I understand that that they want to give themsel like somewhat of a buffer um because we we can expect um more processing power to be needed in the future. Um, in terms of bandwidth, I love that they actually put a number of on like bandwidth requirements because the numbers that we had before were kind of fuzzy. Um, but now it's way more precise, >> right? Um, so the interesting part to that is that the Gusaka super node requirements are not in this EIP >> and they're currently discussing whether

and how they can put them into the EIP. This is has to do with what kind of EIP it is and whether it can be edited after the fact, etc. yada yada. Uh, they basically have to make this a living document which it yeah >> currently might not formally be. So, that's going to be interesting. Um, I have a slightly different take on the two terabyte disc thing. I think with history expiry, people can just chill on that and keep running that if that's what they have. Um, there's no need to run out right this very second, not even sooner rather than later. Um, unless of course you have enough stake connected that you become a super node, then you absolutely need that 4 TBTE drive. So

enough stay connected to become a super node. We're coming back to foraka now with hardware. Um I did the math on rocketpool Saturn 2 and other protocols like light CSM it's going to be similar right. Um if you have 197 ETH on Saturn 2 you're a super node. >> Well that's as low as as that amount right? >> As low as that. 97, right? That's that that sounds like a lot, but it's not that much in the end, you know? It's like six validators worth of or old ones, right? It's it's a on the one hand, it's a lot, you know, and and

money as well, but on the other hand, there are plenty of solo stakers who have that. Um, >> so it's a big trade-off because like if if you want to participate in this ecosystem, um, you have to do this trade-off where you'll need more bandwidth and potentially more disk space um, compared to like if you were just running this as a solo validator, right? >> Correct. Absolutely true. Um, so we don't know yet what the what the targets for BPO 345 look like. Like for BPO2 max, it's an extra 600 gigabyte of storage up to, right? But you don't want to be not ready and then find out you're running out of space. So you want to have that extra space. BPO3 45, we don't know yet what that looks like. But I'm

thinking it's possible that even at a quarter of this size, you're not a super node yet. Once we scale up into BPOS's, your two terabyte drive isn't going to be enough anymore. And if you're a solo staker, okay, I mean whatever that's a quarter is 1,024 E. Um, you can afford a 4 TB drive. Thank you. >> Which is why I mentioned that people should be looking into potentially upgrading soon. >> Yeah, you're you're absolutely right with that. Um, with Rocketpool, a quarter of the way with Saturn 2 is 53 E.

That's not a lot anymore. No. So yeah, uh you're you're absolutely right there. Yes, I I do I do agree with you. Um after just saying maybe not so soon, it depends on how you're running your node. If you're kind of leveraging the LST protocols and you have a lot more ETH connected than you actually own yourself, then yes, you may need a 4 TB drive rather sharpish sometime mid 26 or so. So you talked about like keeping this as a living document, but but isn't the point of like trying to define requirements trying to set them in stone

for the future? >> If only it worked that way. And now Faka comes around and says, "Oh, you're a super node. You need all this bandwidth to make a block." >> Right? cuz cuz like I'm thinking like this is to give everyone like a a a a base to work with, right? Um >> Yes. And I think the CPU, RAM, and storage base is pretty damn good. It's the bandwidth that is probably going to move around a bit.

>> My guess is that uh they'll just keep adding ROS, right? So, so we will set in stone like the full node without staking role as being this value, but like there will be more roles added in the future with different requirements. That's that would that would be one way to to keep this as a living document >> probably. Yes. And also, you know, we'll have to see whether this comes to pass now with Clamsterdam. I am now rooting hard for for sale. I was on the fence about it before. Now I'm really rooting for it. I want that team to be ready for Glamsterdam and get it in. Um, proposal is the fork choice in uh fork choice inclusion list. So it forces

transactions to be in even when you're using an external builder. It means we can be okay with having fewer people who can local build and still get censorship resistance. Right? That's the thing we're losing as people don't have enough bandwidth to local build anymore is the censorship resistance. >> I agree. Yeah. >> So, so Fossil it would be would be a great um >> for that they will that they will make it into Gladam. That would be amazing. >> All right. We wanted to talk about the hoodie um fork and potentially the client version that will be needed. I I'll just let let you have that one.

Hoodi Fusaka Fork

>> Um the hoodie fork is on October 28th. So a little less under two weeks from now. >> Y >> yeah, something like that. Um we of course expect it to go swimmingly well >> because Fleshi and Sapoleia did and then we'll have the um mainet fork at some point after that. The funny part is I don't think all cords have actually said yet when the mainet fork will be. They want to see all of the test network forks to go through >> which is >> everywhere >> very usual as as the way they do it, >> It is very usual but everywhere you look online there's already a a specific slot and date and time for mainet given. So

take that with a grain of salt if you see it. >> I mean is usually like two or three weeks after the last test net that that they plan >> 30 days. >> 30 days. 30 days um minimum and that's because the layer twos need time for their governance >> and so we can expect this to be like if if hoodie goes well uh at the end of November we should expect the the main net fork to be planned for. >> I I expect that the mainet fork earliest can come um like December 3rd um and maybe a couple weeks after that. We'll see. You know that would give them enough time after the hoodie fork to around November 3rd

decide that all is well and they they can uh they can schedule and then December 3rd it it it forks. >> As a reminder, yeah, as a reminder, if you're running a node on Hoodie, make sure to update your clients because uh you won't be following the chain if you're not. Um, depending on how you installed everything, um, you you might need to use like some of the preview releases for some of these clients. Uh, cuz like not all the client team released this as a stable release. So, just have to look. >> Correct.

>> Yeah. And we'll have a link. Um, there's a Reddit post where I'm tracking these client releases. It talks about my own project, ETH Docker, but the release doesn't matter for how you run it. If you run this in ether pillar or in your e wizard or in rocketpool or just straight up with a sad guide as you know a large amount of people are um the versions are the same right it just differs a little bit on how you get the version um and as you say some of these things are an alpha or beta or release candidate um for the for the test net still >> um so the staking deposit CLI was deprecated Uh and now we are left with

ethstaker-deposit-cli

the eaker deposit CLI. Um there's nothing much to say about this. Uh we're we're glad that we um are being trusted with um maintaining this tool. Um Yoric, you are helping uh with this. I'm also helping uh we we've got Valar uh which you guys might have seen before um helping with the tool. Um >> anything else? >> Yeah, congratulations. No, and the bulk of the work has been done by you and Valifar, you know, and I've been doing a little bit around the edges, mostly with um if I recall correctly, it was the redoing the the click integration because it broke with the new version.

So, >> we also had >> Yeah, we also had Nixo help us with some of the documentation. So, this is this has been like a team effort. >> So, hopefully we can keep this tool going around for a while. That's the idea to keep it going, keep it maintained. Um, we should also say so we when we we um released this last year, we had a security audit done after the staking deposi gotten one in like three years. The intent is to do this yearly. So, we're going to have another security audit upcoming end of this year or early January.

Um and then keep doing this on a yearly cadence so that we don't get into a situation again where the security audit is stale. >> Good point. Yep. Um Erex um what do you know about it? Um I haven't even heard about it before. >> I know very little about it. It's um it's a execution layer client built in RO. Um, it wants to be both an execution layer client for layer 1 as well as for specifically for layer 2. That's probably their their um value prop here.

Ethrex

Uh, it's very lightweight in its code. Um, they've made some very specific choices. For example, when you look at all other execution layer clients, they can expire premerge history, right? Ethre said, uh, no, that's not what we are. We are not a client that needs to run as an archive or an RPC, use any of the others for that. Um, meaning an an a historical RPC, right? You can use it as an RPC for sending transactions, etc., but not historical. So, it plane does not execute premerge transactions at all. It cannot have premerge. Um because of some of these choices,

um their code is fairly lightweight, small. Um they've been rapidly releasing every week, sometimes with breaking changes. Uh so you know, uh it's certainly something to try on testn net before you uh put this on mainet. >> Are you running the client yourself? >> Uh not yet. I am actually I'm I've been I don't want to read sync all the time. I'm have other things to do. I need to play Diablo 4.

>> Good point. >> I'm waiting for them to with the next or next after that release they're going to introduce pathbased uh state storage the same thing that G has or similar right. Um and then I want to sync one on mainet and um given the sync time and database size and and um how quickly it grows all of that has been changing so rapidly in the last three weeks to a month that documenting it would have been pointless because it changes with the next release. So I think with pathbased it's probably at a which is the next release it's probably at a point where um I can

reasonably test it and then put that into my um documentation as to the the resource requirements and it hopefully doesn't change drastically then the week after though it may um >> and I'm guessing you will be supported >> you will be including that client in foc >> already done it's supported people can seek that ethics is supported in it docker as an execution layer client but understand that while they currently call this a version three um that is very aggressive versioning they're doing you could also reasonably call this a version 0.3 >> it's pretty much still like a in a beta um phase right

>> they say it's not it's release but you know they've been rapidly iterating and doing things like we'll release every week and then we we're not promising saying that you don't have to rethink every week. So >> they're not afraid to break stuff if if that's >> not afraid to break stuff at this point in time. Yes. So you know operation it it codebase for all I know it's it's GA quality. I have no idea but operationally you'll have to treat it like a beta because you'll be reyncing a lot. >> Awesome. Well that's um that's all we had on the agenda for today. If we if you guys have any uh topics that you'd like to suggest, we're very open to talking about anything uh staking related. Uh did you have anything else

Outro

before we uh leave? >> Um do have you ever listened to car talk on NPR? >> No. >> No. Well, because I was going to make this joke and say, "Don't speak like Remy." >> Why? >> They always ended it with don't drive like my brother. My dad would say, "Don't drive like my brother." >> I see. Awesome. Well, uh, thanks for joining. >> Yeah, I'm I'm not great with jokes like these. Well, thanks for joining and, um, we'll see you guys next time.

>> See you. Bye-bye.