All Core Devs - Consensus #125

Transcript

[Music] [Applause] for

he Jesus w

Danny Ryan: all right we should be live welcome to award dev's consensus ler call 125 this is issue 936 in the PM repo um General didn't have discussion uh a bit of a discussion around a work Choice filtering change that's been brought up as to whether should go in or not um and then a couple of other spec items so we can go ahead and get started oh is my audio coming through loud and clear okay it's ENT um Okay cool so generally

uh we have a testet fork Gorly fork in thck days there is the blog post out which I believe has releases for all the expected clients uh which is exciting um as we approach that do we have any discussion items in relation to that test net in relation to existing Deb Nets in relation to

testinga

Parithosh Jayanthi: uh yeah maybe I can go first um we have a girly Shadow for uh that was launched

like an hour ago or so um it's based off the versions from the EF blog post so it's kind of like a sanity check that everything would go as planned um and it did the only note that seems offline is uh teu bezu note but I'm 99% sure that's my fault um I think I used the wrong flag while starting it up and we'll look into getting on the right chain and otherwise I think there's nothing to note there we've already started spamming blobs and blobs seem to be propagated fine and uh yeah if you guys have something specific you want to test on there let us know and then we'll carry it out

Fe

Danny Ryan: great yeah any questions for

Perry door the Explorer looking really good over here yeah cool um any anything else in relation to testing or the upcoming Gorly Fork okay keep moving forward let's

see okay Phil added the fork Choice filtering change PR to discuss um on whether this is being shipped in the upcoming Fork uh does any anybody F do you have any contacts here to add

Mikhail Kalinin: yeah I can speak on that okay great yeah so um what was previous decided is that we are rolling out this change within the D and uh doing it in a Loosely coordinated fashion so just um so basically this change should be enabled in the main net releases um lines main net uh

yeah releases including the the for keep for the main um and yeah from my perspective there are two ways to do that is one is that just um merging the change um before making the release so it appears in this release only uh the other one is like Ena this logic conditionally based on the whether the for has set or not not um I believe the former is preferable by the Yeah that's the context that was the what was started like um a while ago when we were speaking about how we want

to roll out this change and also one thing worth noting here is that probably the confusion is some of uh confusion uh about this Chang is coming from that the pr that proposes this change has has been yet merged uh but we decided to set the D for for the main net and uh merge the pr after that only

Danny Ryan: sorry your last comment was in relation to which PR

Mikhail Kalinin: uh the pr that proposes this Fork Choice change uh that is required for confirmation rule it's not yet merged into this stack and some client devs uh

were saying that they have haven't started to implement it because of the pr was not mer um but we decided not to merge the pr um until the main net uh ebook is set

n

Danny Ryan: right thank you for the the background here um I would I'm kind of leaning towards now that we're in the launch sequence that it's probably time to merge it uh as a signal is there actually value in waiting for the the neb uh Epoch to be included because that ends up probably on a three-week Time Horizon um and I I know that we decided

to not do the conditional forking or the conditional logic here one for Simplicity and two uh well Simplicity of spec as well as Simplicity of testing um and so we won't be doing kind of this conditional test so I think that most clients are not going to do a conditional logic update um and so given that we're not conditioning this upon anything other than just getting it out and releases soon um so what do you think do you think we should wait until we have the neck or just go for it

I

Mikhail Kalinin: I personally don't see any uh

problems with merg right now and it's actually referable to me but um maybe other people have opinions on that so I merged it and uh yeah in the next release we'll we'll get test factors uh incorporate in this change we already have them but they are attached uh in the comment to the pr which probably not that handy

uh I would support merging it as well

Danny Ryan: anybody against merging this this week and having it available um as a release very soon and to be the

target it'll be the assumed Target of any further Deb Nets and Main net great and if I remember correctly I kind of tagged it I said ah this is the substantive change it's there are a number of um I think minor helper changes just in terms of um being able to reuse logic but it's it's really this one line the or voting voting source. eoch plus 2 is

greater than equal to the current Epoch okay um anything else on this one uh we'll aim to do a release by Monday great yeah thanks pH for catching this glad I didn't still through the cracks okay next up is

um from dline deriving an open API type schema from the ppec now that we do have the canonical Json mapping

