All Core Devs - Consensus #135

Transcript

[Music] time

than [Applause]

oh for okay can someone on Zoom

talk like someone who's not me test hello yeah okay hello is this coming through to the stream I I'm seeing something suggesting that uh like everyone else's audio is not streaming and I have no way to change that let's see uh I'll try okay Christine says yes can someone who's not me just say something again good

morning yeah I don't know we'll just okay we'll go so cool hey everyone this is cons since this

Alex Stokes: layer call 135 I'll grab the issue here for the agenda and we'll just go ahead and get started um so first off there's just a few announcements uh the first one is is about uh curtosis if Barnabas is on the call I think he can give us some more details there I thought I saw him somewhere

Parithosh Jayanthi: uh yeah I

can um so we wanted to just announce that we we're taking a more active maintainer role in the kosis ecosystem SL ethereum package in general and one of the steps is that we've done a migration from uh for the ethereum package itself so it's moving from curosis Tech organization to e panda Ops um you can find the redirect URL uh and a few other instructions on what might break in Twitter or in the kosis Discord but uh if you wish to continue using the old setup you can always clone the last release and continue using that but uh in case you want to keep up with future changes then please update your URLs and uh Target the latest release onwards so

4.0 onwards would be maintained mainly by um e panda Ops

Alex Stokes: okay great uh next up Tim I think had an announcement uh around adding some Nuance to CFI in the IP process uh Tim if you just wanted to give a quick shout out

Tim Beiko: yeah so we discussed this on the last acde but um there was a proposal uh that came out of Kenya that was um to basically improve uh how it Define CFI and also add uh a formal way for the community to propose theps uh to hard forks and then uh just rename included

the scheduled for inclusion before stuff ships because we sometimes remove uh some stuff that's uh been marked as included uh so if people want to yeah review this asnc uh that'd be great and then um hopefully by the next acde in like about a week we can just um yeah move forward with some version of this as official

Alex Stokes: cool thanks uh so next up is Electra and I think the next up that is on everyone's mind is going to be devet one um there's a spec floating around for the El set of eips I don't have that

handy right now uh but we can discuss the CL set of specs and that's generally going to be the alpha 3 release uh so I just dropped a link in the chat here and I think it's uh pretty ready to go shout out to shawe for assembling all of this there was uh one open question I think on uh this e or sorry this PR uh 3768 um before we get into that is there anything else around devet one that people would like to discuss uh as this more like higher level or should we turn to just uh these few open questions for the specs

okay so right let me grab the link let's see it's three yeah this one okay so 3786 this PR is really just changing the layout of the fields uh in the new attestation type that we have and it looks pretty simple um there's some implications just around how ssz works and how these things are laid out um so that was kind of a I think the original motivation was to not break essentially these these indices that come out of the merization um yeah and so this PR suggests moving this field basically to the end uh the way it works is like

appending things is much nicer than putting stuff in the middle in terms of the layouts um yeah so it looks like there's been quite a few approvals on the pr um does anyone have any comments about this um I I think I do at least uh just because we do have this pattern that the signature of a thing comes after everything else and this kind of breaks the pattern so it feels at least aesthetically wrong to me um but yeah no one else is really chimed in otherwise so if there are any comments here um now would be the time to to walk through them otherwise I suppose we can just go

ahead and Merch this yeah

came in

Cayman Nava: yeah I just I just wanted to note um so if we do end up approving like a stable container uh eips that if like in the future like stable containers kind of require us to append only so in this case this is not a stable container this just a normal container but um that's just something to keep in mind that like even if it's something that has a signature kind of by the rules of the EIP that we're setting forward you would we would still be appending in that case

Alex Stokes: okay yeah that's good to know

um yeah anyone else have any feedback on this PR it sounds like I might be in the minority on the field ordering so I will defer to everyone else in that case

Etan Kissling: like uh you mentioned the pattern of signature L um I'm not sure if that's still the case is like uh the way how it's done now is that there is this envelope that has like the payload and the signature and it's just these two things combined and the only thing that keeps changing is the payload right so um it's a bit weird in the attestation because the signature is actually not signing

over all the fields it's only signing over the attestation data but it's not signing over aggregation and comedy bits um so I'm just wondering if this pattern that you mentioned like where is it actually being used like the signature loss

Alex Stokes: like everywhere like is there an ssz type we have where you don't have like a bunch of stuff and then the signature like I don't think there's any like I guess that's my point here is like this would be breaking the pattern and it is arguably just aesthetic so again you know this is not the end of the world uh but it definitely sticks out to

me Casey was asking uh why did we put the signature last originally and I think it was again more just sort of like an aesthetic thing um Justin has a comment typically RP you need to re out the data that is signed over right yeah so yeah you could if you're doing some like streaming ssz thing then yeah you could kind of argue that it's helpful for that um yeah I mean I think it's really just a pattern that we kind of settled on and I also don't think we've broken yet um but yeah that being said I think we should ship def net one so unless there's any other objections uh

we can go ahead and merge this after the call

sorry I don't know how to um raise my hand in Zoom but um I I think this is not something that we can do without breaking things but uh what if we had attestation uh data signature aggregation bits and committee bits that way signature would come after the stuff we are signing and then we'll have the rest of things

it

Etan Kissling: it would also be fine um but uh we should only do that if we adopt

the stable container because right now like um aggregation bits is generalized index four data is five signature is six and commit bits is seven so four five and six um like this PR what it achieves is that four five and six stay the same so aggregation bits is still four data is still five signature is still six um if we adopt a stable container then these indit has break anyway so we can use that as an additional reordering but yeah I mean it would make sense to to put the aggregation bits after the signature because they are not

