All Core Devs - Consensus #142

Transcript

[Music] J [Applause]

Alex Stokes: okay we should be live I assume the chat on YouTube will let us know if there are any issues but yeah let's go ahead and get started so to kick us off we have the agenda here this is issue 1154 in the PM repo this is consist layer call 142 thank you everyone for joining and yeah there's quite a bit to get through today so let's just go ahead and dive in so to get started uh let's think about pectra and perhaps we can just quickly go through any updates for devet 3 uh DEET 3 has launched which is super cool uh I think we had some bad block

testing that we did which caused a little turbulence and it' be interesting to hear an update uh from the results of that anyone have anything like they like to share

Parithosh Jayanthi: yeah we had marius's bad block generator and mainly the chaos seems to be limited to bzu um is someone from the bezu team around maybe give an update

I

Daniel Lehrner: I can give an update yet um so the the fing yes they created signatur that were zero on Hex decimals 0x0 um B has an rule a rule internally that the signature has to be at least

one uh so we reject any transactions with those signatures I'm I'm currently updating this so have open the pr to to fix the issue and to to accept the signatures um as once this um yeah that's fixed I think should be able to to join again

def true

Alex Stokes: cool any other de3 issues otherwise I was looking the other day it looked pretty healthy so that was exciting to see by

cool uh then we will move to the next item on the agenda and yes this is uh discussing the split of pectra into uh possibly two forks we had discussed this on last week's ACD and kind of had asked at least for everyone to have a view on their preference for how to split this into two uh for reasons that were given there and yeah I guess we'll just go ahead and uh open the floor yeah iton put this in the chat thank you so I had a document here that was essentially one way to split up what we have now um my thinking was essentially like yeah I mean I guess where to start is like Petra again is like one of the

largest Forks that we have scheduled as it currently is um ever in ethereum's history so for many reasons around reducing risk and just you know overall success of actually executing a hard Fork it makes a lot sense to split it into two um I think also given just development progress of other features uh we've been we've been discussing for Petra like pados or eof um there's like a pretty natural split between sort of what's on devet 3 today and the other things we've been discussing so yeah I guess maybe to get us started with the conversation here uh does anyone disagree with what I light on the Note uh is there like a

different proposal that anyone would like to discuss are there eips maybe that you would want to see in like this first pectra that aren't in this note happy to hear what people think yeah Andrew

Andrew Ashikhmin: um right so uh um we have a an Aron's perspective on the vector split uh uh I'm basically um I'm posting the um the write up um it was written by our team member somat some not are on the call maybe not

uh and um I can if not I can Briefly summarize uh our position so we basically were against it um and uh there are a few reasons so on the face of it it makes sense but um essentially we we worry that splitting pector into two will will lead to to full to two fully blown Forks um and um uh people will use it as an opportunity to um include more aips into the second Fork uh there might be interactions between various

eips of the two forks um and um that will introduce a lot of interference and uh um last me decisions and we also want to get our priorities straight so if we think that verle is important then we should prioritize vco uh rather than kind of you other random eips um and also uh if we try to like do if we basically if we Implement many eips it might be successful uh in some sense but um it actually uh also uh uh

detracts resources from our engineering resources on on working on uh other improvements to the clients like tackling things like like State growth or code deficiency or and so on so trying to crme as much if into say two two forks it may be not exactly a success story um and basically we propos to uh keep e in pectra given that actually there is a lot of momentum on EF um I'm thinking that like if p is not

ready we can have a c only fork or if Bas requires some uh trivial changes on the side that should be fine because it won't hinder our progress on vco much but yeah I would rather I agree with with somat and I would rather avoid backr too

Alex Stokes: yeah I mean I think that's the key risk here is like we would say okay pector is Big we'll split it into two and then we essentially don't have the discipline to keep the second part uh as is and then yeah it becomes a whole whole separate Fork there's a delay you know with that just necessarily

and that's not great so I don't know like the way I would mitigate that risk is we just commit even today to saying like hey like we will break it into two um but essentially there's not any room for like new feature um you know if there's some EIP that like complements Something In pectra A or pectra B then you know sure that's that's um those would make sense but the point is not to like just push everything to a second fork or you know push some things to a second fork and then open the can of worms of you know hard Fork scheduling again in say six months any other

thoughts yeah you done

Etan Kissling: uh personally I'm also in favor of the split um just because uh like I'm I'm looking at it from a peer perspective and and at this stage it seems like that it got descoped so much that it's essentially like the subnet Des but the Des part is also removed now so it's like just splitting the data among notes and hoping that it sort of works out with the availability without any sampling so I'm not sure I mean not not not fully removed but um yeah it it just appears to me that

it's not like ready ready as all the other features that have already been implemented like the attestations the valid dat requests Max CB um I don't think that delaying all of that which is beneficial for users today um is um warranting to wait until both pias and the are fully ready and fully battle tested

Alex Stokes: yeah I mean I think that's the justification for the two forks uh and then just to com to surface several comments in the chat uh even like gard's here that is the last message

essentially it's just like hey if we like this will this will be most successful if we commit to like a very strict scoping and so that really means like yeah there's no room for like it's not it's not that we are picking pectra then we're going to pick the next work and then now we can decide what goes in the next work it's like kind of acknowledging we've already decided that we have two hard Forks worth of Eeps and this is what we

show uh putus yeah

Potuz: so a i i don't agree with like being strict on the scope and B even if I did agree I don't even trust that we would be strict on this 12 we we set to scope betra very early very early

much wait a few months before we went to Kenya and we we were very clear that we wanted to have a very small Fork because it didn't need to delay ferle that was the commitment that was an agreement that we went all teams went at async and proposed a list of changes prison did didn't even favor maxb on the on the first change and then we have this monster Fork that now we're trying to split if if we were about to have this large Fork then we would have pushed for a very different set of eips so I find it not unfair I find it just simply wrong to already be committed for the next two forks because this Fork actually is in for any practical matters

at two Fork

at two Fork oh yes

