All Core Devs - Consensus #131

Transcript

[Music] for

Alex Stokes: and we are

live okay great uh let's see here let me grab the agenda welcome everyone this is consensus Slayer call 131 I'll drop the agenda in the chat here maybe let's see let me just close obs let me see are we still good with the stream okay I got a yes cool then okay let's get started um yeah hey everyone so this is the call 131 and yeah I imagine we'll have a

pretty packed agenda today so let's get to it um first let's talk about DB um there are a few things that we should bring up uh the first one uh hey can you there we go okay great um let's see here yeah first thing is clarify voluntary exits topic sorry gossip topic after capella um does someone want to take this over I think I know at a high level what's going on

Dmitrii Shmatko: uh I have all on this topic I want just

to be sure that all clients understand it uh on the same way that we should use the topic for this and maybe change a bit burden in in this line

Alex Stokes: okay yeah I mean I think the sort of confusion here is that we're using this old domain for verifying the signatures but the gossip topic I believe should be for denb does that align with everyone's understanding we have a thumbs up two thumbs up three thumbs up okay so I assume everyone's doing this and we understand

and then yeah from there if we can clarify the language of the pr that that works so we're good on this I'll assume silence is yes okay uh next up we have the comment here from Terrance so I'm sure you're all aware but there was a bit of a network outage likely due to some interactions between the cons clients and box routes the relay uh

Terren do you want to give us an overview of what exactly happened

Terence Tsao: sure happy to so um yeah so people can read my comments I don't want to repeat so um since then um blog TR post put their post motor Michael also has their response and uh the kiss of the issue is that there's definitely some I would say Edge case with how B API is interpreted and used So currently B API proposed block Endo has this option to basically say the following if I see the similar block is already GED on the network I will not um propagate the blocks by propagate I mean I will

not even send the block out as the first half but this is to prevent unbounding attack so um so we so basically all the clients do do that do basically Implement that but the open question is that what do we do with The Blob side card because blob side card doesn't have this inherit um slashing condition so um currently I think before that um Lighthouse and prison I can say for them they do not broadcast the blob side carard if they see there's a s block on the G network but since but because of that um block RS block was not able to be uh Gossip so since then we have um updated the behavior to basically fix that so uh Mel

um is also working with the rest of the client team to make sure um their be API is basically um kind of um working for the rest of the relay as well so yeah that's pretty much the update

Alex Stokes: cool thanks and yeah I mean I don't think anyone hears from box route to kind of respond but yeah ultimately I mean ideally this wouldn't happen um we have like a lot of testing in place to make sure things like this don't happen but this one kind of slipped the cracks so yeah I guess from here we'll just work with them to uh try to prevent things like this in the

future okay is there anything else uh for that anyone wants to talk about any any data any stats on bobs anything like that okay that's good then uh next up I want to talk about Electra so I imagine will take up the bulk of the call so just to like frame things uh you know it'd be great to go ahead and move forward on figuring out what Electra looks like

even just like an initial scope uh especially so that we can aim for Dev nuts as soon as possible um you know even ideally within like say the next month we have things ready to go uh Barnabas asked about 2537 so I was only including things for the CL and there really aren't any dependencies for 2537 does that answer the question Barnabas okay we got a thumbs up um right so I started with the four that have been included just going off of this uh EIP 7600 for the hardw work meta and yeah I think it'd be helpful

just to go through each one of these in turn um go through the status of the spec if there's any open questions we can talk about now that'd be great but ultimately let's try to figure out what we need to do to get these to a place where we can Implement Dev nuts again say in the next month uh really as quickly as possible so the first one is 6110 this is essentially making deposits work uh a lot like withdrawals today where they are sort of synchronously produced uh if you deposit within a block the deposits then passed off to the CL who then processes that uh on the can sh are there anything here I mean I looked yesterday it seemed actually like it was in pretty good shape is there

anything anyone wants to talk about any open questions on this one or do we feel pretty good about it yeah

M

Mikhail Kalinin: um yeah so it has AP has a consensus spe test with a good coverage um and there is the pr to this pack which bundles 6110 and 7,000 to which is in progress um so yeah that's also great about 6110 I was just going to raise a bit of awareness that uh considering the max effective balance is