being signed over anyway

Enrico Del Fante: it's safe to say that we can go for it and then if stable container become real thing we can think about reordering the last time

Etan Kissling: yes like if if we adopt stable container we can reorder everything because like the the P Break

Enrico Del Fante: yeah

Alex Stokes: okay sounds like at least on a call we

uh have support for the PRS is so yeah let's ship it okay I think that was the big thing left on the specs release is there anything else uh that we should discuss right now otherwise the plan I think is to get ear out later today or tomorrow um and have that be done that one I think there was something in the chat okay per link something here in the

execution apis let's see okay maybe can someone from the e speak to e consolidations being ready to go PR that one no one knows I think that Mikel

is yeah either Mikel or like CL working on that and I think they're both out this week so um okay we can follow up on that one uh after the call and otherwise yeah I think we are in a good place uh for Dev net one with C specs uh next up I wanted to touch on timing uh if any CL team is here have you started implementation on uh this release uh do you have any sense of like denet one timing I think it'd be helpful for everyone to kind of start coordinating on what time uh we could see the de up

Enrico Del Fante: yeah I caness speak for Te we are okay we are waiting for the

attestation field to the end to be merged but we have the pr already prepared and ready for merge and uh the other thing that we are waiting for is this 3783 uh we haven't start doing anything there um but it's supposed to be not that so as soon as we we have that merched I think we we are we're kind kind of safe to having um clients ready in days

Gajinder Singh: for uh we uh we will uh basically

integrate uh consolidations as the spec gets finalized and uh then uh I think with small amount of changes we should be ready for

definite one

Sean Anderson: uh for Lighthouse I haven't really gone through the new spec changes but um I think we should be in good shape for

devn one

Alex Stokes: right uh so is everyone thinking like weeks or many weeks or we don't know it's fine if we

don't know uh but people have been asking

Gajinder Singh: I mean if spec is sort of finalized then by end of next week

Alex Stokes: okay

Saulius Grigaitis: yeah so from from Grand side we also didn't look for latest uh uh changes in the spec and we we're actually waiting until it's fully finalized but but the rough estimate something like a week or two for us week or two after after the spec is finalized

Enrico Del Fante: yeah we would like to have a

reference test to to run or against consolidation stuff so code is there but yeah once we got some reference test to run everything over we get some more confident but yeah we are kind of in the next uh weekish

Alex Stokes: okay great uh James I think I saw you on mute I don't know if you're going toh give a prison update

James He: um yeah we we have a couple um Pi still waiting I I I think just like everyone else probably like a week or two uh we'll need to reform a new Dev uh

devet one branch

Alex Stokes: cool and I think that leaves Nimbus I don't know if anyone from Nimbus is on the call Dustin

Dustin Brody: hey sure yeah we haven't looked at this um in in totality let's say uh in terms of dead Net One Readiness and in a lot of detail um that said I I mean I didn't see anything in to Waring in it um the but but I I what I would certainly Echo is I would want the the tests um the consensus spec tests uh in

place but aside from that

Alex Stokes: okay cool um right so specs are on the way uh hopefully in the next couple days and then it sounds like people are thinking small number of weeks for de one so that's super cool

Gajinder Singh: I think uh for DEET one uh El implementing 7702 would be sort of uh the key Milestone that would need to be achieved

Alex Stokes: sorry what was it I missed that

Gajinder Singh: I think for the net run we want uh 7702 on the El side right

Alex Stokes: yes uh this is the yeah this is the account ob truction one um I don't know if we landed on that being in

yeah

Parithosh Jayanthi: yeah we did uh that was the main change between Z and one and I think red said uh they weren't ready with it yet but potentially next week and bezu said they'd have it this week we haven't gotten updates from the other El teams yet but we'll follow up and you can keep an eye out in the inup channel

Alex Stokes: cool um okay so it sounds like we have a pretty good plan for DEET one anything else there otherwise I think we'll move to pios cool so right pios so I kind of just wanted to reiterate the thinking around having the separate activation eoch uh to kick us off um the way I was looking at it is that basically there would be this separate Epoch to activate the feature set and the idea is that you know we

could theoretically imagine having pector ship with some delayed puros within sort of the same Fork as pectra that sounds really complicated and I really don't think we should like if we think pios is ready to do that then we should just ship it with the fork right so I think the plan was generally to say okay either this activation eock will be equal to pectra or it won't be meaning it would be delayed until like the next hard Fork um that then means that it gives us room to implement pios as part of Petra sort of on top of Petra and then what do we gain well we gain not having to like have the separate hard fork with all the code infrastructure uh to implement that as we go and sort of develop things

these things in parallel so that at least is how I was thinking about it um I don't know if anyone has had time since the last C call to like think about this some more or if there are any issues kind of with that approach but that's how I was seeing it Barnabas says developing imp parel doesn't sound like a thing if it's built on top of Petra um why not

Gajinder Singh: I think in the appear as breakout call we decided that we will

continue uh doing devet one of padas on top of denb and uh at a much latest State we'll basically see whether we want to uh we want to uh Revis it on top of Le but uh I think the plan for now is to just continue doing Dev Nets on top of

denet

Barnabas Busa: we had a agreement on like how this Fork should actually be activated though and every team seem to have a different opinion on this so it would be very good to make an actual decision whether it's going to be a hog