Saulius Grigaitis: yes I think I I kind in line my thinking kind of in line with with BOS and I I think we why we can just think slightly differently we can just say look we have these features uh from the list that are quite ready and there are a couple of features that uh doesn't look that will be ready uh very soon and we will delay and uh let's ship these

features in the next forec I mean for myself this uh this thinking that uh it's possible to split the the the pectra into two pieces uh and the second piece will be the same exactly the same as we think now I think it's it's a bit unrealistic uh so so if we just change the thinking where we just simply say that look uh there are a couple of features a few features that needs to be uh pushed to the next H fork and that's all so that that would be my my idea

Alex Stokes: right and yeah just to chim what

Marius is saying here in the chat like there's at least two things here one of them is just should we focus on Petra being essentially the devet 3 set of features we work over the next couple months to like get everything polished start thinking about testet timing on the way to mainnet the other thing is okay yeah the scope of say the second Fork I hear everyone that yeah it could be tricky to not want to put new things in um I would lean towards again keeping the scope very small just because then that's going to maximize our chances of actually shipping a second Fork very quickly with respect to this first one say pectra a so that all being said let's maybe take

these separately so is anyone opposed to saying that the next hard Fork call it Petra a or even just Petra uh will essentially be the D 3 set of E I think there's General agreement on that point but correct me if I'm wrong

Marius van der Wijden: I'm I'm very much in favor of that I do I think yeah I think Eric on Aron was the only team voicing their opinions that we should split the

F gotcha iton

Etan Kissling: um I mean generally yes it's just this uh the

7688 um which I think should be in the same one that adds these validator requests like um the the reindexing on the CL side

Alex Stokes: right so yeah um again I think it's going to really complicate things to like think about adding more things to Petra pectra a um but we can have the conversation uh does anyone else feel strongly like in particular different client teams would love to hear your thoughts on this like uh the 7 seven I think it's 68 changes um and yeah uton

maybe just to add a little context this is the stable container set of features uh but essentially just with like C scope

um so my perspective is that like like a big benefit of splitting the works like a reason to do it is that we have something that's finalized and so like we could do it quickly so I would be against adding stable containers to that especially because there weren't like uh there wasn't like a huge push outside of the like um corev calls I guess from people who want that feature um so yeah I think it makes sense to just like go with de net 3 don't add

things it might actually ship quickly that'd be sweet

Alex Stokes: yeah I tend to agree myself Andrew

Andrew Ashikhmin: um yeah I think um uh um it makes sense to split few sale um changes like P do into a separate Fork because or that might entail some like minor changes okay I'm not sure but say p does entail some trival changes on the side that shouldn't be uh that big a problem why uh B basically u i worry about hindering the progress on vle so we on the L side at least I think so we need

some head head space to to concentrate on vle that's why I propose to uh keep EF in in pectra so that we can ship it but I'm happy to yeah to to um have p and SE changes in a split

fog

Alex Stokes: okay uh my understanding is that EF is not quite to the same sort of developmental milestone as the Dead 3 eips anyone disagree with that take

Danno Ferrin: we have patches out for G to pass all the EST tests and we have Basu and

ref are ready to implement um NE isn't far away so we're not too far from being able to execute a devnet with at least three but we aren't 100% across all the clients yet

Alex Stokes: okay thanks so I mean essentially I like I understand the urgency to ship e let's say uh but I just think given all the other considerations it would make more sense to keep it out of this first Spectra okay so what I'm hearing is that that we're generally on board with devet 3 essentially moving on to be the next

hard Fork um yeah obviously there are other things to consider um but I think that's the direction we should move in I don't know if we want to then turn to talking about scoping the second Fork it might be a little premature

um yeah

Matt Nelson: well I think the Counterpoint to saying that it's premature to scope the second Fork was what you mentioned earlier that if we don't do it now the commitment to that fork will we risk scope creep of you know the same exact problem we had with this first

Petra right

Guillaume Ballet: uh yeah I think we shouldn't work

on the scope of the second four just yet precisely because I mean like Matt just said it's going to be to be a cre but um more importantly there's going to be things that change uh we we're just going to add some bike shedding before that you know that is not necessary what we need to do now is ship that fork

Alex Stokes: right and you know to address Matt's Point uh that was just made I like the way at least I would think about it is like essentially I would try very hard uh to stick to B being just pios and sort of The Blob set of eips along with uh EF that being said it'll be a

conversation and just going from the chat and things said here it sounds like it will be hard to uh sort of commit to just that for the second Fork but I think we should all keep in mind that the more we touch or change the second Fork the longer it will take to ship hopefully we have it sooner than nine marus um okay so I guess this is final call let's move ahead with Petra being Petra a which is essentially deut three we can we all with that well just to clarify that we have a number of

things to modify those eips so we don't really mean three we mean deit four but with those eips right or five or whatever yeah this is a good point so there are a number of uh open points still even with the devet 3 scope some of them we'll get to later in the call um but I essentially mean yeah just like the that EIP set or that feature set

so

Etan Kissling: so where do you want to put the stable container stuff into P dra two or which one

Alex Stokes: well I mean I think it's a conversation with everyone here um I think yeah pector 2 is a natural Target

Jacek Sieka: my understanding it's as good as ready

in most clients and it actually has user interest as well like contract developers have problems with this today so pushing that back is seems kind of pointless it's also CL only

Alex Stokes: right so I mean the question for me I would think is just like what like it even if it sounds ready and it's maybe a relatively small set of you know say code change just doing this like again kicks us down like it moves us further away from getting to like a stable pectra with like a spec freeze and all this and

you know that's not the end of the world but I think it's a decision that we should make intentionally um are there other client teams other than nimus who feel strongly about this I believe it's 7768 the stable container eips

um I oh sorry I feel like even though it's most clients have implementations maybe all clients at this point there's still a degree of like testing like we have to update the spec tests at specs um spec test specific to it um and then just the fact that it's not as battle tested we'd have to do fuzz on it so it's like it does ex

