All Core Devs - Consensus #118

Transcript

foreign [Music] [Applause]

thank you now

uh okay but I

Danny Ryan: think I actually had OBS left to open from last time on this computer and I suspect that I've screwed something up because of that um you're streaming you're trying to stream yeah

Tim Beiko: and it said the stream was interrupted when I started streaming into it so oh I think there's sound

Danny Ryan: okay sound is back uh cool thank you Tim for covering my ass um I had something wrong in my configuration clearly uh just a quick recap for those that are on the on the web

um yeah the hardest part of the job um Devin nine uh we did have a spec release for the neb Omega Sims player there was um a couple of tests that were broken those have been released uh as a hot fix to the consensus spec test repo that have not changed anything in the consensus specs repo with respect to release hopefully people have taking a look um I will now pass it off to those coordinating devnet9 what's our intended timeline um I guess with um comments from client teams on whether they're looking ready or not

Parithosh Jayanthi: yeah I think with idea do you like to

have devnet9 some point next week but two things we want to wait for are first a signal from the clan teams as to how ready they are and then um where the hype tests are because we'd like to get have tests and before we do

devnets

Mario Vega: uh I can start with the high tests they are ready and running right now for W9 so yeah they were like updated last night

Danny Ryan: thanks Mario um any client teams that would not be ready for devnet9 which Perry would that mean a uh devnet release tomorrow or Monday what would what would the wreck

was the timeline be for that

Parithosh Jayanthi: uh we can just do it mid next week so Wednesday

Danny Ryan: but in terms of uh when you did client releases

Parithosh Jayanthi: we normally just do um Forks of branches sorry we just use the branches from plants so we don't need releases for

our devnets

Danny Ryan: gotcha very cool is any uh consensus layer team not ready for such a timeline okay and any execution layer teams that are here is anyone uh opposed to that okay Mario says get these blob theme

merge is that something likely the next couple days

Marius van der Wijden: um yes so I think we can be ready by next

Danny Ryan: okay cool uh Perry and Co y'all can circle with the rest of the teams um and make sure that we're in a good spot

Justin so for Els I'm actually literally just running those Hive tests right now and we're running into some issues so I it depends on what the definition of next week is I think so put us down as ambivalent

this one

Danny Ryan: what was that Marius

I said the week after this one of next week

right it's a

difference

Danny Ryan: yeah thank you Mike um yeah so it is that intended Wednesday but um Perry and Coke and uh Circle back with y'all and see how things are going at the start of the week

Parithosh Jayanthi: yeah and if not we can still start the devnet as long as we have at least a couple of plans ready and then we can add the best uh post

fact

Enrico Del Fante: um just want to add something from techu so we are still working on blocks D3 apis so we are ready if we don't

consider potentially interrupt between clients using this new endpoints for Block production is not intended uh we are ready because we have the churn the new churn PR just ready to be merged so next week will be fine

Danny Ryan: let's go ahead and touch that Paul brought up this this is Ish PR 358 in the beacon apis repo looks like there's a change to the block V3 which is used for Block production between the validator client the beacon node um this does seem like a pretty transparent or the network isn't

going to really be aware of this unless we tried to do mix and match things so I would lean in favor of what Enrico just suggested which is to not be concerned about the granularity of whether clients made this change or not but I'm open to Alternative opinions okay does anybody see this API change as a blocker from moving forward on

devnet9

Enrico Del Fante: yeah but to be clear we are still working on the previous PR which is not the consensus value but block V3

this has been already merged so he's not talking about this additional change but the V3 endpoint completely right

Danny Ryan: but we're good to move forward okay I see some thumbs up anything else on devnet9

Parithosh Jayanthi: um I had one tiny uh request to the

beacon API stuff we uh this PR card merge adding blobside current event um Simon Andrew are looking to add like track that event in satu and it would be nice if clients have support for this PR sooner rather than later um so we can also start testing tooling such that by the time we do the first test net we're not testing something that's Alpha

Danny Ryan: got any comments regarding the Readiness of this okay

