stokes:Okay, hey, everyone. Let me grab the agenda for the chat.
Transcript
stokes:So this is Acdc. 1, 57. The agenda is here is issue 1515 in the Pm. Repo.
stokes:And yeah.
stokes:a little bit on the lighter side today. We can touch on Petra if there's anything to follow up with. There we can turn to Fusaka.
stokes:and then a discussion around reconfiguring Acd. This is a post from Tim and our approach to Glamsterdam.
stokes:So let's go ahead and get started.
stokes:So 1st up, Petra. Anything to say here, I guess. 1st off congrats to everyone. It seems like the fork went really? Well.
stokes:it was a big one, and I know it was a lot of work from all of us. So yeah, good job, everyone.
stokes:Any other comments on Petra.
stokes:I'll call it here. Trent published the Petra pages, a number of perspectives from different core contributors.
stokes:Trent. Anything to say there.
Trent:No, just yes, pretty straightforward. Thank you for everybody who submitted. And it's it's always a really interesting snapshot, a lot of work to put these together, but I think in the end it's worth it to have like
Trent:a
Trent:perspective on what people were thinking in in the lead up to the fork. And yeah, I I hope these are useful. 5 years from now, I think some people.
Trent:you know, pushing them to respond to things like the Beacon Book are. It's it's tough around the time. But then you get to go back and look at it years later and have a better understanding of what people were thinking of what their focus was. So again, thanks for people who submitted, and if you didn't, you have the form open, and you know you just lost track of time. Just let us know if you submit and we can update the published post. But yeah, the link is in the chat. So thank you.
stokes:Cool. Thank you.
stokes:And yeah, Perry says, they're doing some analysis around the blob scaling because we increased the blob count and Petra.
stokes:And yeah, sounds like they want a little more time to see how things go. But yeah, super exciting.
stokes:Okay.
stokes:And if that's it for Petra we'll turn to Fusaka. So
stokes:one thing to touch on immediately is pure dos. Devnet 7, maybe Perry or Barnabas. He's here. Either of you have updates on Devnet 7.
Parithosh Jayanthi:Yeah, I can go. So the Devnet was launched a couple of days ago. I will just ping Barnabas for an update. But last. I know it was going stable, and we
Parithosh Jayanthi:are mainly working on getting Bpo. Support on every client right now. So we're mainly making the Ps. To make sure that the upstream tooling is ready for Bpo. But I don't think there's anything particular to report on. Devnet 7.
stokes:Yeah, right?
stokes:And yeah, then, that brings us to the next topic, Osaka devnet 0.
stokes:I'll grab this spec here just in case anybody wants it in the chat.
stokes:and I believe the plan for Monday was to have for Socket 0 be at least on the steel side, be pure dos. Devnet 7 along with Bpo.
stokes:so I don't know if there's any timeline yet again. Maybe, Perry, you have some information there.
Parithosh Jayanthi:Yeah, for Fussaka devnet 0. We had the deadline of 26th of May. And the idea is that it just has the MoD Xp gas cost increase from the El side pure das as well as figuring out everything required for Bpos.
stokes:Gotcha cool.
stokes:So yeah, I guess if you
stokes:want to catch up a bit more on that this was covered on Monday's call, and otherwise. Just have that on your radar?
stokes:Terrence asked. How is everyone testing the Vpo before devnet 0?
stokes:I would guess Kertosis.
Parithosh Jayanthi:Yeah, we just merged in the Bpo changes today to kurtosis. Dora had broken, but I think Pk fixed it like an hour ago, so it should be fine by now.
stokes:Okay.
stokes:then, otherwise. I did want to bring up this issue of value or custody. It was something that we have in the specs, and we do want for Fusaka.
stokes:It seems like, though it
stokes:timelines. Maybe we're slipping a bit. I don't know if that's just because of Petra and people busy with other things. But
stokes:I wondered if there were any things we should discuss now around the future any open issues or spec questions worth discussing.
stokes:Okay, this might be a topic for next Monday.
stokes:Okay, Dustin says they're on the issues. So we can go there.
stokes:And yeah, Justin, there's no Bpo in devnet 7. So
stokes:don't need to worry about that.
stokes:Okay, anything else on Fusaka for the moment.
stokes:Okay?
stokes:If not, then. Yeah. I guess part of the reason today's agenda is kind of light is we've had this proposal from Tim to reconfigure how Acd works.
stokes:Let me just grab a link to this here.
stokes:and there's quite a bit in this post. But I think one big thing it proposes is essentially moving. Acd, E and C
stokes:to focus on say, fork plus one.
stokes:whereas the testing call that we now have acdt would focus on the current fork.
stokes:So how that would look in practice is that again, as we've kind of already started with acdt that's focused on Fusaka. So again, on the Cl side, pure dos. Bpo, all that fun stuff
stokes:that then leaves the floor for this call to focus on the future fork which would be Glamsterdam.
stokes:And I think today I mainly just wanted to have a conversation around this idea this post service any feedback, if it hasn't already been surfaced
stokes:around this idea.
stokes:I think it's a bit too early to get into Glenstream scoping today. But I figured we could use this time to kind of discuss our approach.
stokes:There were a number of ideas in Tim's proposal around, not just like making this current work. Next work split, but also thinking about how we integrate the community much more closely different forms for that and all of this.
stokes:So, Tim, I don't know if you wanted to say anything else about the post.
Tim Beiko:I guess. Yeah, I don't know if people have questions like, I'm happy to give a quick
Tim Beiko:overview of just practically what this would look like. I also posted like some dates in the agenda of you know, if we wanted to move with this, what you know how we would approach it.
Tim Beiko:has a question like, why would Acd be joint el and cl, but acd still split? Acd being being joined makes a lot of sense, because we want every client team to send people so that if there's an issue with the current fork we could address it every week, I do think keeping a split on the El. And Cl. Side makes sense, even if it's not like a super strong split, because there's just less urgency. So if we're thinking about. Okay, what's the thing going into Glamsterdam for the Cl.
Tim Beiko:You don't necessarily need all El Devs to to participate in that, and and vice versa. So I
Tim Beiko:I don't have like a strong view there. But and and I don't think we should be dogmatic. But I I
Tim Beiko:yeah, I I think we should try to like, yeah, move not urgent things to the right weeks.
Tim Beiko:And, Matt, I guess I'm not sure I understand 33% current fork and 66% fork plus one like there is acd every week. So it would be 50 50.
lightclient:Okay? Right? I mean, I still think that's too much for the future. Forks like we should be focused mostly on the current fork.
lightclient:And when there's time like right now, in the next few weeks, there's like this bit of time between really starting to
lightclient:Ryan the implementations of Fusaka and thinking about what clamp scenario is going to be like. Whenever we have this paralyzed track, you end up with a situation where the people who are
lightclient:really implementing this stuff don't always have the same bandwidth to think about the thing that's 12 months in the future or 18 months in the future, and it's not met with the same rigor that it ends up getting met with down the line. When those people do have to implement the thing.
Tim Beiko:Yeah, I think that's that's a fair point. And I think
Tim Beiko:one thing to note as well is the the we in both those sentences is maybe a bit different, like a big part of this proposal is trying to get input from a broader part of the community at the start of the fork. This will take time. And so I think I expect to have, like a different set of participants, or at least partially different set of participants
Tim Beiko:in in that process. It still means we need to, you know.
Tim Beiko:get to like a rigorous analysis of what we want to do. But I think
Tim Beiko:there's a lot of value in having a conversation a bit upstream of, like the specific eips around. What should the focus of this work be like? Do we want Grandsterdam to focus on, you know, scaling the El or some other feature? And
Tim Beiko:is that like what we think the highest kind of priority bit is.
Tim Beiko:And I think this is something we need to align with, not just like core devs on. But you know, different kind of stakeholders in the ecosystem and try to invite them on awkward devs and make a case for why? Something is important. They're not important for them. And then.
Tim Beiko:yeah, once we have that, then we do need like more. Input from from quarters about, okay, what are the specific things we're gonna work on. But the
Tim Beiko:like, yeah.
lightclient:No, I mean.
Tim Beiko:Extra time, I think, gives us effectively bandwidth for that.
lightclient:Yeah, I mean, I agree with that
lightclient:like idea. But I think the
lightclient:pretty black and white distinction between all core devs testing. And then the other calls that are now going to be dedicated to future forks only
lightclient:is unnecessary, because we don't need to discuss the future forks, you know, once a week, every single week.
lightclient:There's just not enough content to be discussing it like that. And to me it always feel felt like maybe we could do a better job and be more thoughtful about when we have those conversations and maybe program it a bit more specifically based on when the last fork happened when we're going to have this period of time where there's like a month or 2 where we really talk about, what do we want at a high level. And then, like, what are the things that we're going to do in the fork to achieve those like high level goals. And then, after that period of time. We spend a period of time just like working on the fork.
lightclient:And I think there's like a lot of content for working on the fork like we've filled.
lightclient:you know, 2 or 3 calls a week.
lightclient:Sorry we feel like 2 calls a week every week for Petra, and you know.
lightclient:Cancun, so I don't see why we're just going to. Now get away with one call a week per for the like active fork.
Tim Beiko:Yeah, that's right. And maybe like, yeah, it shouldn't be as much like a drastic split. That's like just prioritizing. So like, I think
Tim Beiko:I would like to try and have acde and see like
Tim Beiko:default to. You know the fork and plus 1 first, st and then, if there are urgent things and more things. Maybe we we overflow there.
Tim Beiko:yeah.
stokes:Cigar. You've had your hand up for a minute.
Ansgar Dietrichs:Yeah, just wanted to say so.
Ansgar Dietrichs:I do somewhat agree with what Matt has been saying in the context of how we treat hard fox today, meaning that like kind of given that. Say, take Glam Saddam as an example. Given that just now we would have switched over the focus from Pector Fussaka to Fusaka. Glam Saddam. Now that pector is out of the way that feels early. Given that Glam Saddam, I mean, at least as far as I can tell. Looks more like it's going to be a
Ansgar Dietrichs:June, July 2026 kind of fog, or at least that's maybe talking to people. The seems like a realistic type of type of time span. If we if we keep having this rhythm of like 9 months between fogs, or like 12 months even, I think
Ansgar Dietrichs:then
Ansgar Dietrichs:it's just too early to immediately start talking about the next focus, as basically the 1 2 before is out of the way. There is the separate question of like more longer term roadmap conversations around what even should be started to be considered or started to be explored for for Amsterdam. But I think for that.
Ansgar Dietrichs:Our core devs. I mean the name already says that's where the core devs come together. It just doesn't seem like the right venue, I think, trying to take all core devs and just add more stakeholders is just fundamentally misguided. It's just that's just not where you talk about these open-ended conversations like that's more, once you have a scope you talk about like, how much of that can we actually ship? So to me it would make sense to have this longer term roadmap conversation in a different venue.
Ansgar Dietrichs:I think we're experimenting with different venues, like more researchy approaches. There can also be more other stakeholder kind of calls. I think that makes a lot of sense.
Ansgar Dietrichs:The only reason to like
Ansgar Dietrichs:follow this proposed new cadence, I think, would be if we actually get serious about trying to have calls at a tighter cadence. So like, if we basically already, if we're thinking, Amsterdam will happen in February, then starting to talk about it today on all codes makes a lot of sense. But again, I think the plan only makes sense. If it comes with a shortening of timelines.
stokes:Yeah, I guess one
stokes:point of feedback to that is, you know, we do have venues. Or, yeah, we could have other venues for, like very longer term roadmapping discussions. Say, on the more research end, like you're calling out.
stokes:But I still do feel like we're missing other types of community inputs. And then this proposal would give us room to integrate that into Acd, and sure that could be like breakouts of like
stokes:Evm devs or something like this, and then, somehow, that sent as like a, you know, delegation, or like Summary to Acd.
stokes:go ahead right now, at least historically, we've lacked even the ability to like service that input.
lightclient:But that's not really to me is related to this. Like, you know, these calls are just 4 in plus one types of calls like we could be doing that right now or in the next call
lightclient:where we're like more focused on surfacing community input talking about Glamsterdam.
lightclient:And then we go back to just we're focusing on Fussaka
lightclient:like we don't have to then spend every call from now until February or July to talk about
lightclient:Glamsterdam, or from now until like September, October, when we shift to soccer. Then we'll talk about whatever's after that
lightclient:like. We should just get the community members to come on and talk and like make a section of time. But I don't think that we should be dedicating the entire call. I think the most important thing is just to focus on the thing right in front of us. And if we start thinking about things that are 1218 months in front of us. Then we're gonna lose. We're going to just like lose our
lightclient:lose our track of focus, or worse, we're going to focus on the wrong things. And then the people who weren't paying attention are going to start paying attention and be like, Well, why the fuck are we
lightclient:looking at this stuff?
stokes:Tim.
Tim Beiko:Yeah, I think another part as well that we should do better on awkward as and use these calls for is to effectively review. The breakout streams that we have going on. I I feel like this is another failure mode that we have where like people work on these breakouts for sometimes years, and they only get like fairly informal feedback, or, you know, like ad hoc feedback, when like.
Tim Beiko:until they effectively propose their their thing to be included in a hard fork. So the other thing I had in in my post is that I I think awkward dev should like
Tim Beiko:every fork review these different breakouts and be like, do we actually want to keep them going or not? Or change them, or something like that? Because a lot of the actual big, important work takes more than you know, 6 or 9 months to ship and and develop and it's extremely bad if
Tim Beiko:you know, the time we decide to cancel something is like after 5 years of work, when you know we're having the fork conversation. So I think this is another part where, like a lot of work already happens in parallel to awkward devs, and we should use this time to like
Tim Beiko:more explicitly just evaluate like, does that still make sense? And obviously, if all core devs
Tim Beiko:the the decides like, it doesn't make sense. It doesn't mean that like people are blocked from working on this thing forever. But I think it it. I think I think it helps us to like, you know, one schedule breakouts to like at least set expectations like if someone's working on the thing and awkward have said, like, you know, we have no plans to do this in the next year or 2 they can still choose to do it, but it at least sets the right expectations.
Tim Beiko:so to me like that, that's another part. So
Tim Beiko:aligning on the fork, reviewing the breakouts. And yeah, there will be some stuff about the current fork that pops in that that we should discuss but I
Tim Beiko:I would rather like make a bit more space and have like do those things well than to try and crime it all like we've done in the past, because clearly we've we've not been sufficiently good at that.
stokes:Yeah, I mean, I do think that's the biggest risk to this proposal, is it just evolves back into the status quo. But I do think it's worth experimenting.
stokes:Youth, dreamer.
ethDreamer (Mark):Yeah, I I mean.
ethDreamer (Mark):I think there's kind of 2 dis 2 discussions going on here. One is the restructuring of the all court data call, and the other is is sort of like
ethDreamer (Mark):not planning forks.
ethDreamer (Mark):I guess, like, right after the end of the last work and kind of squeezed in at one time, and I
ethDreamer (Mark):definitely can see the like validity of wanting to spend more time, or like spend longer discussing the scope of a fork and not have it be crammed in at 1 point in time, like when we have breathing room between 2 forks. Because
ethDreamer (Mark):there's just a lot that goes into it. And I do think, even if we don't like restructure, all core dev calls that
ethDreamer (Mark):some kind of like recurring
ethDreamer (Mark):meeting just to have people discuss like what they think would go in the fork. And then, maybe.
ethDreamer (Mark):you know, open up whatever questions, come up and then systematically look at those questions. And just just so that we've spent time on thinking in these directions and then have a like. By the time it comes time to have the discussions about what actually goes in and and make those decisions that we've just had much more
ethDreamer (Mark):opportunity to like field those questions and and have a direction that we're headed.
ethDreamer (Mark):So like, maybe one way of doing that is
ethDreamer (Mark):rather than repurposing all core devs just having a call.
ethDreamer (Mark):That's kind of ongoing about, you know, future discussions. I mean, I'm not.
ethDreamer (Mark):That may or may not be a a possible solution. But I'm just thinking that.
ethDreamer (Mark):yeah, when we have more time to discuss these things. I think the outcome would be better, because I think, certainly with Petra. One of the differences was that we were. We were kind of caught flat footed.
ethDreamer (Mark):You know, it was kind of the 1st time
ethDreamer (Mark):that we actually didn't have an immediately obvious priority
ethDreamer (Mark):for what the fork should be in a long time, like we we knew. You know, we had the merge. Then we had withdrawals that we had 44. Those were all, obviously the priority. And then.
ethDreamer (Mark):if if it's not obvious what the priority is, then it requires a lot more discussion and time.
ethDreamer (Mark):and so have that kind of going on in the background. We'll have a better idea.
stokes:Right? Yeah. And I kind of see them as additive like
stokes:Osgar mentioned this protocol research call, or at least he was gesturing at it. And that's like one experiment to have this like longer range conversation. I still think, you know, we could have multiple venues where we have these like longer term conversations. We'd still want to have time in Acd to like, incorporate that and decide as core devs.
stokes:Tim.
Tim Beiko:Yeah, I think maybe it's helpful if I share what the actual concrete thing I'm proposing.
Tim Beiko:so it's a bit less abstract. But
Tim Beiko:so I wrote a follow up to this. You know, to to that 1st post. Let me see. Sorry.
Tim Beiko:okay, hopefully, people can see the screen.
Tim Beiko:Okay? So basically, I think the thing we should do is
Tim Beiko:when we start planning a fork. I guess we 1st agree on what the big core thing should be. And this is when we should get the communities input. Like, I think a failure mode is if only core devs. Think that you know this thing is important, and the entire community thinks something else is important. We should resolve this upfront before we spend a year working on the fork.
Tim Beiko:So this should be like the 1st spot that we actually proactively reach out to the community like, what is the core thing we want to do. And why is this important? Then figure out what is like the actual eip or feature that we do for this? And I think it's important that we separate this from, like all the other eips, so that when teams are reviewing, like the core headliner feature, they can focus their attention on this. If there's competing features. They can like review them thoroughly. But, like.
Tim Beiko:you know, we we 1st choose, like, are we doing the merge, or are we doing 4, 4 or or whatnot.
Tim Beiko:I think the other part that's gone wrong is that we kind of expect the community to give input all of the time. And this means they give input none of the time. And they, you know, like, only find out about changes at the last minute. So I would move towards like explicitly signaling that when we're discussing this 1st fork focus, this is when we'd like their input
Tim Beiko:and then the other parts that we should do is. Historically, we've had these like community test nets that we've launched for forks and we've done one for for for Petra for 7 7 0, 2. I think we should just be clearer that, like this is the sort of last call for the community to give more kind of in the weeds feedback to propose spec change and whatnot
Tim Beiko:and then, like, yeah, the other part. It says, like, you know, we should, we should formalize these working groups and review them. But I think at a high level these 3 things is what I would propose practically changing. So we we reorient the conversation around like, what do we want to do? The community comes in. Then we choose our headliner. Then we, you know, we pick all the other eips once that's done.
Tim Beiko:And then, once we have a a core feature implemented, we set up the public test net. We get people to look to look at, to it to propose spec changes, and then we assume that once that's done like people are kind of happy.
Tim Beiko:And then
Tim Beiko:yeah, I I think then, if you look at like Glamsterdam specifically. I posted this on the agenda. Let me just pull it up real quick. Glamsterdam. Specifically, it means
Tim Beiko:we could spend, you know, the next month or so discussing with the high level focus for the fork should be whether it should be the same on the El or cl, or separate
Tim Beiko:bring in, you know, different perspectives from the community. We ideally agree to this by say, you know, early July, and then everyone kind of knows this is the big thing that's going to Glamsterdam. We can. We can keep working on Fussaka. If we have extra spare cycles, we can start working on this core feature, and then we can also have the conversation then about like which other small vips we want to include, and stuff like that.
Tim Beiko:but yeah, at a high level. That would be my my proposal.
stokes:It seems worth trying to me. And again, you know, we can force correct as we go. But
stokes:there are failure modes with A/C today. So I think we should try to improve somehow.
stokes:and we won't really know until we
stokes:try it and see how it goes.
stokes:I guess, on a related note is Marshall on the call. They had a post about an Ecd. Forum.
Marc:Yeah. Can you hear me?
stokes:Yep, hey?
Marc:Yeah, so yeah. So I wrote up this kind of brief post, which is kind of in in line with what Tim was saying, focused around
Marc:involving stakeholders more in the process, like I think we saw with Eof, maybe like a kind of kind of failure there, potentially to get stakeholders involved enough, or like early enough in the process.
Marc:And what I'm kind of proposing is to kind of create some new platform or website, potentially or upgrade potentially ethereum magicians to kind of be more specialized for Acd, and the reason I'm proposing that is, I kind of think that the existing channels that we have aren't necessarily ideal for getting feedback from lots of stakeholders. So we have these calls.
Marc:which obviously are like very limited in time. Maybe if you're just someone from the ecosystem who's not a core dev. It's a bit daunting to go on the call, or like you have to sit through these conversations about stuff you don't necessarily understand or involved or involved in and we also have, like big eth magicians. Threads
Marc:which I think are also maybe not the ideal format for everyone to give feedback. So I think kind of the way we have things now is like.
Marc:What I'm saying is we could improve generally the sort of ux I would call it, of interacting with Acd, and just make the whole process a lot more streamlined. So if you're some sort of random sorry, like stakeholder in the ecosystem, it's really obvious how you can get involved. You don't sort of have to be active in following every call like following ethereum magicians like. And the way I would imagine this is, you just have some sort of
Marc:Acd homepage or portal right? And it's kind of it will show you. When are the next upcoming? Hard forks are important, like what's proposed? You don't have to sort of cross reference between different forums like Github Repos. It's all in one place, and specifically for hard fork scoping.
Marc:I think it would be useful to have sort of one canonical place where everyone can say their preferences for what should go into the fork. I mean, we have ethereum magicians threads. But the kind of way I see it is like, you can just see a high level like, you know, this is what all the different client teams are saying. This is what the L twos are saying. You know the the different
Marc:I don't know tooling devs, and it's all sort of grouped at a high level, and you can click in to kind of see the specifics. But you don't have to crawl through one big thread. So yeah, just, I guess, just to summarize like I just think that either on ethereum magicians or or some kind of new platform, we could just generally kind of like streamline things and make it easier for anyone to participate.
stokes:Yeah, I think that makes a lot of sense. I think it's
stokes:tricky to know exactly what to do. But yeah, there are definitely a lot of ideas floating around around.
stokes:making this more streamlined, making it easier to discover information. I know at different points in time people have discussed having
stokes:essentially better records around eips because a lot of the work we do is Async.
stokes:So just having that in like a easily discoverable fashion, I think, makes it. It lowers the barrier to entry for someone to come and provide their input in a constructive way.
stokes:It's always you had your hand up.
saulius:Yes. So so one thing that I think
saulius:it often gets touched in some different angle.
saulius:But I really lack wow of, let's say, last mile.
saulius:when when new Eaps are proposed and even implemented. So so people, especially the core Devs, are really good at, you know, building software and coding and hacking things together.
saulius:but it often lacks the last step which is like
saulius:trying this change in the entire ecosystem, or at least a significant portion of of the ecosystem, and in order to figure out the impact of that technical change which often is, is good in the eyes of developers. Like some new cool feature and technical improvement.
saulius:but the impact of that to the, to the huge infrastructure that is, you know, that ethereum consists of
saulius:is is often not investigated, and I think that this is something that
saulius:that could help to you know, to to cut some features quite early, because, as as we already saw even a small feature sometimes bubbles to insane changes and into
saulius:onto the shoulders of end users. So so I would like to see some improvement in the eip process, where where those who suggest the eips, they actually or maybe some other teams which hand over is the implementation. I mean be before there is a hard decision to to ship it, we we really should have much better final impact.
saulius:So that's the point I wanted to to raise.
stokes:Yeah, no, I mean, I think it's a good point. Historically, I think the idea has been like eip champions would do this. But
stokes:I don't think there's ever really been like enforcement or
stokes:compliance, I suppose, is the way to think about it. Because, you know, vip champions usually are pretty busy people.
stokes:and then it's hard to do all this extra.
saulius:Yeah, and it's.
stokes:Making around it. So yeah.
saulius:Yeah, if I.
stokes:But yeah, I think there is a pretty general agreement improvement. There would be very helpful.
saulius:Yeah, it could be even, you know, as there is this analogy with with testers and developers where you need to have a 2 different roles to actually ship the thing right? Because because developers doesn't think like testers and testers do not think like developers. So so it could be that that the IP champions even are not in a great position to to do that, to achieve that last mile
saulius:because, you know, they actually motivated to ship, the the finger at at l. 1, let's say, without thinking too much, or or getting demotivated by the impact, by by the huge impact that we'll do in terms of, you know, a lot of efforts for the end users to support this new thing. So
saulius:so, yeah, I think this this needs to be considered, and maybe maybe we, we should introduce some new rules that that make sure that the impact is on on the end. Users is is right and acceptable, you know, and likely it's even not the eap champions, because they are not in a very good position to do this work in the right way.
stokes:Right? Yeah, or Vip champions supported or extended with others who are more appropriate for this type of thing.
stokes:Tim says here he thinks we should enforce it for headliners, which I agree with, and I think even is this a screenshot from your post, Tim.
Tim Beiko:Yeah. So I think for the headliners. The thing I've been trying to get is some sort of like.
Tim Beiko:it's almost like a wrapper around the eip like we should explain why the thing matters who's affected both positively and negatively. And then you know what's the state of of the proposal, and a lot of this doesn't quite fit within eips most of the time, because it's like these are big features.
Tim Beiko:I think the their credit, like Vitalik and Danny have done this for the merge, like I I forget the eip number, but there was like a huge informational eip for the merge.
Tim Beiko:yeah. So was it for the merger, the launch of the beacon? Sorry. I think it was for the launch of the beacon chain. That actually explained all of this extremely well.
Tim Beiko:I don't know that we need to go in that level of depth, but I think it's like maybe the closest thing we've had historically, to
Tim Beiko:something like this that explains like, why, this is actually quite an important thing. And we should, you know, go on it on it. In that specific case I think they actually shipped it
Tim Beiko:after the beacon chain went live. But it's still like a yeah good reference.
stokes:Cool any other questions or comments.
stokes:Onsgar, do you want to say more about your latest commentary?
Ansgar Dietrichs:Yeah, I mean. And again, I think this is just my personal bias speaking. So, I'm not. I really am not convinced that I'm right here at all, but, like my opinion is that
Ansgar Dietrichs:I think what we have not been good at in the past is like this, maybe less so than the roadmap forming itself. I think more the translating it to forks or something, because then everything and nothing is always kind of like, roughly related to what might be roadmap focuses. And then we have way, too many features, and we cut them down somewhat arbitrarily.
Ansgar Dietrichs:For and then for me, personally, like this example of Maxib versus Pierres is just a very salient one, because both of them were kind of big Cl side features, and so they clearly seem to be in competition for the main kind of Petra Spot.
Ansgar Dietrichs:It seemed obvious from the roadmap side that Pietas was much higher priority. I don't. I don't think I've seen anyone within that had a different differing opinion in terms of like like impact from from the roadmap point of view. But because
Ansgar Dietrichs:and I don't know. Like, maybe for randomness, maybe because Pdas was originally not scheduled for Hardfolk at all, but as like a side change that can be in between hard folks and that. That's why it was not as legible for the Ap process, or maybe because I had a comment to Sasha earlier in the chat that like, I think maybe stakers where we just have right now a maybe
Ansgar Dietrichs:more easy access to Acd via the clients, because they're the main customers for clients compared to other users like L. Twos. And so maybe maybe, that those voices just were loud or something. It's hard for me to tell why that happened. But like the end result was that, like this clear priority just was not reflected in the ordering for hard folks, and so to me, that indicates that it's less about
Ansgar Dietrichs:the fact, like the the roadmap being the issue in this case at least and more. This kind of translation.
Anders Kristiansen:But again.
Ansgar Dietrichs:This could very well be completely wrong. Just my perspective.
stokes:Yeah, I agree with the general point. There's some
stokes:comments in the chat around periodos versus Max Eb. But I'll just let that be okay.
stokes:So I think a good next step here. I'll put Tim's comments here. I think this is like a good straw man.
stokes:and
stokes:perhaps one way. I don't know, Tim. You said you'd write up something for next week, and then maybe in the meantime, if there's any Async discussion, we could take it to the ether and d discord.
stokes:Otherwise, are there any other comments on this? For now.
stokes:if not, I think this was some great conversation to get this process started.
stokes:and we can probably go ahead and wrap up earlier today unless there's anything else
stokes:MoD ask when we finalize for Sokka. So it's I would say pretty finalized, at least, you know, in terms of current. Sfi set for the Cl.
stokes:I don't know if this is a question about the eel.
Parithosh Jayanthi:Yeah, I think we said that. When, as we get closer to Berlin, we should get closer to having everything that we want in Fusaka ssified and kind of locked in for now Fusaka devnet 0 only has the MoD Xp change. But on Acd there were already an indicator of at least one or 2 more eips that made sense to go in, but just didn't make sense on the timeline perspective.
Parithosh Jayanthi:So yeah, I guess we do need to discuss that and decide when we finalize specs and just focus on shipping.
stokes:Yeah, that makes sense. And then, yeah, Tim just says on the next acde.
stokes:figure out the other ele ips for the next couple of devnets, because that was kind of an open thread
stokes:that we still have.
stokes:Okay, are we good for today?
stokes:If so, we'll go ahead and wrap up.
stokes:Okay, thank you, everyone. I'll see you next time.
Marius:Cheers.
Ahmad Bitar | Nethermind:Bye.
Pooja Ranjan:Thank you.
Mikhail Kalinin:So.
Orest Tarasiuk (t1):Yeah, bye, bye, guys enjoy.
Ansgar Dietrichs:Everyone.
Chat Logs
00:00:09
Parithosh Jayanthi:Replying to "Little empty today, ..."
What would you like merged today?
00:00:15
Trent:Gmgm all! Just published Pectra Pages 🦒
+40 upgrade perspectives from Ethereum core contributors - many of you submitted, check out the responses from your colleagues. If you have the form open and submit, just let me know and we can update
https://x.com/trent_vanepps/status/1923009753199833396
00:00:24
stokes:https://github.com/ethereum/pm/issues/1515
00:01:21
Parithosh Jayanthi:Waiting on more time before we publish our followup on how blob scaling went 🙂
Eta next week I guess?
00:02:20
Marius:Easiest way to make it into the next Laura Shin book
00:02:40
Caleb:Gm
00:03:43
stokes:https://notes.ethereum.org/@ethpandaops/fusaka-devnet-0
00:04:34
terence:how is everyone testing BPP before devnet0? kurtosis?
00:05:29
Justin Florentine (Besu):@Parithosh Jayanthi is there value in Besu joining peerdas-7 if we dont' have BPO yet?
00:05:47
Dustin:There are many open spec questions, they've been raised in the relevant threads
00:05:52
Parithosh Jayanthi:Replying to "@Parithosh Jayanthi ..."
Yup 🙂
Devnet-7 has no BPO, and it would help us sanity check that the basic peerdas functionality works
00:06:12
Justin Traglia:Replying to "There are many open ..."
I’ve asked Agnish to open PRs for this.
00:06:38
stokes:https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370
00:07:50
Ansgar Dietrichs:why would ACDT be joined EL and CL, but the ACD calls still split? is there a principled reason why fork + 1 benefits from that split, but current fork doesn’t?
00:08:48
Ansgar Dietrichs:makes sense, reasonable answer
00:08:52
lightclient:i’ve said this before but i don’t think we have the capacity for this level of parallelization and the split 33% current fork and 66% fork+1 puts too much emphasis to the farther future fork
00:09:17
Ansgar Dietrichs:Replying to "i’ve said this befor..."
we have both ACDT and ACD every week, right? so 50/50?
00:10:14
lightclient:Replying to "i’ve said this befor…"
right my bad
00:13:09
Justin Florentine (Besu):are the ACDTs overflowing?
00:13:44
Parithosh Jayanthi:Replying to "are the ACDTs overfl..."
Hmm, not this exact week - but there have been times where it was tight. I think it depends on the week and number of open PRs or changes.
00:14:04
stokes:Replying to "are the ACDTs overfl..."
Yeah I expect as we get closer to fusaka shipping it will be very full
00:14:05
Justin Florentine (Besu):Replying to "are the ACDTs overfl..."
ok, so that will fluctuate
00:14:06
Parithosh Jayanthi:Replying to "are the ACDTs overfl..."
Thankfully we merged most of what was needed for peerdas, hence the lighter calls
00:14:15
Tim Beiko:Replying to "are the ACDTs overfl..."
They are also 60m right now, right?
00:14:18
Parithosh Jayanthi:Replying to "are the ACDTs overfl..."
yup
00:16:18
Parithosh Jayanthi:We could actually invite people to present/talk at ACDE/C, something we’ve had no bandwidth for in the past due to how much we needed to discuss on the next fork
00:16:56
Dustin:How much will community input even exist until perpetually last moment? That's what happened for EOF. Putting aside the idea of, people said thing X happened in October or November (trying not to reopen every issue...), EOF still existed for years and was mostly ignored by all those people who came up in the last minute bothered by changes it made (again, being deliberately vague here)
00:16:57
Ansgar Dietrichs:so to summarize, there are three stages:
A) roadmap discussion
B) inclusion / scope discussion
C) shipping discussion
I fundamentally don’t think “A” should be in scope for acd, nor has it ever been historically.
And splitting “B” and “C” out more clearly makes sense in principle, but right now hard forks are so far apart that these stages are only partially overlapping to begin with
00:18:19
lightclient:reviewing breakouts make a lot of sense to me
00:18:26
Ahmad Bitar | Nethermind:and if the decision is to keep the breakout, there should be a delegate from every client team in the breakout call
00:19:20
Tim Beiko:IDK if every team, but it should be a good signal
00:19:20
Ansgar Dietrichs:Replying to "so to summarize, the..."
basically, acd is the executive branch.
roadmap is legislative branch
(and community / stakers are judical branch)
this is proposing to merge executive and legislative branches, I think that is a big conceptual mistake
00:19:23
Justin Florentine (Besu):Replying to "and if the decision ..."
love this idea, only callout i see is as we spread teams a little thinner, timezone avail gets worse.
00:19:36
sacha:Replying to "How much will commun..."
sort of chicken and egg here imo
00:19:43
Ansgar Dietrichs:Replying to "so to summarize, the..."
I do think the lesson from the past year should be that the legislative (roadmap) branch needs a rework
00:19:49
Tim Beiko:Replying to "How much will commun..."
I think we can be much clearer about when we expect community input
00:20:00
sacha:Replying to "so to summarize, the..."
i think A needs wider community input, even if ACD is not the right place for that
00:20:00
Marius:People really self select into the breakouts. You only join them if you are interested in the idea. You don't join them if you think an idea is stupid/early/not realistic
00:20:12
Tim Beiko:Replying to "How much will commun..."
Right now we kind of expect it “all the time” which leads to “only the last moment”, but we should basically signal the core times.
00:20:27
Łukasz Rozmej:If Glamsterdam is in a year I think we should start scoping it soon.
00:20:38
Ahmad Bitar | Nethermind:the problem with breakouts not having enough feedback is the lack of participation from teams even after the decision to make a commitment to those breakouts.
00:20:41
Tim Beiko:Replying to "People really self s..."
Yes, but having a +1 from ACD that it’s not a stupid idea is good.
00:21:31
Łukasz Rozmej:each breakout room should have a healthcheck every few months on ACD calls with short summary of status and gathering some basic feedback
00:21:47
Ahmad Bitar | Nethermind:Replying to "and if the decision ..."
without the commitment, reviewing the breakout makes a bit less sense as it still means that one the EIPs are proposed for the fork, the feedback will still be very late
00:22:04
Łukasz Rozmej:Replying to "each breakout room s..."
timebox the healthcheck dependent on agenda to 10, 15, 20, 30 mins
00:22:14
Ansgar Dietrichs:I think researchers are only one relevant group for roadmap setting, but for helping make our work on roadmap more open we have these new research calls, I think these can help here
(definitely only as part of the solution!)
00:22:25
Justin Florentine (Besu):get your rotten vegetables ready to throw at me....
should we hire project managers?
00:22:25
Toni Wahrstätter:Replying to "and if the decision ..."
But then we have to be more selective for breakouts. Right now it feels like every topic, no matter if it's planned for a fork, gets a breakout room.
00:22:39
Ahmad Bitar | Nethermind:Replying to "and if the decision ..."
agreed on being more selective for breakouts
00:22:44
Ansgar Dietrichs:Replying to "I think researchers ..."
I think e.g. app devs should coordinate to spin up a similar call!
00:22:49
Parithosh Jayanthi:Replying to "get your rotten vege..."
We love re-inventing things from first principles in this house
00:23:12
Łukasz Rozmej:Replying to "get your rotten vege..."
NO!!!! You can grow/create them from existing people, but please not hire.
00:23:40
Justin Florentine (Besu):Replying to "get your rotten vege..."
let me rephrase:
should we pay people to project manage?
00:23:48
Ahmad Bitar | Nethermind:Replying to "get your rotten vege..."
🥚🍅
00:23:56
Dustin:Ok, but it's still ok to have EIPs which are technical and "back-end" and not just immediately add marketing features
00:23:58
Toni Wahrstätter:Replying to "get your rotten vege..."
🍅
00:24:16
Ansgar Dietrichs:I also think - most controversial - the EF should fill more of an explicit role in the roadmap setting. I think that actually could be quite healthy:
legislative: EF-led, relatively centralized
executive: core devs led, more decentralized
judicative: stakers / community: most decentralized
00:24:19
Dustin:Contra all those responses to various EIPs of "what does this EIP do for me, today?"
00:24:26
Parithosh Jayanthi:Replying to "get your rotten vege..."
And we do need to ack that devs don’t always make good project managers. They can make good managers, but many also don’t 🥲
00:24:28
Łukasz Rozmej:Replying to "get your rotten vege..."
who are "we" ? :D
00:24:33
sacha:Replying to "I think researchers ..."
need to try and bring node operators into this process too somehow
00:24:39
Barnabas:Replying to "get your rotten vege..."
we have a managooor already its @Parithosh Jayanthi
00:26:32
Ansgar Dietrichs:meta point: I would agree that experiments are worth trying
00:26:51
Ansgar Dietrichs:Replying to "meta point: I would ..."
let’s just try to make Glamsterdam not get too off the rails :-)
00:27:18
nixo:https://ethereum-magicians.org/t/for-an-acd-platform/24098
00:27:26
Tim Beiko:I’ll write up a one-pager for the Glamsterdam process by next ACD 🫡
00:27:36
lightclient:eof had stake holders very early in the process
00:27:59
Ansgar Dietrichs:I think stakeholders need to not only be involved in EVM changes - they need to drive them.
We can’t keep guessing what could be useful for them, even if we check with them afterwards
00:28:09
Barnabé Monnot:Replying to "I think researchers ..."
@sacha think there was a good representation in the first call which was more on their topic?
00:29:05
Justin Florentine (Besu):Replying to "I think stakeholders..."
market. analysis.
00:29:28
Dustin:Replying to "I think stakeholde..."
Not sure if this is good/bad, but this is a process designed for a maintenance/bugfixing model of the EVM. People will likely ask for some feature, or precompile, but likely not look at things architecturally.
00:29:42
Josh Davis:@Marc working on this 🙂
00:30:05
sacha:Replying to "I think researchers ..."
yes. that was a great first step!
in my experience, they often want to be heard but don't know how to be
most of the tiem they feel like they're just "told" what to do and at some point i worry it's going to hit an inflection point where they won't be able to do what you expect (e.g. it'll put them out of business) and it'll cause issues (e.g. solana validator mutiny)
00:30:10
Tim Beiko:My one suggestion would be to anchor to already exists vs. Creating yet another platform that will be abandoned in 18 months
00:30:15
Ansgar Dietrichs:Replying to "I think researchers ..."
@sacha I would actually take the other side of this: if you count features since the merge, there have been more staking related features than anything else. specifically because stakers / node operators are the direct customers of client teams, so they have the most direct connection to the acd participants.
compared to say app devs, with no such connection at all. or even L2s.
00:30:16
Dustin:Replying to "I think stakeholde..."
Also, some of this is already done -- look at what changes various L2s make to their each bespoke custom ancient Geth forks
00:30:42
Justin Florentine (Besu):Replying to "My one suggestion wo..."
network effects are hard to rebuild
00:31:13
sacha:Replying to "I think researchers ..."
i think you need more direct input from both!
00:31:16
Josh Davis:Replying to "My one suggestion wo..."
I think that anchoring this to something that already exists runs the risk of not attracting the stakeholders we are looking for feedback from. If they don’t come now, why would they come later?
00:31:23
sacha:Replying to "I think researchers ..."
to make the best possible decisions
00:31:31
Ansgar Dietrichs:Replying to "I think stakeholders..."
yes that’s why I am saying, acd is fundamentally the wrong format for this
00:31:38
Barnabé Monnot:Replying to "I think researchers ..."
are node operators… the military? 😅
00:31:50
Josh Davis:Replying to "I think researchers ..."
@Barnabé Monnot militia
00:31:56
sacha:Replying to "I think researchers ..."
security?
00:31:57
Justin Florentine (Besu):Replying to "My one suggestion wo..."
same logic applies to a new thing that they didn't go to
00:32:10
sacha:Replying to "I think researchers ..."
🙂
00:32:33
Tim Beiko:+1 on impact
00:32:35
Ansgar Dietrichs:ha, no one will ever know what happened in that second
00:32:51
Tim Beiko:I think for headliners we should enforce it
00:33:14
Barnabas:UX + impact for end user research should be prioritized a lot lot more agreed.
00:33:24
Josh Davis:Replying to "My one suggestion wo..."
Not necessarily, current platforms have a stigma currently. If a new platform is created with the direct goal of being for stakeholder and not just devs, I think it could be a more active/attractive place
00:33:42
Trent:Replying to "My one suggestion wo..."
EM has a stigma?
00:33:44
Tim Beiko:EthMagicians has that intent, though
00:34:15
Josh Davis:Replying to "My one suggestion wo..."
I also wonder about the limitations of discourse in building this as well
00:34:19
Justin Florentine (Besu):Replying to "My one suggestion wo..."
ehhhhhhh maybe i could see that. i think the important part is preserving the existing population
00:34:34
Ansgar Dietrichs:just to keep taking Glamsterdam as an example: conversations about priorities for it have been ongoing for a while already! (mostly outside acd).
I think current consensus forming is:
CL: focus on DA scaling. maybe (!) shorter slot times, help with EL scaling
EL: focus on scaling
seems like the process is working as intended?
00:34:35
Marc:Replying to "eof had stake holder…"
yeah wasn’t trying to single out EOF, maybe the problem was not having some clear place everyone gives feedback that could be used as evidence
00:34:42
Toni Wahrstätter:+1, and every repricing MUST come with a propoer impact analysis
00:34:45
Barnabé Monnot:Replying to "I think researchers ..."
but more seriously I think of them as an important constituent of the community, think they have a privileged position from being typically better informed than the median community member, and being close to the metal/protocol
def important to involve for the topics that directly concern them, for any other topics imo it’s the same issue of just being better at involving community as a whole
00:34:57
Ansgar Dietrichs:Replying to "just to keep taking ..."
like, do these seem like terrible priorities that need urgent reworking?
00:35:11
felix (eest):Replying to "ha, no one will ev..."
get ready for the conspiracy theories
00:35:16
sacha:Replying to "I think researchers ..."
fair
00:35:23
Tim Beiko:https://eips.ethereum.org/EIPS/eip-2982
00:35:25
Pooja Ranjan:https://eips.ethereum.org/EIPS/eip-2982
00:35:42
Josh Davis:Replying to "My one suggestion wo..."
Is it though? I thought the idea behind this concept was to bring more stakeholders/community members into the fold...
00:36:02
Ansgar Dietrichs:Another controversial take: If anything, I feel like the roadmap-to-hardfork translation needs more work, not the roadmap forming itself.
Best example to me is MaxEB vs Peerdas. It was super obvious from the roadmap side that Peerdas was a bigger priority. Was impossible to translate that to fork ordering
00:36:11
Barnabas:Could we get some UX improvements into glamsterdam, while we are at it?
00:36:12
Tim Beiko:Replying to "My one suggestion wo..."
Who do you feel is currently not represented on EthMag?
00:36:42
Justin Florentine (Besu):Replying to "My one suggestion wo..."
and what problems do we have with the existing population that we would entertain abandoning it?
00:36:42
Tim Beiko:Replying to "My one suggestion wo..."
Because it also hosts all the ERC threads, I think it gets a really good sample of the app layer part of the community
00:37:00
Marc:Replying to "My one suggestion wo…"
the main thing for me is having some clear entry point / portal for accessing the ACD process that makes everything streamlined
00:37:33
Tim Beiko:Replying to "My one suggestion wo..."
I agree with that, and I wonder how much of it we can get from refactoring EM
00:37:39
Josh Davis:Replying to "My one suggestion wo..."
@Justin Florentine (Besu) Im not suggesting abandoning it, but the current population already has ACD/ethmag. It wouldn’t’t go away
00:37:44
Tim Beiko:We should never schedule things “between hard forks” 😄
00:37:50
nixo:i think more because maxeb was expected to be simpler
00:37:51
ethDreamer (Mark):We decided it because we thought peerDAS was parallelizable and it was further away
00:37:55
ethDreamer (Mark):That was the reasoning at the time
00:38:11
Tim Beiko:PeerDAS also progressed quicker than expected in Nyota interop, which then got us to add it to Pectra.
However, I agree we could have “bitten the bullet” there and focused on PeerDAS from the start because it was higher ROI than MaxEB.
IMO “technical readiness” should be 1/N of the things we evaluate when choosing a headliner.
00:38:12
ethDreamer (Mark):I watched that old ACD recently lol
00:38:39
stokes:https://github.com/ethereum/pm/issues/1515#issuecomment-2883885751
00:39:01
Ansgar Dietrichs:Replying to "We decided it becaus..."
“parallelizable” is meaningless though, if then not actually worked on in parallel
00:39:13
Ansgar Dietrichs:Replying to "We decided it becaus..."
in practice, fork inclusion is an implementation priority decision
00:39:25
Ahmad Bitar | Nethermind:when will we finalize the fusaka spec?
00:39:32
Ansgar Dietrichs:but again, experimentation is necessary, so thank you very much for working this proposal out!
00:39:38
Ansgar Dietrichs:Replying to "but again, experimen..."
all nitpicking aside :-)
00:39:42
Barnabas:Replying to "when will we finaliz..."
after berlin
00:40:13
Tim Beiko:On next ACDE, we should decide what other EL EIPs we want for the next 1-2 devnets
00:40:21
Ansgar Dietrichs:Replying to "Could we get some UX..."
I think same issue as with EOF: we are missing insights into what would be useful there
00:40:25
Mikhail Kalinin:one of the reasons behind MAXEB was potential decrease of the validator set which reduces the strain on the network. i think it is pretty important for the mainnet security. just wanted to remind that MAXEB isn’t only a UX improvement for stakers
00:40:40
Parithosh Jayanthi:Replying to "Could we get some UX..."
How do we get these insights tho?
00:40:46
Ansgar Dietrichs:Replying to "Could we get some UX..."
great question
00:40:52
Orest Tarasiuk (t1):Thanks all
00:40:54
Ansgar Dietrichs:Replying to "Could we get some UX..."
but any answer is probably not ready for glamsterdam