All Core Devs - Consensus #153

Transcript

[Music] Okay, thanks everyone. This is consensus layer call 153. It is issue 1356 in the PM repo. Agenda is here in the chat. And yeah, let's go ahead and get into things. So, first up, one of our favorite forks. So, I think the first thing to call out is that the Hoody test net has gone live. The Pectra upgrade for that test net is scheduled next Wednesday, March 26th.

And yeah, so far it's going pretty well. I'm not sure if anyone has anything they would like to comment on about the test net. Yeah, there's a link here from Perry if you need to know anything about the network. Video.pendops.io. Uh anything to say? I'm not sure if P is around the time around. Uh we can say that uh we started giving out the keys. So initially uh running from Monday, we have uh started running all the keys for everyone. And as uh the different client teams are getting ready to spin up their infrastructure, we can uh hand over the pneumonics and uh they can they can run

every everybody can run their own uh uh valer keys. So if you if you're not running it yet and you would like to then please reach out and uh we can pass the pneummonics to you. We also have a few unused uh pneumonics that we're um happy to hand out to anyone who wasn't allocated keys at Genesis and if we're not able to accommodate you there, we can also get some funds for you to do deposits afterwards. Yeah, just reach out. Yeah. Okay, great. Thanks for spinning it up so quickly.

Uh I was curious about client releases. I've seen some people making them. Uh, do any client teams want to call out a particular release that's compatible with hoodie? For loadar, we have 1.28 released yesterday. That one is compatible with hoodie. Cool. Yeah. And otherwise, okay. Tech release imminent. Yeah. Nether's ready. Okay. also best who great so yeah um if you're listening just look at the usual places you go to get updates for your clients uh they've been streaming in and yeah you'll have a

version to run hoodie if you're interested in that test net and yeah otherwise it looks pretty good and petra like I said is uh let's see I think this is next Wednesday so yeah that'll be exciting to see and hopefully this time around uh there are no issues Okay, just to call it off in the chat, WH has no release, but looks like main will work. Lighthouse has a release. Gat's working on it. Okay, great. So, either way, um, if you don't have a release yet, please, uh, work towards getting one. It'll be useful. A number of different community members are interested in running that test net. So,

a release with official support would be really helpful. Okay, so next up then I wanted to get into uh essentially postmortem for Hleski and Sapoleia test with Spectra. Um yeah, I know that uh there's been some work on gathering information around different issues. Uh does anyone want to speak to any of them now? Um there's kind of a a list of a few different things and I believe uh Mario from the EF is working on a actual postmortem and I don't think we have that yet but uh once we do we can go through it in depth. Um

essentially yeah there were some issues with yeah a number of things configuration in different clients. Um then with Hleski we had issues with the chain split and justification there. Uh that led to a number of issues around yeah that basically made the test not unstable. We saw some issues uh with slashings acting a bit weird. So that's something we should follow up on. And yeah there are a number of things there. So um I wasn't sure if we'd have an actual postmortem yet today but it seems like we don't. So we will wait and otherwise we have been working a bit on essentially like a sort of checklist or

protocol even for instance response. Uh I see Frederick's here on the call. I don't know if you want to say a few words about how you're thinking about that. Oh, Tim says we do have postmortems. We'll circle back around to that. Um I don't have that much to say yet. Um it's still a work in progress and it's uh being discussed with various people from the client teams. Um and once there is some kind of initial draft ready, it will be posted for more general feedback.

Okay, thanks. And maybe just like a brief overview. The idea is just to have I mean there was like some de facto process and there's always been a deacto process but I think having something that is more formal you could even imagine there's like different point people for a particular release. So you know uh or I should say upgrade so if something does go wrong then you know we can say okay this person is in charge of doing this this person is in charge of doing that and hopefully have a more streamlined way to respond uh when something does go wrong.

So, okay, great. Hot off the presses, uh, we do have a postmortem from Mario, which is super cool. And yeah, I guess given that we're just seeing it now. Let me just grab a link to it here. Oh, put it here. And um, yeah, I guess please take a look. And yeah, I can follow up async if there's anything we need to address. But ultimately, yeah, there's a number of things that uh we need to follow up on. And I think the main thing is just having this notion of non-fality, test net or DevNet. Uh so we can poke into these issues and yeah resolve any any bugs that we find.