in Electra as well and uh considering that the max effective balance introduces the pend in deposit skew um the was just thought that we could leverage on having this Q to finalize the deposit flow um before uh actually creating new ERS is helpful for preserving the invariant of uh The POP key index matching and uh if this um can be resolved on the spec level on the protocol level we could probably get rid of additional complexity uh in SC implementations where they will would need to uh manage this cash per each for

independently so because um the same POP key can get different indexes across different works this just one of the things that probably could be introduced um I'm going to play with it um in in next couple of weeks and provide the update if it for is doing or not uh we will decide later on

Alex Stokes: okay yeah that'd be great if you want to open an issue or even make a PR to explore that sounds good okay anything else on that

otherwise we'll move to 70002 okay let's go to 70002 then uh so this is the execution layer initiated exits and we'll get to this with Max CB but we also want to include uh I suppose we're calling them partial withdrawals uh does someone here want to give an update on 70002 again I think the spec is in a pretty good place um except for the partial draws bit so it looks like the EIP would need to be updated and then also the uh the pre deoy assembly like Clan or M I think you guys

have been working on this

Mikhail Kalinin: yeah or do you want me to share the last updates

Lightclient: yeah I think you've been working on adding partial withdrawals so maybe you can share how that's going

Mikhail Kalinin: yeah yeah sure sure um so there is a PR uh into the assembly um into actually the repository um where the assembly code for your contract um is sit so I just send the pr to the chat yeah in this pair basically what we have is adding the amount field um the change is relatively small

because uh the amount field is uh appended to The POP key data and the stored uh in the storage slot where the rest of the pp Keyes can accommodate the amount as well um yeah so it's relatively small PR um to the code and once we uh finish working on it I think it just needs review and then merge um and then merge after that review um yeah we will you know we will update the IP that's it basically and yeah also the corresponding change would need to be done to the uh engine Epi as well um

and but it's going to be relatively small as well

Alex Stokes: right and for the engine API it's just changing execution payload right there's no like additional fields that we need

Mikhail Kalinin: uh yeah changing the um we already have the back for Electra a bootstrap with 6110 and 7,000 to I mean engine API spe so we just need to add an amount field to to the exit data structure and basically rename exit to withdraw request to generalize this thing yeah but that's just rename thing

Alex Stokes: cool okay sounds

good okay if there's nothing else on that one we'll move to uh maxb 7251 I think Mark is on the call somewhere

yep can you guys hear me cool yep yeah so um we've been chugging away at maxb for a while now um in terms of the spec uh it's been merged into Dev um most of the pieces are in place obviously still um minor changes and things being um updated and that will continue for a while um and then there are a few um outstanding questions that we still need to answer before we can really stabilize it um so first of all when a validator opts into being a compounding validator

um they are then exempt from the withdrawal Suite until they hit the max EV um of 2048 um and a feature that we could include are custom ceilings where um vors could configure a custom ceiling um up to 248 but potentially lower if they want to still hit the withdrawal sweep um and it's I mean obviously it's a little more to implement but it depends on what the appetite is for that from the community um we did speak with Lio yesterday um and they said it was nice to have um and it's certainly nice to have for solar stakers um but it's not something that

at least Li to uh I guess it's not Mission critical for them um so that's something to discuss and then the second uh bigger one is um regarding consolidations of validators um so in the third breakout call we were kind of leaning towards there's basically two options for this um one is a beacon chain operation similar to BLS to execution changes uh and another is to have it the execution layer initiated similarly to um uh the new deposits in the and the um uh or the exits or the partial withdrawals um and so in the third call we were kind of leaning towards have it

being a beacon chain operation because it was lower complexity and we kind of made the assumption that um all validators that shared the same withdrawal cred credentials are are fungible with each other but then in the last call uh yesterday um we had someone from wi come in and um they said that this kind of breaks their accounting uh both on and offchain and that it would be ideal for them if the uh withdrawal address had some ability to either initiate or gatekeep um consolidating a validator uh because there's a risk that they wouldn't be able to update their contracts and time um for the fork so this kind of