fork or whether it's going to be a CL only fork

basically

Gajinder Singh: I think on this uh following the discussion that has happened on uh R&D Discord uh basically it doesn't matter whether it's hard for or not or if it's for uh uh activation Epoch as long as uh the for question doesn't change so for our clients may try to May implement it anyway they want if they can sort of guarantee that P Fork version is same as whatever was on the previous Fork so basically I think we are following uh following the approach of uh uh

activation only but uh yeah the clients who still want to use their uh their hard folk Machinery can do so by uh keeping the for question same

Mark Mackey: so did you say well I I don't see much of a point in building it on top of denb though um you said that's like I don't I don't know yeah yeah there's no plans as far as I can tell to push P Das before Electra

Alex Stokes: yeah what was the rationale there I can make the break out

Enrico Del Fante: I guess it's just because uh they don't want to

be um following the spec changes of Electra having more stable spec that they can focus on beer dust and when Electra spec solidifies more then they they can rebase on top of electron that's my impression

Gajinder Singh: yeah is pretty much orthogonal to Electra and I don't think basically basing on top of Electra is going to be a challenge at any given point but yes rather than spending time on the Cycles now and sort of getting entangled in the Electra development uh I think we can keep P sort of orthogonal from Electra as of now

Parithosh Jayanthi: kind of mirroring that point from

testing as well for example if we do mer the two branches and we're testing P specifically and there's a bug in Petra we might actually trigger the bug purely because the branches are changed and we're going to have to spend Cycles figuring out if it was a Petra bug or if it was a pias bug as opposed to if it was starting from DB then at least then we know with most certainty that's a

pbug

Alex Stokes: right okay I mean yeah it sounds like the tradeoff here is like either we have like sort of more upfront development complexity by putting it on top of pectra or yeah we can kind of focus more exclusively on pios by living on top of

denb with the implication being that sometime down the road we will have to rebase on top of pectra um that sounds okay to me for now I mean it yeah I I guess the tricky thing would be if we're like 6 months from now and we're still on top of the and then it's like okay are we going to ship this or not um but also it doesn't seem like that's a huge issue

Gajinder Singh: maybe defet five onwards we can sort of Reas on top of Petra defet five of Petra I assuming the defet will go till

def 10 okay y five

Barnabas Busa: why

10

Alex Stokes: yeah I don't know if we can put numbers to it but

Gajinder Singh: uh I mean just from the past experience that uh the amount of testing cycles that we give to a particular fork and assuming pectra has so much stuff going in so just a hunch

Parithosh Jayanthi: maybe a good time is to say um once we are sure what's going in Petra and we sort of have a feeling that things are stabilizing that's when we can talk about when the fork is going to be shipped and when we start merging stuff

yeah

Alex Stokes: yeah I mean if everyone thinks this a blur I think that sounds like a good path forward for now just uh having P do on top of janb and then you know maybe

even as soon as like a month or two from now uh we can revisit the rebase

Barnabas Busa: how are the client team's feeling about peer death by the way P death St one uh when could we launch that and would we need any spec change or is everyone happy to keep all the same flx as it is set right now

Nishant Das: uh for one what are you planning to test is it the same

stuff

y

Barnabas Busa: I guess so uh there hasn't been many P PRS to the consensus packet as far as I can see

Nishant Das: okay yeah um I I think it should be good on our end so we would definitely like to test reconstruction in general to see how it works across the network

Saulius Grigaitis: yeah I would suggest to think about peras DEET one when uh we have a quite stable uh Network which doesn't split in in cortosis setup so I I think it's it's still not there or or there is some CTO

config that has like three or four clients that can keep on the same chain for a long time what is the current state of beas can somebody comment on that because on in the interop we ended up with a network that was uh splitted to I mean every point was on sound for as far as I remember

Gajinder Singh: I think in my assessment uh nodes need to make sure that uh they are consistently uh cing the data columns that they are supposed to even if they

restart and that was one of the big uh reason big uh uh reasons basically uh lordstar was not able to syn uh definite zero I mean it was able to syn for a few Epoch but then it would hit into this particular problem that uh that the columns the notes that should should be coding they didn't have it and uh so most likely it could also be the reason for the split uh uh otherwise I don't really see uh I mean in the fork Choice was simple that it is the availability is was same as that we have on blob so ideally there should not be any other

reason for uh for the fork split uh in the nodes uh but I think this this could be the reason for it and if sort of we we can make sure and have the stability around this then I think we should be ready for

devet one

Saulius Grigaitis: yeah but but we can test that in curtois I mean it should be possible to make a CTO config that that has a few clients with the ises that you mentioned fixed and if the network is stable there then then I think we can think about the piras that's my

opinion

Nishant Das: so in in interrup um I think the devet images that were running they were all images which is why clients split so we had a few bugs on our end that we fixed but it wasn't deployed to De to um but yeah before defit one we can you know run a kosis setup with all the clients to see how it works

Barnabas Busa: the client teams just uh put their latest Branch their appear branch in interrup so we we have a good idea of like which branches we should be using on devet one and on cryto Sy

well and what is the status on uh p with load star because they didn't participate in the previous DEET do they have something ready

Gajinder Singh: yeah I'll share

Alex Stokes: okay so should we is it worth thinking about timelines for period offet one then like do we want to try to say okay

aim for something in like a month just to give people like sort of a deadline to work towards

