All Core Devs - Consensus #113

Transcript

foreign

Alex Stokes: I'll put the agenda here in the chat I'll be moderating today um and it looks like the agenda itself is pretty short so uh yeah I guess we'll just go ahead and dive in

uh the first thing uh would be updates on test Nets testing uh development of different things for genob uh so I know we have been working on devnet7 and there might have been some chatter about devnet 8.

does anyone hear uh feel compelled to give an update or would like to

Parithosh Jayanthi: yeah I can go with the update um so we we've had devnet up for a while now um it's mostly stable we have almost every client combination um represented there I think uh airguns here to be added but that's the biggest one that's missing um there's a issue tracker I will share the link in a little bit where where where uh we're tracking the the different state that each client is in um we also have a bunch of open issues there once um once we're figuring out the root cause and the patch we also

just update the issue tracker um in the meantime anyone who's working on tooling for four eight four four please feel free to test it out against um against this devnet blob scans been updated as well um to to include data from 4844 I think we have something like 9000 ish blobs at this point and uh this is still as of yesterday but there's there's like a blob spammer and there's like a whole days lots of blobs that that should be indexed at some point I guess um and we seem to be doing okay there

Alex Stokes: cool that's exciting to hear um do we want to just briefly touch on devnet 8 I think that was the one that

was cited to have like the full Cancun slash deneb EIP set um but maybe we're not quite there uh go ahead

Marius van der Wijden: quickly before we go to devnet8 uh one thing I noticed on Death Note 7 was when like I uh I let my lighthouse guest North uh full sync and I got really slow uh just uh when it arrived at the head um so it would be nice if all clients could check uh their perform performance uh right around the head I think the issue was that if you needed to download all the blobs and verify the blobs but like the

most current blocks and um so it would be nice if other consensus clients could test it on devnet subject already anyway sorry

um definitely date more

Parithosh Jayanthi: yeah um so the link for the devnet 8 specs are there um I we will either Barnabas or I will try and make sure that it's up to date over the next days but the ideas that we wanna first have hype tests looking good and then we want to be able to run like a local test net and then we'll spin up.net8 so I think there's still like a couple of phases before we're ready to coordinate that

Alex Stokes: um gotcha that makes a lot of sense

um cool okay so sounds like maybe we want to look at performance on seven uh if your client's near the head and anything else anyone wants to bring up right now for Devin S7 the Forward Thinking is still possible till next week Tuesday and after that we're gonna be outside of the period Then only checkpoint sync is will be available so if you want to check something with the syncing from Genesis you have like a few more days to do

Parithosh Jayanthi: also some client has an archive flag where you just never delete uh blobs I

think that's the perfect time to be testing it and if you don't want to test it let us know and we'll test it

thank you

Alex Stokes: when you said forward sync you mean with a blob expiry

Barnabas Busa: yes

Alex Stokes: okay gotcha yeah I mean that's actually a good thing to see live see how it works um once we go through that first window

Barnabas Busa: we've done it in them not six I think and uh from that point on you have to do checkpoint sync otherwise you're not

going to be able to sync anymore if you don't have any archive notes

Alex Stokes: okay well uh so yeah client teams who are listening take note and yeah otherwise it sounds like things are moving along so that's exciting to hear

next up on the agenda we uh have this note about continuing the P2P discussion I think uh uh was this I think it was the last 4844 implementers call uh we essentially had this note around uh Gossip sub with P2P and like part of how this works so my understanding is

that basically there's like a flood sub mode that uh kind of runs by default and there's like some concern that uh you know it will slow performance of things once we add the much bigger messages with the blobs uh does anyone here uh have anything to add I know I think some client teams are looking into this feature maybe if it could be enabled or disabled more granularly than it could be now um different strategies around publishing and and things like that

Sean Anderson: uh so I was hoping to catch up with Adrian from our team before this call

but he's off this week um I did a little bit of digging though and I found some work that um he and akihito from our team had done around this and they had made an implementation of like a smarter flood publishing strategy in Russell at P2P and had seen like a 30 Improvement on like latency in publishing for like messages at around like 50 kilobytes um so it's just like a bit of like the scale context

Alex Stokes: cool yeah uh as I understand this isn't

a blocker for 444 but definitely something that we'd like to ship uh at some point sooner rather than later so um yeah sounds like we can maybe just wait uh see if age has anything to add uh any other clients thinking about this sort of looked into this issue

uh actually

actually we have a list of improvement that that we want to do with gossip sub protocol but but uh but uh we are discussing that the first thing that we can do right now is to disable the publish uh we because actually we we we can still enable the first publish uh

and and and change how it works but but that requires the the the sharing right it is quite the patch but so uh uh we can just disable it right now like because it is the fastest thing that we can do and and we can improve the first publish protocol later

