All Core Devs - Execution #207

Transcript

over. Thank you. Um, welcome everyone to ACDE number 207. Uh, bunch of things on the agenda today. Uh, first and foremost talking about Hleski, how we move that forward. Um, and how we want to approach testing PCRA given the issues we've seen on the network. Um then there were some uh fusakar topics we didn't quite get to last time uh around the uh the uh transaction formatting for the blobs um and uh some eof and pureas testing interactions.

Um if we get through all this then we should discuss uh how we want to approach uh deadlines for like the proposals for Fusaka in addition to what's already there. Um and then uh we get through all of that. Uh some updates on 44s and uh there were a couple EIPs that uh wanted to be presented as well as some discussion around stateless. Um to kick us off, Perry, do you want to give an overview of your document for Hleshki and the outreach that's been happening in the past week or so uh to figure out the right path forward?

Yeah. So maybe a bit of uh context. So Holski was suffering from non-finality for about two a little less than two weeks. Um on Monday we were able to get it to finalize again. And that helps a lot with um client stability, nodes being able to sync the network for map builders being able to test their stuff and so on. However, a side effect of the long duration of non-finality as well as the invalid justification is that we have a lot of slashings as well as exits due to going below the ejection balance.

Um, and just as a note, the ejection balance on whole is 28 E whereas on minet it's 16 E. Um, it's another one of these discrepancies we probably will standardize in the future. Um so as a result the exit queue on Holski is about a million validators and the downside of this is that it would take over a year for these validators to fully exit. So while Holski is still useful for a lot of things we won't be able to realistically test Spectra exits on it. Um this is of course limiting for for a lot of staking providers etc. um especially because a few of the pectra features rely on on exits. So we had a document outlined u maybe someone could

post it in the chat if not I will try to quickly grab it. Um so we had a document outlined with four um options. So the four options being uh plan A which is we just set up a new test net. So this would be the third line of test nets. um none of the options eliminate whole key because there's still enough to learn from it especially with having such a full exit Q for so long um but instead another test net that we maintain um there was a minor modification to this proposal proposed by Jim um that's essentially let's not do 5year test nets anymore let's do threeear test nets makes it a bit more predictable um there's plan B which is use DevNet 6

as a test net until June um The benefit is that this network is already up and live. Plan C is to set up a shadow fork. So this would happen for span of let's say a month or so until PCRA is live on mainet. And plan D is using a hacky solution. So um a new fork that we introduce on the CL or whatever that empties the exit Q. Um so these are the four options proposed. Maybe I pause here to hear initial feedback or should I already Maybe I pause here for initial feedback.

Yeah. And I guess maybe yeah, for more context, it seems like the feedback uh that we've received mostly leans towards option A. Uh there was some some minor support for the different ones, but uh overall that feels like the one that would make the most people happy. So does anyone have different perspectives on this? Um Ivan. Yeah, thanks. Uh yeah, so first of all, thanks for the talk. It's uh really clear. Um uh from Laya side, the best option would be option D because we already have um all our tooling um u kind of tailored to to the existing Hleski deployment. And if we go for

option A which is essentially a new test net we would need to um probably spend three to four weeks to redeploy the uh contracts all the offchain tools around it including oracles uh monitoring and uh interfaces and also make sure that we have all the integrations on top of lido also there. Um so ideally for us it would be option uh D. Um, if we go for option A, we will probably need a little bit more time.

Thank you. Um and yeah, I think that so the main concern around option D was um that we don't really want to implement code paths that mess with the exit queue um for just holis and then you know risk that being triggered uh on mainet or having even more help issues on hleski. Um Okay. Uh Matt, yeah, I mean across the, you know, the landscape, I think that most of the

protocols that are built on on Holliski that are not core devs are going to prefer D. This is just a hunch. It's the same for IEN uh layer protocol. The reason being is that you know all of the other options require a full deploy of integrations and infrastructure like not just you know it it's lido but it's also lido plus everything built on top of lido and it's ien layer and everything built on top of ien layer. Um we yeah again we prefer deep simply because of the expedience and the the ability to not let's say make mistakes or miss things uh in our testing in general. Um I know that there's a philosophical argument to be made here having worked

on a client team. So I just kind of understand the the the the context in which this exists. But D is definitely preferred for us just from the sake of expedience and the fact that even the new test net solutions or the DevNet solutions will still take time to test in general prior like if we're if we're thinking about the mainet timeline we have to push back in that sense because we wouldn't be able to test any of this functionality regardless using A through C uh with a short timeline. Um so if again if our if we're looking at like the expedience of domainet release as our timing and we want to make sure that the large protocols are tested uh it that's the kind of trade-off that I I think will happen. Um, and yeah, D is D is is is our approach. And if there's

something that we could do on the this like like you said, there's hacks of course. If we can make those hacks uh kind of let's say a rip and replace, let's I think that that would be something worthwhile considering or just code paths so we can straight up delete. Thanks. Yeah, I don't know if anyone on the CL side can share like what the minimal implementation for D would be. Um, there anyone from the CL side who can

give an overview? Okay. Uh I guess until someone steps up. one, yeah, another another consideration is if we if we do option D, um, you know, do we have this as like a short-term version? So, it's kind of a it's kind of a weird uh variant of option C almost. So, instead

of having it be a shadow fork, we say that we empty the exit queue. um we say that we empty the exit queue and then uh we also coordinate launching a new test net so that we don't consider um so that we don't consider um yeah having this be a long live fix. So the proposal there is that we essentially do de for the short term um get holski to a usable testing state and then shortly after sunset it and parallelly spin up a new test net that

replaces holleski longer term is that sort of the concrete proposal of a plus d yeah that's what I would propose so that and then to the extent that we can isolate that implementation on the cl side and you know consider hleski as deprecated Afterwards, we can make sure that like uh we we don't have this custom execute tweak as the uh uh like yeah as part of like the long live test. Um is there any cl who can maybe enumerate like what this would imply?

like is this a new custom fork where we just set the validator state to be whatever we want it to be or is this um config change we're talking about yeah it would be it would be a hard fork so basically we have a really long ex exit Q and we just need to like flush it out on how exactly to do that um we would need more time cuz they're like a lot of moving pieces to how it's all related.

Uh does you Daniel? Yeah, I just wanted something to say I'm not really sure if D would really be faster because if we are talking about setting or like creating a new hard fork implementing the feature then we have to test the feature before we run it on Hleski. So I don't know this this sounds like several weeks that it would take anyways until we can do it. So it's not really much maybe faster than doing a and setting up all the dependencies there.

Well, it's like okay, so A will be quicker for cords to do obviously, but the question is how long will uh mine the execute be for cords? Yeah, but that's that's what I mean. It might even take longer. you know then then doing a and setting everything up there. Yeah. Um and flags are Yeah. Yeah. So I haven't checked in detail how the implementation would look but uh I don't think there's a way to only do it via config change. So you would need a code path like that modifies production code I guess. So would the idea be that we have a separate like olesi version of