add more work to what we have even if we're mostly like Dev complete so in my opinion we should put it in the second Petra for but yeah it's my opinion

thank you

Guillaume Ballet: yeah uh yeah so I did implement the containers on my own Library uh like two months ago uh yeah it looks cool um but I just wonder if it's worth shipping before we actually need need it and okay I for when haven't understood why we need this okay except for veral actually but apart from that is there an actual need right now to to ship this

Etan Kissling: it's the

4788 um smart contracts and client applications like rocket pool has a decentralized staking pool and they want without any multi seek to be able to prove for example that the validator was activated so they want to prove relative to the beacon State trout and that the validator is now there that it's not slashed and access that information from the smart contract so what they have to do today is that when unrelated stuff gets added such as like consolidation requests or whatever um the size of the structure changes of the beacon State

and they have to keep updating the code every single Fork even if only stuff changes that doesn't affect them right it's like if you install a new OS update and you have to recompile all your apps every time even if none of the apis change that um that you're actually using so that's what's being addressed here it's a benefit for the couple users who um who want to use like verification in a smart contract relative to the beacon State um for our elves um the core developers we don't benefit that much from it like we can optimize a couple things by um having fewer hash computations if it's

like an optimized implementation but um the main benefit is for um like those developers and indirectly also the users of the ecosystem because it's easier to create trust minimized applications when you have lower maintenance effort but I agree it's not like the the prime most important feature the only reason why it's um is a good timing in the pectra is because this reindexing reindexing on the beacon state is already happening for other reasons so all those teams that rely on EIP 4788 have to update their code have to

redeploy the contracts based on new indices and that's why um the timing is like tied to those request eips um we can obviously also ship it separately but it means that users will have to go through the migration step yet another time yes the deposits and the withdrawals are more important um of course like but uh I don't think they are mutually excl exclusive like um the stable container is a c only feature

Alex Stokes: right so then the question

becomes like do we for this particular set of users say a 4788 do we like potentially delay Petra even more uh to to account for them and I don't know I think maybe to like reenter things a bit I'll let go with Tim is saying here like the whole idea with the split is to ship the next hard Fork as quickly as we safely can and you know I think what that means is we really stick like we do like we really should stick to like a very strict scope like I think it's already going to be tricky to get to like say spec freeze of first Spectra you know in the next couple say month or two like next couple weeks like ASAP just as is and like yeah I hear that

it's you know the de nets for the EIP has been going like you know code generally ready or mostly ready like I hear that but every little thing will just push out timelines further and further so yeah I I hear all of that I would lean towards deferring to later Fork okay there's number of different views

in the chat um yeah seems like we're kind of slow on this essentially do we keep things as is um or do we want to think about including this ssz EIP into first Spectra okay there's my chat going on sorry for the silence I'm trying to catch

up I mean maybe to ask this question like if we do commit to Petra a being devet 3 plus polish is that the end of the world like yeah I understand that there will be you know a little more Downstream code change for users say of these journalized indices um do we yeah I guess I mean It's Tricky but I really do think the right decision here is to think you know with a B scope and just say hey uh yes this is a sort of consequence of this decision but ultimately we'll get to a faster pectra a and just keep

momentum generally higher for the protocol broadly yeah

yeah

Ahmad Bitar: I'm just going to say whatever I said in the chat which is I feel like it's either we split whatever is CFI and slated for inclusion in current picta and not add anything extra to pict b or we're going to end up with basically scoping a whole other Fork after this pict TR for uh and and we might and everyone is going to end up wanting to add eips to that PCT fork and we're

going to might we might end up with pict C and then goes on like I don't know I don't think this is the right way to go either we are strict or we are totally not or or we stick with whatever we have sorry which which is which is uh sticking with one

14

Alex Stokes: right and that's the thing is like I think everyone agrees that the current Fork is just too big right so then I think a split makes sense and then from there I think if we do split what makes the most sense in terms of again like very broadly from a very broad perspective keeping everything moving and sort of our shipping velocity High

uh adding more things to especially pectra a is going to be quite risky uh Mark

yeah so um if the main difference like there's a difference here between people who think we can and we can and or that we won't be able to limit the scope and then there's a split of people that believe like it's worth splitting up if we could limit the scope um I guess like the main question as to whether or not we can do this is are there enough people that are willing to just not like in 9 months or whatever however many months when people are talking about it are you willing to not let people put anything in you know like

if you're on the team that you want it split up and you want um us to limit the scope can you commit to just in these calls not letting anyone add anything

Tim Beiko: so one I think I think there's two different things or more than in two different uh things um but um basically one is um do we want to ship something relatively um relatively quickly and I

think the only path there is we split Petra along the lines of what's already been implemented um there's a bunch of stuff that different people want to add for different good reasons um but I think as soon as we open that can of worms it becomes is pretty much untractable and um yeah so I think de three is like the right shelling point for if we want to split today I think the other question is if we do Petra B uh there's it's clear that Pier Dash should be the main thing there on the on the CL side on the El side I guess there's like some disagreement between the relative priority of eof and veral um and that's probably the biggest

deciding factor um and then I think the other thing for preure B is like do we want a bunch of small things come in um and then um and yeah sorry po by Dev 3 I mean like the eips in De 3 not like the actual spec as is I know there's like a bunch of changes on all of the or most of the eips um and I think if we if we commit to like yeah assuming we split the fork um on the CL side it does feel like P is the obvious NE thing to work on on the El side there's a question between veral and eof and then there's a question on both sides between do we want like a bunch of other small things to come in the fork or not um and then it doesn't

seem I I I think it it doesn't seem crazy to like try and resolve those things separately one is to say like okay do we want to ship something as soon as possible um and and then two is to say assuming we split it we're obviously removing eof um from this Fork do we want this to be the focus of Petra B and there's some comments in the chat right now saying that they strongly support that um and then C is assuming you know we have uh perod in eof and Vector B um are there other small changes that are not like proposed yet that we think are actually quite valuable to include and how do they affect development timelines um and

