All Core Devs - Consensus #139

Transcript

for [Music] Jes

h [Applause]

Alex Stokes: okay cool I believe we are live let me

grab the agenda let's see there we go uh he everyone welcome to consens oh wait that's the wrong link that is the first item on the agenda okay cool um um there's the right link so this is consus layer call 139 I put the agenda in the chat here uh it's PM issue 1116 and yeah looks like we have quite a number of things to get through today so let's get

started uh first up Electra and I think sh is a few minutes behind uh but she wanted to call out that there's a PR for a new spect release Alpha 4 uh let's see that was the link that I put in the chat just above there so yeah generally just an FYI there's a few things from the last release nothing too major uh but yeah that should be release soon so next up we can look at uh the dev Nets so we have devet 2 now uh let's see maybe pario Barnabas if you could give us an overview of DEET 2 it looks

like it's been going pretty well

Barnabas Busa: yeah sure uh so in the past few days we've been working on trying to get the chain to finalize uh yesterday we managed to get over 85% participation and uh Ving correctly currently we still have a few uh execution client box but I think most of the consensus later clients are able to propose properly we just did a quick non-f finality test and uh we found a uh smaller issue on prison when we try to come back but uh I think they can give an update on

that everything else seems pretty okay and all the issues have been reported for the appropriate

kind things

Alex Stokes: okay awesome are there particular like El eips that causing issues or is it kind of just a mix of things

Barnabas Busa: could you please repeat that

Alex Stokes: yeah you said there were some e issues with the devnet I was just wondering if there were like was it a particular EIP or was it more just a mix of different things across the clients

Barnabas Busa: uh so eum JF is just having a general part time keeping up to the chain and everyon uh had some block building issues that they're working on

I'm not sure if anyone from ejs or Aron are here to give us an update

Gajinder Singh: yeah on ethereum GS um basically whenever the blocks will be full it will start lagging but yeah apart from that uh as I inspected Lighthouse etherum JS and it sort of uh was Sy to the head so I didn't inspect other nodes with the grandine I think there is an issue of optimistic sync because um when etherum JS is trying to pull optimistic sync blocks basically grandine is forcing

ethereum JS to optimistic sync uh even when starting from Genesis I think it jumps the blocks or some somehow forces its optimistic sync and when when etherum JS is pulling uh the blocks from other El uh e clients uh using eot uh so it is it is it is throwing an error that it the block bodies they don't have request bytes which is basically uh something the other clients might need to rectify or they might have forgotten adding block bites uh request bites to the block body so I guess this is something that El clients might need

to fix

yeah

yeah um just wanted to briefly um say what happened on prism since we were mentioned so it was just that uh we didn't we forgot to update validation on uh Aggregates for Electra it was it is related to the attestation EIP so we were losing peers uh on the minimal configuration because pres thought that the committee index is incorrect and The

Valor does not belong to the to the committee and so it uh it down downrated uh peers and we started losing the mental lecture so but the fix is already uh in a PR and it will be merged today

cool per uh yeah

Parithosh Jayanthi: so just to add as another issue that I've posted in the lighthouse note threat on um on Discord so I tried a curosis dnet with just Lighthouse and teu and when I submitted a consolidation Lighthouse seems to complain that there's a missing field of source Pub Key from bezu and then it fails to

propose um this fixes itself once another client has proposed a block so it feels like bezu or yeah I think one of them is not communicating properly uh likely bzu uh yeah it would be great if someone could have a look at that cool and we can also slowly talk about devet 3 because I also noticed Casey's message and I agree that we should probably coordinate a bit better on these calls as to when we do devnet relaunches CU I think we have everything we kind of want from devet 2 uh the main thing is if 7702 feels ready then we can

start talking about

103

Alex Stokes: right yeah that was my next question so it sounds like there's some debugging on DNA 2 um generally we feel like the non-f finality experiment went well it sounds like other than maybe some minor issues with prism uh but yeah so assuming that all comes together then I think devet 2 I think will be about as much as we're going to get from there then 3 yeah I think 7702 was the main thing um maybe just for my own knowledge uh is the spec there together is it ready or not yet does anyone know okay yeah we got DEET 3 was two and then

the 7702 last PR um okay I mean I'll assume that basically means it's underway so right so then okay so then sounds like DEET 2 we still have some things to do DEET 3 needs a little more time but you know hopefully that's sounding like in the next few weeks even sooner it be better uh but yeah next few weeks then uh we'll be in a good place for DEET 3 uh anything else on demet 2 that we should discuss now

bar have you discussed the

consolidation issue

Parithosh Jayanthi: uh not yet do you want to bring it up

Gajinder Singh: yeah so basically probably did an experimentation uh on devet two regarding consolidation he uh so uh two times we tried to consolidate one validator into another and uh what really happened was that instead of consolidating the balance uh so basically consolidation asarch went through in the sense that one validator was sort of exited and other validators compound withdrawal credentials change to compounding but the balance was not Consolidated uh what