Tim Beiko: yeah do we want to I guess there's a question in the chat do we want to do the contract deployment the same way we do on mainnet um even if it's not with the perfect address I think we have mine one sub-optimal one and we're trying to look for a nicer one

Danny Ryan: I would prefer to see that yes yeah um like client are we ready to to do that deployment method weird okay who's going to be in charge of that deployment method and it it also implies

that we need enough lead time between Genesis and the fork to be able to uh you know fund the account run the script I mean obviously that can happen extremely quickly we just need to be on it

Parithosh Jayanthi: uh yeah we can definitely add some lead time like 20 e bucks or something so roughly two hours if if someone shows me what the deployment method is we're happy to do it but otherwise we're also happy to just pass on the eat and someone else doesn't whatever works best

Danny Ryan: yeah I mean I think it'd be great if like Kleiner Martin could work with the devops team to show them how to do it so

that we can get it scripted and kind of integrated into the processes okay and then there's a conversation going on in the chat around um the updated kzg values um Carl says looking like we're aiming for Tuesday on those updated values um is that something that we're attempting to get into this devnet or will we push it to a side test for now subsequent devnet or side test

Parithosh Jayanthi: yes

Carl Beekhuizen: as mentioned I'm hoping to have that

done by Tuesday but no guarantees um the issue here being that after that it needs to be compiled into the libraries um so that makes timing very tight for a Wednesday uh devnet

Parithosh Jayanthi: we've been putting out the alert that um clients should allow it to specify as a runtime flight on almost every single devnet spec release I think all the clients do have such a flat though we've even been using it or is the worry that the flag is not respected in which case we can just get rid of it

Danny Ryan: I think the worry is that there's some final work to do and it's unclear if

that would happen before Wednesday with respect to getting this into the cryptographic libraries are are you saying Perry that the crypto active libraries have Flags

Parithosh Jayanthi: and I'm talking about the final client releases yeah yeah cool and then if it's ready in time then we'll use it but otherwise I guess we stick to the old trusted setup for now

yeah

Danny Ryan: the untrusted setup um Mario

Mario Vega: yeah so one small consideration that might be taking into account is that um we do need to update the the tests

for that so if you guys want to use that the trusted setup for that 9 I think that will be fine we just not need to consider that they had this and the actual then the Nitro setup might differ so uh yeah there's going to be a difference but I don't think it's it should be impactful

Martin right right so I missed a little bit of the context of what's the first sub previously but this is 47

Danny Ryan: you sound very muffled Martin is there

maybe an angle

there's a possibly better now

Danny Ryan: yes thank you

Martin Holst Swende: okay so I missed a bit of the context to the deployment of uh 47.88 and download nine uh but the one thing that is important um I mean exactly what code gets deployed by devops in the Genesis is doesn't really matter they can decide what they want to deploy and all the clients will just use it uh what is important is where they deployed and all the clients needs to agree on what the address they're going to use for this system contract

Danny Ryan: there was an intention to not deploy at Genesis and to instead deploy between

the inner and between Genesis and the Cancun Fork

Martin Holst Swende: um so I went sorry I'm missing it but we were talking about the test Network we're talking about a minute Fork

Danny Ryan: we're talking about death net um I think there's just a at least I have the desire to see just us run through that manual process and kind of get scripts and things together rather than just shoving it into the um Genesis State unless you believe otherwise

Martin Holst Swende: um no that's fine but but the big problem then is not making the transaction and and putting

funds there and deploying it that's not the big one the big one is that we need to make sure that all the clients have the correct address anyway and regardless of how we put it there it really it takes takes longer for everyone to make put the right address and make a release so Matt

yeah I agree

Martin Holst Swende: if you have figured out the the address then put it somewhere publicly so all the client devs can just merge it the correct address

I think it's in the the right address is in the exact spec test it's a version four like there was a release of uh of

that test Suite recently with an updated address

Martin Holst Swende: uh very good then all the client devs should now know that they need to update this as soon as possible

Danny Ryan: cool should be good to go Mario

Mario Vega: so uh the the

Danny Ryan: I believe you cut out Mario uh yeah okay you're back can you start over

