All Core Devs - Consensus #145

Transcript

[Music] J [Applause]

Alex Stokes: okay we should be live there and yeah let's go ahead and get into things so hey everyone this is consensus layer call 145 I'll drop the agenda here in the chat and yeah a number of things for pectra pios and a couple of other questions so let's go ahead and get started uh to begin let's look at pectra devet 4 is there any uh updates there worth going over any open issues or questions we should discuss at the moment

Barnabas Busa: so as of the last week there has been multiple different client fixes for uh

those clients that were missing slots uh in the last weeks and it seems like everyone is able to now propose blocks there are still a few uh questions that we have open but uh everything is uh under discussion

cool no major problems

Alex Stokes: good to hear I guess a related Point uh do we want to discuss the um public devet that we were talking about based off devet 4

Barnabas Busa: yes uh so we were going to announce this uh maybe in the end of the call but

I guess we can already announce it right now so we have launched uh public uh public death net which is going to be a available for everyone to make deposits and exits and consolidations and everything we had Genesis just 3 hours ago and we have a lecture uh getting triggered on it tomorrow on EPO 256 uh client teams can decide if they want to include this as a flag in their clients uh we are writing right now A frequently Asked question documentation where uh going to explain how to run a node on this network but yeah if if any

of the clients are up to adding this as a default uh chain configuration they are welcome but it's going to run approximately three months or till possibly till uh we can Fork may not we'll see uh we we expect it to be shut down by the end of the year so it's it's not like a must have it's it's a nice to have

Alex Stokes: cool yeah

super we have

Barnabas Busa: yeah we have 100,000 validators and uh we have approximately th000 m per client so it's about 100 110 nodes it's a pretty it's a fairly big

Network it's also nice to do some stress tests here and yes this is based on uh Petra 4 spec so it doesn't have 7742 uh requirements yet and uh everything that is running on pure 74 should be also working on this this name test I mean

Alex Stokes: cool and we went with Mong for the name it looks like

Barnabas Busa: yes

cool

Barnabas Busa: so we decided to use this name because the Alternatives had uh some scem coins already running on it so we didn't want to be

that

yeah that's good call yeah

Alex Stokes: uh and you said there'll be like some documentation coming uh for you know the community to engage with it

Barnabas Busa: yes uh we have one that's working in progress right now so I didn't want to link that but uh it's it's coming okay and and we have a a general URL as usual uh to find all the links

Alex Stokes: cool thanks great then yeah sounds like we're good on De 4 uh we can move on anything else no okay cool uh great yeah so we

can move on then to devet 5 sorry

Barnabas Busa: yeah there's one more thing so uh we have been working in the background a bit uh to introduce a new tool that we'll be able to submit deposits and consolidation request kind of like whatpad does but you can actually uh do a bigger deposit now that support more than 32 e and the consolidation request will also be part of this so you will be able to test out uh I can consolate to vators so this is going to help the community to to run a test basically even without needing to run a validator

Alex Stokes: gotcha

cool yeah it'll be really nice to see it all come together

Barnabas Busa: yeah this is still work in progress so we have something maybe by next week

great

Alex Stokes: okay then on to de5 so there are a number of open items here and yeah I think a few of these I think we can get through pretty quickly uh the first one is essentially just a Last Call on PR 3900 we had said a few calls ago that we would Target devet 5 for this and uh yeah there's a little more discussion

after that point but it sounds like at this point it's all been settled and yeah I think everyone is really in agreement to go ahead and merge this so yeah last call and unless someone opposes I think we'll move ahead with this uh we could even merge it after the call today I assume this plus one from Prism is for this PR so yep in that case cool uh and yeah I guess just like one one caveat there is uh to like limit the scope of implementation changes we were focusing on this change sort of just at the networking layer so that you didn't have to go through and change a bunch of other stuff in different layers of the

client uh so just be aware of that cool yeah we got some plus ones so we're good on that great uh next up I did want to bring this uh question up this was refactoring kind of how we do timeouts and like managing peers uh again in the past there was support for this my understanding is that uh we don't necessarily need like even a hard Fork to coordinate this I mean I believe it's backwards compatible uh can someone speak to that point who's a little who's been closer to this PR like especially if it's backwards compatible then I think we're good to go ahead and merge it