puts um execution layer initiated um consolidations more or less back on the table and we kind of need input from The Wider Community to see um if this is something they have an appetite for um so like I said Lio seems to have an appetite or or is worried about that that they won't have time before the fork um and uh I know I don't I don't believe it breaks anything with rocket pool but I do know that they uh like the feature just it gives more um it's just more of a beneficial thing rather than something of a break their contract but yeah basically those two issu issues that we need wider input on

Goa

Alex Stokes: thanks um yeah I agreed with pus here in the chat just like surfacing on your first point like partial withdrawals like with 70002 seem to get at the same thing I guess the trade-off then is yeah maybe there's more transactions you have to send um but yeah I think whatever we can do to reduce complexity is at least should be very strongly weighed um yeah and then the other point yeah I guess we'd want to add execution layer consolidation initiated well execution layer initiated consolidations so yeah I mean again I would just say let's be mindful of scope

creep um if we can get away without it then that's strongly preferable do we feel like we have a way forward to answer these two things

the alternative that L was asking for was like like I guess execution layer gated consolidation so it like might still be initiated but I don't know that kind of seems like not it just seems like worse ux and not significantly less complexity but yeah

Alex Stokes: right okay I mean I think a path forward is we can

agree to do like initial Petra Dove nuts without these things and just work on them in parallel and then you know they're not going to radically change well I don't know if it ripples into 7,02 then that's could become kind of big but either way um I would at least suggest that as an option just to move ahead and then you know work on these things in parallel yeah um is this the thing where we need another breakout call

probably or okay I mean I mean yeah I'm sure we could have another one next week and and talk about it

more

Alex Stokes: yeah and it sounds like we probably want one that you know if it's in two weeks and we have time to like get more community members to be present because it sounds like that might be the path forward is just seeing how much demand there really is um and then using that to weigh our decision

yeah that sounds like a plan um especially if it takes two weeks I have a little more time rather than I guess just the next call next week

Alex Stokes: right I mean you know if it can happen next week that's great but it's more just like giving people time to be aware and then plan and show up

yeah I think it's just about scoping

out the complexity of execution L initiated consolidations might I just anticipated might take a little more than a week but yeah

Alex Stokes: yeah okay well thanks um okay maxv we can move on to the next EIP that's been included 7549 so this is moving the committee index out of the attestation data into the attestation object again I took a look at this specs yesterday they seem like they're in a pretty good place uh are there any open questions anyone here who's been working on this are aware of uh I think M might have some

stuff

Mikhail Kalinin: um yeah so this just for the context this C also introduces um a notion of onchain Aggregates versus network network Aggregates so it allows to um back uh sign es and agregation bits more tightly when we include station on chain um and currently this um design that that is in this back has one downside uh so because those Aggregates uh will be bigger uh because there are aggregation bits from many committees in

one onch aggregate uh so we have to reduce the number of marks at stations and currently it is set to 8 versus 128 as we have it right now and the problem here is that uh let's just consider that U the situation where proposer wants to include many many Aggregates from the same Committee in the same slot which is the case according to the chain data we have because those Aggregates probably have like uh yeah have just more information and just more bits if we include like

several of them for the same committee and the problem here is that uh say we have 10 Aggregates for the same committee and uh one slot uh cannot accommodate it U with this proposal while uh with the status qu it can be accommodated um why it can't accommodate because we have just attestations at at marks and each of those attestation can accommodate just one um one aggregate from the same committee so what yeah what I'm just going to play with is to see if we can replace the commit bit commit bit Vector with the list of

committee indexes and in this case uh they will be possible to include um to to pack gates from multiple Aggregates from the same committee into one chain Aggregate and basically it means that one chain aggregate will be able to contain overlap in Aggregates from the same committee so that's just one addition that I want to try to experiment with

Alex Stokes: okay and maybe just to recap so we lowered the number of onchain attestations per block because they're now more de right but now this makes it harder to get even more Aggregates in

the same block which makes sense

Mikhail Kalinin: uh yeah and uh in some cases in some cases want probably want more flexibility