Mark Mackey: not that I want to accelerate things but it seemed like people felt like two weeks as a gut feeling was all right could go three if you want to give more time or whatever I mean a month it should certainly be fine but depends on how fast we want to go I mean yeah sooner it's better but I'm not sure people are I I think most people felt like two weeks didn't seem crazy but correct me if I'm wrong

Gajinder Singh: yeah two weeks and of the month I mean that sounds fine

Alex Stokes: okay so let's aim for that and then

yeah we can run a devet and I think that'll give us a lot more clarity on the next stops sound good to everyone

Saulius Grigaitis: one more suggestion I would like to do is maybe Barnabas or some someone else from devop teams could uh or or maybe this already done could could find at least two pair uh of clients that uh that interrupts correctly so so this would help for the rest of the teams to you know to take this uh these reference to clients and interrupt with those two

clients that almost sure that are correctly working so maybe it's already known that there are two clients that interrupt very stably is it the case or or it's unknown that there are two pairs

Barnabas Busa: we haven't been testing lately uh because there has been just development so as soon as at least one of the clients say that their branch is ready to go then we can start testing but without anyone saying that they are ready there is no point

Saulius Grigaitis: yeah but it's kind of chicken

egg because for for example for us we really would like to to have a two clients working together so we can join it and it could be that the other teams feel quite similar or at least some teams

Barnabas Busa: does gr has a working implementation you think

Saulius Grigaitis: yeah no I mean the the idea would be if if if there are two teams that are quite confident that they are they they are quite done with pias I mean given that it's still early stage but uh that they believe that they should have everything to interrupt then

let's get these two teams to make curtois setup that is very stable so the rest of them could join that would be my proposal but do we have these teams that are very confident about their piras implementation

Sean Anderson: so I'd have to check with Jimmy because he's been doing most of P work in dep line but I think Lighthouse has a pretty solid implementation if uh if I'm following things correctly

Saulius Grigaitis: okay is is is there any is there second one uh that feels Sim

similarly

yeah yeah

um yeah manuver okay can say for pris we are quite confident about p as well

okay so so Barnabas just take Prisma and Lighthouse and try to make a stable Network and if it happens then I think soon we will have a

d one

Gajinder Singh: um one thing I want to know that the pr regarding uh specifying the block count uh through on the FCU patterns and the associated change for for it on on

the E block header for adding block gas limit that is part of Petra or is that part of uh p and I mean I guess it will be part of pectra if this is not really a

for

Alex Stokes: sorry what were you asking about

Gajinder Singh: uh so UPR regarding uh adding Max uh blobs Max blops per block to the FCU pattern right so is that part of Petra or is that

be

Alex Stokes: yeah so that was next on the agenda

um do we feel good about de one just in terms of development timelines I mean sounds like people are on top of it uh when clients are ready we'll start testing soon uh and then we can move to the Bob count conversation but do we all feel pretty good with the devet one plan for pios okay I got at least one thumbs up I got two I'll take it uh let's see here so well okay there was actually one quick thing uh before we get to the blob count itself uh Tim

let's see Tim has a draft PR here for including pios into Petra and yeah this kind of starts to all touch on the same thing um Tim did you want to say a few words about this because I think there was some novelty around the pr and our usual EIP process

Tim Beiko: sure so yeah I had the the reason I kept that as a draft is it just felt a bit like so P ass as it spec is currently a networking change and not like a core protocol change but at the same time it's literally the biggest feature that we have going into pectra so it feels like we should include it um and then then you know the activation uh

stuff we can add to the mea EIP later but I guess anyone think we should not list it in the Met EAP and if not I'll just merge this now

Alex Stokes: I think we should because it just signals that we're serious about this and we are okay cool uh let me go check the agenda okay yeah so I think we kind of

covered the P things themselves and then the next question then is like yeah somewhat how do we actually ship this do we increase the blob count how is it all roll out um and all these things uh so gendra was just talking about uh PR I had to suggest a way to have the CL Drive the blog count I don't know if people have had a chance to look at it but the motivation was essentially to uncouple like so right now there's basically a hardcoded constant both on CL and El for the The Blob count this couples together the layers and so it kind of makes things a little less flexible in terms of us having these like shipping timeline discussions and you know Fork scoping and all of this so it would be kind of nice if we can

uncouple them you could then theoretically have like a CL only fork where you know if we want to change the blob count independently we wouldn't need to update all of the execution clients but just the SE clients so I think there's a good reason you know there's a good motivation for doing this and the question is just how would you do it um the suggestion that I have in the pr right now is basically just to send it over with every payload so whether you're like validating a payload or building a payload the CL would just send it as part of the parameters that already exist to tell the E hey for this block there can only be this many blobs the catch here now is that this kind of breaks optimistic sync uh because the E can be in regimes where it

basically can't talk to the CL synchronously like this and then it might not know what the Bob count should be so yeah the question then is like what do we do about this and uh yeah I think gender maybe Terren uh there's some conversation on the Discord around this but the suggestion was basically to actually include the blob count and some representation in the El header um which does I think nicely solve all these issues um yeah has anyone had a chance to look at this PR or think any more about this

Dankrad Feist: I mean I think um not knowing

whether it's valid for optimistic sync isn't a problem per se like you can simply accept um like whatever you're told it is and then like verify it once you get the beacon block I think the only problem is that you need to know everything in order to be able to compute the block gas like I think that is that is the problem that approach so as long as you can do that I think like it doesn't matter like you don't have to care about optimistic

s

Alex Stokes: right but then you like that suggesting that it does have to go in the header which is I think at least it's a different type of change which is