our code so we don't introduce a regression in like our production code or couldn't we add a new fork and at that fork um change the churn limit to something insanely large but you still need like in in your condition you still need is it this fork and then you applied the new limit right and you would I think in any scenario we need a new fork um but if it's config value change that doesn't feel like it needs much other code.

But adding a fork to a glance, but this could live on a separate branch. It doesn't need to ever go back to master or anything. I think the issues is like a high fixed cost, the hard forks on the consensus layer. Um, so I think if we have just a Oh, sorry. Yeah, go ahead, please. No, go ahead. And then so I think yeah, if we have like a custom build where we maybe even set just the epoch like how the idea previously was with peerless, I think then uh this could be fine. Yes.

Yeah, Mikuel. Um, we will have to reset the earliest exit epoch um in in the state. This is a new arrival introduced um in Electra. So, we will have to reset it to uh whatever epoch we choose for this hard fork. And uh uh because simply changing the size of the churn will not help much uh because we already have this parameter. We have this earliest exit epoch somewhere uh an year after now.

And uh yeah so um it will uh for any next exit or for any next partial withdrawal uh that is submitted this variable will be used as like a basement to compute uh the exit def. So uh the hard work would look like resetting this uh variable um and uh yeah maybe increasing the churn because we are still see some uh slashings there. So the exit queue will be reduced by slashings anyway.

Um but uh I don't I have checked uh and I don't I don't see that those slashings are really uh big issue at least now because yeah there are a few maybe a few per epoch. yeah might be just resetting this variable in the state be what we want to do if we want to option D. Got it. Uh Barnabas I think the recent uh slashing were not related to the nonfalt by the way the those keys were just run uh by two different people at the same time.

Oh yeah, please. How about this? It seems like in any scenario A is required, a new test net. So let's just decouple that a bit. We will be then we already have a proposal for what A could look like and maybe we can talk about what that is. Um but we go ahead with setting up a new test net and D is something it feels like we don't have enough information on the approach today. So how about we just do a quick breakup room breakout room tomorrow um where CL devs can show up. We have some time to think about potential options and then on that call we decide if D is viable or not. So either D happens or D doesn't happen but A can happen irrespective.

It seems reasonable to like yeah move forward with A. Um agreed. It seems like the CL side needs to look a bit more into what it would take for for D to happen. Is it realistic to have that tomorrow like uh say after the EPBS call at 15 UTC or do people think we need a bit more time to review this and then we should just do the testing call on Monday? Yeah. And um I think D in any option would imply that Holleski is basically sunset once we've gotten its purpose for testing spectra. So if clients do need to make a hacky fix, if clients do need to make releases, whatever that um it can be done in a branch that they can

basically delete once Spectra is live. I think without uh enough CL devs on the call, it's going to be very hard to make any kind of decision about the Yeah. Yeah. Yeah. So that's why I would kind of lean towards the testing call on Monday to at least give people a couple days heads up especially like the folks in Australia. Um unless like yeah I don't know is there is there something we gain by deciding tomorrow versus like versus Monday. Um I assume that setting up the new test net is some amount of work and so we on the

DevOps side we can like prioritize that over the next couple days. Yeah. Um yeah, it seems like we're going forward with a anyway. So yeah, I think we're unblocked. Um so yeah, it should be fine to Okay. So then I would lean towards okay let's let's uh ask the CLS to show up on Monday or to at least articulate like their uh preference around if and how we could do D by Monday and make a final call about that on the testing call. Okay. Um and then do you want to walk us uh so you posted a doc about uh

about how to uh set up the new test net Perry as well? Um I think there were two different options there. So do you want to walk us through it? Yeah was fetching the um the link. So the test net we want to propose is called hoodie. Um the idea is that it since it replaces Holski it needs to be relatively similar from a testing perspective. So public validator set we'll use all the mainet variables that we can. Um I think there's two options. One is that it's slightly smaller than mainet and B is like plan A is that it's slightly slightly smaller

than mainet and plan B is that it's slightly um larger slash on par with mainet. Um, and in both options, we can either do stake distributions similar to mainet, so 32 ETH per validator, or if that's going to be expensive for client teams to run, um, we do 248 ETH validators, uh, we have a few ideas on how we can put that in the Genesis state without pective and still, um, you know, do the transition quickly if we coordinate it at least. And um yeah, in either situations, we'd propose that client teams plus ethandops together does something like 67 70% of the validator set. So in the future, it

would be relatively easy to coordinate upgrades and so on. Um yeah, any any thoughts on if people would prefer 208 ETH or 32 E and similar to mainet? So I guess the there was a a comment by Paul in the agenda talking about like the different roles of test nets and and you know what we want from them. I think one question here is like what is the purpose of uh hoodie? Um do we want it to be like a a performant um you know like a per performance maxing test nets?

Do we want it to be just like a stable staging environment for people? Um because you can imagine if we wanted to be more on the stable side in the place where say LIGO and others just can reliably test stuff, we should probably do the lowest uh kind of the lowest overhead uh which is B. But if we wanted it to be a test net where like say we pushed a validator account beyond mainet then maybe we do things like push a gas limit beyond mainet as well um we should probably do a but that raises the question of okay should there be somewhere else that we expect uh projects to test and that's more of a a staging environment for mainet uh solius yes so so one thing that I I raised on

this uh agenda issu I'm I'm thinking think that we could have uh two networks two two networks something like the the current hlesk and then one would be uh the network that um that has uh uh regular non-falities so it's a kind of battlefield uh network where we could uh I mean the the client teams could uh regularly test their clients and even the community could uh test their setups, applications or whatever they use uh in in a uh close to mainet type network where there is a battle mode. uh

and then we would have another one let's say a new network which is also a large network um close to uh mainet in terms of the data counter uh or stake teeth uh and that that would be dedicated for um like um steady uh performance something like um you know like like we experience currently on the network on the mainet and hopefully it will it will proceed like that on on the mainet. So I would like to hear what what are your opinions on on this uh idea.

Um yeah Ivan maybe. Yeah. So uh generally for us uh having a task net means that we need to deploy all the off-chain tooling uh around it and also have third parties for example those running the oracles and the council demon and uh other critical uh offchain parts of the protocol to be involved including node operators um and also have things like uh DVT from both mobile and SSV uh deployed and run and maintained uh which essentially doubles the coordination workload for uh yeah for us and for everyone involved with uh

Lido. So it probably okay like in the short term but I'm not sure it will be uh sustainable for us in in the long term to have two. Yeah. So maybe that's where Paul's point about the staging environment makes sense. So the hoodie network could be smaller than mainet but still large where everyone external can test. So Leo can stay test here and so on. And the idea is that it's quite stable. Um we can either repurpose whole ski or we can have another network that pushes the gas limit that pushes validator count and so on and that can purely be client devs and opt in for anyone in the community who prefers that sort of test. But the