So I think that might be that for now. Uh anything else anyone would like to say about uh Sepia or Helski? Okay, then I suppose we'll move on. Uh not too much to say there. We've just covered this on previous calls. So we'll just keep those threads running. Um from there then the question is uh essentially yeah getting a temperature check on Petra and mainet. So I believe we discussed last call around some

things we wanted to see. One of them would being the Petra hoodie fork going well. Uh so that is going to happen next week. Uh there was or there is a bug bounty competition that's wrapping up I think next week as well. Uh Frederick do you have more information on when that's over? Uh yeah it's the 24th. And yeah, so there's a few more days and uh yeah, there's a few findings coming here and there. Okay, great. So yeah, then I wanted to check in with people and understand kind of where we're at. So I think seeing hoodie go well is a prerequisite. Uh like Frederick

mentioned, I think there have been some findings from the bug bounty. Um and so you could imagine we want to have some I don't know if you want to call it a mortorium but basically have like some period of time in between when um you know we found a bug and there have been no bugs and then we wouldn't really think about mainet until then. So you can imagine there's like a two or three week buffer uh in between that um before we move ahead with mainet. Uh there was a comment here from Andrew on some actual timings uh which is useful although it might be getting a little ahead of ourselves. Yeah. Yeah. Deno has this concept of bug escrow which I think makes a lot of sense. So either way,

yeah, I mean I guess I'd just like to hear from client teams like how are we feeling? Like do we are we feeling good about Pekra? uh would people want to still give it some time before we seriously think about mainet or do we think we're ready to go ahead and set some dates? Um you know, we could imagine basically saying on this call, hey, we feel pretty good about it and then next week check in with the heel teams uh and move forward there. Okay. Like says he wants to see hoodie. Justin says he'd like to give us some time.

Yeah, Paul. I know that previously we've already kind of indicated that we want to see Woody actually upgrade to Electra. Um we've also indicated things like we want to see how people like Lido use it and they going to they're going to take a period of time. So, I think we need to understand how comfortable in all of that that we need to be before we're going to be talking about dates because I don't think that the dates really cover what reality is where we have to wait for 30 days postrelease and we want to see hoodie upgrade and all of that sort of things.

Yeah, I agree. Um, yeah. So basically from the chat and what people are saying here uh we are not ready. So we'll keep an eye on it. In the meantime there's a lot of work behind the scenes to squash any bugs and yeah just ensure that things proceed smoothly. Okay that was pretty straightforward I think. Otherwise then on Peterra there was something that came up um around history expiry. So with history expiry I believe there was a May 1st uh commitment to get rid of the premerge history and that's fine. Um one thing

that is complicated a bit is with 6110 and how it uh interacts with deposits. Uh essentially before that you need all the deposit logs and you know that basically means having the history and that kind of then implies if you think about it a dependency of history expiry on the current history existing uh which then implies that uh with 6110 you can probably get around this uh but I did want to call this out just to confirm with client teams uh if they are seeing this the same way. So maybe let me like rephrase that a bit like do we feel like we can ship history expiry um or petra goes live and the sort of key unlock

there is 6110. Okay. Well, we got a confirmation from Dustin. I'm not sure if there are any history expiry or port of people on the call. Yeah. So Sophia asked it shouldn't matter for premerge history. The thing is if so there are deposits before the merge and so you could imagine wanting those for example if you're syncing the chain.

Yeah. Uh, Nico asked if we just expire history before deposit contract deployment, right? So, that would be another way to do this. And yeah, um, again, I'm not sure if there are any portal people here, but yeah, what what question is being asked specifically? there's a dependency of the CL on the history basically and this goes away with 6110 but that's only live in Peterra and so then now we kind of have this dependency between the PCRA

dates and any history expiry dates and there was a commitment uh to drop history in some form I think coming up in May now given with the you know possibly extended picture timelines There's something here we need to coordinate. Uh I think it would be fun to do the proposal of chat of doing like some number before the log started appearing. Sorry. Yeah. So that would be one way to do this is rather than premerge you just go back further in time I guess to the beacon change in um possibly before then whenever I guess