fine um but that just needs to be something that then all the extion clients with

Dankrad Feist: yeah I tried to think about that as well and it's it is like a conand how to do that part um I mean the optimal way would be to change to change the computation I think it's probably a mistake that block like the gas P computation happens in the E like that should have been in the CL but yeah that's um more difficult to change now I guess

Alex Stokes: we could but I think you didn't have the same issue right it's just more about communicating the information at the right time and the blob count and the blob gas are kind of the same

thing

Dankrad Feist: uh um I mean one thing you have to remember as well is if you actually want to change the blob count there is a computation that has to happen to update uh the excess gas as well M right uh I guess that that works automatically if you do yeah maybe maybe the easiest is that what you suggest yeah like adding the adding the blob count see would solve that because then you can just keep track of the excess gas um except that the unit changes right because like when you have more blobs the constant you want to divide by

changes this is actually like yeah it's not this is not easy this is why it would be easier to have it in the CL because then it would be part of the part of the fork like in the fork you would just recompute all recompute all the constants um whereas if you have it in the E then there's like a some weird backward math to figure out what the right excess gas and what the right um uh ip1 1559 devisor is

Alex Stokes: and this is just at the fork boundary when we changed the blob count is that

what you're referring to to

Dankrad Feist: so there's basically right now right the the the gas cost is computed as like an exponential of like the excess gas divided by this uh blob gas Fe constant I can't remember what it's called um and when you whenever you change the number of blobs you have to adjust both of these numbers as well because they will be like first the constant changes but that that at the same time means that old um excess gas is no no longer in the right units either because it was measured in terms of the old constant essentially

Alex Stokes: right yeah okay that makes

sense

Dankrad Feist: um okay the more the more the better way would be yeah if if there is an easy way I I'll have a look at this later if there isn't is a way to transform the whole thing so that all the gas computations happen in the CL then this is actually more elegant because then it's just part of the um Fork boundary right which we'll have anyway as far as I understand for we have a blob in the E there's actually no such thing because for the E we want it not to be a fork yeah so this could be easier otherwise we can figure out another way in which the CL messages the El about

the change in those constants but they is need yeah it to

right Oar yeah just to mention if we want to keep it in the E then one way to get rid of that annoying discontinuity where basically you need um or thing where you basically need to make an update to that excess gas at at the for point you can you can basically just accept that you will have a discontinuity in the base fee so basically if you say you double the um the blob count then then basically base you would have but there's only it's like a 5 to 10 minute period until you basically you're just

for for a few minutes you have you basically have cheaper blops and then you're back to the same price these adjustments are very quick um and it it's a little inelegant but that would turn that those those constants back into pure pure functions from the from the C BLC so that if you communicate the popc count then you can compute the this this adjustment ratio you just cannot compute the you just kind take that you would have to do this one time update to the the exess GU um the con constant like the

Dankrad Feist: the one in the exponential but I I I assume you want just want to make that a function of the blob

count

yeah exactly that one can be a function of the bobc because you don't have to detect the the for itself it's just basically always SU some concent ratio

Dankrad Feist: right that is I mean that's probably the simplest solution the question is is it the most like the like is it the most elegant solution I guess

Alex Stokes: okay so there there's two things here like we kind of started talking about just how to communicate this generally if we took the data away from the e and then having it go from CL back to the e uh and then also now we're talking about you know if we do actually change the

blob count there is going to be this discontinuity with how we compute the actual blot Bas fee uh and that needs some thought as well so yeah what I'm hearing is that uh this is not that simple to change but I do think it's worth changing um so yeah I would suggest people take a look at the pr um and then yeah this has all been good discussion and from there we can try to figure out uh another path forward if anyone wants to take another look at um yeah maybe even a more invasive change to move more of the computations of things into the CL um that would be great and I think we'll just kind of keep turning on this

cool so yeah I think we've kind of covered a number of the pios things on the agenda that I had here the other big thing is just actually like yeah how do we raise the Bob count and how and all of this um is this a conversation anyone is Keen to have now and the general you know the intent is to raise the Bob count in pectra um obviously the question is how much and you know is it coupled with pios is pios pectra like I think there's a lot of uncertainty here still um but yeah I don't know if anyone has any uh any thoughts or updates on this we're sharing right

now yeah Tony had a comment here um we also want to be mindful of the worst case block size if we do raise the blob count and this calls up uh EIP 7623 I believe is a number uh that's more of an execution layer change but also worth calling out here otherwise yeah from the data I've seen uh honestly it looks like even already uh weaker nodes on the network are having issues with the current Bob parameters uh I had a document where I was talking about the uncoupling of um the CL and E with respect to Bob count that we were just discussing I also

suggested another feature essentially where you could like customize your local Bob building uh to help with this issue I think these are all things we want to keep in mind as we move forward and yeah I think otherwise at least where I'm at right now is just having more time to have more data analysis around how blobs are actually going on Main that it seems a little bit early to me to say oh yeah we definitely want to go to like 816 or like some concrete number um especially without seeing how the pets go and all of this

onar

Alex Stokes: yeah I I think that makes sense I just want to briefly like that in the chat we had a conversation quite a while and

there were some people um under the impression that we basically did not specifically did not want to increase the the Bob count at all uh doing pictor just because it would add quite a bit of testing overhead um and other people that were very adamant that we actually should really increase the popcorn so so I would just want to flag it as a topic where we will at some point have to have the conversation and neither side should fully assume yet that that decision is made either way yeah definitely I mean I would say if pios is ready with Petra then we would also raise the block count um just because of the demand so I think that's uh understood at least hopefully it's