Alex Stokes: okay sounds good sounds like there might be it on the subject will btp topic so we'll just keep moving

to the agenda next up is this e-star upgrade name

uh let's see there's a con oh this is uh this comment here so yeah we we are here we have enough visibility in the next hard Fork that uh you know we can start to think of a name uh the El Fork will be called prog following our scheme and following our CL scheme uh we would like to pick a star in this universe and or maybe not even in this universe but some star and uh the name should start with an e so I'm just looking at this comment uh it looks like there's an eighth magician's post here people like Electra uh it says Danny like eniff uh Danny's not here though so I'm not

sure how strongly feels about that I'm assuming this has ever been not suggested air I there's a couple different posts here so yeah I don't know if anyone wants to like chime in their opinion but we're not going to spend much time on this uh at least synchronously I'm seeing a bunch of electras in the chat uniform uniform electrodes and we can call it electrog thank you again um so anyway I suppose if you uh really want to chime in I'll put these posts

here where there's been some other discussion although it seems like people really like Elektra and yeah maybe we'll just go ahead and assume that and if we all say it everyone else will have to say it as well um cool thanks everyone EIP I'm looking at this next agenda item comment all right I don't know why we're talking about this well okay interesting uh has anyone thought about eip's they like to get in for this next Fork then um this is on the agenda I think Danny probably added this he linked to 7002 uh

so I think that oh sorry there's a few more down here so 7002 execution uh layer triggerable exits six one one zero which is uh I think this is moving the deposits like reworking how the deposits work there's 7251 the max effective balance proposal I don't know if Mike is on the call but that's uh something he's been working on and okay I think uh Danny put this on here he just wanted people to be aware of this and if there's anything else that you would like to start to get into the discussion uh especially with respect to like the CL or any like cross layer

features that would also involve the CL go ahead and add them to this issue I'll drop the link in the chat uh there we go vertical and VLS yeah those would be nice so there's some there's some uh chatter in the chat around some other ones but I'll just let that be for now point being start thinking about it uh you know presumably we're shipping dencoon very soon you know the next couple months and uh we will get to decide or at the end at that point we'll get to uh think about what comes next so

so that's for that and next up uh we'll just move to General more like uh research spec topics one is here uh I think from Matt who wants to talk about web3 signer standardization uh uh so I think basically there is a web like there is a standard for this API and maybe let's see is Mountain McCall yeah do you wanna

Alex Stokes: do you want to give us an overview of this

Matt Nelson: uh yeah sure so the goal here is to basically standardize a remote signing API similar to the you know the rest of the apis that we have in the specifications uh the reason being is that there's you

know traction around remote signing and integration with clients uh and all these other things that we're working on we want to make sure that it's pretty easy to you know integrate essentially remote siding into the consensus layer clients so the goal of us of this is to take what we already have uh in web3 signer basically clean it up a little bit and then put it out for kind of a comment and feedback period and then whatever we decide is a community we will basically standardize back into web3 signer and then uh of course going forward we can you know maintain that against new Forks new functionality and uh we'll be working out of that kind of Standards repo as opposed to just setting a standard within the product

itself so yeah basically the goal of of this was just to bring attention to it we're going to work to open up a repository in the ethereum GitHub for these remote signing apis uh and when that's done we definitely want a little bit of feedback in comments uh to make sure that we have a pretty reasonable view of the API and then it's you know again it's intended to be long-lived and we'll continue to update it through hard forks and through spec changes um so that when clients go to integrate remote signing they don't have to go through a lot of headaches with web3 signer they can go straight to the standard so that's pretty much it

Alex Stokes: cool things yeah I mean they missed a

lot of sense this seems like an API that uh is you know has a good amount of adoption so the general strategy of uh you know making it a little more polished and kind of more formally supporting it I also think it makes a lot of sense so yeah thanks for the notice uh if anyone's listening and you rely on this uh take note and yeah come back when uh when there's an update on on the API okay

so uh next thing on the agenda there's an issue from dap lion uh actually this is a PR so

let's see is that line here I'll just let you take over uh otherwise I can give a little summary yes I'm here okay hey

dapplion: so yeah the background of these proposal is that as you know different items of the roadmap most namely ssf are much higher to deliver if we have a big State a large count of indexes so we have different purposes starting around to deal with it if we don't deal with it we need different crypto and other stuff there is good proposals around this anyway so the point of this proposal is we could very easily for the nip potentially

um limit the churn it's questionable if we if it's positive for ethereum and it's positive to have such a big account of indexes so we could limit the turn and then by us some time to deal for the electro Fork for a more proper solution like limit increase in Max effect the balance or having some in protocol consolation so this would just cap the max churn so that we don't find ourselves with a 2 million ballet account in about nine to ten months okay yeah