understanding is this sort of non-fality network will always be breaking. We'll always be pushing the edge. Um and if you're interested in testing the edge of your protocol, you can deploy there. But if not, it's up to you. Yeah. The way I would think about it is almost like Lidle. Lidle is a very weird app because there's a sense in which it's just a contract similar to say unis swap but then there's a sense in which it's like much more complicated infrastructure but I think maybe in in the like medium term we need like three test nets one for just vanilla contracts which is is fine for and whatever successor is um so if you're just building something that's purely onchain

maybe one for like infrastructure which is kind of what 2D could aim to be which has like similar parameters to mainet but it's it's hopefully relatively stable. I think we probably also need one that's like focused on what core devs wants and this is where things like say having like a higher validator count than mainet or potentially having like a higher gas limit than mainet could help because we see what actually breaks at the protocol level. Um would that generally make sense to people? So it's like we have the least stable kind of core dev oriented test net which doesn't exist today. one that's more more for infra providers um that would be Hoody and then one that's purely for just like vanilla apps that

don't have many complex dependency especially on the validator set and that's a yeah maybe I can start from light of side I really like this idea with this multiple test nets I think it's it's really good uh the only risk I see here is that if something is tested on one of these test nets and then it goes to mainet and some part uh parties are not present on the test net. For example, if we test something on the client team test net and then push it to mainet bypassing the test net where we have lido then it might like break lido unintentionally.

So then perhaps we should also have a preview. Oh to be clear. Yes. Yes. Yes. To be clear, every hard fork should go through all of the test nets. But um there's the way I would order them, you know, had we if we had these three test nets like first you go on the core dev test nets. If that one breaks, only client teams are affected. Then assuming that's well, you go on the infra test net and if that one breaks, well, it's kind of the similar situation that we're in now. So we should really not want to break it. And then the last one is Sapoleia. And by there, you know, we should expect absolutely nothing to break. And you know that's and and if you're a new developer coming into the ecosystem um it means that you you know we we kind of maybe point you towards

Sepia first because you don't care about the closed validator set. If you're like a more uh um yeah if you're like I don't know like a more uh infra or like complicated project then maybe you are testing on on UDI um but most and then most people don't quite test on um on the core dev test net. The one the one risk I could see there though is that we if we want to create like a high uh like a high performance test net for core devs, how do you actually get transactions? Um, yeah. And then if no one's using yet, like and all the blocks are empty, that's that's perhaps not ideal.

So for this high performance test net I I would see and I already discussed that internally in entermine and was discussing yesterday with parto would be great also to consider it to have some very big state. I don't know how to achieve that yet but would be great to have something which will not start from empty state but something which will be at least twice bigger than mainet. So we can test much more edge cases and test everything under bigger load than only increased gas limit or or something that would be also somehow beneficial.

Um how should we uh how should we distribute twice the mainet state? That seems pretty difficult to me. I think he means just by using tools that um increase the state regularly. Oh yeah. Well, yeah, we can we can we can just pass all the time. That that's fine, I think. Or using like a shadow fork or something along those. Yeah. So ultimately we'll have something which will allow us to test under those worst conditions which we always consider with for example increasing gas limit which will start increasing the state size and how we will behave under

such such such conditions right so would be great to have a fuzzing tools which will really pump up to the limits that the test net and make it at some at some point bigger for sure than mainet And also one thing to consider for such one would be great to maybe uh as team already said in in terms of development and hard fork schedule it should be always before the other test nets more more official and more stable ones but maybe it could even I don't know to consider pu push some changes from upcoming hard forks earlier when we will be after a

few deaths nets and already start testing those on bigger chains rather than only on devets. Yeah, I think part of the issue has been our um test nets did have like different configs from mainet. So that's something we already said we would stop doing. So hoodie would just basically have contracts live in the same location, have the same injection balances, have the same values that mainet has. So that should also go a long way to um make for an easier fork basically. Okay. And yeah, we obviously already have a ton of work on our plate, so uh we probably shouldn't spin up like a

another test net uh just for fun right now. But I think framing Houdi as the place where we get infra providers to test feels reasonable. Um if we go that route, do we do we want to have um a smaller than mainet validator set size? Okay. Does anyone disagree with a smaller than mainet set size? So basically plan A in Perry's document

and why do you want to make a smaller set because after consolidations it should be easier to run a large number of validators. So, so I would prefer the the similar size of staked ETH uh and preferably even uh consolidate consolidations that are quite close to to mainet. Uh so basically you'd want option B using as many 2048 ETH validators as we can.

Well, not as many because that that's a very large number theoretically. I mean something close to to mainet uh distribution of validators and cons consolidations. I think to Dustin's point we essentially want to keep it as similar to possible as mainet for now. If there's a lot of consolidations that happen on mainet then we can also do so on hoodie. Um but if not then we basically leave it as a mirror of mainet. Okay. So that means we launch it with mostly 32 val or or exclusively 32 validators.

Exactly. And if we notice that there's a lot of um consolidations happening on mainet we can just proportionally so on the on the hood test net. Okay. Does that seem reasonable to everyone? Yeah. So to the dock uh plan well plan B says bigger than mainet but I guess here we just say about the same as mainet and then start with non consolidated validators consolidate them over time.

okay. Anything else on the test nets? And again, uh, yeah, so this is still what we do about the new network um, for Hleski. If people want to review the different options and, uh, check in on Monday, that would be ideal. So, we may, uh, be able to get, uh, a quicker, um, a quicker turnaround there. Um but then there's no world I guess where we do keep plesi as the main place for infra providers long term. So uh once hudi is live applications uh should start thinking about migrating to this um and maybe this will be after petra if we

manage to keep hleski uh around. okay. And environment says, "When do we want to launch it? How long the client teams need to integrate a new network?" I guess this might depend on what we do for Hleski. So, let's maybe discuss that on the testing call Monday because if teams are going to prioritize uh doing some weird fix for Hleski, I assume that'll delay um yeah, that'll delay launching the new network. Um unless anyone has a strong opinion now shouldn't be the other way around.

Prioritize A then uh D. Well, if we are doing D to Oh, sorry. Go ahead. I was just going to say if we want to go to mainet faster, D then A is sounds right. Correct. Because then we can test the things that need to get tested as far as you know app and validator set level integrations can go quickly. But A doesn't really get us anywhere. just means we have to deploy a bunch of new infrastructure which will delay the timeline. Yeah, I think D just needs a bit more information. So up until Monday when client teams are having their uh are all there um there won't really be a location to discuss how D looks. Um but yeah, I think D if

