All Core Devs - Consensus #149

Transcript

[Music] get a group here. Uh, let's see. Josh, are you able to help with the stream? Okay, cool. Thanks. So, let me grab the agenda I just lost. Here we go. Okay,

Alex Stokes: everyone. This is consens consensus layer call 149. I'll put the link to the agenda here in the chat. Uh it's issue 1258 on the piano repo that we all know and love.

And yeah, so the agenda is pretty light today. I imagine everyone's really busy with DevNet 5 and getting pect ready for mainet. So yeah, let's go ahead and uh just jump in. And first up, yeah, we'll open with DevNet 5. Uh I'd love to hear how we think about how this is going. Um I know there have been a number of issues uh with clients people have been working through. I looked at the DevNet yesterday and this morning and yeah it's well it's looking better this morning than yesterday uh in terms of the chain health uh but we still aren't finalizing. So, um, yeah, anyone want to give an overview of, uh, the latest

progress there and if there's anything we need to touch on to get back to finalizing.

Um, yes. Uh, so Perry's not around, so I'm giving the update. Um, yeah, regarding Defet 5, as you said, we had a couple of problems there. It's currently not finalizing. There was a problem with um regards with uh gases as a gas estimation bug uh which caused like a three-way fork uh between GE. There was Nethermind and Aragon um that has been patched and um we now have like um Nethermind and at the same fork. Uh but there's also on the rest side there's like another issue that

they are uh actively uh looking into right now. Um we also had a bunch of changes on Aragon that just got merged uh that we have deployed recently. Um there is also a bug on some bisu nodes that are being investigated by the team and um we have also updated um yeah that's mainly on def 5 and then uh regarding also tests and hive um we have updated hive to uh the latest images we also updated the curtosis configs on the interrupt channel on the pinned messages. Um, and

yeah, we we tried to run a uh execute a hive run just before this um call to to kind of uh yeah, tell you guys the results, but unfortunately that hyphen failed. So, we yeah, we have to investigate why that happened and just re-trigger it. yeah, I I think that's mainly it regarding DevNet 5 and uh which means that yeah, we we are just we have all the client teams looking into these bugs and yeah they they basically have to be fixed and uh there's also regarding definite 6. So there's going to be um an execution spec

test release um soonish and we are basically going to uh rely on that release to also um run hive tests against the clients. And once we have like these definite five bugs fixed and uh start running these hive tests, I think then we we will be ready like to start definite 6. Okay, great.

Alex Stokes: Thanks uh Mario.

Mario Vega: Yeah, so we have two trackers now. So the first one I'll share it here is the uh DevNet uh 5 1.3.0 uh release. This is basically compatible

with 1.2. to um and we're just waiting waiting on a couple of PRs to be merged before we make we tag the release and and just make make the release to to the clients. Um this still does not contain any breaking change. U so it should be compiled with the clients that are now right now running on the net 5 sorry and we also have another uh tracker here which is just contains one more issue. Um and this this should be the one that we see if we are going to launch a 10.6 six. Um, so this will contain the the up update to 7702 and this is incompatible with the client's current Dev 5 releases. Um, yeah, that's basically it.

If there are any comments, please just uh chime in and and to see if if we can uh make any changes that are necessary, just let let us know, please.

Alex Stokes: Cool. Awesome. Thank you so much. Uh yeah, I mean that was going to be my next question is what was the difference between six and five on the spec level? And yeah, there was a 7702 change. Um let's see. I mean I think that tees us up for another thing I wanted to call out. Uh which was essentially the CL specs release coming up. Uh it'll be let's see I believe beta 1. Yeah, so version 150 beta 1. The only change from zero to one here on the CL side uh is some extra testing at the moment.

So yeah, nothing substantial there. And then in terms of specs on the EL side, there's a 7702 change. So yeah, I mean given the turbulence in DevNet 5, uh and yeah, the the spec change with 7702, DevNet 6 makes sense. And yeah. Okay. I guess that's where we're at. Um, anyone? Yeah, I guess one question is like timing wise, do we want to aim for DevNet 6 like next week? Is like even, you know, early next week would be ideal? Um, anyone feel like that's too

aggressive or is there any sense of timing to fix 5?