okay actually it' be when the deposit contract went live yeah I think that's a good middle ground and then pear will ship in like a month or two later and then we could just uh move the number for 44s or 6110 I Right. Okay. So, yeah, I just wanted to flag that. And um yeah, I can also make a note on next week's ACDE uh just because there might be some more oral people there. And yeah. Okay.

I think that well it sounds like the decision is to do history expiry but uh you only expire before the deployment block of the deposit contract like Lash was saying here. Does anybody actually want to do this? Because one of the things with the premerge history is it's all of this data that is not of the format that we have anymore. Like now postmerge we have all of the Ethereum block data within the beacon block. But premerge one of the advantages was you know this is old format that we're not going to use anymore. We can just make one commitment to all of the premerge history at one moment. And now we have this route that

you can put into bake into clients and then you can always prove this premerge history. So if we break this up now we like create this root of the the pre-Marge data of the pre6110 data and now we need again need to like deal with the data between 6110 or sorry the data between the deposit contract launching and the beacon chain launching in a separate issue. Right? So then the other option I think like Tim was calling out is we just delay history expiry a bit.

But this is something people should be aware of if that's what we do. It seems a lot simpler just to like wait for petra in my opinion at least. I had a question around the test nets as well. So um Nishan says this is already live on Sapoleia but I feel like we should test this on test nets as well. So um is there value like is it are actually all the validators on Solia running this and should we test it on Hleski and Houdi as well

or yeah I guess Hudi has no premerge history but um same problem with there's also no premerge history so is likely the only okay and when we say it's live on Sepia is it like there's one node running it on Capoleia or are the majority of the validators and nodes that we're aware of running this on Sepia? I'm not as far as I know. Uh Nant made the comment. Do you have more information to Sean?

Yeah, I I just know some ELS are testing with dropping the history. I do not know if it's all of them. I think yeah, Nethermind is testing on it. Yeah, because it feels like this is a pretty big change like we should thoroughly test it on at least a test net before we move to mainet. So that is something that we can prioritize now if um it would be nice to see like okay what percentage of Sapoleia can we get to drop history? what issues come up when we do that and what not before we actually ship test the mainet.

So I want to give a quick comment here and just say that the a big chunk of the testing related to history expiry is just on the clients themselves because most of the impact of this change will be within uh the functionality provided by the clients and then on the network wide there's actually I think not a lot of interaction to be expected except for the two things which is that the sync still has to work after this. And by that I mean the sync up like down to the merge point that should be working with all of the clients even though a significant chunk of the network has

dropped the rest and then the other thing is the interaction with the CL. So these two things I think can be tested uh in the test net. But most of the uh tricky bits of history expiry is just going to be stuff within each client, right? And are you suggesting that this can be done in isolation like just locally with your client or does it need some more thorough testing? Like for us at least like with GU we are in the process of implementing this right now and most of the stuff that we found so far is just stuff that we have to fix within our own client. We have created a

testing tool for this as well that will basically just hit the RPC and check what the client is doing and uh but it's not I don't think it's like this type of change that really requires like a ton of network testing sort of right yeah so that all makes sense I still think to temp's point we should roll this out formally on Solia before mainet so given that we do already Pectra on Sapoleia, then we can move ahead there. Uh then yeah, it sounds like most people here want to wait until Peter's live on mainet before rolling out history expiry to mainet.

yeah, I can put a summary of this uh into like the history expiry discord channel. Is there a better place? Uh I think that's a fine place. Um, one question. Sorry, just to to follow up on the SEO stuff. So, I asked what percent of stake and nodes do we want to see? That's right. Um, and then Barnabas says 100. My expectation is we probably won't get 100, right? We'll still have some nodes that want to store everything. Um, at least from the validators side, I think we're going to get 100.

Yeah. And I guess I don't know Kobe like what is like a reasonable expectation here like I do feel like having run you know like a a small number of nodes ad hoc in an ad hoc way on cipoleia feels insufficient to then say we're defaulting to dropping this on mainnet. Um but I I don't have a sense for like okay what is the like number we want to see on Sapoleia. Um do we want to move 100% of the stake? Are there like some is there some percentage of nonvalidating nodes we'd also like to see update like yeah do you have a feel for what's a reasonable thing to aim for before we actually ship this to mainet?