would be the fastest way. Yeah. So okay. So let's figure out the launch timing on Monday when we um yeah when we have a better idea for D and then yeah uh last question maybe on on Julie is what would be the plan to fork it to uh to Peterra so I assume we would want to launch it pre-fork and get people upgraded on it or would we want to do fork at Genesis? this um I would go through the upgrade on it and give people maybe a week to deploy contract whatever um before the upgrade.

Yeah, we can basically schedule it at launch. We don't need to do the fork. Okay. As in it would be um Denun Genesis and then there will be a pect fork and the pectra fork is shipped along with the u network configs. Yeah, we can. Yeah. Okay. May maybe we can create an issue on GitHub to discuss Genesis validator keys as well as timeline. Um because I doubt I doubt we're going to be able to do that in a short duration today.

I wouldn't I would yeah honestly I wouldn't uh worry about the genesis validators that we should just do the same as holski. Otherwise we would spend too much time on uh deciding whether we want to give or not uh the heat to those people. So we already did this whole big list. So I think we can just do the uh it distribution there and then the genesis valator set would be just uh a bit smaller amount of validators. Are there any client teams that would not want to run valator for hoodie?

Okay. Doesn't seem like it. Okay. So, yeah. uh let's create an issue to to at least coordinate on this and then figure out the right timing uh for the fork. But hopefully we can get this sorted in the next few days. Um I don't have something we can share uh on Monday or Tuesday with with the community and maybe for everyone listening who's interested all the updates will be posted in the test nets channel on um ETH R&D discord. So coordination about valid data set um timing all of that stuff you can expect to listen there and get the info.

Okay. Yeah. Thanks a lot to the DevOps team for yeah putting this together so quickly. Um, next up, uh, so I think it's it's probably worth having a conversation around what do we want the path to mainet to be in terms of testing at this point. Um, there's some couple small spec changes as well to review for perpetual. I think at a higher level discussing like what do people want to see to be comfortable uh before a choosing a mainet uh time and then b actually seen the fork deploy deploy on magnet. Um obviously a lot of the testing uh kind of got sidetracked

because uh because the hleski issues um there was a minor issue on seapia as well around the log parsing. Um, so yeah, I guess from the client team side or testing teams, like what would you like to see before you feel comfortable scheduling a magnet block uh Barnabas I would like to see who forked without any pain then we can probably discuss minute.

Okay. So, seeing hoodie fork, is there anything beyond that people would like to see? I mean, I think I would like to see the like all of the staking protocols that are sort of waiting for Hoodie now to go live to have their testing done. I don't think that needs to be I don't think that needs to happen before we choose a mainet date. I think we definitely need to see uh we definitely need to see hoodie fork without issue before we choose a mainet date. But from there I think like within one week we can choose a mainet date and that mainet date should be 3 weeks 4 weeks in the future and we should just continue having

expectation that people will be testing and preparing throughout that time and be ready if there's like something else that goes wrong to u push the main update. But yeah, I think the first thing to do is just fork the new test net. Thanks. Uh, Enrico. Yeah, I want to see a big network like Holski uh finalizing because the participation more than 95% so we can check the aggregation and all the votes from validators fullon chain because now we were just running small test nets and key so a big one network

with the good participation will be a good confirmation for the station stuff. Um Ivan, yeah, for us um it depends on whether we go with option D or option A uh at new test net. So with option D since we already have all the tooling deployed uh once uh everything is stable and works we'll need a few few weeks probably three to four weeks to test everything and to prepare for mainet but if we go with option A like new test net then we will need to also redeploy all the tooling which will probably add perhaps at least a month maybe month and a half

on our And so, okay, so you're saying if we don't have option D, then there's no way you can have the tooling set up in less than a month and a half uh post launch. Yeah. Yeah. Because we'll need essentially there are four components. First, it's uh the contracts that can be done relatively quickly, probably like a week or or even less. Then we'll have all the um tools for monitoring and alerting that we'll need to test. Uh that's also around a weekish. We have lots of them. Then we'll have dependencies for off-chain uh guardians, oracles, and council demons. It's also

can be started in in parallel, but it depends on the previously deployed things. So add roughly a week to that as well. And finally, we have uh node operators running DBT. um that will need to uh be integrated with all those other tools. So there it's like a waterfall full process. Um right I think also on our end we probably would need to rethink how we structure the development going forward with maybe aiming for a possibility to support more frequent changes in the test nets because so far we've been doing it very seldom maybe once once a year or or even less seldom. Not everything is automated and I think if we invest into more

automated process we would be able to do it faster next time we need to adopt a new test net but for now it's still a lot of manual steps therefore it takes time. Got it. Um yeah I just want to mention want to stress what Enrio said. We really want to measure packing. This has been a pain in the butt for us. Uh for this we need a stable devet stable test net but also I'd like to make sure that the slasher is actually working. Uh when we were expecting to see mass slashings uh the slasher was only taking just one index and it'd be nice to know that the slasher actually can go back grab the blocks from hleski's back fork and actually slash allers together.

Okay. And this is something that like yeah I assume we'll need to do on hoodie. Well no it's it's so I mean I'm worried that validators in hleski did not get slashed and all of them at the same Uh we have the blocks these blocks included at the stations. The slashers should be able to go back grab those blocks and and slash everyone. And we do want this on mainet. Yeah, we can set something up for you parallelly next week. Um, so different from hoodie, different from wherever where we can just do the slashing test.

Oh no, but I I really mean Hlesi. In Hleski, we can slash everyone. We already have everything there. And so what's missing to run? Like what's missing to actually do this? I think the slasher might not be running well. I haven't looked into any slasher, but there's no reason for the slasher not to be able to slash everyone at the same time. I I I don't think we want to fork into Spectra without having a working slasher. Wasn't the problem that nobody seem to be still on the old chain or nobody seem to be running a slasher that No, I think there is a slasher because because validators are including slashings. I think just the slasher is

not uh packing all of the slash aggregating the slashers the slashings as per electra. Okay, so I I I don't think there was any recent slashings by the way. That's even worse because that probably means that the validators that just restarted like removed the slashings from the pool and then there's no broadcasting of the slashings now. But we can discuss this later. But the point the point I'm trying to make is that there were clear problems with the slasher on Hleski and we want to make sure that the slashers are working correctly before forking mainet.

So, okay. And then Spencer added uh some some east testing. So, uh all the tests pass. Uh reviewing tests we have for all the EIPs. Uh adding some missing edge cases. Um updating the old Hive simulator uh Hive Engine simulator. And then uh nice to have uh line coverage reviews for spec tests on all the clients. I guess as well on the on the E side, we can probably test all of the EL only EIPs on Sepia at this point.