Mario Vega: Mario? Yeah. So maybe I can give a um um an update on the timing release of Den 6 release. I think um I think yes it's doable. Uh we just have to merge basically two PRs for the five uh new release and one for the other one. So I think it's doable. We have to make the changes on still but I think they are pretty manageable. Yeah. So next week sounds sounds good on the testing side.

Yeah. I mean, as I mentioned, like once clients have fixed the bugs that they are looking into currently on DevNet 5 and like the hive tests are passing, we

we can do it.

Alex Stokes: Okay, great.

Yeah,

Perry's

also saying in this chat that um yeah, we are planning also shadow fork. Okay.

Alex Stokes: Yeah. Amazing. Uh, we got a thumbs up from Nethermind. Any client teams feel like do they feel good about this? Do they feel like it's too aggressive? Um, point being is as soon as we knock this out, we can then think about test nets and mainet. So, we would like to ship Petra as quickly as possible as we all know.

Uh, Tim has a question. Do we want all DevNet 5 bugs fixed or do we want in DevNet 6 ready teams? Yeah. So this is a good question like you know rather than blocking on every less issue with five we get to go ahead and pipeline six of it. Um anyone opposed to something like this we could basically say clients who are ready with net 5 now then we can turn around and launch six you know again pretty early next week.

Sean Anderson: I like that idea.

Justin Florentine: Yeah. Same.

Very cool.

Marek Moraczyński: So I think it would be good to verify that clients fix Devet 5 bugs.

So we can use this network to test but it shouldn't block us to start uh Devet 6 with the clients that are ready. That's my opinion. Great.

Alex Stokes: Let's see. And there is Okay. So it looks like uh this PR is open. Is this the 7702 update? I don't know if this was an update to the update. Uh, PR 9248. I lost track of who was owning these changes. Is anyone here responsible for them?

Do we have is Onsgar on the call? You're an author here. I don't see him. Oh, here you are.

Yes, I was uh ago which which

Alex Stokes: is to 7702. Uh so there was a kind of last minute update over the last week or two and yeah in any case like Lance here he says I'll merge it. So I think I think Matt has had the the closest kind of focus on the AP.

Okay thanks. Uh, so great, we can do that and yeah, that should have all the specs settled and then we'll get the testing released together and we'll pipeline DevNet 6, get it out the door as soon as we can. Very good. Anything else on Pekra? Um, we could go ahead and talk about potential test net or mainet work timings. Uh, I don't know if that's going to be a bit of a distraction for us today.

Do we want to wait until DevNet 6 is out and looks stable before talking about that in earnest? Okay, I'll assume that's a yes. Uh but in that case then maybe since the bugs are known, right? Well, and more I mean more just to get you know start to build a consensus around timelines. Like ideally we can have six out next week and hopefully it looks perfect and from there

uh yeah we can at least think about moving to test nets uh in February. Yeah. Okay. Look at the calendar might be a little tight but yeah I mean again ideally then we can do chest mats in February and aim for a March mainet fork. Does anyone disagree with these highle timelines? Okay, we got let's try.

Okay. Yeah. So, yeah, there's there's generally consensus in the chat. So, yeah, I think that'll generally be the plan and then sure, you know, as things come up, we'll have to maybe adjust here or there, but seems achievable to me. Um, oh yeah, Tim has a nice comment here. So if we fork before March 13th, uh that would be less than one year since we shipped the blobs to then turn around and upgrade the blobs again, which is super cool. So yeah, that gives us some anchor in mid-March. And that'll just mean, yeah, we'll be quite busy with uh releases and then also the test forks in February.

But assuming we can get five and six wrapped up in the next week, let's say, I think we'll be in a really good place for that. Yeah. Okay. So Tim here has a suggestion. Say we go for like March 11th for mainet then that would suggest yeah I think what is that the second week of February either way Feb, you know 12th through 19th or then a shot a week to 19 or 26 for test nets. So February is kind of short. Those are kind of pretty much our only options.

But from the chat it sounds like people are generally okay with this.

Tim Beiko: So if we wanted to do February 12th, it means we want the client releases out say on February 3rd, which is less than two weeks from now. If we wanted to do February like 19th for the first and we want the fe the releases out maybe for like February 10th, which is like three weeks a bit less than 3 weeks from now. So I don't know if like yeah, practically teams have a deal of like is two-ish weeks reasonable for test net releases? Is three weeks more reasonable? Um, yeah.