Uh I don't uh as Felix was saying earlier that this is mostly like uh there's not a lot to test on the peer-to-peer protocol from my understanding. Uh, so I guess it would kind of be up to your guys' comfort levels. Uh, if you want to do the whole network. Uh, if you don't do half. I mean, it's pretty flexible. Yeah, I'd imagine we just get all the nodes we can on to update. Maybe one one thing I don't want to derail it too much but like on this topic uh uh since we had also the portal meeting last week and extensively discuss uh the ETH wire protocol version 69 this is maybe more of an EL call item

but we do actually need to still formally agree on the definition of this protocol version and one of the things there is that I proposed uh to add uh the uh sort of like history pruning block information into the wire protocol alongside some other changes. Um I'm not sure uh we do kind of have to at some point make a decision on this and say yeah we're going with this or we have to change it still. There was a bit of a disagreement earlier about this and um it would be kind of nice because then we could actually check on the network which you know like how many nodes are supporting it first of all like how many nodes have actually dropped the history but also we could test all kinds of interactions like if a client goes too

far for example what does that mean like if they if they uh prune basically like much more history than they should do we disconnect them or how does that affect the other clients and so Okay. And yeah, it sounds like will be a good good place to test that. I guess one thing then to follow up with uh around this E69 protocol like is this being tracked somewhere? Is there an issue? Are the district expired people just aware of it?

Okay. Um, yeah. How about we add an agenda item to next week's call and I can also put a summary of all this into Discord. Okay. Thanks, Felix. Okay. So I guess a quick summary uh we do agree that there is this dependency with pectra and history expiry. So one way to move forward is to keep this May first date uh but then do that on sepoleia. It also gives us room to test and then once live on mainet we can think about his expiry there.

Uh I think that was all I had for lecture today. Anything else we should discuss? Yeah. Uh I would like to mention that on factory we have raised the gas limit to 60 million and we have been spamming it pretty heavily. Uh we have found that guest and lighthouse uh pair seem to be struggling uh to keep up. I think guest is already aware of the issue but uh I just wanted to raise it here too.

This is with 16 gigs of RAM. Yeah. Okay. Yeah, we were seeing some out of memory issues at the higher gas limit. So yeah, now you said G and Lighthouse. Yeah. So that specific pair. So like G doesn't seem to have issues with other CS and Lighthouse Lighthouse doesn't seem to have issues with others. Oh, interesting. Okay. Uh yeah, G Lighthouse, please take a look. Otherwise, Barnabas, I am curious like how generally did that go moving to 16 mil.

Other than that, it was pretty smooth. Like we had to bump uh the resources on every single node. Uh we started out with 8 gigs of RAM, but that was just really struggling for lots of pairs like Bez and Tech really really struggled to keep up. So like 6 gigs of RAM is the absolute minimum. Okay. Well, that's good information. Cool. Anything else on PCRA? Okay. If not, then we'll move to Puros.

So, uh there was a nice breakout this week. Um, I guess maybe we'll start with DevNet 5. Uh, does anyone want to give an update on how DevNet 5 is going? It sounds like it's been pretty stable from what I've seen. I can just say on lighouses and we had some syncing issues, but we've identified those and fixed them at this point. Okay, awesome.

Sorry. Oh, go ahead. Prism supernet has some issues because um the way the database is designed we we save one data column per per file and so in total we need more than 10 million data columns and 10 million files. Uh we are working on a fix to redesign the database to avoid this issue. Thanks. And presumably you'd fix that before sex, right?

Yeah, it's ID. Yeah, hopefully this week. Okay, cool. And yeah, otherwise uh there is DNET 6 planned. Uh there are specs with a few different things. I think at least validator custody is uh one of the big differences. And yeah from the breakout it sounded like implementations are underway. So yeah things are progressing there part of us. So yeah we would like to have validator custody as soon as possible already deployed on devet 5 because uh really we don't have to wait for devet 6 uh to launch. It will be a nice separation but if any clients are ready just let us know and uh and and we can basically