Um is there a reason why we could not do this? Like should we be just trying to yeah make sure all the edge cases are tested live on Satia and that there's no consensus issue there. I don't know like we have the test cases as test cases if they would hit any consensus issues they would have shown up in the in the normal test. So I don't okay like we don't really need them on the network. If clients are not running those tests and uh uh then have like

some open consensus issues then it's kind of on them in my opinion and then so okay so the issue we ran into though on haskkin support that the configs were different than mainet so should we have all the configs on hoodie be the same as mainet or like yeah I think we're definitely choosing basically everything the same as mainet for hoodie Okay. And this includes the deposit contract address. Yep. Okay. And how sorry, how does the deposit contract work on Hoody? Is it going to be like some uh just like vanilla ETH or will there be a Yeah, we just do the vanilla ETH deposit

contract and then we put it in the same location that the mainet deposit contract exists in. Okay, great. Okay. So from what I understood here um what we want to see so we want to see hoodie fork we want to see the test net finalizing at the stations being packed in blocks uh sufficiently following the electric specs. um we want to see um that the slasher is actually working and obviously that all the tests pass before we pick an mainet fork block.

Once we see all of that we would at least some of us would feel comfortable picking a mainet fork block. The question is then can all of the applications that are deployed uh on mainet do proper testing specifically LSTs and there's a concern that if we uh only deploy you know hoodie next week um and fork say a week after that it doesn't give enough time for uh teams like lido to actually run through the entire testing cycle. Um so I think you know here there's two options. One is either we um either we do this Hleski custom fork which we still need to discuss

or we effectively wait uh until uh Lido and potentially others have finished their testings which might delay mainet deployment. Um or we find a way to speed up Lido's deployment and or uh we'll have to move to mainet or very close to mainet before there's like a full testing run. Um and yes it seems it seems a bit reckless to deploy without uh not only Lido but other like large staking pools testing um and so I think if that is a hard requirement and that their speed of deploying and testing is also set the two options are either we have to do the

hleski revival or we have to effectively just wait a bit longer and that's probably going to like 6 to 8 weeks after Houd's launch before we can go to mainet. Um, which means we'd probably be going to mainet, you know, call it like uh early May or something like that or midmay. Uh yeah, Carl, I personally feel like we're optimizing for the wrong thing here, and that's to get to main it as soon as possible, which obviously is great. But I think another very important resource here is client dev time and attention. Um if we are having to wait for uh Lido etc. to

deploy things. Um, fine devs can be working on um on um on on on on upcoming forks and more more specifically pure dust which brings much bigger gains further down the line and like we can pipeline this a little bit so it it achieves some parallelization there and and and and get more to mainet sooner in the long run. I'm worried that if we if if we have to do this thing where we start having all this bespoke code that needs to now be tested and whatever the coordination cost is extremely high and we end up spending a lot of time on something that allows us just to ship one fork a little bit earlier but I don't think that much by the time we account for for all this client to have time and attention.

Yeah. Right. So yeah and and so if we just quote like wait um we that means that yeah client teams are effectively done with the fork more or less and then we deploy it on hoodie um and after that uh you know we're waiting for app layer or infrastructure providers to test on it but yeah ostensibly by that point hopefully the client teams don't feel like there's more work to do on pectra yeah that's pretty much the the proposal here. Um I I think in relation to the the other thing is Pis's concerns about the the slashes which I do here. Um I mean it would give us some time to think

about to think about and work on that. The second thing is like that's not really fork specific. We can we can work on that at any time and we don't need to coordinate to release updates um etc. So yeah, I don't know. I'm not sure we should worry too much about implementing that before the next upgrade because that is something we're concerned about and need a fix anyway on on on separate timelines. But yeah, basically I'm arguing primarily that we should we shouldn't be doing a hacky fix to try save her to ship something one week earlier but maybe delay uh podas by whatever another two months or something.

Yes. or uh have a bug uh on mainet when we actually ship Fusaka. Um yeah, the argument is that we should just do A, forget about D. Um that it's better off to not waste any client time on figuring out D and that we'd rather wait uh for infra providers and others to just use the new test net. Um and like yeah and to be clear like the

quote cost that we pay here is we ostensibly will get pect on mainet later um because you know there's there's not as much upfront work that's done for infra providers. But um we will um we but we will uh not have that bottleneck on client teams as much. Um, and yeah, to Chris's comment, like the infra providers would need to move to the new long live test nets, but there's a question that, you know, they probably weren't planning to do this two weeks from now. And so it does shift a lot of their their their

timelines. I know we didn't have it didn't seem like we had sufficient CL devs on the call earlier to make a call about like whether we want to do option D but um if the rough consensus is like we don't want to do it um should we just decide that now so that we can kind of move on and not spend more cycles on or worst case, we can still discuss this

on Monday. But yeah, I think we should we should just do a and get on with it and do it as quickly as possible and not not waste another week debating this. Yeah, I think at this point it also makes sense. Let's just do A. Um, we can leave D alone. And also just want to bring up the point that Holski can still be used for almost all testing except exits. And also my document was wrong. Mikail pointed out that you can also do consolidation testing. The exit epoch in consolidations is not reliant on the

exit Q. So that was a type that was a mistake in my original document. Leo, etc. can test consolidations on Holski as well. They just can't test partial exits and exits. Okay. And then Okay. So, let's move forward with that. Um, option A in terms of uh actually scheduling the fork uh and the deployment there. Um, it does seem like there's some stuff that client teams want to have in a release, especially on the CL side before we we do that. So, I I would maybe defer to like either

Monday or next Thursday to discuss like when CL teams feel like they can have a client release um that that supports uh all of the fixes and and that they're comfortable using for Hoodi. I know. Pis, do you mean shorter than that or longer than that? Oh, no. It was a question for Ivan. Like they seem to be several weeks as in plural.

Yes. Okay. So, let and yeah, I think I think regardless of like you know what we do with option A, like the timelines are kind of somewhat out of CD's hands. Um we should obviously stress that like the quicker we get everything tested on Hudi the quicker we can ship uh petra to mainet but this is kind of the bet that we take if we take option A is that we have a clearer path for for core devs but then we are dependent on like the

community for some of the testing infra and yeah pus yeah so from from above was asking about uh whether or not we could just replicate the state can we just not fork and take the execution state of Hleski and deploy a new test net already bootstrap with that execution state so that we could just start with contracts already present or if we can't do this with hleski can we just talk to these teams so that at Genesis they have already the contracts deployed it's not the contract deployment that takes a long time and we already had uh this discussion about doing a shadow fork of that was uh option C if I recall correctly.

No, but it's not a shadow fork what I want. I just want to bootstrap a full a whole new definite if you want, but have already the contracts of and all of the structure of these people in in presence so that they only need to change the ID the chain ID in their in their tooling. So the problem with this is um that the clients do not have the ability to import like multiple gigabytes of uh of genesis state like the genesis state is usually pretty small and uh I don't know if you if you want to download guess with like 40 GB of state or something.