now

I think it's backb compatible

Alex Stokes: cool yeah that's my understanding um right okay so then in that case I think we go ahead and also just roll this into down F5 and great uh we have those so next up there are a number of well maybe I'll start here so my understanding is that there is some demand to refactor the requests coming from the execution layer a bit further for Dev net5 and there are some PRS that are tracking that and it cons specs and we go ah and get them uh I think in the

next release or two pretty easily but first I just wanted to do a temperature check um and this is maybe even more question for the Els because I think some of the changes touched the execution layer a bit more um do we have anything to address there do we feel like that change is moving forward well I know Felix was driving a lot of this I'm not sure he's here though

James He: for the execution request I think the big thing is uh just documenting all

of the edge cases the pr itself um and the descriptions uh don't fully document all of the different um thing edge cases that we have to deal with like if we get like a type and then we don't get the list or um checking for uh the max range of the requests like how many you can include for the decoding or if it's empty um or if it's out of order uh th those things should be added somehow especially because

there's no spec test for this

thing

Alex Stokes: right uh so the consensus specs PR that I saw for this did have these checks and it was I think pretty pretty well handled um but yeah it does sound then like things are moving forward um and yeah I guess no one has any questions or points to raise about that at the okay then we'll assume that's moving forward so next up then uh 7742 uh just to remind everyone this is

the EIP to uncouple how we handle the Bob counts between the CL and E and right so this the CIP has been included uh it'll lay the groundwork for us to more easily make changes to the B counts pectra which I think there's plenty of demand to do that uh the question that has come come up in the last week or two uh is that as written 7742 is kind of missing a piece at least potentially missing a piece around changing the base feed calculation so right now uh it's essentially a function of the target blob count and especially if we change the target uh that could have implications for the blob base fee

and how it responds to these changes uh once we started getting into this there's like a number of other questions that came up and I think now we kind of have this question to answer of how invasive do we want to change this like do we sort of aim for sort of a more elegant thing right now or maybe do something a little more practical that is simpler to move forward and think about this work at a later date so I guess I can go ahead and grab this update to the EIP I'll put this here in the chat so there are a couple options here here uh one of them is to basically just do nothing and not worry about how the

target would impact uh the base fee here although even moving to say four and six would have some implications the I think next sort of simplest step would be to just go ahead and update 7742 so that the base fee scales with the target this is what I'd call kind of the quick and dirty solution um I think it would work well for pectra and is like pretty you know it's not like a super invasive change then from there there were some questions around revisiting how we again compute the Bas fee uh so it's kind of tolerance to any Max or Target change and those implications for again sort of like the symmetry of how the base feed scales uh either coming up or coming

down from wherever we're at at the moment so yeah I know let's see I don't know if Tony's on the call I think he should be somewhere um I don't see him but anyway so he had a more uh sort of elaborated take on this and yeah I guess the question for today is just trying to get a sense of like how much we want to do now um I would say the the EIP PR that I linked here what is it 8994 uh that one is like I think a pretty good balance of like you know addressing some of these concerns for pectra uh without being like too much of a big lift so that 7742 comes like very

complicated EIP

gender

Gajinder Singh: yeah hello uh is the audio okay

Alex Stokes: yeah that's great

Gajinder Singh: all right so yes so uh for uh for the Symmetry I mean it's a very small change to include and if we actually want the symmetry of gas changes while going up or down I think we should include it so the main and it wouldn't really make make 742 any more complicated than it already is uh but it will introduce the Max uh blob count to the header because then it would be required to make sure that there is

symmetry and uh yeah I think that's it

Alex Stokes: right and so I think what I linked doesn't have the max right I think that's where we landed on that

Gajinder Singh: yeah we basically right now remove the max and only we have Target blob count uh right now