just roll it out on dem 5 already and see if it works expected and also tested ones. Additionally we also uh filed some uh private keys P2P private keys. So, we're going to be launching uh a 16 node uh network basically with each uh node covering one uh subnet a one unique subnet. So, uh we're going to try to sync up a super node to a network of nodes where uh everybody has only one unique subnet.

And that should that should probably help us understand if every client is able to serve every single submit. Okay, sounds useful. There's um one more topic. So the Sunnyside lab guys have been doing some um test nets with higher blob counts and what they've noticed is that uh there are some peering issues that start occurring uh at higher blob counts and we're current they're currently testing mainly with Gats and the current assumption is that Gat's implementation of get blobs might be um not as optimal.

So it would be nice if we could have other clients also implementing it and engaging with the topic in general. I think right now there is only a get implementation. Um so yeah just having more EL implementations would help. Can any teams here speak to their git blobs progress? Okay. Aragon has good bulbs. Anyone else looking at it?

Okay. And there's a discussions right here in Discord. Uh Roman, do you want to say more about your comment here? Uh basically the Sunnyside guys flag is um experiencing problems whenever there are higher blob counts and we did discovered the bug that's causing that. Basically for engine we only check in memory index and don't check it on disk whether they're available.

Gotcha. Yeah, I think they already have a couple more experiments they want to run. Um but yeah, I would assume the team would present their findings either next week or the week after once we have some explanations. Okay. And Ben says here in the chat, another mind should have it as well. So it might help with testing parry because then we have G, Aragon, and other mind that support get blobs.

Perfect. And just to confirm, are all of these get blobs both for W1 or for W2? Okay, got it. So, it might be V1. Um, yeah. Either way is just it would be great if more EL devs are engaging with Pas and we can take it from there. Okay. Yeah, I think people are a little busy with Petra, but soon we should have pretty full attention on Kudos.

Uh, cool. Okay, let's see. I did want to call out there was a small spec update for Fulu. And this essentially just moves some of the validator concerns into a validator guide. This is just consistent with previous upgrades and the specs. Uh so this is mostly a presentation thing uh but just an FYI and yeah please CL devs take a look uh when you have a minute. There was something else that came out of the breakout call Tuesday and essentially it has to do with how we handle valer custody. Um so the way it works today is that

uh basically the number of columns you custody scales with how many validators you have and there was a point brought up that this might not be responsive in the event that your validators change while you're running. So why could they change? Well, maybe you consolidate so you have some number that becomes a smaller number. Or you could also imagine um many different software setups have the ability to add validators dynamically while say a beacon node or VC is running. So in this case then you would essentially be out of sync with what you should be custoing and what you started with. So does anyone have any thoughts on this or do we feel like we need to address it?

Is it not balance based? So, I'm actually not sure what the wording is at the moment. There was another PR uh from Goodender to uh touch on that, but either way, there's still this point that I think sort of the negative limitation is you just when you boot, you figure this out and that's what you custody. But you still have this issue where this could change, you know, at runtime essentially and then the question is how to handle that. You could make the argument that like there won't be frequent enough consolidations uh or additions like this that it would really matter, but it did it was a small thing that came up and I thought I'd bring it up here.

yeah, just want to add to that. uh since it's uh indices based and therefore basically the balance on consolidation or for any other reason for whatever reason the balance changes uh uh so the custody requirement will change and the peer will have to dynamically uh update back fail and update the custody that uh it has of the history in the last window that it has to maintain the custody for as well as going forward. So uh that way I think dynamic one uh automatically takes care of it and uh uh the static one uh we are basically uh figuring out whether to change uh uh the language uh to support both type of dynamic and static types of

custodies. Uh but yeah we'll we'll see on that. Could we have that uh note somewhere just store how many validators they were connected to? Then at least it wouldn't be a problem at every like startup and they would just remember oh like the total balance that connects to me is 1,000 ETH. So I'm going to custody for that.

Yeah. So what my proposal was to have this as an explicit uh input where you know people can so where the spec itself is just talking about uh the sport is stake whether it's dynamic or static and again it can as you said it can be done in many ways you can take uh you can basically have validator registrations take care of how many validators are registering through you or maybe the validators who have used your APIs for uh two epochs Right. So you can do validator registration or you can provide them as a static input uh validated indices as static input or provide a supported stake which was uh the uh PR that I was pushing. But uh yeah I think we we would