gotcha yeah teren um in this mod

Terence Tsao: are you assuming there's this like aggregator that just volunteer the um decide to subscribe to all the subnets and then by aggregated alra races basically U basically on it behave versus like the current model is more like a random selection right you basically um say today there's like you like

2048 committee and each committee has like 500 validators and by chances There are 16 validators I'm sorry 16 aggregators per committee so so basically those are by random live stream so I I just which model does this okay put just answer the proposal does this I see thank you

Alex Stokes: right yeah so the way it's WR right now is there's like that's sort of an additional step from what we do today where as far as I can tell the network level stuff stays in place but then the proposer Now can do this additional thing where they can like pack things much more tightly on chain because now the attestation can like span rather than just like one committee they can

now span all of them

Terence Tsao: right but this doesn't reduce the beacon attestation aggregate subnets bandwidth and traffic right which is well I thought it does but I am run there

yeah

Alex Stokes: yeah I mean it would make box smaller because again the stations are just more tightly packed which is nice um it would be like a more much more invasive change as far as I can tell to like yeah touch networ I mean theoretically we could do it but yeah would be much bigger change yeah

ptis

Potuz: yeah just on that it it does help in a few in a few things the economics of validators that are losing

attestations because they can't Feit after reor and clients are dropping attestations because it's not just profitable for them to pack them uh I think this this is going to help on that um but yeah stance is is is it's also it's Al it also helps some security we have some security assumptions in that in the worst possible attacks to for choice we we should be able to repack attestations from other blocks into the canonical chain so it even helps in the in the theoretical properties that for Choice has but I think uh Terren is getting into something that we should be prioritizing which is what Julio from

Eric on try to come up with Solutions uh which is change the adapation format so that we actually lower the bandwidth on on the network I think this should be a priority for next

fors

Alex Stokes: yeah I tend to agree but then I think that would touch subnet structure right and so that's just like a much bigger thing says it's scary in the chat um cool so it sounds like M's going to look at uh getting more flexibility into like the onchain packing otherwise this one seems like it's in a pretty

good place okay again silence is compliance um great so those are the four eips on the CL that have been included in Electra um yeah next on the agenda I did want to touch on updates with respect to each team's implementation status like again uh well again maybe taking a step back like I guess my plan now is to get all of these four at least into some like Electro spec and the CL specs um and have that out ASAP um obviously then

we'll like work on spec tests and you know hopefully ideally even by the end of the month we have all that ready to go so in parallel it'd be great if client teams are implementing these things uh could I get a brief status update from each of the client teams uh on their implementation progress are there some of these that you've looked at some of these that you haven't um anything like that

Sean Anderson: uh I can go for Lighthouse um yeah I would say we've got a lot of progress on Max CB Mark's been working on that obviously um 6 6110 we've had a an external contributor

implement this I I think what's lacking still is um any changes related to uh like The Pub Key cache um and mial mentioned that he might be working on a design that would alleviate us having to make changes around this so that would actually simplify that a lot um EIP 7002 I don't think we have any implementation progress on um and is that it or am I missing oh yeah the uh ad a station change um yeah that one yeah Aon from our team has also started

Alex Stokes: cool

thanks any other clients want to chime in

Stefan Bratanov: um yeah for Techo we have uh implement imped 6110 um but so we we also implemented the cash but we may have to revert that depending if the specs uh which M discussed are going to be part of it uh 7002 is in progress we have a PR it uh and the attestation changes are also being looked at uh maxb we haven't done any coding but uh we have someone looking at

it

great

Gajinder Singh: for loar uh 6110 we have we have implemented and uh we have mostly implemented Max CB as well and we might just push in other uh PRS that are required so yeah we are sort of uh feeling confident on it

James He: for for prism um we're ping 7251 Max EB um but the other ones were still in the early phases uh of assigning to each of the team members they're they're being discussed but um not not too too deep into

it

Alex Stokes: sounds good and I think uh Nimbus we're still missing if anyone is here okay I can follow up offline with Nimbus on that so yeah kind of what I expected um some teams have different progress in different ones and yeah hopefully that can be top of mind for everyone over the next month so yeah