Alex Stokes: right and then yeah to get to like a sort of more nice solution we would also need the max being sent over so that's a question for cl dos right now and also El doubs whoever's here um yeah do we feel strongly about adding this field to the header passing it through the engine API and all the different places it needs to be

onar

Ansgar Dietrichs: yeah and I just wanted to very briefly explain for people right because this might sound complicated but the idea is very simple right if you only communicate the target to the El then in the calculation you can you basically just don't know how much more room there is between Target and Max and so you basically look at the Target and if the target is say four you just say okay for is the ma four four is basically basically the the the you can have zero blops one blob two blob three blob or four blops so if you have zero blops then basically you want to go down by sell 12% or whatever the the maximum kind of change rate per slot you want to have and that's fine at all but if you don't know the max then you don't know if the if the maximum is eight then then

you're good because then on the upside you also have like this maximum of 12% per per slot that you can change but if the maximum says only six like we had discussed 4 six for example as a potential change then all of a sudden you only have half of that of respons responsiveness to the upside so now you only have 6% of a Max uh increase at Bas fee per slot and that means that now anytime there's a demand spike your reactiveness is half as fast basically you need twice as many slots to react to to to a new base f that you want to get to then you would otherwise so basically communicating the max together with the with the target would allow us to have an an update rule of some sort kind of depends can be simple can can be small change to today can be bigger change um

but it would basically be able to take that into account but if you only communicate The Target just conceptually there's no way of knowing how much room you have between Target and Max

Alex Stokes: right yeah thanks and then onar do you have a sense of oh go ahead

Gajinder Singh: I would just want to add in this basically want to add that you know the upside is uh is basically limited because actually the upside for Max blobs that that that that can be included is also limited I mean it basically reflects that so if if Target and Max uh are are basically not symmetric in the sense that this is just reflecting that and in my eyes I think

this this is just fine uh we should be okay with a little bit of asymmetry but yeah so I mean if this is a really desirable quality to have then definitely we should go for it right

Alex Stokes: I mean I think you know the ideal state is that and so it is desirable but I would kind of bias towards again sort of a good enough solution for pectra and we can always revisit a deeper change to the fee Market uh in faka along with pios so I think we have some room to be flexible here right so okay

I'm yeah I would lean towards moving ahead with uh this 8994 update here uh for 7742 for pectra and delay a more complicated change uh to a later Fork I suppose we can give people um well I don't know I'd like to go ahead and merge this to keep this moving I think what would help is maybe having either like some sort of Speck or EIP for the more complex thing um to have people sort of have something more concrete to like think about but yeah I guess yeah does anyone feel strongly about this or are we happy enough with sort of the uh good enough solution for pectra yeah okay ongar said he would like the

Max and then otherwise yeah okay so then I think we'll directionally move ahead uh with 8994 and yeah ongar maybe I'll follow up with you to see if uh you think we can change something simplest like in a simple way cool so then what that means is yeah I would hope to then have 7742 uh sort of the spike finalized in the next week or two and then yeah as soon as we can get implementations we can start testing this out um yeah I guess we Dev n 5 maybe some early experiments even before then and yeah can keep this all moving cool there was one more thing for

Electra if there's nothing more to say about that for now and I just wanted to get an update uh on the BLS promiles uh this is more of an e concern but we had kind of been discussing there was a question around um effectively the API for the promiles which I think we've kind of resolved and then now the question was uh Downstream of that then doing the gas bench marking to uh make everything work work well uh does anyone here have any updates on that and they may not but I figured I would ask I don't see anyone on the call who has been closer to this so okay that's

fine then we can follow up async so yeah I think that's all we had today for uh Electra anything else anyone wants to bring up

um if

Mikhail Kalinin: if I may just a quick um thing

Alex Stokes: yeah please

Mikhail Kalinin: I have yeah thank you so I have recently submitted a PR um which is the pr number 4,000 just send a link um yeah just basically this PR is about adding a couple of there is a couple of uh checks that we do uh while processing the voluntary exit and uh they for some