really happened was that the source validators balance was sort of withdrawn and uh the reason for that was that there was a one of work for which uh mik raised a PR uh so in process pending consolidations as well as in process uh deposits uh so there there was a oneof uh in the in the epoch calculation uh that is used because if you use uh get current EPO of the state it will it will not come to the it will not it will be one less than uh the epoch transition for the epoch for which you are running uh so that sort of fixes uh so comparing

it to the next EPO sort of fixes the issue and the pr is merged and I think in the next devet uh we will try consolidations again where the behavior should be correct

Alex Stokes: right yeah nice find on that one um I don't know I'll check with Shia I don't know if that will go into Alpha Four but that would then suggest it we'll go into an alpha 5 and I think it makes a l of sense for DEET 3 to have that included uh so yeah we'll be sure to get that taken care care of so there's some chat here around devet coordination testing timing uh

let's touch on this so right I mean maybe a good place to start is just uh Barnabas comment here around a testing call um I know we all have plenty of calls already uh do we feel like a breakout for the thing would be helpful or do we want to try to coordinate more async

Parithosh Jayanthi: I think in the past the breakout had been helpful we can also keep it really short instead of a 1 hour break off breakout we can just keep it 15 minutes or half an hour if

required

Alex Stokes: right and like maybe we could just do them one off like just for DEET launches rather than like a standing call

Barnabas Busa: I think standing call is better because we always every week we will have something different especially when we have uh continuous Dev Nets and we're going to have uh P death Dev Nets we're going to have e have Dev Nets we're going to have Vectra Dev Nets so there will be a bunch of topics to discuss

Alex Stokes: yeah makes sense uh let's see should we just use the same time from the previous testing call

Barnabas Busa: that was Monday 4 p.m. I think

Alex Stokes: yeah something like

that okay I mean it sounds like it would be helpful especially as we get closer to shipping Petra so I think that's probably a good idea I just ask why not use the first of these calls I mean yeah but so yeah pus is suggesting like just using now basically but it seems like even in addition to this there's space for more fine grain discussion um so I think it makes sense again the call is optional but it'll be a dedicated time for people to talk about exactly this and hopefully it will smooth the whole DEET process cool any other comments on devnet 2 or

Dev Nets uh next up we have essentially some other things that will go into some dnut uh but just around processing things any closing comments okay so let's see if I have all my numbers right I think the idea was for debet 3 we would include uh this change engine get blobs to V1 let me grab a link um so yeah basically the idea here is like we could save on a lot of

bandwidth with blob propagation if a node has a way to essentially check their M pole first and I think this makes a lot of sense right like presumably blobs are in the M Poole and you kind of already have this propagation process uh just via the mol and yeah this essentially provides a way to um avoid needing to fetch data twice uh L did you have a comment on this

Łukasz Rozmej: uh yeah I put the comment in the pr today but the comment is that uh Els as far as I know at least NE mind and I think we looked into ref implementation keep the data by transaction hashes so um not by blob version hashes

and the question is does CL have this data and can request this by transaction hashes or at least add transaction hashes to the request it would be very straightforward for us to implement it if it will request by blob version hashes we either need to iterate through all transaction pool or need to build a separate index uh to keep the data in this way which is uh adding a bit of complexity so the question is does CL have transaction hashes too that can request by it

Alex Stokes: right uh let me go

check yeah so put says transactions are Rob byes so there might be a way to recompute them uh I'd have to go check the pr to see what they proposed but doing it by commitment is what makes the most sense so I see the issue here

Łukasz Rozmej: so if not it's like it's it's still doable it's not like it's a deal breaker it's just a difference between a bit more work and something really really or or per worse not suboptimal performance which still might be good enough uh but if the transaction hashes were available it would be extremely strict forward for us to

implement

Alex Stokes: right do any s clients care to comment

I we it is

Potuz: it's going to be hard to break that invariant that we don't need to interpret anything inside of the payload particularly transactions are just Rob bites for us so one way out of getting the El to do this is for us to request the transaction hashes for a given payload uh and then they y giv this back to us but I think this probably is harder I mean doing this in two Communications is probably harder than just asking the to keep this map

Alex Stokes: yeah that'd be my intuition as well

that essentially just having this index on the E is the simplest way forward even though it is a little bit more there

Łukasz Rozmej: okay just wanted to uh you know ask if this is possible and if not that's fine too

Alex Stokes: cool thanks so okay that was good and related to this was a clarification to the P2P spec uh I also dropped this PR in the chat here it's 3864 and generally this makes sense along with the other change um yeah take a look there's been some review and yeah