yeah

Mario Vega: yeah of course uh so the the address in the latest release of the XXX test is the uh the one that is on the latest commit in the EIP

um but it's not the one that is being mined right now so there might be a change got it

Danny Ryan: I think we're on the same page on this any other devnet 9 related items okay any other the NAB or Cancun

related items

Tim

Tim Beiko: um okay not that we need to make a decision about this now but I think um it's worth it assuming that nine goes well to think about uh how we want to approach test net deployment um and I guess there's a few considerations there uh the first is obviously a whole ski at the launch didn't go quite smoothly so uh we probably don't want to use that as a first test net and then second whether we want to

um whether we want to uh have a first test net before Dev connect or not um because given devconnect is in uh you know mid-november uh this means that we'd probably want to have that test net early November at the latest and if we want to have the releases out that's around like mid October or maybe late October um which is you know probably a month or less from now so yeah I'm curious if anyone has thoughts about that like how realistic that is and and I guess also it's worth noting I think the implication if we

don't do a test net before Dev connect um it's probably unlikely we can do mainnet before the like Christmas holidays um because after Dev connect there's U.S Thanksgiving and then there's basically three maybe four weeks uh before like uh Christmas holidays and and people being gone so that's probably not the best time before commandment yeah so just wanted to put that out there

Danny Ryan: curious this is your first point in relation to holski is it is it unlikely that we would be able to use whole ski in in a few weeks

Tim Beiko: I'm not sure maybe someone from who's

more involved there yeah yeah

Parithosh Jayanthi: I think it uh so the whole ski Genesis is scheduled now for next week so the 28th so it will be usable in terms for deaf in time for Deaf connect but I'd still make the case for host key not being the first Fork but rather potentially the second or third mainly because we have girly as a perfectly functioning test net that is deprecated which means we can try out the three six lob option on girly and if it goes badly it's a deprecated test net anyway uh if it goes badly on whole ski then we have to figure out how to save it

Tim Beiko: yeah I would also

and and also like if there's something that goes wrong with the whole ski deployment the second time I think it's good to have like a bit of buffer where we can you know if we go for Gordy we don't have any other variable to control um we could also choose to do sepolia first sefolio has a smaller validator set um so it might be a bit more easy to coordinate the upgrade but yeah either sapolia or Gordy at least are stable and we can just think about deploying the fork rather than the stability

that has worked you know the Gorly

Danny Ryan: first argument given the deprecation uh it seems like a sound argument to me

Enrico Del Fante: yeah I think we can get to more insight from 360 prefix blobs if we do that one first otherwise so small that might not get enough information

Tim Beiko: yeah and we agreed as well a couple calls ago to not like if if three six is bad just leave it as is on one test net and you know shift the value for other test Nets um so in that case yeah I I'd also leave the words Gorly being the one that's like not up to maintenance spec if there's a change to be made yeah

yep

Enrico Del Fante: yeah I considering that is doomed to be deprecated it would go away with

three six

Danny Ryan: yeah so Tim's second point was with respect to timelines uh and whether a first test net is in the cards to be forked prior to Dev connect called you know first week of November so um is there a reaction to that type of timeline intended um One Way Or the other

Sean Anderson: uh on the lighthouse side I think we can

make that timeline um I'm Keen to start testing on like bigger test Nets because it is like the um like the networking component would be like the most like at this point an unknown that could require more work so I think it'd be good to get more information about that more quickly and then just on our development side where in the process of getting the dinab work merged into our unstable branch and I think that's probably the Locker for us in terms of getting it into one of the bigger devnets but we

should definitely have it in by by devconnect so

Mars and chat

Danny Ryan: says lfg any other reactions to the timeline

I think we are on that in mind it's okay with this timeline barrier

Danny Ryan: are we intending to do some mainnet Shadow Forks as we move into the test net progression because that also depending on how many how we scale up nodes and stuff could give us some

interesting data