be able to easily identify the stake that this particular nodes needs to provide and the custody that it needs to provide. Right? Yeah, I'm trying to think about what's like what would make it the easiest for users and then like ideally you don't want another command line parameter that you have to specify but if it could work it out at automatically and then just store it as a reasonable default it would mean that users don't have to change anything. Yeah. So once we have dynamic then basically you don't need anything because then everything is automatic automatic and uh then the uh uh beacon can decide whether it's want to store but there is no need for it to store

because whenever it will restart again the validators uh it will keep track of the validators that are uh uh getting duties from it and uh then it will be able to do it. I think basically it's client dependent how the clients want to handle Right. And do you know gender for the dynamic setting? Like would it pull for like periodically because that would address the issue that I was bringing up originally. Uh could you repeat that?

Yeah. So I guess there's two things here. I guess I don't fully understand with the static method how it would update. Um so dynamic then makes a lot more sense to me. And then what you would want to you know this is also to Denra's point like you would imagine you just boot your node like today and then the beacon node could ask the VC for how many valors are attached figure out custody from that it could also then do this periodically so like every few epochs or something or you know on some cadence then it should just track in the way we want it to.

Yes. Yes. So we generally have uh every on every poke we generally have validator registrations especially for uh uh the feed recipient as well as uh for builders and maybe we can use that method to register uh the validators into beacon node the indices the into beacon node that beacon node should be serveing uh the duties for and uh so so yeah that method can be done or you can we can also do that okay what are the uh what are the validators whom you have served uh uh APIs duties for two epochs in a row because for example suddenly you have to switch your validator to someone else to a backup node and it

should not then reject it because your main node uh uh was the only one having the custody and the backup node was not having the custody. So uh so I mean we can basically say that okay uh so validator can track what are what are the uh uh so beacon can track what are the validators which are consistently using it and uh there can be many methods for it. So right right and can someone speak to how it works right now like is it something you hard code in your configuration? Uh could you repeat that please?

Oh yeah I was just asking how does it work right now because it sounds like it doesn't do this sort of more dynamic periodic check. So we have registration and we can as photos is also sh saying that we can just directly reuse it. So we have builder registration we also generally do a fee registration registration uh fee uh recipient registry. But yeah I'm asking if it if the custody infrastructure already works like this today. the validator custody one.

Alex client haven't implemented it yet. It has not specified as how the registration should happen. Uh so there is no specification for that right now. So it I mean clients are coming up with their own ideas as of now. I guess I mean in this spec it just says basically based on the current state like uh look at what's the balance that's attached to your node and and use that. So it's like as dynamic as it can be I guess. Um but yeah I think it's okay to to make it more more flexible or or more restrictive. I mean if if you want to make it if you want to really like specify and expect that it should be based on um registration like that that's also fine. I think it would be

good to like decide on this sooner rather than later because it's just been like this uh kind of unresolved thing for a while and like people are already working on implementation. So I think it like yeah if you want to simplify it would be better not to waste people's effort in the meantime. if we if we're going the registration route then basically I mean we could still do the supported stake PR in the sense that cleanup in the sense that uh uh so wherever spec has uh validated indexes in is available data or to figure out what the custo needs to do.

It can just use the sported ST and then sported ST itself is maintained by the beacon node through this registration and it could basically be a uh independent thing and that way basically the spec uh can be cleared out and that was what my suggestion was on how the static uh custody PR could be reshaped. Okay, my sense is that we leave the spec alone. Uh, but yeah, it does seem like this is some type of implementation note that would be valuable to have written down somewhere. Um, I'll take a look at your PR agender and yeah, I'll make sure that we move

forward on this. Uh, because yeah, sounds like there's something to resolve here. Franchesco, uh, yeah, I don't know. I guess I would if we if we do make it more flexible, I would want to change the spec just because right now the spec does basically say like you should I mean it's phrased in a way where like it seems like you should be uh dynamically adjusting it and I feel like yeah if we if we don't want that then let's just I mean we don't have to talk about implementation details in the spec but like maybe just like phrase the spec in a bit more flexible way.