I think the thing that becomes hard there is like drawing the line of with like a small change versus not um but they're effectively like three sequential decisions

um yeah

Alex Stokes: yeah and I think just going sort of by that framework like it does seem like like yes the SEC features are important like in in isolation they do seem to kind of fall in this bucket of things that you know are not quite ready say if we want to sort of slit off pectra pectra a today um if only just because you know it has been part of core pectra Dev Nets yet like there'll be tooling updates like testing security there are many things that will need to be part of that process before we want to sort of

say this is now in pectra a and yeah it's it's hard for me to see how we could sort of accomplish the best vision of all of this uh if we include it in this first Fork So to that point like I would propose we go ahead and say again pectra a is devet 3 plus the Polish it needs um we can have the conversation to put s theps into the next work and uh probably handle the scoping conversation there a different day

gam

Guillaume Ballet: uh yeah I just said an idea um if you want to be able to keep some flexibility for picture B while still uh

making sure it doesn't blow up you could introduce a rule uh for example that if you add any IP you have to remove two from uh from what is already scheduled this way you know presumably only the bettery IPS that everybody's can get behind are are going to be scheduled and I think it will uh it will you know make people think twice about pushing new stuff

Alex Stokes: yeah I think that's going to be really hard to do in practice but uh it's an interesting way to think about it uh Andrew

Andrew Ashikhmin: um yeah I'm just thinking that um I don't see why we should um join PS with

u with say pectra B on the L side I'm thinking that they can can be developed quite independently because um PS requires Min minimal if non e changes um we on the L side we'll have to discuss uh assum assuming we do this trans spit then we'll have to discuss whether we do vle first or E first because yeah there is a dependency but other than that I would develop say we decide to do vle before EF then I would develop I would have two two sets of testet test nets for EF and for veral and then they can progress quite

independently and we we we still have to do some okay say for verle that might require some minimal C changes and the same thing for PS and we'll do that but the bulk of effort will be quite independent and then we basically deliver whatever whichever is ready first

Alex Stokes: all right okay so how do we start talking about dropping you off I don't know if we necessarily did

Andrew Ashikhmin: well my point is that we should have

a discussion like like honestly we have to discuss whether we do V first or E first we we'll have to have this discussion on the L side but I was just saying assuming we prioritize vle over

EF

Alex Stokes: right and I mean again I would just Echo what's in the chat here like I think we can just see which ready which is ready for from my somewhat limited perspective just right now it seems like UF is much further along than

veral

Guillaume Ballet: um I wouldn't be so sure

Alex Stokes: no okay so again before this like explodes and we just spend the whole call talking about a feature Fork before we've even

decided the first one I would like to Ingress to make a decision on Petra today and um I would strongly suggest we have the understanding that there is like you know features from current developments that would make a lot of sense in the next work um but yeah I think we can have that conversation uh especially in the context of an El call uh even next week or sometime soon in the future uh dragon

Dragan Rakita: I think we starting again making decision like in the call this kind of decision where there is a lot of team that needs to give their opinion I think they're best done in like in R form so

we can compare the stances of all teams for example in this call we started talking about work before UF while the main point of the split was to speed up the the prag so we are jumping from one topic to another topic depend you on the various teams incentives that's proba fine but the main point get lost in that hey good morning I would um yeah I ask teams to as ol did put it last week uh in the writing say your like stance of this and we can compare

it and be a lot easier to see the various teams uh where we are basically going that's it for me

Alex Stokes: yeah thanks that makes sense uh Mark we'll take your comment and then I think uh we'll try to move ahead

yeah it does seem like like Tim pointed out there's multiple decisions that go into this one decision and so I mean could we I I like what he said that we need the teams to get together and do things in writing so could we commit to a timeline for deciding the pector B scope today like not not the pector B scope but

just like by some time we will decide it and then it won't be changed after that point and then we all we'll get together put out our arguments debate and then we'll have a call and we'll decide

yeah I think

Alex Stokes: yeah I Think It's tricky to kind of make a deadline just given everything um you know if we want to try to have a view on Petra B in the next two weeks that would be great um we could soft like I don't know like I think everyone this is top of mind for everyone so like I think naturally it will happen pretty soon um but yeah it's

it's hard to just like declare a deadline and then just assume that that will happen given all the uncertainties

maybe stop

Alex Stokes: well yeah I mean I could just say two weeks from now and then we'll see what happens I think there's going to be like I just think there are a lot of uncertainties into like Petra B and so yeah it sounds like at least just from the conversation on this call it sounds like the conversation is a little more complicated than like uh just split current pectra into a and b uh which is just where my hesitation is coming from but generally yeah I think uh the the faster we can make a decision the better so there there are other things to get to on the agenda today so yeah

let's uh recenter and there seems to be agreement to split current pectra somehow uh I think there's very strong support to have again this like devet 3 plus polish idea be the pectra fork and then Downstream we can figure out what comes next can we all agree to this we have a thumbs up

Guillaume Ballet: yes

Alex Stokes: there were other thumbs up in the chat to this idea earlier okay let's go ahead and call it okay thank you

everyone and yeah I guess sort of the takeaway for everyone else is uh be thinking about Petra B and expect to have this conversation in the next few weeks okay thank you okay let me look at the agenda so there are some blob things to discuss and yeah it's a little we might kind of jump around a little bit um but I think the right way to move forward now is then to turn towards this sort of Petra a scope there are a number of PRS open uh still in flight for some of the pectra a

features and let's just touch base on a few of them right now so this first one I had uh Mel had this PR let me grab a link to it here um he and I were talking about this and you know one thing at least that I'm trying to do is even for like the sort of again pectra a scope uh simplify things as much as we can I think there still are some open questions around you know where we can simplify what makes sense and how it does to do it one thing that came out of a conversation with Mel and uh is a way to change how we're handling the move to consolidations uh for a validator the way it's currently spec is