Alex Stokes: I feel like historically it's been more like two and Yeah.

I mean

Tim Beiko: from now, right? It's more like Yeah. So from now, do we think we can actually get kind releases in like two weeks? Yeah. Or is it more like three weeks? Yeah.

I think we can do two weeks on the lighthouse side. cool.

Alex Stokes: So, yeah, I mean, focus on devet five bugs. We'll get six up next week. Then from there, uh assuming six looks great.

Then, yeah, we can charge ahead with releases and two test sites in February. No one everyone seems to be generally on the same page that this is not impossible which is good to hear.

Tim Beiko: Great. So maybe in terms of next steps um I can propose some blocks uh as sync in the chat. We can agree to that on next week's call assuming things are going well and then if um if next if you know things are fine by next week's call. Uh clients should be ready to put out a release sometime between like next Thursday and the Monday after that. And

then we'd have the blog post go out um you know on somewhere between the 3rd and the fifth and then first folk first fork hosski and then

sapi

Alex Stokes: sounds great to me. Uh one question I'd have is if we can basically pipeline the test net releases like could we cut a release for the client each Yeah. Like could we have one client release that has both Sapolei and Kleski?

Tim Beiko: Yes. Sorry. Yeah, that was my assumption. So on Feb 3, we release clients for um yeah with with the fork blocks for both test nets and then once we fork the test net, we release uh clients with the fork block for mainet.

Alex Stokes: Okay, then. Uh, anything else on Peterra? Uh, sounds like we have a path to mainet, which is really exciting. And otherwise, yeah, everyone's pretty heads down on getting there. Anything else we should touch on right now? Okay, cool. Then we will move on in the agenda. Uh, next up, yeah, section around blob scaling. And yeah, I guess one uh question to ask is if there's been any update with uh the pyos work.

Uh there is a parallel stream with pure and I saw from the testing call the other day that uh people are kind of progressing but no no big update there for the moment.

Uh I can give a quick quick update. Sure. Uh yes so um run DevNet with Prism only during about five days. Uh but prism has a very slow memory leak and so the kubernetes cryptosis killed the prism super after 5 days not sure it's related to gardas and we're investigating it uh for since yesterday there is

lighthouse and prism which are ready to interrupt. Uh so the devs started to interrupt lighthouse and prism there is some issues and we are investigating and other clients are uh still implementing the spec uh for the next DevNet. Oh yeah, progress is progress. I'll take it.

Alex Stokes: Um yeah, great. So yeah, I mean hopefully once Spectra is out, you know, this should be on top of everyone's mind and uh yeah, we can really dig into PDOS on top of the foundation from uh yeah, this work stream that's been happening

in parallel. Thank you.

Ansgar Dietrichs: Maybe just a just a quick remark on on that point. Wait, wrong microphone. Yeah, I can hear you. Um yeah, just a quick on on that. Uh I think right now for these uh devets or the preparation for the dev nets we are still using relatively low throughput numbers just to to make it easier to basically reach stability there but just to basically the expectations are set right like I think at least the goal maybe it's a bit of a stretch goal but the stretch goal basically for pas would in principle be to like roll it out at 8x the throughput of um pectra so basically 69 both values times 8

basically more or less because that is in principle on paper kind of like the efficiency gains you should get going to sampling. Now the expectation is that then once we kind of have mature dev nets there might be some bottlenecks that we run into that basically just like will require some work to to resolve so that maybe we then decide to not actually ship Fusaka quite at that level and we go back down a little bit but just so that people don't expect that just the throughput levels would be the ones that that are basically the target for for Fusaka just so that kind of that expectation is set as early as possible. Um yeah just wanted to mention that

Sorry,

what what numbers did you say?

Ansgar Dietrichs: Basically um eight times the uh pectra throughput. So wait, what is that? 6 * 8. So like 48 and 9 * 8. So 72 48 72 should be like the at least the the what we should aim for for like mature devets and then we can see if we can actually stay at that level or if we have to go back down before we roll it out. But but yeah, 4872 I think should like would be the logical on paper kind of goal to aim for here given the efficiency gains of sampling. Cool.