understood

Parithosh Jayanthi: isn't that starting to get a bit risky though because we don't actually know how pias will play out on

Main net

Alex Stokes: sure so they conditional onered us right I mean I don't know like so that does raise an intermediate stop that I think Fresco is calling out in the chat just now like we could imagine well that's that's the thing there's a couple things so like one option is we should peos leave the blob counts Alone um again I think if we're confident enough in pi us to ship it then we're probably also confident enough to raise the blob count we could also just yeah we could ship here to us and not raise the blob count we could just raise the blob count 444 um I think that's probably not as preferred to everyone but that's an

option and yeah so there's many things to work through here

barnab us

Barnabas Busa: just because we are confident enough to Shipe P death that is not give that's not going to give us confidence to increase the BLC though that's not the same thing

Alex Stokes: I agree

Barnabas Busa: because that's what you just said like one minute ago that if you have enough confidence in shipping per do then we have the confidence to increase the B count as well but those two are completely different things

Alex Stokes: they're pretty different I mean I would hope we get to a place where we have confidence in both that like one

implies the other but yes I agree with what you're saying

Barnabas Busa: the point is we have so many IPS and I I feel like we just keep shoveling more and more and more into it and and it's just never going to end so we we'll have to draw some line somewhere where we say okay this is this is where we're going to end it and I think shipping P death and an increased block count in the same uh in in in the same Fork case is just not something that we can do in like the next year and a half testing wise as well as all the other eips that we have included as well

Alex Stokes: mhm yeah I mean I don't know how valuable it is to have a Forks grouping conversation today but you know I think if we get to that point and it becomes clear in a few months then that motivates splitting pios into a different fork or yeah rethinking

uh Franchesco

Francesco D'Amato: uh yeah just wanted to point out something which I think G already mentioned in the chat that like the block count means something quite different with pi do PI so I mean this doesn't mean that necessary we can feel confident having I don't know like six or eight or whatever like Target but it doesn't mean that we can't really just say uh you know we are okay with a block count of three because we

know we've seen itain that like it means something different in pios like it's the through that I mean the bandwidth that you need to handle uh 36 is is very different in pios it would be like much less um so yeah I don't think they necessarily um this seems a bit of like a a bias there of like you know we we we ship here do without doing any change to block count then we can feel confident that it works but that's not really to me that's not really necessarily the case um it's this doesn't mean that like you know necessarily we should increase it but that that's one thing to keep in mind um and also another thing is um I think if we're not willing to do that which I I can understand there's like I

agree there's there's a ton of VIPs and things um going on and it's hard to test all of it but if we're not willing to do that what benefit are we actually getting from doing P do uh with Petra if that's and that that ends up being the case like at that point uh does it not just make more sense to drisk the whole thing just do Petra without Pier do just to Pi commit to doing Pier do as its own Fork like much before bural because I think I think the only really like stupid outcome that we should avoid all cost is trying to like Tye D and with a blob count increase to like some Fork we in the future like that's like really the only outcome that's just like to me unacceptable um but other than that like you know whether we do Pier do in

January or like April or whatever like I mean doing it earlier without Bob count increase to me like just doesn't really add that much

Alex Stokes: right I mean it would give us evidence on mainnet that peros is working like we expect right so like it does actually the shipping

pados

Francesco D'Amato: but it also increases risk to everything else and like to the whole Fork

Alex Stokes: well I think that's a different conversation and that's where this starts to get tricky is yeah like aligning pectra timelines with periodos timelines Bob increase timelines

um paros

Parithosh Jayanthi: uh yeah so the one point I do want to bring up is like we're talking about

testing but the issue is that testing networking is extremely hard uh we did do a lot of 48 44 related testing but the way blobs played out on mainnet is not a onetoone analog to how it played out in testing we do see weaker nodes having issues we do see timing games being played and stuff like that and that's the main reason why even if we can simulate a perfect world in which pias along with the blog increase does work in all of our Dev Nets it doesn't actually mean anything for main net and that's my main argument for why we should probably do things step by step rather than than all at once because just testing doesn't mean anything

onar

Alex Stokes: did you have your hand up for

Ansgar Dietrichs: yeah

I just wanted to yeah I just want wanted to to briefly say that um to me really like this this point that is super important that like the meaning of of of blobs already changes and P so I don't even think it makes sense with P to call it a blob count increase because we we have to pick a new number of blobs for p anyway even if we happen to go with this kind of 36 that we also have today that doesn't mean we can actually reuse anything I mean maybe like a tiny sliver of el side logic around the gas computation but that's the easiest part anything else changes anyway and then I don't know specifically why mayet might break under say I don't know 816 or something but it would not break under 36 it could also break under 36 and so

the only World in which I see that there's any reason to stick to as a default to the the values we have to have in a pre preus world would be if we ship peer with some sort of fallback mechanism to disable it if there are issues and fall back to the existing version but that seems so incredibly complex including for for fork Choice implications that I don't think it's realistic to ship it that way so if we already ship it as its own standal on thing that has to not break otherwise May itet breaks then I don't see why why 36 would have any more value as a default than any other other count number we could I just want think calling it an increase makes sense when we have to pick a completely new number anyway

for

Parithosh Jayanthi: um actually Franchesco I think said something earlier that made a lot of sense if we are moving to a paradigm in which the CL is setting the blobs we could potentially increase the blob count um and we already have this mechanism with the circuit breaker where if we see a bunch of Miss slots in a row SL nonf finality slash a lot of other circuit breaker conditions that we use for me we could reuse that same circuit breaker conditions for blobs as well