that you can essentially top up as a validator and if you have a credentials change uh in your deposit message then it would like signal to the chain to move you to this new sort of uh class Val validator this kind of touches a bunch of other things around you know week sub activity deposit handling deposit flow and um yeah it was it ended up being a little tricky one simplification here is actually to change how we handle this um and essentially rather than have topups and like the deposit flow be the let's say infrastructure uh to surface that signal from a validator uh we move it uh somewhere else and in particular the

suggestion was to move it to the consolidation pipeline uh and one way you could think about this is just if I have a consolidation coming from the e L if I just say source and Target validator are the same one meaning sort of like a self-c consolidation we kind of piggy back on that as a signal to switch to this compounding State uh that was a lot is Mel on the call he might have other yeah I don't know if you have anything else you want to add um this one's kind of hairy but I just want to bring it up because it does kind of change how we're thinking about this particular feature

y

Mikhail Kalinin: thanks Alex pretty much it and yeah it it also entails an update to the next uh

um PR that is on the agenda to the 6110 PR it's been updated with removing the um switch to compound from the deposit pipeline so um I think we should wait for this one uh uh we're talking about how to get merged and and then merge the 6111 that's good time

Alex Stokes: okay yeah sounds good and I put the second PR in the chat these are kind of coupled because again it's just trying to like simplify the deposit flow along with this consolidation flow and again this does just kind of point to a lot of the complexity even we have in Petra a today so that all being said um I think the

ask here is just recognize that uh we are changing this feature a little bit in terms of how you wouldve move from a validator to a Consolidated validator or consolid 18 validator uh so yeah please take a look at the pr uh that would be 3918 that I put in the chat here and the idea is that this one would be merged and then it kind of uh should further simplify this next PR 3818 and this has been an issue even from you know earlier this year even like interop around handling the deposits and making sure that the load on the beacon chain uh cannot become too much so these are core changes that we need to resolve and yes please take a

look I don't know if there's anything else to add muel on the 6110 PR

Mikhail Kalinin: um nothing on the pr itself but uh just wanted to mention the U performance stuff uh yeah some some deps were concerned about um having these then deposits cue which will be um entirely rehashed every EPO processing so it can cause some probably performance issue and I just want to ask if we want to check this and do some performance measurements because before leure we we do not have uh the lists in the begin state that are um

that we um remove elements from the beginning uh from so that was kind of the concern and this why we wanted to explore some alternative Q designs you know to make it always a pendon um not remov it from the beginning thing so yeah just wanted to not ask to forget about this um concern maybe someone already did some performance measurements and can just share them

Alex Stokes: yeah I'm not sure if oh

Jacek Sieka: yeah I mean I look at the performance quite regularly and and and hashing is like one of the big things that we do

with the state which takes actual time um the other one being shuffling right those are the two big thieves there the third one is slightly uh different which is basically signature verification and replay of deposits it's also something we discussed I think in Kenya uh but I would be l to add uh too much hashing because it affects uh processing in places which are already significantly uh heavy such as you know processing and often it can't be avoided it can't be cashed away it can't be you

know tweaked

Alex Stokes: all right so I think the the takeaway here is that uh we should look at this and this would be a nice Target for devet 3 devet 4 uh again around this first pcture set of features and the Polish we do there just to get it on people's radar I think there are at least potential other concerns around uh not just the deposits but also consolidations uh and what is the other one there's essentially like a number of cues that we're adding to the state and they're kind of all uh all relevant here so you know when I say DEET 3 plus polish this is kind of what I mean is I

think there will be a number of things that we need to you know ideally we could even get benchmarks and implementations today um and use that to inform where we go from there so something to keep in mind okay so yeah there's those two PRS again please take a look when you have a minute next up uh there were two more PRS uh again in the Spectra a scope around the attestation updates so as far as I understand um essentially like the points actually let

me grab them for the chat um but essentially it's a number of PRS to make handling uh attestations easier in clients just given the changes is from let's see it's 7549 I think the ATT to station thep uh sorry if I forgot the number but essentially uh these are simplifications uh at least as proposed for that feuture set and we had a bit of a temperature check on the last call and I guess yeah I'm just bringing them here again as another temperature check uh if we are serious about having these in pectra then uh we should we should make a

decision and and keep these moving along there were some comments on the PRS here around again concerns of complexity you know and again we just kind of get back to the same question like yes we could imagine sort of a perfect world uh but we might have to stick with a good enough world uh anyone here if you've had a time a chance to look at these PRS it'd be good to discuss how we think about them uh Terrence

Terence Tsao: I started implementing 3900 which is the a single attestation I think it's a very nice to have like it just feels right it's very clean but I do worry about like the complexity so

it's just one of those things that from the specch perspective it looks very simple but once you like added it to the C base then you see this C of changes that you have to make I mean but I do think this is much like easier in terms of complexity versus the attestations one uh previously but yeah I just wanted to make like a minor warning on that another I also do have a question just on the spec side you also it only makes changes to the PTP interface but as a validator I need to be signing and sending those attestation out right this is also part of the honest validator Duty change

Alex Stokes: right with the implication being that

you know this might sound like a simple change but it might end up being quite a bit more work than it sounds like which is also the issue had with the CIP in the first place so that's now the call to make um yeah where where do we sort of draw the line on good enough versus shipping the perfect solution

um so yeah atown was working on this from our team and he had similar feedback um I think if we wanted to Shi the Spectra one quickly we probably shouldn't include this change just because it's like a lot of extra work for like not any tangible gain in the clients although I think it's good from like the spec

perspective um uh yeah I was going to say something else but I forgot I was gonna say

all good

Jacek Sieka: I can answer the question at least uh for validator part um can be updated doesn't have to you can convert between the two formats freely uh the the networking part like what we put on the gossip channel is important for two reasons one is um the Dos possibility that we close with single

attestation which is very easy to exploit today if we wanted to if somebody wanted to and that sort of closes the Gap so that's the immediate kind of benefit that the pr gives it's a security update basically uh and at the same time it's also an efficiency update because we'll be spending less CPU um processing at the stations if we include it which uh those that follow performance like hashing takes time there's a lot of ADD s to process and the more validators we have the more that particular Point grows