Terren

Terence Tsao: are there like a general tracking shet for like team progress you can think of like a table Where The Roses of the eips and the col of Clan teams and we can Mark like progress like basically M Stone one M stone 2 blah blah yeah it looks like

Alex Stokes: yeah Barnabas is already on top of it great um cool yeah I think that will help people understand where their clients are at and then again I think it'd be great to aim for devet in like the next month month and a half and you know if client teams can do sort of parse inter op um sort of on their own when they're ready that'd be

great okay so those are the eips that have been included uh let's take some time to talk about about other eaps we might want to think about for uh the initial pectra devnet one that was CFI but not included is inclusion list um I would at least like to get to a point today where we agree on I's well yeah should we should we focus on them or not uh does anyone have any thoughts here I'm not sure exactly what the latest status is I know there's some um complication let's say around AA account attraction with the design

Mike Neuder: yeah I can give a kind of brief update

um right so I guess the last all core Dev execution call has has a a similar update but um so yeah if you want kind of more details check there I think potus's post is the most um the most thorough description of the relationship between 3074 specifically and inclusion list um I just sent the link in the chat so yeah I guess this issue came up and it's around kind of this idea that um we used to have this assumption that if the transaction was valid in the pre-state of the block it would be valid

in the postate of the block unless the only condition that would change that is if there was a a transaction from that address in the block um 3074 changes this because you can spend the balance of a different account um so an account that shows up in the inclusion list could could be corresponding to an invalid transaction um if someone else spends the balance from that account so that's the the tldr and Y 374 in particular um causes issues we have a breakout room tomorrow show the link it's PM issue 1000 um yeah we hopefully we'll over that um kind of exhaustively

there um yeah I think the general sentiment at least in the I channel of the eth R&D Discord has been that we have a few Solutions but most people are uncomfortable with both the the speed at which the spec has changed given these Solutions and the kind of Aesthetics of the changes being um I feel like they they kind of look a little less aesthetic than the original design um I think it's still going to be something we have to face down the line um I don't think the 3074 compatibility will ever go away personally but yeah we

can probably get more into the details tomorrow I'll probably cut it here and yeah definitely bunch of other people have have a lot of context too if they want to chime in

Alex Stokes: cool thanks okay so what I would like to do today is just focus us on devet zero which you know given ILS or maybe a little up in the air um they'd also you know like we won't make a decision today because we're also going to need El Buy in and like 3074 is not even CFI so if that's an issue for but then it's on the

four like you know maybe that un blockx like it seems like there's some uncertainty there and so I would kind of suggest just putting it to the side for now um again for like our initial for our initial devet zero scope uh I think everyone also be plenty busy with these other 4 IPS and yeah we can work on uh Isles in parallel was 3074 CFI yeah I thought it wasn't I think going to be discussed next acde it was CFI for CFI great so yeah I mean there's definitely

some open questions here with respect to AA and yeah I don't think we're going to decide today what I would then suggest is yeah essentially what I said so basically let's focus on these other four again I think that'll keep client teams busy and yeah Isles can just kind of go in parallel and uh yeah we'll see how they shape up uh let's see yeah so Tim put the included eips in the chat so it's the four that we've talked about today and then also 2537 which I wasn't going to touch just because I believe that's only El uh scope and so yeah none of us really need to worry about

it so cool um let's then you know it'd be good to hear what people think about timelines for again this initial devet so you know assuming we only target these 40 IPS do people have thoughts on you know when we could start seeing early Dev nuts like is this something that's going to take one month two months it's too early to give estimates anyone have any thoughts

Sean Anderson: I feel like we don't really have enough info for estimates yet if um 6110 and Max CB could both have um design changes

I could change the workload of decent amount um so yeah I think we just need to focus on like getting a Dev net spec um because like rushing to the devet prior to having a spec is I think a bit counterproductive um it ends up with us like writing a lot of code that we can't end up merging

Alex Stokes: yeah totally okay well uh I think that's at least my Show's top priority over like the next week or two is like getting to some electrospec that's final and then hopefully that uh gives us more clarity moving