Parithosh Jayanthi: yeah we can plan for that uh I think the main issue is that our the nodes we land for I mean that shadow Fox tend to be quite well provisioned which means like the blobs won't really stress them um I'm Loosely in favor of having smaller nodes but a larger Network like more physical nodes in the network um so that we can test more peer-to-peer related timing issues ETC that might teach us more but if there's more appetite for midnight Shadow Fox I can do that first

which I was prefer

Danny Ryan: um yeah I mean mainnet Shadow Forks but

in the direction of slightly low resource and more nodes or other types of tests that are have more nodes I think is gonna push us in the direction of a match that's interesting

Parithosh Jayanthi: yep once we have uh tap net9 up and running we can look to start doing that kind of guess I would guess that's what we would spend most of October on

awesome

Danny Ryan: any other comments or reactions to uh timelines or anything Tim brought up

okay other

Dane

Danny Ryan: related items um let's see Enrico put up a link to a um it's either an issue or PR about some uh discussion in relation to adjusting the attestation timing window Enrico can you give us some context here

Enrico Del Fante: yeah it was more uh focused on not this specific new attributes that has been discussing actively discussing the pr is more on the configuration changes that we recently had uh let's say starting from the networking configuration that at some point we did they become configuration this triggers some interoperability issues especially sometimes with the light client um with Lighthouse sorry um and this was because at some point the validator client that's used Beacon node so remote validator clients lost

the configuration from the bigger node and if you don't have a pretty rated your bigger node with the new value the VC will not start because the new version expected these parameters to be and so what we did recently very recently at least on The Deco side on the VC side we we try to start from a known configuration and no preset and then apply the attributes the parameters coming from the beacon node endpoint which means that if if the beaker node

is still on Old configuration the VC side still get all the all the other all the parameters that expects so it should fix everything that happened in the past but I know if the other clients what are the logic on the other clients uh when they start VC getting configurations from the beaker node so I think on the taco side we should in a better position to try to avoid those configuration changes and breaking changes

Danny Ryan: okay so we're saying

if the VC is out of sync with configuration changes in the beacon node we can sometimes have failures

Marius van der Wijden: yeah

Danny Ryan: so there might be a better practice to pull down configuration values from the beacon node instead of strictly only respecting what's local to the VC or am I missing something

Enrico Del Fante: yeah I I so previously we were applying only the preset and then all of the configuration from the beacon node so this opens the door of having bigger node not providing everything that BBC expect and force The Operators to have to upgrade the bigger node first and

then the values of Client First after and then if you are also have a mix of VC from one client and the BN from another client you have to make sure that the other client has updated the configuration first so he he happened uh recently so techno now applies also the configuration from from from the VC perspective so ignoring well yeah get it getting the information the updated information that we value their client has

locally so even if the bikaner is slightly older it can still get all the

Danny Ryan: I see um do clients have reactions to this strategy that techu is using

Sean Anderson: uh I'd have to look into what Lighthouse does in the scenario but I thought we just like loaded configuration in both the validator and the beacon and we would just log if they don't match in the the like based on the HTTP request um but I don't remember what we do if

there's a mismatch

you know

Enrico Del Fante: we learn where we do some warning when we can ignore something that is not mandatory but now we we actually default to to a known value and then override if Beacon provides the information seems like a nice strategy so it could if all the clients applies this and there is no drawbacks it could be reduced the interoperability issues when new config arrives

Danny Ryan: right so you're taking the strategy of Beacon node config trumps the BC config in the event that that doesn't break anything um Enrico is there maybe we should Elevate this to a maybe an issue in the beacon apis for further discussion rather than embedded in this since the specs issue

Enrico Del Fante: yeah I could yeah it could be a nice place where we could start a discussion there yeah yeah

Danny Ryan: would you mind quick you're just writing up a quick version of this there any other perspective or comments on

this otherwise we're going to take it into the beacon apis uh repo um are there any other items that weren't on the agenda that people like to discuss today okay then quick and easy that usually means that

the hard work is not on the call it's happening in the plants um cool so let's uh keep things moving forward for devnet9 next week and otherwise talk to you all soon take care everyone thank you

bye everyone thank you brother thank you thank you thanks bud

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