Alex Stokes: I mean it's not uh you know

it's not a wild option um I do have to wonder like if we were to do this you know it does kind of like marginally affect small stickers more uh just because like essentially you're capped like now everyone slows down in terms of like exiting and it seems like if you have more validators then uh that's more less of an issue for you but yeah on the other hand we don't want the set to be two million evaluators like you said so yeah I don't know if anyone else has had a chance to look um this is something we could do I don't have like a much longer opinion on it at

the moment

dapplion: so I'm aware the discussion is for Electra but these could be considered for an app otherwise I don't think it has that much of a use case

Alex Stokes: it seems like it's we don't want to be changing the dinab schedule the slate in the game and I do kind of agree that it might not matter as much uh if we can't do it that quickly

dapplion: so I would say technically this is a very simple change probably just a couple lines on every single client I think it's most about getting it right in terms of security and political implications

Alex Stokes: those are important concerns

how does you have your hand up very much are you talking POTUS can anyone hear him

dapplion: I hear something very very

Alex Stokes: yeah it's like really tiny okay yeah try that one more time

Potuz: yeah now it should work

all right

Potuz: the issue that I find is that since this involves a political

discussion and it's very very unrealistically that's ever going to happen that we're going to get into consensus on this uh by the nav uh and since this seems like a very simple change that we could actually put in a in a just purely consensus hard work that we can just ship quickly uh I'd suggest looking into other Alternatives and if we don't find anything we can just ship this I would prefer personally to use a different PR from a double lion I would prefer that we actually compromise ourselves to quickly ship the ReUse of indices

um after or with this we could just think about this Max EB increase because that would certainly allow us to like reduce the number of elevators quickly and I think that's that's a cure more than just uh as Danny put it as a Band-Aid

Alex Stokes: yeah I tend to agree I mean this is like something we can do and it's almost like you know if we found ourselves overnight in a terrible situation of too many violators then yeah we could like think you know it doesn't seem so urgent we need to do it in the next like you know a couple months um and then one round longer time scale we have other options to to think about

as well so it's more just probably a process of considering all the different trade-offs of these different options and picking them when we like the best I don't it doesn't feel like we should be thinking about changing the denab schedule like no like if anything we should just be like shipping it up like in the next couple of months

dapplion: so I don't think it's realistic the thing that will ship so fast that hope I'm proven it wrong

Potuz: what I do think is that we need to lose the fear of having consensus layer only Forks so that we can actually deal with these issues

Alex Stokes: I don't know if there's like fear it's just like even if we do a CL only fork it's just so much overhead like even for just the sail devs on the call right so um you know it's just not something to really take lightly but certainly if we got to like an issue if everyone was convinced that like the network is going to be in a really bad place soon then we could have a sale only fork soon it doesn't seem like we're quite there yet or anywhere near it really

dapplion: I guess just to test the waters now

we're here is there any strong opposition from anyone on the idea of copying the churn

Alex Stokes: the only thing I would say is if we're doing something in parallel like for example max effective balance where we know we're going to also be touching the size of the set then you know we don't necessarily need to be doing other things um and that would just probably come down to the timing of these various features right

correct me if I'm wrong I mean but we've brought up these other issues of max effective balance and uh reusing validator indices but neither of those are specced out to the degree that we would need

to implement them quickly um correct so like this is really just I mean this could be done real quite simply this is almost like difficulty bomb pushing back level of trivial but yeah I just I would just say this seems like a much easier thing to do um to buy us time for those other things because I don't think they're they're specked out

dapplion: yeah and I want to point out if say the same goes to the 2 million and then we find ways to shrink it that is some dead buckets that will have to pay forever

until we get to a point where consensus clients can deal with state in a very significant way than they do today because as I'm aware of every single client needs to have a full State loaded in memory to do anything basically so the dead weight in the state has a cost

Miguel

Mikhail Kalinin: um I personally don't think that reusing indices will help us that much here as if the activation queue will remain full as it is today uh so we'll see these two million welders as a lion has mentioned quite soon

um I don't see how the their uh we're using

Michelle

Potuz: reusing indices is used with the increase of is tied with the increase of mass effective balance so this two together reduce drastically the number of validators

Mikhail Kalinin: okay but yeah yeah sure but before that time before we have this max effective balance increase um we can get to this number quickly assuming that the cube will be full I mean like we will not deliver max effective balance before these two million while there's in in the set before we see them in this in the weather set that's that's the point so it is like a kind of a