Alex Stokes: More blobs is better. So yeah, uh that'll be really exciting to see.

Okay. Uh if there's nothing else around Purdos in particular, I did want to bring up this idea uh a number of people have been discussing lately uh on Twitter and various places like yeah essentially how can we think about uh making core development uh faster essentially uh with lower latency to these different things and you know one obvious suggestion would be to parallelize things uh there's this concept that's come up of a blob parameter only fork a BPO fork where we would essentially make a commitment to treat the blobs kind of like very fully as a different layer of the stack. And in doing so, you could imagine that uh

once we are convinced that uh you know some increase to the blob count say like what is suggesting with uh with pios and this adex scaling once we know that's ready to go we basically green light that uh and have some sort of accelerated uh stream or lane let's say through ACD to make that happen. Um, I think it's a pretty exciting idea and yeah, I'm not sure if anyone else has uh seen this, but in any case, I did want to bring it up, get it on your radar. I think it's a really interesting prompt just to think about like, yeah, you know, we do have these very important parts of the protocol. And, you know, sometimes, uh, we can get really in the weeds with some particular EIP discussion, which then can block other

things. Um, given again how important blobs are to scaling Ethereum, this seems like a natural fit to be one of these things that we kind of focus on in a special way. Terrence, do you have a comment?

Terence Tsao: Yeah. So, I think given the current testing, it's around 12 max blocks per block. I think eight times. I don't want to like sound like a negative Nancy, but it sounds I think it's a little hard. It could be a little harder than we think. I think it all depends on testing results. So I think like the sooner we can simulate the better. I suspect like we may need something like EPBS at the end of the day to do more delayed pipelining such that there are uh 12

second to propagate the blobs versus today is only one second because of we're close to the 4 second deadline. So I think timing might be an issue there.

Alex Stokes: Right. So I mean I think this was Ongar's point is like you know the max that peros would give us would be sort of this 8x scaling but then you know obviously if we're on test nets dubnets and we see that there are issues like this we we would scale it back down. Um yeah Franchesco had a question here. Is that because of local block building or yeah was there like something in particular where you started to see these tight timings?

Terence Tsao: I mean just today like timing game is inevitable right

builders there are even relayers they delay until three seconds to do anything because they get more time for the get header right so because of that you either see timing gain or if there's a huge am opportunity then builders are just willing to censor blobs they just choose not to include blob and that's not ideal either so yeah so you have this inherent like country uh country beating force at play,

Alex Stokes: Yeah. So, I mean, pipelining is good if we, you know, definitely if we find that we need it,

that's like a tool in our toolbox to also consider as we like think about these changes. And maybe circling back to this VPO idea, like you know that would be an obvious sort of caveat if you know we need like the vision with this VPO fork is that you know almost like the ice age but for the blob count you could imagine we have like almost semi-regular forks where you're like bumping up the blob counts to numbers that we have you know done the analysis and research to understand is safe. If we need say like some massive consensus change like moving from pure dos to you know some other DS construction then yeah it's not as simple as just dialing up a number and uh that's like a bit more complicated.

So you know and to your point this is something that we could see where it's like yeah you know we do run into some like timings either due to timing games or just like you know client software today then we might need more invasive changes to get to a safe spot. Kev has a question. This would be the worst case where toning games are being done and the proposer falls back, right? Well, I mean, so Terrence's point is that even with remote building or like using the M pipeline like builders still play timing games, but they basically just, you know, they do it at the expense of blobs. So, you know, blobs are relatively big. They also don't block propagation. And so what you

can do instead of um yeah like if if you want to like get that extra edge by like delaying a bit, you would just have fewer blobs and then you can still land on chain uh in time, but then yeah, there's there's less block throughput. My client has a comment here. the fact that we need to do analysis to verify a particular blob parameter increase is safe means it's nothing like difficulty bomb and yeah I mean maybe that wasn't a helpful analogy but ultimately the idea is to make a commitment as ACD to like focus on this

and yeah have it be like a primary thing that we think about um one point here to recognize is that a number of different layer 2 have reached out and I think they're very interested in helping us with any anal process we need to do. Um, so very much they they want more blobs. We want more blobs. We can work together to get more blobs. So, uh, yeah, I'm pretty optimistic that this is, uh, definitely at least an avenue worth exploring.