Um so the like what we can do is we if we have specific contracts that they want to have in the genesis block we can we can add them just like we add the the deposit contract. Um but they can also just deploy it like I think it's it's quite bad if uh these large entities cannot spend the money to deploy uh to deploy a bunch of contracts and set up a bunch of infrastructure within a couple of weeks. Like we are not going to go to mainet um before they've they've tested their stuff. Uh, but I also don't think we like we need to spin up another network or spin up a shadow fork for

them to to to test this and spend like hundreds of thousands of u of dollars for that. Uh, we should just do this network. Everyone can maybe chill for a bit, maybe work on their client. I think there's a lot of client improvements that can be done that this uh this Hleski incident uh kind of showed. Um, especially in GU, we have a bunch of uh things that we would like to do that we don't have the time for if we we always going after the next uh hard fork. Uh, and so we should just uh schedule Hoody uh and then uh uh work on the other stuff. Okay, Roman says no chilling Faka

next. We so I guess everything for Fusco already. On the on the topic of like clients improvements like when do clients have stuff that they want to test for Houdi Genesis? Because if we are saying we want to see a stable fork on Houdi. I assume this implies we want to test some stuff that are that has been found since the Hleski and Seolia incidents. So should the path be that like you know in one or two weeks clients put out a hoodie release and we schedule a hard fork you know maybe like a week or two after that we don't need we don't necessarily need like that much time in terms of heads up because uh

client teams will be running most of the validators at least at Genesis or and it'll be a pretty small group to coordinate but do we yeah like yeah should we plan for a client release cycle before the electrofork on on Hoodie. Uh yeah, Ahmad.

Yeah, super quickly I'd just like to uh like point out that just copying the state whether with the shadow fork or without a um or with any other mechanism the EL state that is does not really um just uh work uh for for a lot of protocols like rocket pool like um even L2s will will struggle uh if if there's any L2 that is deployed deployed on holiski etc. There is a lot of dependency on um blocks call data sometimes um uh blobs etc. U all of this will not be

supported um with the shadow fork or copying the EL state. So E state is copying EL state or the execution state does is not a magical solution unfortunately. Okay. Yeah. So we yeah so we are starting with a clean slate clean state sorry uh for hoodie. Um, and then yeah, so the question is when we deploy Houdi, how long do we want before Electra goes live? Do we want full client releases?

Um, or our clients fine going live with whatever they have now on the hoodie. Uh, my sense is if we are going to get node operators and others to um actually use this, we should point them towards a specific release. Um, yeah. Okay. No strong opinions. Um, okay. We can and don't need releases out

by Genesis. Yes. My question is, do we need releases out by the electrofork? Uh, yeah, I think well depends on when we schedule the electro fork, but I think we should uh have releases out like we can we can we can start the network early next week and have releases out late next week or early the week after. So I think that is that would be fine. Um polus I would prefer if these kind of decisions are made by a smaller group say Par and company just like inform us what is the deadline that they are planning the network and then we need to adjust to have the release by then we

need to start like moving to something like this otherwise we're going to be blocking on a bunch of teams having releases to have these dev nets what I There's a broader question. I I don't think it's that intrinsic that that for very testing oriented uh networks run by ultimately relatively few people. This is this is not thousands and thousands of of of enduser home stakers that are initially being primarily targeted here in terms of bottlenecking any kind of of mainet.

It's pector etc etc. I all I mean I believe all these clients because I they have to for DevNets and the like but for sure for Nimbus and and I know for sure for a couple others can can and do today support custom networks and and of course this is less convenient in a number of ways. I understand the UX the ergonomics is just not as good. But I I want to I would like it to at least be very explicit that there is no intrinsic connection between launching uh a a new network of any sort um uh hoodie anything else and getting releases out that this is strictly a convenience feature. Now it may be a convenience feature we want or we like

but that's a distinction. Yeah. And to be clear, yeah, I'm less concerned about launching Hoodi. I'm more concerned about Electra activating on Houdini. Um because a bunch of people have said they want to implement some fixes and they want to test those. I assume those fixes relate to Electra to some extent. Um and so do we want to have enough time for clients to put out a release that that has their Electra fixes prior to that fork happening on Hoodie? Um, yeah, Barnabas, I think we should set the Electra fork already at Genesis at Genesis.

Yes. Not like set the flag not to be Oh, okay. Sorry. Okay. Not activate. Yes. Yes. And I guess maybe my question is then how long do we need like do we set it Genesis plus two weeks, Genesis plus one week, Genesis plus 3 weeks? I think that's that's detail. Uh we can discuss that later on but uh but we shouldn't probably have two separate releases for Woody. No. Okay, I agree. But then clients should be able to run their Electra version before it goes live. Um happy to defer whether it's a couple days or 10 days to the testing call on Monday. Um and we can make a final call there.

Or actually do you need this if you're going to launch a network? Are you going to launch a network before this? Do you need that number now? Oh yeah, Barnabas, is is Hoody going to be live before Monday? I think I think we should launch the network on Monday uh somewhere during during working times and we should just default to 10 days. Uh so the fork is uh two weeks afterwards on Wednesday. That's okay. So the so petra would be on the 26th of March.

And the thing is Leo mentioned that they would need a lot more time to do their deployment and they would probably want to deploy before Spectra is active. Is that is that true? Uh Ivan, does it matter if you deploy before PCRA? Not necessarily. We can deploy after as well. Sorry, we can deploy before uh when Yeah, you have 10 days for like the contracts. I assume you can. Yeah, deploy the contracts in 10 days. But like if some of the infrastructure is only set up after Peter's gone live, is that okay?

Yeah, I think it's okay. Okay. Okay, great. So then uh yeah, maybe we should just do Genesis plus 10 days. Yeah. And I think just to keep it a bit simpler for the first week or so, each panda can also run the key. So whenever client devs have their machines ready, whatever, we can transfer the pneummonic and turn off our keys. So that would allow us to hit like aggressive timelines like the devet is up by Monday basically. Yeah, perhaps I'm the only one here, but I think 10 days is a lot. We would rather have more time testing Electra. Our code

base is more or less stable. I would rather have that 10 days being a shorter So it already seems like we're going to have a long time after the 10 days if we're waiting, you know, uh, say like a month or so for info providers. So I it kind of feels like doing like, you know, a quarterish of the time up front before Perra, giving teams some time to ship fixes if they need to is isn't too crazy. Um, yeah, Ivan.

Yeah, I just want to understand does it mean that we are effectively decided that we go with um testing spectra on the new test net or we still have Okay. So that means that option D is kind of off off the table, right? Correct. Yeah. I think we prefer we prefer to wait on say you guys and others to test on Hoodi than have core devs spend a couple weeks trying to do this hacky fix for Hleski uh because if core devs are quote you know just waiting and not doing much else which kind of a simplification but uh you know they can either work on their code bases take a vacation or start working on