so

Terence Tsao: um so if validator doesn't do

this then are you are we expecting there just like notes basically will convert to a different format and just forward it again so you can assume there's like honest behavior in the P2P for this

Jacek Sieka: um to be honest I didn't re like I I didn't really consider it if I if I was looking at it um after your comment I think I would include Don validator change as well right I think that's reasonable uh but it doesn't matter for uh let's say the bulk of the pr right it's it's it's it's better to have it in on the

respect as well I agree but it's not critical so if we wanted to have kind of a minimum impact on clients change then you can actually do all the translation in the gossip layer then um then many of these you know cascading code changes concerns can be uh swept under the rug I would say

Terence Tsao: but when you do the translation you still have to do some CPU cycles and compute right so is that less than today

basically because when you do the translation you still have to get the Committees you have to like figure out like which bit to flip in the aggregation field for example or yeah something like that so there is also compute there right

Jacek Sieka: not really it's all information that you have uh I mean in order to know whether you're supposed to create an attestation to begin with you have to load the the shuffling because that's what determines which slot you're actually sending the attestation in uh so that is all information that you have at hand when you're doing that processing I agree it's kind of pointless to not make dest validator change but it's not strictly necessary that's what I'm trying to say and it

doesn't affect the prime benefit either which is that um nodes validating the single attestation can do the um signature check before doing the shuffling with this change those that produce it they have to get the shuffling regardless so it's kind of uh again like I appreciate your comment it's really good and I think we should I should update the PR but uh that's you know um that's the nice to have of this change

Terence Tsao: yeah I think if this PR would to go in I would definitely prefer the honest valid dat change as well just because it feels

right to me but yeah other than that I have no strong opinion

Jacek Sieka: all right I'll just throw it in there I think I kind of agree

Alex Stokes: okay so then to move forward uh on the dock if you can add the Val guide changes to this PR I think that would help people sort of think about it and see the full full scope and I think I'll try try to get maybe another client team to look at implementation at least to like weigh in um and then we could try to make a decision on the next C call I think that's a nice path forward unless anyone disagrees Okay

cool so there are those and then next on agenda okay I want to be mindful time uh because there are some other things to discuss but I did want to bring up again this PR from Felix uh to think about how we handle the request and the engine API um yeah I feel like on the last call we were pretty close to saying this was good to go uh there was an update requested around I think some of the ordering semantics which I believe has been added um can we go ahead and agree to this change or are there any dates or questions we'd have about this change

Mikhail Kalinin: um there is probably an idea to

keep requests to not keep requests on the e at all so because they are now capped by CL and only keep the request West throughout in the El block header as a commitment that will be validated um by by the El given the requests sent from the CL by why engine API that's that's probably the alternative to to to this PR so El can do uh can compute this request rout so this commitment in a way uh it wants and it will not affect anyhow the CL part I don't know how much do want to um

explore towards this this idea but yeah at least it can be an alternative

Alex Stokes: okay thanks okay yeah I'm not sure we're going to make a decision on this on this call um I would hope we can next week uh also you know this one goes across Slayer so also want uh the perspective as well so that might be that for now if there are any other comments uh on this set of changes Now's the Time otherwise we'll go ahead and move

forward

okay uh so next up we're a batch of things things um essentially looking now like okay we have Petra a sort of again this devet 3 plus different polish things that we've been discussing there are a number of other PRS uh they're all pretty simple sort of one by one so maybe I'll just call them out um but there's this one to get rid of the skip payload bodies V2 uh set of methods I'll just post this here uh let's see Mel you have this are I don't know if there anything else you would like to add my understanding was that basically we

added this uh for Petra when it wasn't as clear how we'd handle the request and it's just actually simply no longer necessary so it makes sense to go ahead and delete which is what this PR does

Mikhail Kalinin: yeah basically it and it's just you know announc and to do the check if anything is missed and we should not remove those methods but I think we should if there is other opinion please um let us know before the next call

Alex Stokes: okay yeah I lean towards merging this even sooner uh than the next call but uh yeah we'll at least give it a few

more days so please take a look um and add any feedback uh to the pr and then otherwise there was a batch of things uh essentially again around polish uh for ra and kind of saying you know with the deet 3 feature set what do we need to do there's a bunch of things around apis and connections between you know the beacon node by our client there's the Builder pipeline there's a bunch of sort of pural things that are critical uh and need to be addressed so I called some of them out uh what is relevant here there was this PR for the engine API which just reflects uh how we're going to handle the request

and that's in progress another one would be the changes to the beacon apis I think there are still a few things there but let me just drop this in the chat so people can take a look at that and otherwise uh let me grab the Builder specs PR as well give me one second um this one is here so point being is you know moving ahead with devet 3 plus polish as Petra uh now as the time to be thinking about you know these various apis so Beacon apis Builder apis all the other things

um another one that uh is relevant is the remote signer and like web3 signer I don't know if anyone here on the call uh is more involved with that and would like to give an update there it would at least be nice to get a acknowledgement that someone is keeping track of it okay that's okay uh we'll follow up async with that and great so yeah again take away here uh just be aware of these PRS there

are some sort of minor changes to all these apis to reflect the latest Petra eips and that's something we very much want to get settled uh as quickly as possible so that we can facilitate Petra main net as quickly as possible okay that was more or less it for Petra uh if there's nothing else we can move on to pios uh and we do have I believe a presentation around uh The Blob counts which then also just kind of funnel back into this Fork scoping discussion um but maybe we'll quickly just start with uh any devet updates for pios I know they've kind of been in progress for a

little while I don't know if there's anything to update there first yeah

on duck

Jacek Sieka: yeah there's one more uh spec PR I wouldn't mention which is the tfb timeout thing to get rid of it I haven't seen anyone against so maybe we can just go ahead with it

Alex Stokes: okay uh yeah I haven't looked at this in a little while um yeah uh how about I'll just keep track of this and uh we can discuss either at the end of the call or probably the next call um but yeah I agree that this journal looked like it was uh moving in the right direction to