I think the next step would be to get both of these merged and then they can go into DEET 3 uh let's see I don't think enrio is here but yeah has anyone had a chance to look uh anything they' like to discuss about these two PRS at the moment Okay cool so yeah just uh be aware the intent would be to get these into demet 3 so take a look and we'll get them merch surely let's see I lost the agenda here

we go cool so next up uh we had a request to discuss implex uh so Lighthouse has been working for quite some time on deprecating implex generally uh I don't think well I think there's a number of issues with it um but yeah so AG was asking for essentially timelines in the past we've generally agreed to go ahead with deprecation but it's the sort of thing where clients need to put some alternative the Alternatives aren't quite baked uh so yeah he wanted to discuss General status there as far as I've seen so far uh techu was saying that this essentially have progress on this

alternative yamix but it's not quite ready uh any other clients have an update on implex deprecation do you feel like you could are you ready already uh do you feel like you need more time or any thoughts on timeline

Phil Ngo: so I can speak for load star here we um have started testing yamok on our side um we noticed that we have a lot of um uh performance gains with yamuk but that's only with yamuk on its own and when we enable that with mlex um the combined overhead gives us issues so you know we're kind of ready to switch over

to YX at any time but we prefer to just you know switch off implex and go right to YX but we also don't want to cut off our other peers so that's kind of our status at

load star

Alex Stokes: gotcha yeah I mean that kind of implies then that we well yeah that one's tricky because it almost implies we just want to switch to hard Fork uh if there's going to be issues like this for everyone around performance

Potuz: yeah I think means that there's going to be some time to switch off not that it needs to be coordinated or

Fork

Phil Ngo: yeah this just in our case specifically it's just when we have both mlex and yamuk enabled um we we get a lot of churn and are not a very good Pier with uh with both of them enabled so our preference is just whenever people are ready to just kind of go over

YX

yeah I'm not sure about the state of nimbus I know prism's fine so if teu can support both at once then it should be fine fine just swap over I imagine I unless we do it at a hard Fork there's always going to be old nodes

that haven't updated though

well can can't Lighthouse um sorry

Potuz: can't load star just add a flag and you just pick one or the other one and then your load star nodes are going to be only peered with some subset of the network at least until we deprecate templates

Alex Stokes: I mean one issue there is like if everyone switches to YX and then load star is still on implex and they just kind of thre themselves off the network

Phil Ngo: that could be an

option

do

does anyone know where Nimbus is with this

Barnabas Busa: we have it implemented I'm not sure how well it is tested compared to amplex but um if Dustin is on the call I'm not sure uh I don't see him today but uh I could ask him

okay awesome it just means I just Chase up teu and then and then we're all good

Alex Stokes: okay great so yeah follow up with teu and then yeah maybe in another month or two uh we can revisit this on SE call okay any closing implex

discussion otherwise we will go to the ssz

eips

Alex Stokes: okay um right so Eton wanted to discuss inclusion of VIP 7688 which is the stable container EIP uh let's see I don't knowon do you have any uh quick update you'd like to give around this um before we move on to discussing inclusion

uh sure

Etan Kissling: um last time it was mostly this uh DEET 2 instabilities that we wanted to resolve before discussing extending scope which which makes sense

um now from today it seems that those issues have been fixed and that devet 2 is stable so the remaining question now is if we could include the 7688 stable container without risking Pier do getting out of hands um at least in Nimbus it's not the same people who work on those features so from our side it would be fine but I would like to also ask the others for opinion and that would be for denet three like the one in a couple weeks not like something that needs to be rushed out on the implementation side um kiom has started on Zig ssse

implementation um I also saw that uh Casey asked something about testing in the chat so I guess that he's in he's continuing progress as well on the go implementation um rust is also still incomplete as I know but uh yeah there's a definite on the stability now that box if you scroll down to the left there is a c Tois config yeah that's essentially the update and yeah what would like to ask about d three inclusion of this feature

Alex Stokes: right and just to clarify I wouldn't I mean it is it could go to

some devet but I think the bigger question is do we put it in to pectra

Etan Kissling: um exactly yeah

Alex Stokes: right and I mean again just to make the point again and again pectra is already massive uh but yeah do any clients here have a have a sense on this um how are we thinking about it

uh I'll talk for prison real quick that um I have merization um passing tests uh with our new code generator um so there's a lot of steps for us to switch over to that new code generator so um whether it's able to land in a devet in

two weeks is a little a little iffy just on the timeline um but I think we're we're positive on um uh inclusion overall um yeah

Alex Stokes: right so again before this kind of gets away from us like I'll Echo what per saying in the chat like it would be devnet 5 or later uh before I think we'd even see this on a devnet so the question is not so much like oh do we rush this feature like now it's more just like does this Stack Up along with everything else um and again I would strongly urge you to consider the size of

Petra

Sean Anderson: um yeah for life we have a solid