Fusaka um so we're not like bottlenecked on core devs as much and Um yeah, we can we can we can just like this means that Peter petra will probably ship later on mainet then if we did option D but the bottleneck is not the same and so you know ostensibly fusaka ships earlier on mainet because we didn't waste those two weeks dealing with with option D. Yeah. Yeah. Makes sense. Okay. And then if on Monday we have the new uh test net even if it doesn't have PCRA yet we can already start working with it deploying our contracts and and the tools uh so we can hit the ground running and do doing some testing as well. Um and I agree

with uh yeah with POTUS we can also test things on Kleski. We also have a bunch of devets where we've tested actually almost everything already. Uh the only thing we haven't tested yet is DVT and that requires us to coordinate with uh SSV and OEL. So um yeah, I guess I'll I'll just coordinate with them so that they also get ready for uh uh the Monday's deployment of of the new test Got it. Thank you. Um Andrew um so u if we start the test net on Monday uh I don't think like like who who run the validators because to set up

a validator it will take some time it is kind of devops who who are going to run the validators initially or do you client we can run the validator keys shortterm and then as and when client team spin up the instances we can transfer the keys to you okay fine fine Thank you, Bella Ops. okay. And then there's a question in the chat asking what does this mean for mainet dates. So, like at the very least, we're not going to fork mainet until 30 days after co uh who fork successfully.

If we have fork on the 26th, there's an awkward on like the 27th. Imagine that we chose the mainet date there to be one month out. That would be like the last week of April or the first week of May. So I think like yes applications can assume the fork is not going to happen before the last week of April. I do think at that point though like um in general awareness is already pretty slow process and we uh adding more and more like external inputs in terms of setting the dates uh would mean we never ship.

So I think people should assume like if the hoodie fork is successful there's like around a month uh before the fork and uh they should plan accordingly. Um um Ivan Andrew I don't know if your hand is still up from previously or do you have something else? Yeah I think Andrew was first. Yeah I think Andrew might have just had his hand up before. Okay. Yeah. Okay. Uh yeah just um wanted to clarify when we go live on Monday will it be without Peterra initially right?

Yes. And we'll schedule for 10 days after that. So we go live say we go live on Monday March 17th Pekra will be scheduled to go live on Houdi on uh Wednesday March 26. Okay perfect. That that's uh great for us. Thanks. Yeah. Yeah. And so yeah, so anyone who wants to test PE pretectra stuff has about 10 days to do it and then we'll have at least a month uh after Perra to uh on Hudi to do further testing. Um and yeah, in terms of like faucets and whatnot, we can figure this off figure this out async and and just have

some instructions. Um yeah. Okay, I think we have a path from here to mainet. Um, very last important question. H O DI. anything else on just like yeah the path to mainet. Okay. Um then next up continuing on our agenda um Andrew you had a point around

uh error handling for system contracts. Uh what happens if uh uh there's like all the gas um and it seems like the EIPs are underspecified there. Uh right. Yeah, exactly. So the u difference in the contact onia uh uh got us thinking and we are considering a PR uh to like to to to define what to do in case a system contract fails. So like may and so we we should probably specify it and like by failure I mean it can run out of gas and in one of the it says that the gas is 30 million but I don't think that other EPS

mention it and also it can just fail so the might fail or revert and uh I guess one one possibility is to um but that can happen like theoretically it can happen for some transactions or for some system calls but not others. So maybe we should mark blocks in which system contract calls fail as embedded, right? So but uh yeah so I think we should specify it and test it uh and then we'll be we'll be because potentially it's a consensus uh issue.

Right. Right. Then do we already have tests around this these edge cases? Probably not. But yeah, I'd love to add those tests. Well, I mean I I'm not sure whether I'll be able to add them myself, but if somebody adds them, it would be great. But that we also need an an if or some clarification to the existing ifs to to to have this patch so that we are on the same uh page. But even if we if it does test that that's also fine.

I just want to quickly mention here that I asked the testing team to add tests around this also uh on the day of the support accident because I thought it's also kind of an unspecified situation. uh it's also like we keep coming back to these things like what should happen for example if the contract returns an invalid encoding or something and uh from the get perspective we think that the correct solution is just to fail the block in this case so basically if any system contract fails then just uh treat the block as invalid yeah I think yeah I'm fine with Okay. So I guess in this case we should

codify it. Um and we noticed that actually there's a bit of an issue because especially for the deposit contract logs not all of the uh clients treat it exactly the same way. So for example, as far as I understand in REST maybe uh they actually pro collect the deposit contract locks during the execution of sorry yeah so this definitely feels like something we should harmonize across all the different system contracts. Um I don't know if there's anyone from the testing team on who has more context on this. Otherwise, I would uh maybe push this conversation to Monday uh and make

sure that we uh we can yeah have a clear solution there by Monday. Yeah, we we still have a Mario's PR up. Um and the test we have right now assumes that um the decoding is hardcoded. Um so I guess yeah we want to check if people or what the consensus on um the decoding is essentially before updating the tests.

Okay. So let's yeah let's maybe move this to Monday's call. Does that make sense? and then next up there was some uh there was a PR around this that Yokim wanted to uh yeah move I think so people can review this as well. Um yeah that'll help us move forward. I think that was everything on Peterra. Anything else before we spend maybe the last eight minutes on Fusaka?

Okay. So, uh on Fuseka, um we have had this PR uh by Franchesco uh around the uh the rappers for the blob transactions. Um I believe we were almost ready to merge it. Um I don't know if Franchesco is on or I know Felix, yeah, you had made a proposal that I think we we were likely going to go with. Yeah, I mean you go with my proposal is great. So I don't have anything to add.

Okay. Has anyone does anyone have a strong opinion on this or I'm not sure if people have had much time to review but if it seems like the threat the PR has had a fair bit of reviews. So, um, yeah, hopefully we can just go with Felix's proposal and merge this, I think. Um, if not, we can discuss it, uh, next week on this call. Um, okay. Um, and then, oh, and then Alex, uh, Alex couldn't make the call, but he said there's a correspondent, uh, execution APIs PR that we should, uh, we should merge if we are merging Felix's proposal. So um yeah should just make sure to do this as well.

Um okay next up um there were some discussions this is a few weeks back now about how we want to test kusaka and if and how we should be able to disable eof to allow for uh like purass testing. Um I don't know if anyone has an update on this. Um we haven't pushed it out to the clients yet, but it's a fairly simple thing to make sure that UF contracts don't get in. Um you just put a flag in the creation contract or what's going to be happening with TX not deploying the TX deployment contract and then EOF wouldn't enter the system. So there's a very well positioned place to uh to bottleneck and keep EOF out from running and we would use the same client code