Um I think we do want the dynam Oh, at least I want the dynamic thing. Uh and I think there was at least some support in the chat for that. Yeah, dynamic thing could still be maintained through that same spec. I guess uh the change that I was pushing for uh so that basically doesn't uh put any on the clients to implement it in any particular way. Um, okay cool. Yeah, I can follow up here and we will get this figured out.

Anything else on Purdos? then great. Uh let's see. I think there is just one more agenda item then for today uh moving towards Fusaka and uh there is a a request to move EIP7688 uh to PFI status which basically means that it's proposed for Fusaka. Um the way that this pipeline kind of works is

that you would have various things pfified. Uh then there is then a downstream step of actually scheduling things for Fusaka. That would be what's included in the fork. Uh so we're not quite to the SFI stage yet uh with Vaka. But yeah, just a call out that this EIP has been pfied. And if you don't know the number, so this is 7688 and this is essentially stable containers. This came up because yeah so I think as many of you know uh there's this notion of generalized index with SS and essentially they're not stable if you change the type past a power of two uh is the TLDDR and uh this EIP with stable

containers this is one designed to give you the stability and this is really nice for applications because if these generalized indices change then you know presumably you need some sort of governance mechanism um some way to update your smart contract infrastructure with the new indices and something like this would make it so that uh you essentially just write your smart contracts once and then you don't need to worry with any sort of governance. So yeah, um let's see. This came from I'm not sure. This came from me and I'm here. Okay, there you go. To me. Okay, cool. Yeah, I wasn't sure.

Yeah, thank you Alex. Yeah, if you'd like to say anything. Yeah, sure. Thanks. Thanks for a short introduction. So basically the thing is that with uh 4788 which is beacon boost available on execution layer uh applications can now verify consensus layer data. To verify this consensus layer data they need to know where this consensus data is located in the container and that's why we need gene indices. But the problem is that the algorithm of containerization right now is designed in a way that if any structures change on say on top of the tree or at the beginning of the tree it means that all of the indices move uh further down uh the tree which creates

two problems. The first one as Alex mentioned is that this indices should be at least upgraded with the hard fork. And given that there's no way to have a simultaneous upgrade that will go together with the hard fork, there's an additional effort required not only to support and update and prepare this new indices and to applaud them to approve them by governance and so on and so forth. But there's also an uh additional effort here to create mechanisms that do understand like on which fork we are currently at and depending on that they're using either previous indices or new indices. So that's a huge pain in ES. Uh and why I have raised this question specifically at this moment uh

from lighter point of view is that before like before the current moment we have only one place where we use uh this mechanism and it's like pretty okay to update this one place and it's a community staking module where we proof validator withdrawals and slashings using that. However, uh in the lighter road map in the upcoming six months, there's three more places which will potentially use the same functionality which is ZK oracles which is proofs of triggerable withdrawals and uh one additional place that I can hardly remember uh but yeah that and and SD volts for sure SD volts. So the problem is right now is with with the current state we will have to and basically any

other protocol uh using EIP4788 will have to do this uh significant development with the support of this uh dynamic G indices which can switch from hard fork to hard fork then on each hard fork and we've seen it before like starting from denun this hard this G indices they have been changing they will change in pectra and they will most likely change in Fusaka and moving further on. So on each hard fork there's an additional governance action required and the additional complexity of the code uh required from any protocol using this uh EIP4788 is uh significantly increased. So my proposal here especially given that I

know that uh several client teams uh have almost done this implementation namely Lstar and Nimbos uh I propose to consider the implementation of this relatively small yet uh significantly valuable EIP and included infosaka given that with the peer das things are seems seems to fine and this EIP itself is not a significant step neither in terms of development nor in terms of testing. Okay. Yeah, thanks for the update.

Uh I guess yeah, before we take any more comments, I will surface Nixo's comment here. Uh Rocket pool could not make the call, but they're essentially in the same place. uh where yeah there is very nice infrastructure uh for this uh for any type of staking pool or like other I mean there are other applications as well that you could imagine using the beacon layer data and yeah um this has kind of been like a long-standing issue with the SSC spec uh yeah thanks Dmitri and uh sure I just want to add that this EIP P while it solves these uh stability issues, it