implementation of this um and something I guess unique to the SSC changes versus other changes is that like as we add the um as we upgrade this in the spec we'll get all the ssse tests updated um so we'll be able to like regression test a lot of stuff um so it could be relatively well tested as far as like a um a that change um yeah I I sounded like people from Lighthouse generally supported it

Alex Stokes: um right but there's like support now versus like in the next hard Fork you

know like there's like yes I think we all agree that the features are beneficial but then it's very much a question of like scheduling and then like the testing load across devops and the different testing teams the testing that each of the client teams do individually and all this stuff

Sean Anderson: yeah so there's a timing component thing um that's yeah I I think on some level that's who needs to use this feature and how big of a deal is it for to use this fature by Petra or like a year plus later so yeah and I I feel like I haven't really heard much feedback about that but

yeah so I have been speaking to some people I saw that rocker pool had a thread and and that's been posted I also spoke to aan lay and and their opinion is that um with some of these hard Forks we're actually changing core things in the protocol so they have to update their proofs anyway so stable containers isn't really a like a massive thing for them to have they have to change the proofs anyway essentially

Potuz: yeah I want to say two things but one of them is what Adrian just said uh one is that there's been two arguments that I've seen one from Sean from Lighthouse about having a prescribed overhead to

fors uh which is true we have a finite amount of time that it's added to every fork in testing and getting it and shipping uh but on the other hand there's this is offset by the exponential amount of time that testing grows with adding new features because you need to test every single combination of them and this is exponential uh so I would urge next time we already screwed up this port by adding indiscriminately many many features that we shouldn't have ADD uh to keep this exponential growth in mind as for this particular one uh I mean again I I'm I'm definitely biased in that I I'm pushing for a change like PBS

but any such change will change will not be contemplated by stable containers we will change all of the G indices uh as soon as we move a payload outside uh and it's it's hard to believe that we're not going to be making changes in the protocol that are not going to be contemplated by stable containers so I I sincerely doubt of the impact on contracts for stable containers I can certainly see that some contracts might might be saved from changing but I can also see how rocket pool might need to change their contracts anyways

Alex Stokes: right and yeah I mean to add to

this I would just probably Echo what Tim saying in the chat here that essentially you know let's focus on getting the current Petra set working well a devet that's going super smooth from Genesis uh before really opening the scope discussion further so can we agree to that

Etan Kissling: uh from my point uh it makes sense yeah like to delay it until the rest is more stable um with the caveat that we should um have a time at least where we definitely agree on like we we cannot

indefinitely delay the decision right

well

Alex Stokes: we should I mean it could be a thing where you know it might take you know a hard fork or two um but that's like yeah different different conversation yeah

Etan Kissling: like what says that we should um have another should bring up bring it up one more time before definit 5 because that's the earliest one where it could go in right

Alex Stokes: sure yeah and I mean again like yeah that sounds good okay cool anything else

there otherwise we'll move to

P do

Alex Stokes: okay thanks uh so puros uh first I'm curious if there are any development updates last time we touched on this I think people were more in sort of engineering mode and just doing some more groundwork um for the changes Peri off Springs generally there was also a bit of a complication with targeting denb versus Electra and then integrating the peros work into Electra given Electra still kind of a Target so yeah I expect there hasn't been too much here uh but does anyone have anything they'd like to

share

I can quickly share the update for prism during the last two weeks um yeah we implemented the metadata vory um so basically um if you want to know what are the colums your your peer uh custody you need to read cust subnet count in in the eum not record but unfortunately this not record is always only available for your outbound Pierce and so it's an issue and so lion did a specification change where as the C sub cons is also in the Met metadata which is called metadata V3 and so we Implement in

it um yeah we also work about some tricks on data C sampling on initial things and we are right now working on the blob side car um Bon API yeah basically for blobs before p is quite simple to to to reply to this uh API request because you just have to to read The Blob in your database in your store but with data columns you have to convert data columns to blobs and you you may have to also to reconstruct all the data columns if you don't uh custody them all um and yeah also we we work on the our data colon verification

pipeline this is for our updates during the last two weeks on prism

Alex Stokes: cool thanks

Gajinder Singh: so unless you are of uh full Note customing Everything You won't anyway be able to reply to blob site car request so I think blob site car Quest should be deated anyway

uh yeah actually um it's not not really because um so of course if you are if you are super no you are able to respond to this request but if you are not a super not but if you custody at least the half of the columns so you are able to reconstruct the all

the columns from from the half it is a principle of for construction and then you can transform col to bloves and I don't think we should decate at all because um a lot of application and among other Layer Two really need this API endpoint uh for an nextal application is I guess it's the only way this this um API endpoint is the only way to to retrieve the blobs actually

Gajinder Singh: but if CL node doesn't have any full blobs or does not has 50% of the column so it can't reconstruct any uh how will it sort of respond to the