reason was not included into consolidation processing and consolidation is basically consists of two steps the first one is to make the L exit and it makes sense um to preserve the same uh condition checks uh for consolidation as we do for exit and uh we were kind of aligned with that but for some reason those two have been missed and this PR just adds them and yeah that's the quick announcement please take a look because basically we want these to be part of Electra

Alex Stokes: yeah that makes a lot of sense

uh so yeah please take a look um I will do the same and yeah just from a quick scam this makes a lot of sense and this is also something we should do and next month or two is just a passing all these things uh Hector has a lot of features they all kind of interact in very intricate ways so yeah making a second pass on all this uh is super valuable okay yeah thanks Mel so then we can move on to pios uh and any blob questions um I just to kick this off I will ask if there's updates on the dev

Nets I heard there was something like 100,000 slot reorg on devet 3 which is impressive

Barnabas Busa: so we had a method yorg like um end of last week I think or beginning of this week I'm not exactly sure when it happened and we decided to shut down dast 3 uh because it was pretty much unfeasible to recover at that point we had only uh prism dating at uh at this point and only I think one teu super node so we decided to uh postpone a relaunch for after uh Defcon because uh everybody wants to focus on rebasing on top of ptra and

that will take some time and we want we would like to discuss whether uh we can include uh P death as Fu named uh future for or or can we stay or should we stay at the using the EIP 75 whatever the numberers I think it's 94

Alex Stokes: yeah yeah uh do you have a sense of just on the on the reorg do you have a sense of like what caused it like did some node eventually release like some data column that triggered this huge Fork Choice

Cascade

Barnabas Busa: uh maybe someone from prison can comment on it I think uh the problem is that the

people that are working on this on the prism side are on holiday right now so okay I'm I'm not sure if uh we would have anyone yeah all good I'm just I'm just curious that might be the deepest

reorg

Alex Stokes: okay cool well yeah so that tees us up to I think the agenda item here which is uh moving ahead with this rebase so uh I don't have the pr handy but there is one to essentially yeah put the pios EIP into Fu and yeah there was a bit of a holding pattern with when implementers were ready to do this and uh the timing

there I think at this point we should just go ahead and make the merge and uh go from there anyone feel that we should hold off for some reason right yeah I think it's 3994 here I looked at the breakout call notes uh from this week and it said that we discussed on this call so my read was that uh basically people were ready to do this

Barnabas Busa: would be nice to get some input we got no input on the the sko so right it

would be nice if people have some opinion

Alex Stokes: yeah I mean the thing is we're going to have to do this eventually so I think if we can't get an opinion then we just bias towards where we're ultimately trying to land which is uh going ahead and putting this on top of Electra

Barnabas Busa: I mean the question isn't whether we want to have it on top of Electra the question is whether we want to trigger it as full

Alex Stokes: what how would like what would sure but what what's the alternative

Barnabas Busa: the alternative is we keep it as EIP 7594 and we trigger it under that name and we only include it in fulu if we are

100% sure that P is going to make it full

right

Alex Stokes: I mean that's generally what we've agreeded via ACD and yeah I don't see how that would be any different moving forward

Barnabas Busa: and also if we activate the at Fu then on the El side that's going to activate Osaka which will also activate eof so it would be good to be able to activate these two features separate in a way so that we don't have

e

Barnabas Busa: problems in peer death networks or peer death problems in E networks

Alex Stokes: right I mean so couldn't on the E couldn't we just set basically unset the E features so that they aren't responsive to Osaka even if like there is Osaka Fork logic

maybe can comment on that

Alex Stokes: ideally I don't know I don't know if they're here um okay yeah I mean to move us forward like again I would lean towards uh moving ahead with all of this having P do be fulu have it activate at fulu and yeah that this is a good point about eof Andor any like Osaka Eeps on the El side so we can definitely discuss this on the next acde um but yeah perhaps in the meantime I'll try to get some async information even in the next week uh and try to move things forward but I guess what I'm hearing at least from lack of

input is that there's no opposition to moving ahead on the seal uh in this direction okay then we'll move on to the next agenda item uh let's see so I think we had yeah Lucas I don't know if he's here but he has an EIP for uh changing withdrawal credentials I don't know if uh lucus is on the call uh but it's here so yeah I think the idea is essentially to have um another type of like execution change