merge I don't know if anyone else has comments on this right now okay we got to I like it um but yeah this would be I think pretty in scope for uh the Polish of Petra and otherwise if you're listening uh yeah client teams take a look at this PR there's been a good bit of conversation already uh but yeah we I believe we discussed this interrup and yeah it seemed like everyone was on board so just one other thing to keep track of okay thank you uh any puros devet

updates

Barnabas Busa: we are working on it

Alex Stokes: okay great so yeah they're in progress and again yeah it just kind of reflects that uh yeah the it's a little bit earlier than in the development pipeline than some of these other things we have going on uh thanks for that cool so then the next thing on the agenda there was quite a bit to get through today um I think so is it Francis I think Francis uh should be on the call I think they wanted to give presentation oh hey um yeah I'll just hand it over to you I think you have uh want to talk about blob limits

for all right cool do mind not sh my screen that easy yeah

okay um can everybody see

it y yes okay cool thank you um so uh hello everyone my name is Francis I'm from the base team I'm a protocal engineer there and three grad I have this opportunity to talk to you guys about this um so like I think we have a lot of time to discuss about like the potential stability about pure A and pcture B it seems like the consensus alignment right now is that pure a will take the current de3 like ready eips and ship and we will put pure that into Petra B and potentially ship later so our main point here is about like the Rob capacity for like l2s in general and if we are putting P death into the next

hardk which is kind of like 9 to 12 months later then we think that the current capacity uh three Target BL will not be enough for L to to scale in the coming months especially with L to continuously to grow and with base uh we have this scaling plan to increase our like Target uh gas per second from 10 mega gas to like 12 25 Mega gas per second till the end of the year so the point is that uh the capacity might not be enough and uh we would like to recommend a slide modification to the current proposal like in scope for Petra a which is that we integrate a blob number increase into Petra a um so like how do we do that there are

two like ways which is like pretty I I think it's pretty straightforward the first one is like we let's increase the Target and Max for the prop number so we set we can set Target to four and Max to eight and or we can do just a Target increase and keep the max blob number to Six which helps keep the like worst case scenario like in check uh we understand that there are like a lot concerns around the uh Network bands essentially their effects on the solo stakers so we did some like very initial analysis and um and we would like to share it with everybody here so uh regarding the

network bandwidth uh we are like to be to be clear we are using six Target and 12 Max as a like uh for Street purposes and all the number here right now are average Network bandwidths so there's like really good concerns about the peak bandwidths and we can get into that a little bit later but right now uh let's talk about the average so for the past week the C clients uh just for the just P2P data and the EO clients they are using like 400 kilobytes and 140 kilobytes inbounds like data for the past week and for the like outbound data it's around like 660 uh 670 kilobytes in total and we have some data from like expand UPS

teams dashboard that showcases the entire data coming in and out of the like uh container which includes the RPC and B API traffic which you can see is naturally a little bit more than the uh just P2P data but the point here is that like P2P data is kind of like the main uh data in and out of the like Co and EO client so if we are adding like three exra Target blobs uh to the uh Network we are going to have like 50 4 kilobytes of data addition to inbound and this 384 kilobytes of outbound data to uh in addition and if we add them like uh together in total the P2P data in after the blob in cre will be 300 kilobytes

and the total P2P data out will be one megabyte per seconds and this is where I think it's really important to talk about not only average like uh data but also the like Peak use cases or the worth cases so if we say that okay everybody has to disseminate the blobs like within two seconds or like four seconds as the current like spec um defined then we can like in wor cases without any other like change like to like to detailed analysis we can say that okay we can say okay for the block out data it could be like three megabytes per second or like even like if you have to determine then within two

seconds you it could be like six megabytes per second like counting everything into that two second slot so I guess the question here is that is that reasonable enough for SLO stakers uh who are like band bandwidth constraint I did some kind of like really really quick search around the upload upload uh bandwidth across the world it seems like for the like 200s uh country their average upload like uh speed would would be like three something megabytes per second uh per some like uh testing Network testing uh website so this is just like for thoughts but we

believe that if we keep the max in check and only increase the target you'll be like definitely uh reasonable in terms of like a Target blob increase so the second point is like uh for imposing a high minimum price for GR data the current argument is that like the validation are not fairly comp compensated for their compute storage and bandwidth required for providing the data availability and we believe that the problem is definitely legit but addressing them by constraining the da capacity is a step in the wrong direction instead we would suggest that a different approach which is that we can work on something that is uh both

ensures us to have a healthy market for props but also keeps the target blob number unconstrained for L2 to scale and uh that I believe can be AOG to like increasing the BL Targets in this hard and can be worked down in parallel maybe into the next hard or the next one like after that um I believe that is all my uh presentation I'm curious about your guys thoughts on like if you are okay with like going with either of these like choices or if you have any other concerns thank you

Alex Stokes: great thanks yeah it's really nice to see and thanks for putting that together um yeah these are interesting

options and it's something we should discuss uh obviously again the data facility of ethereum is uh one of our most important features uh so it's very important to support it where we can and one way we can do that is think about changing the blob numbers even in pectra um to that I would have have to say I'm going to maintain my earlier position which is just that you know we really should leave Petra as is work on scope freeze and not think about changing anything else um that being said I will just kind of summarize I think what's kind of in the chat in particular like osgar here had a nice message that uh changing the max I think has a lot of

implications um changing just the target is a little more reasonable and is like a much more sort of narrowly scope change uh yeah I think I think that's my take um we lean towards leaving things alone for Petra and then just focus on all the Bob things in the next work after Petra uh I would be open to a Target adjustment anyone else want to chime in

Dankrad Feist: um I wonder if it's worth like what is the progress on uh peer-to-peer improvements like um like it feels

like we there's still a lot of things that we could improve in TP top to reduce these bandwidths and like then it would probably easier to justify increasing uh both Target and Max um is there like is there any update on these things

and