request and then there is question of PS always penalizing you if you are not uh properly responding

um so um here I'm talking about the the Bon API so um so there is no really question of penalizing a pier because as a pier you you you expose the number of you as a p you expose yes cols you you should custody and so here the question is is not here yes you should always custody the colons you you you advertise um but for your question what about if a node is not able to is not

coding enough colons um and in this case what happens if uh this API this beon API call is is uh is done just um as far as for for prism uh what we do um you can force the node to custody all the colums by enabling the flags the flag um um bying the the all subet SL you have a flag which is called the uh yes um uh something like uh get all the subnets and if you enable the flag so you will have all the columns and uh if a user uh use this beon API call and is

not able to get all the columns because the N doesn't have all the columns in the error we advertise the user that he should enable this flag on beon not start

Gajinder Singh: all right so we can still deprecate uh the request response and points right

um I don't think we should but because if weate this blob side car endpoint we will break a lot of application

so I think talking about the

Alex Stokes: like the gossip RPC separate from the beacon API

here I'm talking about the Bon API yes only the beon API

Gajinder Singh: yeah so that that is fine and as Alex mentioned was talking more about the request response and

Alex Stokes: right so yeah I I think you're correct gender that would make sense it sounds like this is a topic for perod breakout uh separately also equ in the chat we

definitely need some way to get blobs um if a node has them so the beacon API should stay I guess there there's a question then like how does a node respond if they don't have all the blob data yes so if a not doesn't have all the BL data

so basically all the columns and as I said either you can reconstruct so in this case you reconstruct and then you you you respond to the API to the API call and if you cannot respons because you have not enough data in your store because Bas basically you don't cust have data you just return 44 from just return an error and in prism we

advertise the user that he could get all the data if if he enables the subscribe to Al net flag on the on the on the beon Node start

Alex Stokes: all right yeah no that makes sense uh is that in the beacon apis or is it planned to be soon

um so the advertis mod is just um just in the response when we respond with an error in in the error message we just add please please enable the subscribe to upet to subnet flag that's all we do but maybe we should add this as a

requirement is the in the Bon API as well

Alex Stokes: yeah no that makes sense okay cool yeah case you had a suggestion to use resource unavailable here um yeah that makes sense okay uh so next uh we had discussed last time about dropping sampling essentially to ship pios more quickly uh it would cut a lot of complexity and Franchesco was kind enough to make a PR that would demo this

so yeah like zooming out a bit with pios in general like there will at least be another devet I would assume if not several uh before we even think about merging this into pectra and this is definitely an option here if we think it will simplify development uh of these Dev Nets in parallel to drop samp Lane uh have clients had a chance to think about this more uh maybe even look at the pr and do they have any any sense of uh which direction we should go in

Gajinder Singh: also B what we discussed in appear as breakout call was yes uh so for

currently we will for Focus towards uh not doing sampling and the clients which are doing sampling they can still do sampling but they will not penalize the peers if the sampling fails and they they will just log it so it will be just for the information purposes uh and we will we decided that we will uh think about inclusion of sampling at later demets uh because the priority right now would be to get a uh functional defet that hasn't happened till now uh in that sense that uh it has stayed up and has not foged and uh and the new Nords Would

S so that manner we the priori is was to get a stable

DEET

Alex Stokes: yeah that makes sense um right and it seems like it's simple enough just to essentially ignore sampling like I don't think there'll be a ton of code thrash to make this decis now and then just enable it later so that generally makes sense um I'm not able to make the peros breakout calls but uh yeah I'm not sure if people have been talking about devet timing there does anyone know who's been able to make those calls

Gajinder Singh: I think yeah BOS could update us I think we want the next dite to happen uh

soon with uh without sampling and uh uh with the metadata PR changes uh but there is also another PR which uh sorts of uh uh uh sorts of uh separates out uh the custody groups then from subnets and I'm not sure whether we want to include that PR as well in the next devet but I think we should because uh we should try to make sure sure that we uh we do Dev Nets as close as to the architecture that we intend in uh intend to go live with so maybe Barabas can give us more

information on this

Barnabas Busa: I think the general idea was to try to launch another DEET as soon as possible with alha four spec so whatever is going to make get into alha for that's what we were going to launch with but uh I think we we can discuss that in the next period disc call what exactly we include

Alex Stokes: okay and I think the two things were this metad change which I think is an alpha for already the other thing would be this uh PR from Franchesco so that would probably take a little bit more time uh but yeah so that sounds good uh get to either specs relase 4 or five with a peros Target and then that

will be the next peros de net and it will happen when it's ready okay anything else on pios otherwise we'll move to some more open research oh yes barav had this comment yeah yeah

Barnabas Busa: I had one more question regarding the uh how how can we uncouple the blit from

and yeah right yeah