forward okay um I think that's all I had for Electra is there anything else that we should discuss I think it sounds like there's plenty to do and people know what to do but if there's any else Let's uh let's hear it

oh well we didn't mention pieras right

Alex Stokes: yeah I was going to go that next jump into yeah sorry what was that nothing I just gave you I I prompted you thank

you um yeah so I put it more in like the research slpc side of things um yeah so pios hopefully is also St of mind for everyone uh you know at a high level we should focus on what we can hopefully call a small fork and then I think in parallel well you know if your team's working on this you know say 80% is going to Electra maybe 20% is going to pios um and yeah that's something that we can move uh forward in parallel as well are there let's see yeah anyone here want to give an update uh I know there's been some like proof of concept work on implementation um also the spec is well there's a huge

PR around the P spec I think the plan is to merge that as is and then you know any open issues from that PR we'll just move to another issue and an iterate from there is there uh yeah anything on pios people want to discuss

Sean Anderson: um I guess I can give like a general update with Lighthouse stuff we've made like a lot of progress um right now we're spending a fair bit of time though refactoring existing Lighthouse code to sort of um like support integrating P ass more simply um so I think we're still a

decent amount away from a like a full Lighthouse implementation um but we have like a lot of progress on individual pieces

Alex Stokes: okay awesome are any other client teams actively pios yeah

Potuz: yeah so I can't really speak for prism because uh I don't know if Nishan is here Nishan and Manu from Prism are looking at this and they have been uh looking at the specification started uh thinking I mean brainstorming for for the actual coding but uh something that they pointed the Nishan

pointed is that uh even though Tech techically it's not a hard for it's in practice it is because it seems to be very hard to have this uh these networking changes uh not affecting brutally the network if you don't ship them out of hardw fork so I wonder if this has been agreed or not because if this is going to be in a hard Fork then this this decision has to be made right now

Alex Stokes: right so I mean I think the thinking was kind of that assuming it's not like yeah like you're saying really complex networking

wise like clients you know you can imagine that I download prism and I set a flag in terms of my like availability mode um and that should just sort of be transparent at least that's the intention with peros uh the only like necessary hard Fork would be bumping up the the blog data gas on it right

I

Potuz: I technically that's correct but the problem seems to be along the lines of like proposers not s proposers are updated and they don't send the full blogs or like be Das nodes don't download The Blob so they don't have the blob to to to serate completely and then non beer that blobs wouldn't be able to get the blob and this can create like head split views

Alex Stokes: right so what I would say to that

is just like I think we keep working on you know implementations on the side I think it'll become clear you know if we have pios Dev Nets say six months from now eight months from now then like it'll be clear if this is an issue or not and then we can go from there um yeah it's I would rather focus on shipping Electra as quickly as possible and so like I don't want to have this huge uncertainty appear off slow things down personally I don't know if anyone else disagrees

Sean Anderson: um so we had sort of talked a little bit about potentially having overlap and like um serving both like P do samples

and um participating in Blob gossip and blob validation normally um so then we could get like even on Main net some degree of like uh uh certainty with sampling that like when you sample the blows are there but there'd be like a lot of redundant um upload down that we'd have for a period um so unclear if it's worth it but I thought

Alex Stokes: yeah but it does like greatly due risk rolling out pios which I think is important so I know I don't like that would be my preference is to like d risk as much as possible have a more gradual roll out and then once we're very confident then go ahead and do like the

hard Fork to bump up the block count okay well there's some chat I guess that's worth surfacing onar saying you know pios is definitely very very urgent um and then yeah to put this point next in the chat that would change prioritizations yeah onard you want to say something

Ansgar Dietrichs: yeah I mean I don't I think there's not like unanimous agreement in here yet necessarily that there is the demand on the layer two side yet to already absorb the the block throughput that we have today and that basically it's it's going to be very urgent to scale I personally predict that that will happen of course we will

see by the time we Bic have to make final decisions around elector we will we will have more more time to see how much the demand has picked up um but ideally at least I'm operating on the assumption that it will pick up I would personally like to see at least this be prioritized in the sense that clients spend attention and resources on this and then if it's not ready in time for Electro I don't think Electro should wait for it because it's not necessarily strictly like has to be combined with the fork but I would not I I would personally think it would be very unfortunate if basically everyone focuses on the elector features and only once that's done basically starts really working a lot on on FAS that that seems like the wrong order of priorities to me