Alex Stokes: uh my sense is that that's kind of been thought about under the sort of work stream of pios so we have the state there which is uh still pretty early any other client teams have you have you looked into this at all I think there's like a basket of different things we

could think about to help the bandwidth consumption

Dankrad Feist: I mean the main thing isn't isn't wasn't that that I don't want discussion where we said like we reduce the peer-to-peer um Factor on blobs especially in order to reduce the bandwidth like that seemed like a very promising Direction so I wonder if that's like are we further on that

Jacek Sieka: uh it's been merged in the LI P2P spec but the LI P2P spec is moving very slowly at these in these days uh Nimbus has an implementation I know Lighthouse was working on one I don't know about others

Dankrad Feist: right

I think both uh liouse and and Pim have the I one implemented already like yeah because the the underlying lip uh both in go and R uh have I what invented already I think

Dankrad Feist: and have we seen improvements from that or not

uh I don't know it has been deoy or not but yeah maybe the C team can can how about

Potuz: I think we haven't shipped it uh so it's for the next release so we can only measure this impact on this in several weeks it takes a lot of time to users to actually update

Dankrad Feist: right but would it be fair to say if we

get like a large saving from saving from this then we can commit like giving that to al2 in the form of a Target and Max increase

Jacek Sieka: so I can just give a random number it's very easy uh we have a dashboard that tracks how much we save and it's on the order of 40 kiloby per second right now uh for I don't want uh on the mainnet Node with you know standard nus settings at least um which may not sound like a lot but it's like compared to those numbers that were Pres it actually isn't nothing

either uh this number will grow with the number of peers that Implement I don't want so it depends on everybody deploying it it's a feature that needs to deploy it

is

Dankrad Feist: is there any client that doesn't like isn't going to implement this in the next few months okay sounds like there isn't

I think there are some but but I don't know which one

Alex Stokes: yeah sounds like it sounds like we we don't know right now

um You your hand out

Potuz: right yeah I had like three unrelated well or somewhat related comments so for the first one you to get a good measurement you don't really need all clients uh you need uh the largest operators that are running essentially prism and Lighthouse to update um and and then we're going to get like statistically relevant uh numbers and I think regarding your comment I think everyone would agree that if we have a good measurement and and we have like a good U experiment that shows that hom stakers are are capable of taking an increase then then I think it's fine we can go for it um although we've been already in situation

in which Builders were sending Target or even under Target number of blobs and home stakers since the ble was full were sending six blobs and hakers were hurt because their band weight was was taken so I think we even measuring this is non-trivial we need to we need to be clear that the average bandwidth is not the right number to look for we have currently when you submit your blog you have less than two seconds to to broadcast to everyone and everyone to validate and consider it available so again I repeat that 7732 is very far in advance and it gives you 12 seconds instead of two so it solves most of

these problems as a no-brainer

Dankrad Feist: right understood um I well right um yeah pre does there's also the other one which is that uh like some clients have implemented that you consider blobs that are the M Pool is available as well like I think that could also be a big Improvement especially for home builders who are only going to consider

mlops Jo to say Francis oh

yeah like I I think all like concerns Mak sense I'm just curious like

if everybody's okay or like open to maybe like just keep the max to be the same so that it it fixes the like worst case scenario for all these s of stakers uh to be the same as currently and we increase the prop Target to a higher number maybe four or five

Dankrad Feist: so I have an additional suggestion I think like what putto mentioned that um uh that the that currently some Builders don't include blobs and then home stakers pick up the slack is an artifact I'm not saying currently yeah yeah but like that is an artifact of blobs having low tips so I would

encourage especially rollup teams to consider uh just right now maybe already increasing their tip size because right now like everyone who includes blobs is essentially already subsidizing blobs because they are not being fairly compensated for the increased offering risk that they're taking um so if we had like sort of like uh some big rollups agree that like it's a good idea to pay say $5 of tips per blob I don't think that comes down to anything significant per transaction but it would probably make a huge difference for the builders on like considering whether they should include blobs

yeah I think this is definitely

like great suggestion and we agree that to have everybody like to have the network fairly compensated for the block space is like something we are okay with so definely we can do that but like to maybe a little bit question about this are we saying that the builders are currently not including blobs as they should

Dankrad Feist: well everyone is free to build their blocks as they like right but some Builders have at least in the past chosen just to not include blobs at all because they said well there's no incentive to because they don't pay any fees

are we talking about uh like flash BS I think previously

so

Potuz: getting out of hand this

was an issue a few months ago and most Builders have fixed this issue flashs was one with the serializing issue that uh is already fixed R sync was another one that was pushing three blobs when the home stakers were pushing six at the time but then they moved into pushing blobs as as they were G itself had a problem in the way that they computed the tips that favors or it doesn't favor some rollups that have more or less execution all of these issues I think are sort of orthogonal to what we're discussing here

yeah

yeah that makes sense um so if you I believe that makes sense and we've

talked with like CR team they fix that and the other things might have been like fixed already like uh down p like or if they haven't they would be probably do it down the pipeline but like as why we said we are definitely okay with like increasing the tips to like include to maybe help with Builders to include that into their blocks so that's Sol takers can take less of the burdens on that

Alex Stokes: right so we are almost at time uh and maybe just to get to some resolution uh for the current topic it does sound like we need

a lot more data I think to understand what a safe sort of modification uh for the blob parameters would be uh especially with alpos uh for scope reasons and again just like General momentum reasons I think we want to touch less rather than more that would kind of motivate thinking about just the Target and separately yeah I think uh there's a lot of work here um especially if we want to roll out gosip sub changes and all this like that's going to take time um yeah so sounds like we should move ahead on those uh separately I don't think we'll necessarily make a final call today and um yeah we'll we'll definitely I think it's very top of mind for everyone so

we'll definitely revisit this uh before Petra hits mainnet okay uh yeah we're pretty much at time uh any closing comments otherwise thank you all for joining that was quite a big call but a very important one so yeah if uh there's nothing else we'll go ahead and wrap up

thanks everyone yeah yeah cool thanks

see you all next time by everyone bye

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