Mark Mackey: um I think that isn't I don't think we can do that here because all the clients have to be consensus on the maximum blob amount and and like the circuit breaker rules are not something that all clients

have consensus on and I don't they they could either because what they see is can be different

Francesco D'Amato: but you could for example just locally say like I'm not going to propose a block with a with more than I don't know two blobs or something if I see that things are not working um I don't know how viable it is but and I mean if someone else does propose a block with a lot of blobs and it turns out that that um like um that the network is not able to handle that I guess that just you just get

reor

Mark Mackey: yeah I guess but you know if you see a block with three blobs and your node is feeling like the

Network's in bad shape and only two need to like we should only ship with two or something like that then you have to reject that block and then what if the rest of the N like I don't know that seems can you really do that unless we have special rules where it doesn't actually make the block invalid to have more blobs than you expect but that's weird but I

would I don't just want to say second what onar was saying like if we have to pick a number even I mean what if we even just picked a small blob size increase I mean if we're going to test with six with period we might as well test with eight and then leave it to some future date to increase it further that would that seems like a safe option and a small increase

Barnabas Busa: what's the point of increasing if it's not significant like why why risk of increasing if if there's no actual benefit

Sean Anderson: I think this was franchesco's point where it's not that we're we're not increasing from known value if we're

implementing perer to us we are just like kind of picking a number that we think is right and like yeah lower is maybe safer if we imagine there going to be bottle uh bottlenecks with upload download but it's not necessarily like like we don't know anything about the new limits

Mark Mackey: also eight is a power of two just say

Alex Stokes: so we can Target the same amount of Bas right like we can do that calculation and we can know that with pios you know the Bob count might change but it's going to be the same amount of bandwidth so that's like a good starting point yeah

Fresco

Francesco D'Amato: yeah just I mean I don't know how meaningful this is but just to give everyone like a very very rough idea with the current parameters in the spec for a validator you would be using basically um like if you're like a really low power validator that's running like one or two or like a few um then you would be using roughly like 8X less bandwidth for the same amount of data so you know maybe we don't increase the block count by 8X but like maybe safer to increase it by 2X or something like that and as a full Noe even it would be even less like you'll be using 11/16th I mean of course we should like actually confirm these numbers on on on test Nets like compare you know for the

same amount of uh blobs what what are what is the bendwi usage um from PR for four versus Pi do but in principle that's what it should be

Alex Stokes: right so you know seems like there's plenty of head dargue for a double but yeah I don't know I think at least I would hope we're going to have a better understanding of how this stuff works you know once we have Dev Nets that are running and PS is actually live and then hopefully the conversation is a little less uncertain

Mark Mackey: and I guess I sorry I me to jump but I I just want to say like if the problem is that we're putting too

much in the fork like I just think the blob increase and puros are something coupled like changing the blob size by a little bit compared to the other things that we're putting in this Fork is such a small change if you already assume that P do is going in if we have to pull things from the fork I wouldn't I don't I don't think a configuration where pectra ships or where p dash ships and the increase doesn't ship makes sense I think we would pull something else

andrio I think you hand up

Enrico Del Fante: yeah just a comment because we are saying that we are going to the with the

pier D activation eoch in Electra it means that p d will activate later so it's weird that we get a blob increase and then the the pier do activates just later so picking up the right blobs count at Fork seems like weird to me unless we we increase the the blobs at add P do activation which is a different story so we we we end up not increasing enough

because we have to cover first month of non-peer D activation and we don't get the full benefit of the right number of of blobs that we can support in beer dust which is weird

Alex Stokes: right and you're just referring to having like some delayed activation of

PS

Enrico Del Fante: yes in I mean the the moment of if we agree on the delayed activation of the

pier do

Alex Stokes: yeah I don't see why we would ever do that myself because it just seems to complicate what's already very very complicated um I think we either ship P do with Petra or we don't basically

um because otherwise yeah it's just's going to add even more sort of huge decision points on top of something that's already quite complex

Dankrad Feist: in terms of The Blob count I think it's also not crazy to think about what if we just do the same as with call data and make um validators just vote on it um I mean it's working there's no crazy increases um and it allows us uh to change it without a hard for because I think largely in the end like the way it's always work with um with gas the gas limit is that uh

the the miners and other the stakers just like listen to the core defs what they think is a safe limit and then increase it to that um so this would be would allow us more flexibility in the future

Alex Stokes: right I mean do we ever think we're in a situation where you know people on this call for example want to raise the blob count but then the validators let's say aren't listening not because they don't want to but just because you know they don't understand how to like go and change Target limits and all this stuff okay um so yeah I think we just keep

charging ahead here I again I hope that having P test Nets will give some certainty to or at least some insight into some of these things and hopefully we can uh well I mean we will figure something out so we just have to keep pushing ahead um is there anything else on pios or Bob counts or anything like that otherwise we have an S update okay uh Eton I think you're driving this would you like to give an overview of the latest there

Etan Kissling: sure um so progress has been going well uh te cool has joined the

SSC 7688 DEET as well that's the CL one with the stable containers for all the data structures in consensus that keep changing across Forks um last time grina mentioned some uh questions about type systems I'm not sure if those are resolved uh otherwise I think we can just give it a brief discussion

Saulius Grigaitis: yes so for for us we we think that we will go with the approach where uh will try to keep the the types that