message uh that would let you change your withdrawal credentials we've discussed this stuff in the past and I think generally the sort of consensus has been like uh handle this within the execution layer so you know have some withdraw address that then points to you know a multisig or whatever smart contract where you then have the flexibility to like manage that policy there um but yeah I guess let me grab the link to this and I guess the ask for the moment is just to take a look uh he did say in this comment that basically um he's just looking for feedback and it's very likely to be uh something in future but if you're interested about

this you could go ahead and put it on your radar

uh pus

Alex Stokes: says it'd be nice to have them on the side okay

cool yeah

Mikhail Kalinin: just a quick comment on that so I this proposal is actually yet another request um that we used to introduce used to have now um part of electr will have the protocol so it should be pretty straightforward thing I guess

Potuz: yeah it is a it is a really trivial change on the CL side as well and I suspect on the El it should be

too y

Mikhail Kalinin: because the complexity will be

handled by the yet another system smart contract um as long as our request design is kind of good for and yeah good for extending it like for from the Y perspective and yeah

Alex Stokes: yeah got you yeah that makes sense cool well that was pretty much it on the agenda is there anything else uh that anyone would like to bring up

yeah yanis uh hello it's Janis from Pro

um one issue that relates to the blob scaling uh part uh as you might know at Pro blob we're crawling the um consensus layer Network and then using that information we uh we have put together a tool that is probing basically all the different nodes to see what bandwidth availability they have uh so that might be we're going to have results soon but that could uh be helpful to see you know what is the ideal blob increase that should be targeted for uh for the next upgrade or perhaps the one after that if we're too late to have that um again I don't we don't have results right now so

I cannot share anything but uh hopefully next week and before the before Devon we're going to have something so could be some uh topic to be discussed there

Alex Stokes: great uh so you're crawling dis 35 this link here is to dis be five and then I'd just be curious like are you looking at latencies or trying to infer bandwidth or something else

sorry that uh yeah the the infrastructure bandwidth yeah

Alex Stokes: okay gotcha cool well yeah we'll be looking forward to uh the results there

um yeah I guess there's not going to be a call in two weeks but uh at some point uh in the Devon week we could discuss about that relevant

meetings

Alex Stokes: sounds good

thank you

Alex Stokes: anything else

yeah very quickly I missed my turn that plate but I think you mentioned it already I just wanted to put it here in the chat and so that it's um that everyone knows about it it's basically um I quickly drafted it as an EAP but I think we we could add it to 7742 but we decided we wanted to keep it as simple as possible this is fine it's just a a change that would allow us to move away from the um from having the target um of the

blops always Beal of the max so kind of if you want to do um 4 six instead of 36 then what we might end up with is some asymmetry when it comes to blob Bas fee scaling because currently the blob Bas fee can scale um 12.5% in both directions and I just wanted to yeah paste that EAP or this draft into the chat so that everyone can see it

Alex Stokes: thank you uh yeah we we covered this a bit earlier and we kind of decided to move ahead with the simpler thing for pectra but I think uh sort of more you know uh complex revisiting of this uh in fusaka is definitely in

bounds

yeah this is this is fine I I'm fine with that

Alex Stokes: okay well uh if there's nothing else we can wrap a bit early uh I guess two things to note then one of them is that yes the call what is it on the 14th uh so essentially the next ACDC uh we're going to cancel everyone will most of us will be in Devcon uh so we'll have plenty of conversations there and otherwise yeah if you're listening uh we do have the

launch of this uh test net Mong that is sort of a preview of Petra that's open to the public and yeah be on the lookout for that and yeah I think that's it so we can go ahead and wrap up bit a bit early today uh right blog post post

Barnabas Busa: yep

Alex Stokes: yeah the blog post for Mong will be coming next week so keep an eye out for otherwise yeah we'll go ahead and close and yeah I'll see a lot of you at

devcom very excited see you see you thank you bye bye bye everyone you

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