Alex Stokes: so I had this PR to do this and yeah I think there were some a few things that needed to be addressed

which I haven't had time to do yet um right I mean I think the way I kind of see this shaking up is this would come later but was also yeah I I guess I'd want to see a little more progress on pios uh before feel a lot of urgency here I don't know if anyone else feels more strongly

Barnabas Busa: I feel like this would need to be included regardless whether P death makes it in or not because we going to need to have a way to update the number of blobs whether we have P death or not

Alex Stokes: right and this PR I think just makes it simpler um and easier to think about we could still in pectra with no other

changes increase the blob count just in the way we did essentially for DB so and that's kind of what I'm saying like this is nice to have um but I don't feel a ton of urgency at the moment

wait

Dankrad Feist: but I mean like isn't the whole point that in case that we will be able to like upgrade it separately

Alex Stokes: well like ideally but I'm just saying like worst case we just have the constant set in flers and we just update them regularly like this

updating well in practice it will

because like if we say oh p is ready two months after Tetra it's very unlikely that we other where if you can do it as a c only

Alex Stokes: right okay well in any case uh yeah I will Circle back to this and get it ready and yeah hopefully by the next sale call we can be in a place to uh discuss in depth around inclusion and yeah there's generally support in the chat so uh great anything else on

pios

okay

Alex Stokes: let's see so next up we had a question from Eton around the interaction between consolidations and the Sy committee uhon would you like to give us an overview of the question

Etan Kissling: yeah um from how I understand the consolidations the way how it works is that it transfers the balance from one validator to another but um it could be that there are still like the source validator could still have open sync committee duties that last all the way into the next period like up to two days in the worst case like 27

hours plus one Epoch less than 27 hours I guess is the worst one um I wonder if that is something that needs to be addressed I think at the very least it should be explicitly thought about uh whether such a consolidation should be delayed until the source validator no longer has active duties um the duties themselves at this time are not slash like the S committee do this but uh yeah I don't know like it we we cannot just ignore the consolidation because because it comes from the El as well so it is not like uh if it doesn't

work just retry it a day after um because there is an El transaction that needs to be made and when it succeeds I guess the consolidation is expected to eventually go through and I I think exits have a similar issue but

Alex Stokes: uh yeah they do

Etan Kissling: yeah but but for exits at least the balance is no longer in play maybe there are also I don't know like oh yeah

it's still

Alex Stokes: it's still flashable so so yeah I mean I agree we should think about this my gut would say just to leave it as is like there is this similar Quirk with exits where you can still be in the same committee even

after you've exited so for this I would say to keep it the same just because it's going to complicate things to like have like pending consolidations like in this sense and yeah do all the accounting um I don't know if anyone else sees an immediate issue here with approach like yeah I mean so I guess to make it more concrete like leave it as is and probably just have a note somewhere like hey by the way this could happen just so implementers are aware

Etan Kissling: yeah I think that that would make sense as well just to have it explicit and not

be an oversight because it's an interesting interaction

right

Alex Stokes: yeah I agree nice find okay cool uh I can work on a PR just to call it out Mark ssz and that's probably a good place to continue the thread here let's see so next up uh we had this PR to add quick uh to the enr let's see so pop raise the point I

don't know if he's on the call yeah oh hey yes

I am H yeah uh the pr is about adding

a quick entry into the enr uh uh what I think uh uh I wish to to to to to to have uh quick as a as an optional transport protocol like yeah uh currently we uh currently we try we try to use uh Yas right but but if if if if you support quick I think it's better to use quick instead yeah so uh this Pi is just about adding the enr so that the enr in so that you know that okay this

note is uh this not support yeah

Alex Stokes: right so yeah in general I think this is something we want eventually I think at the moment only Lighthouse supports quick please correct me if I'm wrong okay nice um right so yeah I guess this is the thing where it's optional in a sense like you can add it if you want um right so then I guess pops point was just uh I guess merging in the pr just to make it more formal um anyone feel we should not do that

yeah just just to to reply to Barnabas who said L already had quick in

the it's that's right um but yes it's not in the specification and that's why I I wrote the specification just to be sure that every new clients uh which want to add this quick support use the same uh enr entry actually um Lighthouse use this exact quick node record entry and I just copy copied what what Lighthouse used to do

Alex Stokes: yeah makes sense and yeah I mean I think there's a question of the actual identifier I think what we have the qic works cman has a question do we need a

separate entry for the V4 and V6 quick ports

yeah we have Quicks we have quick six um but I was just looking at the specs like in the specs we only have UDP and TCP but I think there's TCP 6 and udp6 so maybe there's a separate PR for IPv6 support but Lighthouse uses quick and quick six for the en fields

Alex Stokes: is that in this PR do you know the quick six

no it's not it's not in this PR but we probably need to also add tcp6 and you do P6 if we're going to do ip6 support