countermeasure so I mean like uh and if we have these two million welders and while they're sad it would mean that in terms of attestation and attestation aggregation the load will increase uh three times or yeah three times at least I don't know how this is sufficient um how this how bad it is in terms of aggregation but from what I've heard that the aggregation is almost at its capacity today um and if we drop mobile layers on the

network it's purchased you know I can get really worse and I don't believe that we will have a hard work to deliver this feature only even if it is a CL hard sport it requires software upgrade so it requires coordination of not operators and all this stuff and all the um related things

Alex Stokes: yeah I think unless it was like very obvious like almost an emergency then uh you know the Temptation would be too high to like slip some other stuff in

and then suddenly we just have another you know regularly sized hard Fork um but yeah I mean I did again this is like uh you know card to keep on the table I don't know if we need to make it I mean it feels like we don't need to make a decision right now um certainly I don't think we need to think about putting it in the NAB so uh we'll just continue the conversation as things evolve obviously if we come back in two weeks and like the state is twice as big that's a different conversation

Mikhail Kalinin: yes so um and assuming that the activation queue will be full all the time uh which

is not unrealistic assumption I guess um and if we don't do something about um whether sat uh uh the speed of growth of whether it's that so we will get this 2 million uh whether it's in nine months and yeah if clients are fine with that I mean like in coping with this load then that's probably fine really and nothing to care about but if not then I think we should pay more attention to thinking on whether to do this or any other countermeasures um really quick

ly

dapplion: yeah so I see you with with this PR we have to choose a value and choosing that value comes with an opinion that can be controversial but I think it's important to accept that before the beacon chain started we chose a base reward and that's a very opinionated decision that clearly motivates the market into staking more or less so if we took that opinion decision at the time I don't see why we can do that again especially as the landscape has changed dramatically from when the beacon chain was designed and today

so yeah I wanna motivate or at least disperse the fears that this is not such a controversial thing that we have done in the past and we could do that again to adjust to market conditions

Alex Stokes: wait sorry uh or use maybe I misheard you but something are you trying to link like the reward schedule to this change with the the tournament

if we

dapplion: if we chose a base reward that produced a widely different API API that

we have today we may not see the queue as full so that's a direct incentive for it that's causing these big States

Alex Stokes: sure yeah I mean so again touching that knob you're now touching like our security spend which is just something we want to like very carefully think about um which like you know zooming out some this is like all of these different proposals kind of touch on like either very like core security or economic concerns or like otherwise very political concerns which is why they're just uh they can get kind of

Airy

dapplion: true my point is on the design phase when the base rewards fee was chosen if we had if we could look into the future

and see the colors that we can chain I'm not sure that that value was picked like I I don't know if anyone anticipated that there would be Center demand for speaking um so acknowledging this reality just we are not going to change anything which is going to slow the inbound it doesn't look like such a dramatic change

Alex Stokes: there is a curve that's like responsive to Demand right so like this there was some decision made um it's not that it's like flat right

Dankrad Feist: I mean I would say I agree that the reward course was the most uh thing to

adjust if we want if we want uh to change the amount of

if I don't think he was necessarily saying that we change the reward curve I think he was just saying that it was a sort of political decision to begin with and and that this is a much less dramatic decision this is simply limiting the rate of incoming validators it's not saying you can't stake or anything it's just the growth is quite High well

Dankrad Feist: but effectively it does change basically it means that you're giving preferences

to those who have already staked true over those who want to studying so it is also an economic decision so the fairer way to adjust it is to adjust the reward curve to get into New Balance rather than giving preference to those who have already

stated

Ansgar Dietrichs: yeah I just wanted to briefly say on this topic that there have been some thoughts in the past to just basically completely changed the way we we do we dislocate validator rewards to more explicitly kind of Target specific participation sizes and and then a month of each stake everything kind of just

shifting the the reward curve might be a good kind of just pragmatic first step in that direction before we make the kind of bigger more and more kind of deeper deep rooted change um but even before then maybe I would say one thing that would be very just useful to do in the very short term would be to just start communicating that the way we pay out rewards for staking might just change in the future so no one should basically no one should make a decision about staking they eat relying on that basic the payment schedule will still be in place here from now five years from now um I think business is preparing the community for that this might change in the future would be very valuable to do in the short term already

Alex Stokes: yeah I mean that makes sense and like you know one way we do that is like having these conversations on these calls so if people are listening then they can start to understand that maybe something will change so that being said uh I think we might be done with that topic unless there's any final comments uh otherwise I'll open this up uh are there any any final remarks or things not on the agenda anyone wants to discuss uh otherwise we can go ahead and wrap up a little bit earlier today

okay sounds like no uh I'll go ahead and call it thanks everyone for attending and uh we'll go ahead and close

thank you thank you bye

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