also opens up some synergies if we want to do things like reducing beacon state size because it also gives us the concept of optionals. For example, if you want to get rid of the ETH1 votes in the beacon state which are used for the legacy deposit mechanism which is no longer used after um after pectra is fully uh done with the legacy deposits. If we just delete them from the beacon state, it would also reindex everything, right? But uh with with this uh EIP 4788 uh not 4788 the other one 7688.

Um with that one we get access to optionals which means we can just mark that field as optional and then exclude it from the Faka profile of the beacon state. And we can do the same for finalized epochs in the validators list. There are currently several epoch timestamps tracked there even after they are no longer required for any state transitions. If we can get rid of them, that's uh dozens of megabytes that we can get rid of. So uh if we decide on getting this EIP, we should also think about what else can be uh combined with it on the beacon state because it will

essentially require us to think a bit more ahead about the design space that we would like to have. Oh, just a mic glitch. But yeah um it's mostly staking pools Tony and uh layer tools I guess as well layer does use 4788 just by the way. So I mean there are there are a number of people who use this contract and potentially have this issue.

Yeah. At the very least, what we can do is just like I can bump the EIP to FU. We can run it on the DevNet and we can think about possible other changes on the side like if we want to get rid of E1 data, if we want to clean up the beacon state and so on. So, yeah. Well, on that note, so first off, thank you everyone uh for the comments. I do think the prudent choice is to focus on puros and puros stability before we think about other EIPs to add into Fusaka.

And yeah, I think for today it's probably best just to acknowledge the PFI of the CIP. Uh everyone can keep it on the back of their minds, but otherwise I think we'll leave it there for today. okay. Tim has an all caps message. No additions until DevNet one. Yeah. So, let's stick to that.

Um, and that being said, yeah, there are a few PFID IPs that we can keep on the radar, but yeah, I think everyone here agrees we should focus on PIDOS on the CL side. And speaking of, I think Jinder, you had one more comment to circle back to POS. Yeah. So uh one thing that while we were looking at the implementation of our custody was that we had to open up all our gossip channels uh we had to subscribe to all the custody subnets all the time because uh we had we have to do a local block publishing and uh I'm not sure how other clients are managing it.

For example, you only maintain the custody of four but then you also have to do a local block publishing. If you don't have to do a local block publishing then obviously there is not an issue because the builder will have builder will transmit it. Uh but uh for local block publishing how are the clients uh handling it because if you have an open subnet then you will receive custom messages on it. I didn't quite catch the problem. You're asking about the column publishing when you're local when you're locally building.

Yes. So basically I'm saying that let's say you have a node which has a custody of four you only are custoing four columns but uh you have to open subscribe and maintain PS for all uh all the subnets because uh when you want to do local block publishing then you won't be able to publish all the data and for example if you only have if you're only subscribed to four subnets and then uh you won't be able to get enough of your uh columns out there for anyone to even reconstructed them back.

Um, unless I'm wrong, if you are doing local block building and you I subscribe only to four subnets, you only need to have peers in your fan out, not in your mesh to be able to publish a block. So, you don't need to subscribe to all subnets. Only have enough peers in fan out. Okay. and then dynamically push them uh those columns on that subnet, right? Yeah, that's what he's referring to.

All right. Thank you. Yeah, that makes sense. So, we will try to include this approach. But however, that mean that you need to look for peers in all sub as soon as you have one validator connected. Uh and so possibility possibly you are going to propose a local block you have you you need to have peers in all subnets yeah even if you don't subscribe to the subnets right so ID any of our once validator is attached any of our uh peer uh prioritizing algorithm should make sure we'll basically for this particular thing will go out of the window because

you got to have all the peers at least at least 64 on the 64 subnets maybe. Yep. Thanks. Thanks for this. So, let's see. I think that was everything on the agenda. Um Paul had a comment speaking to some other things that we've touched on already. Anything else? Otherwise, we will wrap up early and turn our attentions back to Petra and Puros.

Great. Thanks everyone. I'll see you next time. Thanks. Bye. Bye. Bye. Bye. Bye. Bye.