Alex Stokes: right and this is kind of my point a

second ago where I think you know if client teams can split Focus 8020 let's say I think that is a good compromise

I also have brought up something to a few people but um is it possible in Electro you could consider increasing the max poop size to something like 10 or so and then when we are closer to the electro Fork we'll have more of an idea of how much demand there is and then potentially you know uh for like while fstar is going on maybe there's a CL only fork and we can decide at that time whether or not maybe we just further

increase SM blobs per block to something like 14 or 16 or if pios has made sufficient progress then maybe we could handle the CL only fork that that does p ps but we could make that decision later like right now we could plan for a small increase in capacity for Electra and then later decide on what the next increase in capacity is

Alex Stokes: right and Anar you had the IP right to suggest bumping up the Bob counts even without

pios

Ansgar Dietrichs: uh yes uh it's still in draft but it has a number 7,500 um basically the idea would be to have it gradually increased um and Electra basically like a small bump at Electro itself and then two months later like another bump and then two months

later another bump um exact details like in this case I was targeting 816 basically it could of course be less ambitious initially um but but but some something like that the one complicating Factor here is just that basically we have two alternative approaches for for scaling right so basically there there's still head room for like a one time pushing the existing for form mechanism to its limits right so basically just really optimizing BL propagation seeing how well thework handles things today and then pushing to this of course this will require some engineering effort and so of course once we move to PS or other forms of data availability sampling this will basically no longer like this this will become redundant work so the question is if we are optimistic on the timeline for for dis it would basically

be a waste to put engineering efforts on pushing to the limits of 4 for four but if we think that say DS P us will still need a year or so to hit mayet it would maybe make sense to First have like one in initial step of throughput increases just by pushing for it for and then a second step moving to D so I feel like we just have to agree on a strategy

Alex Stokes: right I mean that makes sense and then the question is like how do you actually get there um it seems a bit early to like commit one way or the other so you know I think we see how main that goes right just getting data is going to inform how urgent it is to bump up the four44 blob count you know if pios implementation proceeds a lot

more quickly than we expect then that kind of pushes us that way so yeah I mean I guess it's just something to keep on everyone's radar and then we'll address as we go

I mean I I think is it true though that either way the pressure for Electra is small uh four or four block increase

Alex Stokes: well it sounds like I mean yeah so I think it'll just depend on pios implementation right like if pios is ready to go and we are confident in it then like great we'll do it if we're not then like I would say you know Das or like you know data scalings sort of a soft question mark with with Electra right now and what that would likely resolve into is bumping up the 44 counts

um yeah I mean luckily that should just be a constant change so that's something we can easily do you know down the line so takeaway is focus on puros focus on everything um but actually like you know to the extent that you have spr capacity uh definitely keep eyes on pios and um yeah otherwise sounds like everyone will be head down on these other eips so that was uh pretty much

everything I had in the agenda are there any other things we want to discuss while we're here

Hsiao-Wei Wang: like um does any client wants to test with just basic two e that has been pretty close to finalized I mean the 6110 and 7

02 or like people just want to

yeah t says in the chat

Hsiao-Wei Wang: oh yeah so like um know if people think like two weeks is too long to wait and uh I can generate the test vectors just early next week but I think it won't be a foral release yet just the test vectors is that okay

Alex Stokes: yeah also from Lighthouse uh yeah test are good so yeah I mean I think that's a good path forward with the spec shway like we can work on that into show

Electra PR that has 7110 and 70002 and yeah then again something I'll be working on next week is getting these other two in a place where we can merge them all and then yeah again my aim is by end of the month to have or even sooner to have uh yeah this like Dev Net Zero uh Electra spec test ready to go okay uh anything else otherwise we can uh wrap up a little bit early today okay seems like a know thanks for

joining everyone and uh yeah I'll see you around

thanks Alex thank you bye guys guys up

J

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.