we have uh the type system in generally that we already have in the application and we just trying to to build something like meta structures or so that would accommodate uh functionality required for stable containers so that's the current plan for us but the implementation we have it's it's not it's not finished and I think we will tell more after it's done

Etan Kissling: um do you see any blockers like uh same goes for Lighthouse and prism like is there something that we should know about

Saulius Grigaitis: at the moment for grina we don't see we don't see blockers but you know

as the rest environment is quite restricted restrictive and not too flexible I think until we finished U we we cannot fully confirm you that there are no that there will be will not be any blockers but so far we are progressing

Etan Kissling: okay and from Lighthouse I se in the chat that there is also no blocker so far

Sean Anderson: no

not no prism

Etan Kissling: I think uh Casey made some comments on the spec as well

not sure

yeah we're we're still

looking into it we should have an update by the next ACD

Dankrad Feist: okay cool yeah I I think we should Target the next ACDC um like uh it seems that everyone started implementing it and that we could could resolve the questions there and it would be really great if we can have the full demet with all the clients so that we can decide if we want this incture or not um for remarkable the like the the implementation in Python that we use in consensus specs I have pushed that one to production quality but um I'm still trying to get hold of protol Lambda is a bit uh

hard to reach if if anyone could uh ping him about this PR that I just put in the chat would be great um just because we need that in consensus SP to to do any um tests um and also a small update on the SSE transactions ethereum Js has started working on that one and Nimbus has a corresponding consensus client one question that came up is that right now in in the CL we we need to

know about all the fields in the E lock header um so every time that there is a new field and the El block header the CL execution payload header and the El EXE the CL execution payload have to be updated in log step and one thing that happens if we go with the SSC transactions in the same way is that the cl also needs to know how to Hash the transactions um in order to do you know the optimistic Sy and also in order to have the transaction type as part of the

execution pay so um that would be a small restriction for the El because right now they can introduce new transaction types unilaterally without a CL Fork um but with that it would mean that whenever there are new fields in the transaction that the cl also needs to be updated at the same time um the same way how it's already done for the Y block header I I'm wondering if that is fine the alternative that I'm seeing is just to make two trees uh one with the serialized transactions like the same

how we do it today and then a second tree with the transaction IDs in a list like all the has roots in a list but that would mean like that we essentially double the amount of hashes that are needed and I mean most of the block is transactions so a bit suboptimal so yeah just wanted to point that out that um whether that's someone sees a problem with the CL knowing how to meriz transactions and what Fields there are

Alex Stokes: yeah I don't think there really any

issues it's just yeah it's it opens a lot of sort of feuture set things to consider um yeah but thanks for the update uh pus you had your hand up

yeah

Potuz: so yeah I have a horrible connection I don't know how much is I'm cutting up but I think we should uh probably revisit or evaluate whether or not we can remove completely the execution payload header for currently there's no in protocol usage of it uh we only check uh the blog hash we check against the parent hash uh in my epbs Branch I have it essentially with

minimal data removed most of it uh I understand that there are some concerns about like clients uh but like clients currently don't really use the the header and they can probably use it check it on the on the on the Y side I think we should probably think about removing all of this information on the execution payLo head that we're not using and that would solve also problem

Etan Kissling: um the light client stuff should still be fine like uh full note that serves that data it can still inspect the block and construct it right it's just that

Potuz: exactly so and we are not using at all the execution payload header we we can only we can replace the last execution payload header in the

beon state by just the last block hash

Etan Kissling: yeah in the in the ex in the beacon State yeah um in the Builder API it's still relevant of course um but uh that one is not on chain right but it's a good point like maybe we can go the other way and make the execution payload opaque as well and then the El would be the one to

Potuz: yeah that that makes the life of us of of everyone much better uh there are some things that we need anyways even in the

Builder I you need the kcg commitments and a bunch of things um but it can be reduced quite a bit

Etan Kissling: yeah we can we can think about that once uh once we have an implementation luckily it's quite orthogonal so um the SS transaction it can be implemented on an and then we can figure out how we want to um like whether we want to add the transaction as well to the c or whether we want to remove the um execution payload yeah uh could you could you send

me that Branch as well like the epbs branch from the chat a big rule as well yeah anyway so yeah that's the SSC update for um this time um goal is next ACDC to have the full devet with gr prisonment Lighthouse as well then we can decide whether to include it um and yeah if someone can poke protol Lambda about the remarkable PR yeah that's all from my

side

Alex Stokes: is this a Petra DEET or DB or something else

it's an Electra devet um it's on stability now. boox the cortosis config is there

Alex Stokes: cool nice work so we only have a few minutes here at the end of the call and we did have one more thing on the agenda to talk about the name for the fstar um I think there have been a couple different suggestions flying around uh sounds like we have some leading favorites either fulu or felus um I don't know if people want to

discuss now I think there's also I'll go find a link but I think there's an eth magicians post for it does anybody want to Champion their favorite

Mark Mackey: is there a name for the

eel side oaka

Mark Mackey: so it's kind of between like fro Saka or faka for the combination

Alex Stokes: Saka F Saka

prob suggested a Sulu which I kind of like or yeah faka okay well uh I would suggest going to the SE magicians post if you feel strongly and uh otherwise if there anything else anything else on the FSR name uh uh it doesn't sound like there's enough demand to make a decision right now okay uh anything else to wrap up the call otherwise I think that is it for

the day okay sounds good thanks everyone and uh see you on the next call

thanks Alex byebye bye

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