but there is only uh there is

only an ip6 field in the enr right so why do we need like tcp6 and quick six like because you you just look at the

ip6 Mt

yeah but if if you have dual stack where you have ipv4 and ip6 you can have different ports for different sockets so then there's there's ambiguity there

got it

Alex Stokes: do we feel like we want to add the V6 identifiers

I think we should do it in a new PR yeah

I can add it in in this this P

request it's okay why why do we need to to do it in a new P request

Alex Stokes: one argument is it be simpler just toerge in the quick thing I think we've been working on this for a little while and then otherwise yeah yeah I might just add leny if there's back and forth on the V6 part okay I think it also works in the same PR so yeah I think

whoever is writing this can decide

okay so um it's okay for me to add a quick six as well in this this PR request I'm the author of this PR request just to we have a thumbs up cool

Alex Stokes: thank you and okay last on the agenda we had um a request from prob lab they'd like to share some of the work they've been doing around dis V5 and

some network analysis let's see is someone let's see yeah yeah hey

Guillaume Michel: hi this is G from probab so yeah I'd like to present what we've been working on with respect to monitoring the consensus layer Network especially the dcv5 DHT um we've also done some work on the gossip set part but Mikel will be presenting this work probably during the next go or the one after so what we've been doing is we've been running a crawler that's basically getting a snapshot of the dp5 DHT um every 30 minutes so just enumerating all the peers and

trying to connect to them so try to open a l2p connection but also sending so dc5 pure UDP request um to learn about the full routing table of every single peers and this way we can just enumerate the whole network get the enr get all the information we put everything in a big database and thank to the lip connection we can also get some extra information from the identified protocols such as the supported protocols um the multi- addresses um so all the multi- addresses that are supported um and so on and from

all of these data that we gather we can do some statistics then on cloud providers on where the nodes are located on the protocol that are supported um and so on so let me quickly share my screen and also send the link here all right so that's the the product that we have and in the end we build weekly report so we create one report for for every week and um we show a lot of data so I will not stop on every single plot there but for instance we

show the the client diversity um just one thing to be clear that's counting the number of Bon nodes and not the number of validators so you might be seeing different numbers from different sources and we're showing the number of node not the number of validators um we so we can see distribution over time we can also see the version distribution um for the user agent so can be helpful to see how your um client is getting adopted um and so using this plot you can see for instance here the last version of

lighthouse has like an adoption rate among the lighthouse nodes of 29% and by the end of the week okay didn't grow much but say if we take um another one here for Lo star we can see that the latest version um has quite some adaption during the last week um and yeah then so we have other numbers and something where so so we don't need to address it now but we have some numbers that would like to flag and then we can take the discussion offline is for instance here here we see

the support protocols for all of the notes we can see that for instance 99.9% support the mesh sub 1.1 protocol which is kind of required and then we can see the breakdown for uh each of the user agents and with all of the supported protocol and we can see for instance for teu that take is only advertising these protocols um at least through identify so I'm not sure whether the other Protocols are also supported but just not advertised um or if they're missing so yeah

um and then maybe one last plot so yes some things we can also do is checking here so we can see the in the distribution per country that here there's a Okay small drop from the number of notes that are hosted in the US and an increase in the notes that are hosted elsewhere and if we look so I think yeah it was um again take notes so so it means that they have been changed from a Us location to elsewhere and when looking at the cloud providers because we know it's Stu nodes

we can see that they've been taken from a data center in the US and that they are now hosted elsewhere not inside the data center um outside of the US in another country so that's how we can use for instance um the stats we're doing and yeah the last thing that I wanted to touch upon is on the number of stale record um the way the this V5 DHT works is um each node is going to keep connection to other nodes so they're going to keep their enrs and then upon request they're going to share it to

each other and it turns out that around a quarter of the record they hold are pointing to peers that um aren responsive so two peers that may be dead or offline and that's not healthy in the network so it means that we didn't do any analysis on which clients um aren pruning the the the records or if it's all of them but it's generally not really healthy because when you use this with if I want to discover new peers you don't want to learn about some peers that are not there anymore and so that's a bit concerning but it's not like a

major red um so yeah if you have questions so we'd love to have feedback and so we plan on adding um a plot on quick showing so which clients support quick and and so on um in the future and if there's anything any other plot that you would want to see or if there's something useful um you wanted to add um feel free to reach out um and yeah or if you think something is wrong it's possible so we've discovered recently that um for instance we weren't able to um to actually count the number

of Lighthouse note that were at um supporting quick um so we retroactive the the the plot but so it's also possible that for instance for the take note we missed something and yeah so I think that's it I'm going to write in the chat the email that you can reach us at and if you have any question

yeah P

Potuz: yeah the question that I asked in the chat I found it strange that Lighthouse is the only one with this uh with this curves reverted where there's more data center nodes