Oscar,

Ansgar Dietrichs: yeah, I just wanted to say on on this kind of general topic like I I do think ultimately blob throughput is mostly like a supply side thing, not a demand side thing. So basically yes we should

of course in terms of setting priorities always have an eye on like how many blobs could would there be demand for um and I think right now the answer is as many as we can give. So basically like definitely would it should be a priority for us but ultimately at the end of the day kind of there always the technical constraints of like within whatever thing we think is the the acceptable maximum load on any given node how many blobs of throughput can we have and then the only times that ever changes is usually whenever we actually change the protocol um in in one way or another um or I mentioned chat like for example if say we roll out a sh me pool design or something sometimes those could be out of protocol changes but still usually only when there's actual like an actual

change in how much we can sustain sustainably basically support. Um so I don't really see the case of like basically we can't just be like oh okay now there's more demand so like tomorrow we are increasing by by 20%. because presumably hopefully nodes already run at the maximum that they can support at any given technology stage,

Alex Stokes: right? Yeah. But I don't think we always know that, right? So like you could imagine that we do, you know, I think historically the ACD posture has been quite conservative. We could say, hey, you know, let's start with 36. And you know, did anything actually change with respect to get to 69? Well, what changed is just our confidence in seeing this on mainet understanding that, you know, it

actually works and that there's headroom to do this. So, I think that's where this sort of idea is coming from is like yes, we would have these like technical changes that would unlock sort of new regimes of like possible numbers, but you could still then imagine almost like a linear or like a scaling on some curve um to unlock more blobs. And in a world where that's the case, then something like a BPO fork or like sequence of forks, I think starts to make a lot of sense. There was another idea floating around that Tim shared here. Another version would be to move blob target control

under the validators domain. So the idea here would be treating it like the gas limit. Whereas today, you know, if we want to pump the gas to say 36 million, uh that's up for validators to signal and then as they go to build blocks, the gas limit can raise or lower over time. Uh there has been this idea to do this with the blobs as well. Um yeah, it's an interesting one. I don't know if anyone has any thoughts on this. Uh would we want to basically take the blob limit uh these blob parameters out of the protocol and put them into stakers hands?

Ben.

Um, I think it's I think it's an interesting idea and it would be good. However, it's a hard one because the gas limit's easy to vote on because it's so fine grained. Mhm. Um whereas the blob limit since it's you know hard low low value integer numbers I don't know how that would work unless you know people voted fractions like they do with the gas and only when it's passed or drop below you know you took the you can have five blobs when it's touched and touched.

Tim Beiko: So you can set the blob the uh let me get the name right here but the target blob

gasp per block and this would mean it's not necessarily like a full integer but I don't know so a researcher told me you could target a non- integer value um in the client but then I don't know if this is only true at a spec level but then you know the clients make all these assumptions around uh roundings internally that it would break Um but there could be a way to like yeah we we have a bit more of like a gradual uh like some gradual threshold a bit like the gas limit and then when we go over that threshold then you know we raise by one or lower by one right

Alex Stokes: that was what was suggesting just now but I mean at the end of the day

like the blobs are you know they're discreet they are relatively big so like it would be like say adding another 128 kilobyt for every increment, right? Um it's not something where you can like just very gradually do this and then if you think about it, it's like, okay, as like a homestaker like yeah, am I supposed to be like, oh yeah, I feel like I have more bandwidth. Let me just bump this up. Um I mean it would have it's an interesting idea.

It would have to be post where there's, you know, a lot more flexibility in the the capacity.

Alex Stokes: Mhm. Okay. So, some interest, but a lot of open questions it sounds like around having validators control the bottom. Um, cool. I did uh drop a link to more information if anyone's curious. Where did it go? So, there's an ETH mag editions post here. Um, CO has a nice post here. uh I think explaining more of

the idea. Let's see. I think I saw proto on the call. I don't know if you want to say anything else, but if not, uh yeah, I think to continue the conversation, go to ETH magicians. And yeah, definitely an interesting idea.

Protolambda: Yes, feedback welcome on Eve Magicians. We're here to support uh the safe increase of blobs.

Alex Stokes: Sweet. Thank you.