uh that plan

dapplion: yeah hey everyone so now that we have a canonical mapping from s to Json we can drop a lot of Bo On The Pon apis so I wrote a short python script that converts the ppec into into the types that are needed for the API plus we can also Define the extra types that are ssz is as ssz instead of the classic open

API so in in my opinion it looks much cleaner it's wayless code for now it's not critically important but for future Forks it should it should alleviate a lot of Maintenance and we can easily ssz everything if we want to later which is an idea that has been floating around for a while and this would make it very easy I'm bringing this up because it's a change on how the repo would work so I would like to make sure that there is no one opposed in working with SS instead of open API or if we would lose some sort of exclusivity that someone finds important with this

approach so with the information that is available right now is anyone strongly oppos into dropping all that open API bu plate and just dealing with SS exclusively okay awesome then if you can please take a look at the issue uh it's a decent change it's a chunky PR so I would work uh with with involved maintainers to try to make the

transition as smooth as possible making sure that nothing is broken so that's all thanks

Danny Ryan: and this assumes a merge of 3506

dapplion: yes

Danny Ryan: which I think we've discussed quite a bit and just didn't click the button

dapplion: yeah so now is a good time

Danny Ryan: great

Jacek Sieka: I think I might be the winner of

the uh longest time open PR that actually gets merged competition

Danny Ryan: there are some PRS open up from uh even older than this we can go look at them see be record

Jacek Sieka: I'll just make up some so they don't get merged

Danny Ryan: great thanks dine thanks jessic okay and finally uh pop wanted to bring up

PR 3545 um which uh was a proposal from age to modify the long liveed standing ad station subnet um to utilize I believe prefix bits instead of the entire note ID um pop or age or anyone that wants to give some more context on this

uh yeah uh I think this PR is about using the P instead of the suff to determine the the the subnet that the note are supposed to subscribe to uh I think I think it's good idea because uh

uh because clearly uh the enti node ID is used to determine the the subnet but but that is a problem uh because uh be uh because uh you you when when when you want to find the note that I subscribe to the subnet you have to go to the dv5 and then and then do a random walk to to to to f the the note that are subscribed to the subnet but if you use only the the pic you can just uh you can just use that pic instead of the entire note ID and it will be faster in in in the kadia DHT I think I think that is the the OB

yeah

Danny Ryan: does the current logic use the suffix or does it just use the entire node ID

uh it use a suffix like some some some bit of suffix but but I think it it make more sense to use only the

Prix

Danny Ryan: I see so this doesn't change the grindability right because it it would utilize the same amount of the prefix as as the suffix apparently like if if an attacker we're trying to grind node IDs to um take over like a subnet this doesn't change that calculation does it

I think it doesn't change like uh actually I think yeah

I think it doesn't

change because you cannot prevent the attacker to to generate a lot of not ID right it's like it doesn't matter you use the prefix or suffix that is what I think yeah

Danny Ryan: okay

Jacek Sieka: I think there is one downside actually which is that if you search that cademia by prefix you will not find the Subscribe all subnets nodes that subscribe to these subnets regardless so you're kind of uh limiting your search to one whatever it is 64 302 of of all notes out there

Danny Ryan: but couldn't you do that search as well

Jacek Sieka: you can but like you know if the

reason we're doing the prefix is so that you don't search the whole cademia and everybody goes on to change so that we don't do it then you could but you don't

Danny Ryan: sure I guess I see you can have like Fast lookups on the kind of honesty assumption here but you also if you're heris it can also walk on whatever speed it wants to find the other type but yeah I yeah I don't know I mean there there there's two things there it's like one purposely populating but those peers still do exist so they still will exist even if nobody's looking for them um and provide additional utility

so I don't know I get I get the argument I don't know how strong I'd claim the argument

is I guess

Jacek Sieka: neither do I it's an observable change though

yeah

Danny Ryan: uh I mean it also is an observable change in that it's a breaking change and you would very likely have to condition this upon a fork um or have some sort of transition period or or something uh you can't just like put this out and slowly upgrade uh which is a downside uh I