than the non- data center uh yeah so why is this I mean is there any it's striking

yes

Guillaume Michel: so we don't really know why so we basically our methodology here is to gather the IP addresses and then check whether the IP addresses are associated with any known data center or Cloud providers and then we classify it this way whether it's data center or not data center so I guess it depends on striking

I I

Potuz: I can't even think of an explanation

because also this is according to your numbers this is client that you have most data points

Guillaume Michel: yeah that's right but so it means that overall around half of the of the clients are running from a Data Center and half of them not from the data center

Potuz: yeah no so the this the total numbers is not something that strikes me but it does strike me that if you look at Nimbus then essentially every node is on a non data center uh and it's a huge difference prism is also higher not that much higher but it's higher for the non- data center ones and Lighthouse is the only one that has that is connected in data

center so that's why I'm surprised

Guillaume Michel: yeah yeah I mean I I guess the question would be to ask to The Operators of the actual nodes or I mean unless you know them and you're sure that most of the nodes are running from outside the data center and then we can always double check so the sources that we have to map IP addresses to Data Centers there are some other

Alex Stokes: questions

in the chat

Guillaume Michel: yeah I see a question from Adrian what classifies as enrichable in the DHT um so we consider node as unreachable if we cannot open a Le P2P connection nor um send um the UDP dis V5 um yeah packet connection so in this case we consider no no as unreachable if we cannot do either of these

if

if you can do one of them is it reachable

um yes

Guillaume Michel: so the condition if we can reach out the node on P2P it is reachable and if we

cannot but we get but we we can reach the node on UDP and the the error that we get from the lip connection so there is an active error not a timeout and the error is everything but PR ID mismatch um we count it as online so yeah essentially a UDP connection is enough to to be consider as online

okay thanks

Guillaume Michel: and then is this filter by main net yes so it's main net for all of the plots but the stale records one so we

can see so that's the one filtered by main net and this one is global for all of thec5 and for all of the other plots it's filter just for

main net cool

Alex Stokes: yeah generally uh super nice work the charge look really nice I like the the version thing cuz we have this question with hard Fork so like we tell everyone to update but then don't necessarily know if people have updated in time so I could see this being useful for that just watching the data update

you know week by week or maybe even day by day

yeah

Guillaume Michel: also concerning hard Fork um we wrote the blog post here so showing exactly the same data where we can see so nodes leaving the so the cap Network and then joining the neb and some of the nodes that are still remaining in Capal after the hard for and so on so yeah if you want to have a read um just check it in the chat

cool thanks

Alex Stokes: and yeah if there's any feedback uh is this email the right place

team PR

blob.io

Guillaume Michel: cool thanks a lot

Alex Stokes: yeah thanks okay we have a few minutes remaining uh any other closing comments otherwise we can wrap up a little bit early today you

Tom

Etan Kissling: um I have one more thing for the requests like the the validator operation requests and there is this disconnect still between the El which has has this requests list that contains all of deposits withdrawals and consolidation requests and on the CL where we have

these three separate lists in the execution payload so I wonder whether we should put those separate lists into a subc container just so that we have like when we later extended with additional request types that they still conceptually our group together um I have linked it in the chat as well

Alex Stokes: yeah thanks yeah I think both these came up on a pass call um and yeah I'm not sure people have had time to review

Etan Kissling: um the last call was for the engine API and this one is something similar for uh the crl data structure

no

no no

Potuz: last call we discussed them both and and it's important on the CL data structure itself

Etan Kissling: okay

Alex Stokes: right so I mean

actually my

Potuz: my take on this last time we were we were supposed to open that issue we opened it and the idea was that we were going to discuss it there my feeling about this that uh well Misha doesn't like this but everyone else seems to like it but there isn't enough feedback in that issue so at least we should have at least someone from each CL client signaling something in that issue so that we can actually go ahead or not

Alex Stokes: okay so can see all teams take a

look um I'll try to follow up independently with everyone before the next sale call and we can make some progress then

Potuz: so there's something to note this change is is a very simple change perhaps in a code base but but it's it's a pain in well to write the spec PR I'm definitely not writing that spec PR and it's really going to be painful to write that spec PR and changing all the python tests so so it should be done quickly if we're going to move if we're going to move to such a thing

Alex Stokes: got it okay well I'll take a look at these and

I will try to follow up independently with the client teams and yeah let's just try to make some progress here I don't think there's any anything new to add otherwise uh unless you see something else iton or pus okay yeah thanks for bringing this up let's not drop the thread there and otherwise yeah anything else uh let me double check the agenda people like to add comments as we

go okay yeah I think we've cut everything and yeah unless there's anything else going once going twice going three times okay uh then I think we'll go ahead and wrap up thanks everyone see you next time

Potuz: bye everyone

Thanks

so

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