And yeah, I mean just from scanning the chat looks like there's more interest than I would have thought for having this be a validator control parameter. So I would say that's another avenue to explore. Cool. Okay. Uh if there's nothing else on the blobs for now, uh there was a comment here. Uh Tim wanted to make a suggestion around again improving ACD process and in particular a bit of a retrospective on Pekra. Uh Tim, I don't know if you'd want to give any context otherwise I can say a few words.

Tim Beiko: Um sure. So um as some of you may have noticed, uh people have opinions about awkward devs. Um and I think PETRA has been kind of a wild um fork in terms of coordination and planning and um also a lot has changed over the past couple years. So we've had a few of these um awkward devs like retrospectives in person at different points. Um but I think before we kind of jump into plan Fusaka, it might be worth having uh like longer conversation around how do we want to approach the process? are there things we want to do differently? I think we've done a couple tweaks in the past year which hopefully uh will be

good but um yeah I I wanted to open the floor of like you know one are people generally interested in this and then two how do people feel uh we should like gather input or feedback my sense is if we just like dedicate all core devs to this without any prior context it'll be kind of a mess. So, um I was thinking either we do some sort of like breakout room tracks or we have an ETH magicians thread where people can chime in and then you know I can try to summarize that before a call. Um oh yeah curious how people feel and then maybe the other dimension as well is like to what extent we want this to be you know client teams feedback versus like the community's

feedback and how we should potentially um you know separate those two things. Um yeah, so I guess it's kind of like a meta conversation about how we improve the process and then um if we do want to move forward from this uh based on the feedback today, I can make like a more concrete proposal of how we do this as we wrap up.

Alex Stokes: Yeah, I think it's a great idea. I think like you said and we all very much feel is quite of a yeah, wild hard fork relative to the others. So taking a moment to reflect and you know just generally check in with like ACD as as a body and as a process uh sounds super valuable. So yeah I mean I think what

you said with like having a magician thread we can leave that up for like say two weeks or something and then find an ACD to kind of discuss feedback and and have a conversation there.

Justin Florentine: I think um this is Justin from Basu here. I think wild probably means different things to different people. So, I'd love for whatever conversation we have to, you know, call it some of the explicit things and and cite examples of, hey, this was this was tough or stressful or or whatever the impression is.

Yeah, I agree. And I think one thing that could be quite helpful um for client team is if every client team could like think through this internally and then share some sort of summary kind of like we did for the hard fork uh inclusion proposal. So like understanding like you know this is what the

Basu

Tim Beiko: team thought and this is what like Netherm thought. Um and if people want to share their personal opinions in addition to that I think that that's fine as well. But like um yeah being able to like average out or get like the the the rough mapping of all the all the client teams would be good. And then um yeah and then I my sense is I would also open this for the community and we can figure out based on how much input like what do we want to do on a call but it

would be good to get like external observers and and users perspectives into this as well. Yeah. What's your sense having like should we just have one massive like awkward dev or sorry eth magicians thread or maybe like one that's like more community focused one you know I think at times we've talked about having sort of like gated participation not really but just to keep the conversation manageable I think I can handle one single thread um there's now an AI summarizer as well on each position so if it gets too wild we can rely on LLMs um and then I'll try yeah so I'll open a thread And then I'll try to like pin uh you know the client team's perspectives and then if there's

any particularly good comments or writeups uh to try and keep it a bit cleaned up. Um and based on how um based on how Pekra like shipping goes, we can find the right call where like we're kind of waiting around for it to activate on mainet or something to have a deeper discussion.

Alex Stokes: Yeah, sounds great. cool. Okay. Uh that was it on the agenda. Uh anything else anyone would like to discuss today?

Okay. Sounds like that's a no. And I assume that's because everyone is super focused on the DevNets and getting packer to mainet. So yeah, uh a bit of retro would be nice. It has Yeah, it's it's been it's been uh been quite a fork and we are almost at the finish line. So uh yeah, again, awesome to see everyone's work to get to this point and yeah, uh I guess we'll go ahead and call it for today. Um, the next thing I suppose will be the testing call Monday. We can check in with progress on the dev nets over the weekend.

Okay. Yeah, that's it. Thanks everyone. Byebye.

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