guess I I don't have much fun fundamental opposition here and I would presume most people don't um but I think the conversation needs to happen in this PR is actually how the upgrade would look like um and given that we're coming up against the neb if this needs to be upgraded at a fork boundary I would presume that it wouldn't go into denev at this point uh but nonetheless I think we do need to have the conversation about how this upgrade could occur in that PR um are we comfortable bringing that question to the pr um and hashing it out there or do

Is there further discussion for this call

Jacek Sieka: I'll make a comment on the PR but like what I just said doesn't isn't the blocker for the pr it comes after right um like having nodes already do this that doesn't change anything it's the change in behavior in cademia lookups in clients that that is potentially weird

yeah

Danny Ryan: yeah but I do think that independently like how you actually upgrade this in a live network has to be discussed in this PR

uh yes I think yeah I agree

Danny Ryan: okay pop can you either pose that question or pose an upgrade path in

there U we can further discussion there

sure

Danny Ryan: okay thank you okay that is everything that is on the current agenda um I know there's beginning to be discussions as to what we do next um personally would probably get us a little bit further into the fork um before we hash out all individual proposals but if people would like to open up for discussion broadly

about the framing of the fork um kind of if there's a big thing what the priorities kind of feel like um by all means we can have we can begin this conversation I'm also okay with um you know having a bit more of a structured conversation next time I didn't give you much to bite into

there um but I can come in two weeks if no one's opposed and give a bit more to bite into to begin the conversation anyone opposed to beginning this conversation in the next uh on the call

Alex Stokes: not oppose but I have a question where is there a place we could in the meantime uh you know discuss async things for the CL

Danny Ryan: there is an open issue on the consensus specs repo where we have been Gathering uh a list of eips which right after this call I can kind of go through and make sure that it

is reasonably up to date I think there's one more comment since I last looked right so EIP 749 7549 um okay so it is this issue 3 449 um so I either cataloging the information here um there also is a magician thread that is open that does have some dialogue

um Anar

Ansgar Dietrichs: yeah I didn't want to kind of get too much into the discussion already I just wanted to flag that this year we might be in a somewhat unusual situation especially on the on the SE side in terms of kind of for what features going

forward where there is this work on the data availability sampling side um that it very much has the nature of of a feature that usually would be part would be an EIP or something but just because of the way we structured fo for for does not actually require a hard for or an attached EIP um and I think with that comes the risk of it maybe not having quite the same visibility where like maybe we start collecting APS for the next quock and then we basically say oh now we have so many things to do so we can't focus too much on data availabity sampling anymore where that's kind of backwards because that would kind of um because to me to me data available something really is kind of the the highest priority thing thing to do so just wanted to flag already going

conversations that yeah just because it's not an EIP we don't

I'm not certain

Danny Ryan: I'm not certain why it wouldn't be an EIP uh we had this conversation a bit the other day on some of us that have been working on the peer D spec um and I think it is I think it should manifest as an EIP it did it it is uh newly in an open PR on the consensus specs repo as of some amount of hours ago and I think the the intent is to couple it with any IP even it's kind of work in progress status uh Shia did you want to go over some of that or at least signal that it exists okay okay well there's the draft

um and the intention is to while we're getting the draft open to also get an EIP open in relation to it um as noted in the okay has a mic issue as noted in the chat if you did modify the data gas limit um it it is a hard Fork consensus change um if you don't you could imagine a pure networking change it does beg the question as to why you're doing it um I guess you could make an argument for upgrading to the modified networking before updating the gas limit but um I imagine we would

be having those conversations in sequence but but yeah the the intention would be to make this an EIP regardless of how the upgrade path is um and we should have an EIP number for it for discussion uh by the two we count from here yes so that issue on the spec repo where we have cataloged um things that people do want to bring up for discussion if you do have additional eips please get them there soon um

conversation can obviously occur dynamically in um the Discord or more async in that magician's thread um if they're technical items to touch on maybe put it in the consensus specs um but we don't have like a 100% perfect division on where to have these conversations all right yeah check out that uh PDS spec draft um especially if you're on the networking side of things on your

client um relatively simple relatively straightforward any other discussion points for today let's go with debet zero after didn't that hard for

okay cool uh appreciate it thank you please um get your thoughts organized around um how you and your team are thinking about proceeding from here in terms of priorities and upgrades and we will pick up the conversation in two weeks thanks everyone

thanks everyone Bye by

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