and still have the same stable code out there. And then when the off is ready, we just put the contracts back in place for everyone. Uh it turns off their flag. So this is something that's very achievable if it's valuable. Um so we just need to get the clients to implement it as part of DevNet one if that's what's needed. Does anyone else have thoughts or opinions on this? If not, is there a specific do you have a specific uh like description of this that people can look at? I know.

Um not yet. We've been working at working um on DevNet one features uh finalizing those so that we could I'll make sure it's part of this next Wednesday call. Okay, sounds good. And yeah, I think it's fine uh to table this for a couple weeks though given everything we have to do. Um, okay. And then, uh, next up, so we had a few weeks ago also agreed to try and, uh, finalize the Fusaka scope by the time, uh, Perra goes live. Um, so we had all these dates that, uh, now will obviously push back. Um, do so, so I think I had two small questions. one, we set all those dates for like proposals

and and teams sharing their preferences on like Thursdays. First of all, I think we should move them all to Mondays of like whatever week we choose so that it gives people a few days to actually review things before all core devs. Um second of all like um you know based on our current plans now um when is like a reasonable time to have like a deadline for people to propose EIPs for the fork and for teams to share their views on what should go in or out. Um so we'll have what is hopefully the last test net fork on March 26. Um if we keep the same schedule, it means that three days ago was the deadline for new proposals for Fusaka. Um and that

Yeah. And that a week from now would or 10 days from now would be when we uh when we want to have client teams put out their like preferences for the fork. My sense is teams have been pretty focused on Hleski. So I don't want to like add another thing on people's plates for the next week. So, I would I would at least wait until I think the um the uh Houdi Electra Electra fork before teams have to like put out their their preferences. Um but I don't know. Is that too long? Do people already know what they want? Um yeah, Justin.

Yeah, thanks Tim. That's actually good for us. Um waiting for what you just suggested. uh we have positions that we're still refining. We wanted to hit ETH Denver and talk to some folks then have a couple of conversations um before committing to anything. So I think that timing works great for us. Okay. So if we did this what I would say then is uh March 31st would be the deadline for client teams to submit their proposals which is a week uh or a bit less than a week after the Hoody fork. Obviously, if everything goes 40y on Houdi, uh we can uh we can revisit.

Um and then what I would do is then push two weeks uh or maybe like yeah have March 24th to be the deadline for people to propose new EIPs, which is about 10 days from now. Um and yeah this will give teams a bit over a week to uh to uh this will give teams exactly a week to like finalize their views after that. So to recap uh it would be March 24 deadline for EIP to be proposed by anyone. March 31st deadlines for teams to share their views and then hopefully this means on the awkward abs of like April 3rd and 10th we're able to finalize the scope. Uh okay any concerns with this?

And actually April 10th was also our deadline to finalize the scope. Um, yeah. Um, okay. And then, okay, so on the topic of EIP being presented, so obviously, uh, we've skipped a bunch of weeks. I think we should find a way to do this better async. Um, I don't know that we can actually get like, you know, 10 20 different EIPs to all come and present. Um, so I think for people who want to actually propose an EIP to the fork, the way to do this is by opening a PR to the meta EIP, which is EIP7607.

Um, and so client devs would have to review all of those. Um, we can try, I think, on the next AOR devs to have some of the some of the EIP presentations, but I also would like to move more of this async. Um and and I think um yeah one breakout calls are another option for this. William also had shared slides on the previous awkward devs agenda which people could review. Um so at the very least um yeah at the very least we should try and uh have PRs for those proposals to the meta EIP. We'll try to get as many presentations as we can. Um, but realistically we may not have time to get through all of them and and I

think it's it's better to move some of this more async and if if client teams feel like there is an EIP that needs like a deeper dive and that we actually want to bring up on the call, we can prioritize that but I would I would prefer to uh yeah to move more of this async. and I know we're at oh actually sorry one last thing before we move on from this. So I think when client teams also uh propose what they want in we also h we now have this new status uh decline for inclusion you know things we don't want in this current fork um so if there are things that teams feel strongly should not be in I think it's also worth trying to signal this um because if there is an EIP that you know every single client team feels we should not

be spending time talking about then we can just avoid this um uh DFI means not now so I don't think we can make a commitment beyond like the next fork. So DFI means we don't think this should go in the next fork. So if there is an EIP that people feel like, you know, it's been proposed and they really don't think should go in the next fork, I think it's fine to include that. I think it's also fine to say that, you know, the priority for the next fork is already pure and eof. Those are huge. And if client teams feel like, you know, there's seven different EIPs that they've never heard of and they don't have time to actually look into very deeply and that they don't feel like um, you know, doing like that they feel like the odds of doing more than what we've

already committed to are low and they can just DFI those like I don't think it should be taken as this EIP is bad or there's something wrong with it, but just this is not something we want to prioritize for the next fork. Um, and so hopefully having the signal helps us move a bit quicker in terms of like not spending time on stuff that people think is just um not a priority for now. And okay, I know we're already at time, but um there is uh I believe a portal workshop going on this week and there was a uh RPC request uh or RPC change by light client. So I don't know if like do you want to say something real quick

about it before we wrap up? I'm I'm not in at the portal meet up but I think there is kind of agreement that they wanted to have this error in the RPC to return when uh someone is requesting you know any kind of block data that has been pruned due to the history expiry. So this is basically just that error uh the code in the message that should be returned when those circumstances happen.

Yeah, I can give more I can give a little bit more context. We want to add this error because um the RPC API has a defined signal for like saying that something doesn't exist. But um it is a distinct case from basically uh the um the history expiry because we don't want the uh usually the expectation is that um the data will exist all the way back to the genesis. So we want to add this special condition that if if if a client is trying to access a block data that isn't we know basically the client cannot make a good statement about then uh we want to signal it to the to the to the caller.

that seems reasonable. Um yeah, so I guess if people want to review this in the next week or two and then we can we can merge it. Uh yeah, we can bike shed the uh actual error code. yeah, we're pretty set on this code though like we've already done most. Okay, so the code is set. Um okay, great. So we'll let people review that and then hopefully we can get it merged in the next few days. Um again, yeah, apologies. We couldn't get to there were two EIPs people wanted to discuss today. And then Kev uh had some stuff around stateless uh clients for MPTs. Um hopefully next call we have

time for it. Uh the EIPs people should review it async. And then Kev, I don't know if you're still on, but if so, is there somewhere people can discuss the stateless uh MPT stuff async? Okay, I will I will ask Kev to share something on the Discord um about the stateless conversation. But yeah, thanks everyone. Um I know there's a lot going on right now. Appreciate uh people working to get this uh this fork uh this work wrapped up. Um yeah, hopefully we we manage to do this in the next couple weeks. Um, yeah, that's all for today. Talk to you soon.

Bye. [Music]