All Core Devs - Consensus #166

Transcript

Alex Stokes: Hello. I think there was a mix-up with the Zoom links today? Oh wait, okay. And then… I think we had a king on the other one? Let me start…

Josh Davis: Yeah, of course.

Alex Stokes: So, you know.

Josh Davis: Our room, passing people off to this room.

Alex Stokes: Okay, great. Hmm. Okay. Nixar, you're in both rooms? Yeah, but I'm wondering if… More people will join that link. Because it's on a calendar, invite.

Saulius Grigaitis: So, is, is this right?

Alex Stokes: This is what we're gonna use today. This is not the link I would have used. I will…

Nixo: I'll go over to that… I'll go over to that other, meeting and sit in there and tell people to go over here.

Alex Stokes: I think that's okay. I think… We'll just go ahead. Yeah, I think it's something where the ACD bot, like Trent was saying. If I had to guess, ACDbot is, like, getting a new Zoom room every time. And we usually just use the same one. But, in any case… Looks like people just clicked the link here on Discord, and we have enough people here, so I think we should go ahead and get started. Let's see… Josh, are you helping with the stream today?

Josh Davis: Yep, go ahead, you're live.

Alex Stokes: Okay, thank you. Okay, everyone, let's see, let me find the agenda… so… This is ACDC, number 166. It's issue 1740 in the PM repo. Here's a link here. And… yeah, on the agenda today, pretty straightforward, some Osaka things, some Web Amsterdam things, and then a few… other things around different EIPs and the process. So let's go ahead and jump into Fusaka. I thought I'd ask if there are any DevNet updates. I know there was some chatter on Discord across the week to this effect. There might not be anything. We did have the Heleshky fork, which we'll talk about next. Anything on the DevNets that we should discuss?

Parithosh Jayanthi: Yeah, we tried non-finality on Fusaka DevNet 3, and we had non-finality for about 2-ish days, and then healed the network again, and it's been finalizing since. I'm not sure if Barnabis had any other… Updates to add?

Alex Stokes: He says no. Okay, cool. then let's move to Aleshki. So we had the fork activation, about a few days ago, and yeah, as far as I can see, it went pretty well. There was… A little turbulence, which I think at this point is to be expected with testnuts. Yeah, again, Perry A Barnabas, any updates, there? Or anyone else want to add anything about Halushki? Do we feel like it went successfully?

Parithosh Jayanthi: Yeah, so we had the DevNet fork yesterday, and we've been, keeping an eye on it. There was one incident halfway through the… so, sorry, so let me start from the beginning. As soon as the fork was done, we did notice a participation drop. But all of the participation drop was associated with, missed updates, so once the updates were applied, we were able to hit back almost the same as, before the fall. We're still tracking around the missing diff, but later in the day, we did notice one scenario where we're still figuring out what's necessarily going on. But there was an unexplained drop in participation rates. We went below 66%, and then it came back up. Sam's posted a few theories, mainly to do with, either missing or late blocks, and also associated with,

spikes in CPU usage, likely related to spam or kind of spamming in relative, like, it has ticks to when it's spamming stuff. It could just be a combination of all of these factors. Also, most people tend to have something like 10,000 validator keys per beacon node on Holzky, so it could just be a combination of everything, but we still don't have a… Concrete answer for, why the participation rate went down, or how it recovered, either. But since then, it's been… we haven't noticed any, any big issues. So, yeah, like Bohus says, there were a bunch of hiccups.

Alex Stokes: Yeah. When you were saying updates, you mean, like, just people updating to new versions of the client?

Parithosh Jayanthi: Yeah, you're right. Yeah.

Alex Stokes: Okay. And yeah, there could be a number of reasons for this. Yeah. So… it was good to see that, and yeah, it looks like it's pretty good so far. So, I guess we'll keep an eye on it. The next thing there to call out is… the first VPO scheduled, which is… Let me just double check, because I think I actually have the date wrong on the calendar. So yeah, that's, on… Monday… Unless this is Tuesday UTC. anyway, let me… let me not confuse people. But there's one in a few days, yeah, again, check the blog post if you need the canonical time. Or any of the client configuration. So, have that on the radar. And we'll see how that goes.

But yeah, I think all end, we're moving along pretty well. So, anything else on Haleschi anyone wants to discuss today?

Ameziane Hamlat: Yep.

Parithosh Jayanthi: Go ahead.

Ameziane Hamlat: Yes, sorry, I was going to say, I have noticed a drop in the network activity on on peso validators, on HODI. And I guess that was expected, and I wonder if there are any other metrics. I think it is interesting to see, like, the drop in the network usage. Especially just before the next BPO. If we have other metrics related to that.

Parithosh Jayanthi: Is this for the whole Ski network, or the Houdini network?

Ameziane Hamlat: Sorry, holesky, holesky. Like, the… after the fork.

Parithosh Jayanthi: Okay, yeah, maybe we can just chat about that on, on our group, and then we'll try and see what we have associated to the bzov validators, and see where we can help.

Ameziane Hamlat: No, it is not an issue. It, it, it is, it is more, an observation, That, in my opinion, was expected, like the drop in activity, in network activity related to PERDAS. So that was something that I noticed on the… like, on the… on base validators, and I was just wondering if… If that was the case, and if we have, like, numbers, I thought it was interesting to check… to check that specific metric, just before The next BP rule?

Alex Stokes: You just mean, like, total bandwidth usage?

Ameziane Hamlat: Yes.

Alex Stokes: Yeah.

Barnabas Busa: Did you notice the song on Super Notes, or also on full notes?

Ameziane Hamlat: Sorry, say it again?

Barnabas Busa: Did you notice the bandwidth usage increase only on super nodes, or only on, full nodes?

Ameziane Hamlat: It's, it's a decrease, it's a decrease in the bandwidth. So we dropped, like, by more than 50%.

Barnabas Busa: Yeah, but is it a validating node, or not?

Ameziane Hamlat: Yeah, yeah, validating notes.

pk910: Was that exactly at the fog boundary? Because we… shortly before the fog, we started spamming blobs to the network. Before that, there were basically no blobs.

Ameziane Hamlat: Yeah, so that was exactly at the forked boundaries, just after the fork, actually. But do you, like, do you see the same on other clients, or not? Because I would expect to see the same. So, basically, a drop in the bandwidth usage.

Parithosh Jayanthi: We're still working on our bandwidth analysis, so we don't have… have that yet. But yeah, as soon as we do, we have it clustered per client, and then we'll have the report generated probably tomorrow.

Alex Stokes: Okay. Anything else on Halashki? Okay. Then next up, I did want to call out this PR, so… This came up from ACDT on Monday, and… Essentially, I think it was a couple different things in here. One of them, is just having, what we usually call, like, a readiness doc. So, you know, you could imagine there's, like, a pure DOS readiness doc, which just runs through, you know, these are the different checkpoints we need to see on the network before moving ahead, these are different tests we want to do, things like this. There was one here… from, you know, sort of across the whole lifespan of PureDOS development, and it kind of became… well, let's just say it became a heavy working document. If you go to it now, it actually links to a Google Doc that also has a bunch of stuff.

That was one part. Another part, is actually just copying over some of the process stuff that we put in place with Pectra. And most of this is relevant for mainnet, so I just started the PR and just kind of put down the skeleton here. We'll fill this in, you know, once we're closer to Fusaka Mainnet, but it's there. And… Yeah, I should probably go and clean up this readiness document. It's… I have a mess right now, but either way. I'll keep working on that. But just wanted to call this out, again, it'll probably be more relevant As we get closer to mainnet, but that's underway. And… Yeah, I think that's all we had on the agenda for Forsaka today.

Anything else? I mean, in short, So far, Leshky's gone well enough, and we're gonna keep moving forward. Okay. So then, Glamsterdam. I'm… curious what people think, you know, so we've kind of had this… let's just say directive over the past couple ACDs of saying, hey, you know, we're focused on Fusaka, so let's, you know, kind of not think about Climstrom too much. It seems to me, just kind of reading the room, that we're at a place now where I think we can start putting more attention back into Glensterium. You know, obviously, if some of the FSACA changes, a testnet doesn't go over something, that will change. But it seems like we can start focusing more on Amsterdam, so I would expect…

kind of starting today and moving forward, we'll have more emphasis on Glamsterdam back in the different ACD calls. So, to that end, we should probably start thinking about, you know, the whole process. So what does that mean? The process here is getting the specs hammered out for Amsterdam, it's getting to DevNets, and going from there. So, one thing I could ask today is, how do we feel about, the DevNets for the various headliners? I don't know if we want to touch on BLs today, but we can definitely touch on EPBS. And again, everyone's been busy with Fisaka, so if the answer is not much has changed, that's fine. But I would be curious, for an update there.

Potuz: update on PBS or on… on… on block-level access lists?

Alex Stokes: Oh, sorry, on EPBS, yeah.

Potuz: There's, nothing that has changed on the specs side. There's lately a discussion of, how to Better enable, trusted payments. We can have trusted payments just with the protocol as is right now, or there's a suggestion to add a field for off-protocol payments. That's the latest discussion on the spec, but the spec itself hasn't changed, we've been adding tests. And since we are finding still bugs on Fusaka, we cannot. start merging on develop. I think Teco is the only client that actually has, on their main branch, passing tests. Prism has a branch that has passing tests, but it's on a branch. It's still not on the main develop branch.

Alex Stokes: Gotcha, okay. So we're probably still quite a ways away from, EPF WebNet.

Potuz: It's… probably not. As soon as we actually have a stable Fusaka branch, we can quickly merge all of Terence's work, and we will have some interrupt. And I… from the message that, Stefan posted on Discord. Porteco, I mean, probably Stefan is here, that he can say, but it sounded like they are close to at least Cortosis.

Stefan Bratanov: Yeah. From Deco perspective, I wouldn't say we're close, I think… we want to focus a bit more on the design of… I mean, passing the reference test is a good first step, but there's a lot of things that, Because the interop branch that we had before was very hockey. So, I think I want to focus on, like, a proper design. So, I think there's, there's a why I want to… We have DevNet, and since other clients, are also… Oh. not, yet ready, I think we will wait a little bit and… Be more careful when merging to master.

Alex Stokes: Yeah, I can see that. Yep, Harry and Barnabas are asking… Or at least they're just pointing out we can run from our branch, but… It sounds like what we don't want is to have, quote, a random branch that just becomes kind of unmanageable down the line. So… makes sense to be a little more mindful with that, because we kind of got into the situation with Pyrodos, as far as I understand, so… Let's not avoid that.

Potuz: Yeah, we don't want to repeat what happens with Fulu. We really want to start merging and develop right now.

Alex Stokes: Okay. So then, yeah, we just need a little more time to get Fusaka even more stable. Well, I guess, yeah, I guess that's the question, like… how much is it we need to, like, think about more bugs coming down the line with Husaka versus… it's just gonna take more time to get to, like, a stable EPBS branch, because we don't want to develop on the non-trunk.

Potuz: I think we're gonna be very close. We just, like, had a release with a regression, and that's why we are delaying, but we were about to start merging this Monday. So I suspect that next week we will be merging already on develop our gloss code.

Alex Stokes: No doubt. And yeah, Pari has a comment here, are we happy with the design then? Unknown unknowns, and I believe you're referring to the spec, and that also tees us up for the next thing on the agenda. As POTUS mentioned. And some others have been discussing this week. There's a question around exactly how trustless payments work in EPVS. Lenoscope, if you're here… Oh yeah, I don't know if you wanted to say anything.

Lin Oshitani: Yeah, can I… do I have time for a quick presentation?

Alex Stokes: If it's quick, yeah.

Lin Oshitani: C. Who… Can you see my screen?

Alex Stokes: Yep.

Lin Oshitani: Yeah, so, like, this is basically a call for discussion on trustless payments in EPBS. And quick context is that, EPBS, like, brings two critical changes to Ethereum. One is payload separation, is execution payload block separation. A lot of nice things, you separate the execution plate from the beacon block, you propagate and execute them separately for good pipelining, you get CL-side delayed execution. And process payments is another critical change that it introduces, where your builder becomes in protocol staked entities, commit to bids, propose or fetch bids, and payment is first in the CO. So, my proposal here is that we should either have a convincing argument on why trusted business payments cannot be separated from the current DIP,

And that the complexity is worth it. Specifically, that there's no incentive to bypass it? Or we should have a separate EIP between the payload separation and the process payments. And discuss and decide them separately. Why? I see two reasons. One is, like, that these two features fundamentally have different stakeholders, so payload separation, it's about slot restructuring and scaling, so core devs are the experts here. They know all about scaling and can run benchmarks and all that. And ecosystems, they largely depend on CoreDevs for their expertise. On the other hand, for choices payments, it's about changing… fundamentally changing the block building pipeline, so I would say that the stakeholders are more the ecosystem players, like validators and builders.

That are the experts, and end user of the feature too, and core devs, in my opinion, should take into account these activities, and My impression from the outside is that a lot of this discussion has been focusing on the payload separation. when Lamstrom was being discussed, like, what's the best pipelining solution and slot-restricting solution? I think there was fundamentally less discussion around the trustless payment part. And I think this is important in terms of governance, and one… I think, interesting case study is EOF. And I think I know that it's very, very different, but I also see a lot of parallel, and… Enough that it's interesting, and… I think EOF had different stakeholders. One is, like.

with the core devs, and this was about removing tech tip and enabling easier upgrades of the EVM. And another was app and tooling developers, and they were, like, about the enabling better compiling tooling, and also at the cost of breaking changes. My impression from the outside was that the former was convinced, and the latter was not, and the end result was a loss for everyone, in my opinion. Well, the next reason I have is complexity and uncertainty. So, like, complexity of trustless payments, like, in terms of spec and CEO implementation, it's relatively simple. I would say is still, like, conceptually adds some complexity, because they're the new staked entity, but… I do see that it's, like, not the bulk of the complexity in each PBS.

Well, in terms of ecosystem impact, I think it's far from simple. Like, it requires fundamental upgrades across the tool links, taking… And also, like, staking protocols, their accounting contracts and infrastructure. And it also had, like, a fundamental impact on the builder market that is very unclear. And, like, you can see, like, they send different, like, write-ups from different teams, like Lido saying that it adds a non-trivial increase in the protocol complexity, especially if they have to maintain both, like, the in-protocol payments and the off-protocol payments. And yet Aitan has pointing out that it will also negatively affect competition and increase concentration by raising barrier to entry, because you need to lock Like, liquidity up front, and also, like, you have… also always have the risk of losing it to everything if, like, your block doesn't land, and all that risk is up to the builder.

So, like, complexity may be worth it if trustless payments are actually widely used, however, I think bypassability is an open question. Like, referring to the fact that proposers may be incentivized to bypass an improtocol justice payment. and instead use off-protocol options like MedBoost, And… If We have, like, bypassability, rational actors will bypass, hence we'll be introducing this complexity for nothing. And, yep. So… And, like, does justice payments re… like, one of the counterarguments here is that Business payments reduce latency, so that's why it's abused. Inc. that the card argument there is that current builders and relays co-locate, so ATC is mostly negligible. the point on, like, that we shouldn't… enforcing… like, we shouldn't be removing MedBoost supports from clients. I think this was another

like, option that was raised by core devs, but to enforce trust payments, but I think that's a… Bad idea, because it will introduce, like, security risks. Here. So, if justice payment is clearly and uncurially accepted, maybe it's fine to just bundle it with payload separation. However, based on talking to ecosystem players, it is a fact that trustless payments is controversial. And so I believe these should be separated, and separately discussed with the ecosystem, unless we have a strong convincing argument to bundle them together, and… I think that's also a possibility, but it's just that the people are not convinced. And… I think if there's, like, even a single-digit percent risk of ending up like EOF,

I think… I don't see a reason why we shouldn't separate. This is… Yeah, my personal opinion. Yeah, so this is my recap of the proposal. And… Yeah, that's it.

Alex Stokes: Cool, thank you. Yeah, I think this is definitely a question we need to settle sooner rather than later, and like you point out, I do think there, yeah, are some arguments here to consider. Ansaber?

Ansgar Dietrichs: Yeah, I mean, just in terms of progress by process, I would expect we wouldn't decide something like this just today, just because that's so short notice, and I would expect that many people are probably quite strongly opposed to separating the headliner AP out into two. I personally just wanted to briefly speak out in favor for such a split. I've been… I've had some troubles in the past with specifically the aspect that EPBS, just for historic reason, nothing wrong with this, no fault of the champions or anything, but, like, it just morphed. It started out as something focused more on specifically, like, trustless payments and these things, and then it, over time, morphed more into being focused on scalability, because that's kind of where the trend overall went to, that we wanted to focus lump sum on scalability, but

I had to look back, and almost all the clients that had a post on their position on EPBS, just before we made the headliner decision, specifically pointed out that they are supporting EPBS for scalability reasons, and so I do think that now puts it in this awkward position where there's this aspect of it, which might still be a good idea. I personally am somewhat skeptical, but the point is, it's kind of not… that was not part of the core of, like, why this ERP was chosen as the headliner. So I would really appreciate if we were to split out trustless payments and make the decision separately. It could still be… included in Glamsterdam, but as a normal EIP, that then has to basically, like, have one more round of discussion around it, and then, yeah, I would have my arguments for why I might caution against it.

But yeah, I expect that there's a lot of people that are on the other side of this, so I feel like we should probably not make a decision, like, today. But in two weeks, maybe.

Alex Stokes: Yeah, I mean, I think people will need time to dig into this, so I don't think we're gonna decide today. But I did want to, have the discussion. Yeah, there are a lot of moving pieces here. There's… you know, on, I guess, on one side, core devs here, you know, understanding some of these trade-offs, and just getting, you know, wrapping their heads around the spec and how it all works, and understanding that in context. Then, you know, another part of it would just be reaching out to the different community members that have been listed. I don't know, Greg here from Lido just had your hand up, so yeah, like, different sticking pools, different builders, and…

Yeah, getting their take on the feature as it is. And that process will probably take some time to play out, just given how we can service input to ACD from the community. And, yeah, sure, Greg?

Greg K | Lido: Yeah, hi guys, I'm Greg from, Lido. Yeah, I just want to say that, yeah, I pretty much, agree with the comments of, Lynn and, Anskar. Basically, yeah, on the conceptual level of it. So I think that, you know, as I said, we have this kind of two different PBAs. Basically, the one is the payload blocks operation, and the other, the… proposal builder separation. And, yeah, I think it would be a much more lean approach if we just have two separate things, because it's really conceptually separate, the one thing The main reason of this, like. It's the scaling part, and everyone agrees, and, like, we have a very good consensus on that, like, it's a scaling feature. The proposal builder separation has, like, other consequences. It goes beyond the scaling, it's about, you know, censorship resistance, it's about centralization, it's other stuff. So I think it also logically makes sense to separate those two things anyways.

So, yeah, I think it's very good that, Lynn brought it in the discussion today. Yeah, I agree also with Anx that we cannot take a decision today, like, it makes sense. But yeah, I think also, like. research-wise and logic-wise, I think it makes sense to have those two things separately, like, like, to have a more gradual upgrade. That doesn't… it seems a bit complex to have two sorts at one ape.

Alex Stokes: Yeah, thanks for the thoughts, Ryan.

Lion Dapplion: Yeah, I just went to boys that… Since 2 or 3 months ago, I was… I find it strange that we didn't have the chance as client teams to voice if we wanted to get payload separation and trustless payments, or just… payment, payload separation. So, yeah, I would support to have this split as soon as possible, so different stakeholders can clearly voice their opinion.

Alex Stokes: Makes sense. Yeah, Produce?

Potuz: Yeah, so… I think this presentation and this point of view lacks understanding of how the implementation on the spec is. Trustless payments. is two different things. In fact, for that separation, just to have trusted payments, EPBS as is now is easier and safer and easier to implement than going trustless a la MapBoost. The reason being is that we want to have separation of broadcast, we need to have the payload being signed. I'm sorry that I'm going to be technical for a little bit. But, to have that separation, if we keep without all of the machinery that EPBS brings, and we keep the map boost. sort of diab… the boost mechanism that we have today, then that incurs in a bunch of trade-offs of, like, going back and forth to share the payload and blind signing, and all of this machinery that we have today, just to prevent the builder from being unbundled.

If we have EPBS today, just as today, no changes. Lido doesn't need to change their contract, Lido just needs to tell their node operators, hey, listen, only whitelist these builders. These builders are going to be paying you on the EL and are going to be bidding for one way on the protocol side. EPBS does not prevent off-protocol payments. It does not prevent a node operator from trusting a builder and whitelisting it. What EPBS brings, and now, having said so, that it's actually easier to have trusted payments on the EL with the current implementation and the specification of EPBS, It's also better for a lot of other reasons, because even if the builder is paying on the EL of protocol, is still signing the payload, and we can actually detect on-chain, we can detect censorship, we can blacklist particular builders even without having been the ones that proposed the block, we can do a lot of things that we could not do without having a signature on the payload.

So those are just… those are already reasons to have the on-protocol mechanisms, and at the same time, it's very simple to go off-protocol for the payment itself, if the node operator just has. EPBS does not try to force an on-protocol payment. EPBS just gives you the option to have a trustless payment.

Alex Stokes: Okay.

Potuz: And just in response to Francesco, it's exactly what I'm saying. So, the people that want to remove trustless payments, what they are saying is, remove everything, like, all of this withdrawal mechanism, the state builders on-chain, and all of these things. It's not what we're discussing now on Discord. They really want to remove the whole… so they are calling trustless payment two different things. One is the stake builders, and the other one is the payment itself. And the claim is that the payment itself can be trusted on EPBS, just as, without any change. And Lido doesn't need to change their contracts at all.

Lin Oshitani: So you… Just to confirm, like, you're saying that you're… Fine with, like. In Prism, for example, like, you just keep the Memboost support.

Potuz: No, we don't keep the MedBoot support at all. We don't have any MedBoot pipeline, but you can whitelist the builders that you're gonna take bids from, and those builders are going to bid, say, one way only on the actual on-protocol side, but they are promising me that they're gonna be paying me off-protocol. And this way, Prism doesn't need to do any changes on the implementation, and you just only whitelist the builders that you're going to be dealing with.

Lin Oshitani: You see? But yeah, I mean, if you're… I think your point here is, like, that trustless payment is critical. For the scalability part. I think that's the part that a lot of us are not quite getting.

Potuz: I am not claiming that at all. I haven't even mentioned scalability.

Lin Oshitani: But… the commit and review… okay, so the commit and reveal, like, difference, right? And you're saying that if we… that difference. Is tied to trust this payment, or… like… Or, or do you…

Potuz: incometer reveal with assigned payload by the builder is easier than doing it when the payload is signed by the proposer, because then we need to go the blind route, signing things that we haven't seen, and exchange the payload and fill it as we do now with MedBoost. Doing it as it is on EPBS is much easier. Because the signature comes from the builder, and the builder can reveal whenever they want.

Lin Oshitani: Yo. I think… Yeah, I think there's still the question of, like, well, probably we maybe don't have time to go… too much, but I think there's still the question of, like, bypassibility, even if we… if it's, like, in-protocol cleaner, if they… you know. go through the trustless payment? Like, will they? I think that's still an open question, and if it's an open question, is it worth it? But, yeah, I do see your point, that… With the comment real time being, like, 4 seconds or 6 seconds away, like, trusted payment, Might have some. Advantage. Either way, I think, like, we need convincing. About these facts.

Alex Stokes: Okay, so, yeah, before we get too deep into the weeds here, It does sound like we should look at all these different, you know, the different design decisions here. have some written document, ideally, of the trade-offs, and I think that would help drive the conversation forward. That's not gonna happen live right now. So I would suggest that's something that we work on, is sync, and yeah, again, we'll see, timing-wise what that looks like. I don't know if anyone can guarantee that, you know, by the next call, we'll have this all together, but I do think we should keep this moving. Yeah, Terrence has a good point here. There is an EPVS breakout. It was next Friday, yeah, so…

That would be another good check-in. If anyone wants to get deeper into this conversation, that's probably the place to do it. And in the meantime, yeah, I think we should… I guess to Ansbar's point here, just around the process, like. What we don't want to happen is, yeah, something… like EOF with this EIP, so I think we should be flexible around the actual ultimate shape it takes in Amsterdam. And that's a conversation that can play out in ACDC, over the coming weeks. So… I think from there, I think things are pretty clear on next steps. And… Unless there's a pressing comment on that point. We can move on in the agenda today. And in that case… so, I think the last thing here for Glamsterdam was, again, just this reminder, so…

We had the headliner selection process. We'll have a selection process for non-headliners, for EIPs. And we had kind of said, okay, it'll be around Fusaka Mainnet. I wanted to propose a refinement here, just so it's, like, super clear exactly what we mean. I think the call where we set the Fusaka mainnet date, you know, it would essentially be the next ACD call would be the deadline for non-Headliner EIPs. So, again, that shouldn't be a surprise to anyone. But, yeah, just a reminder there. Okay. Yeah, Osbury?

Ansgar Dietrichs: Wait, yeah, just can you… can you clarify this one more time? You're saying the call itself… so basically you're saying in two weeks, we would set the dates, and that would then already… the call where we set the dates is already the cutoff time, because it feels like I would have maybe expected, let's say. on the call where we set the dates for the releases, we then also say, and that means that now we can set the exact cutoff time for ERP proposals, there's, like, one last week, or something. I feel like it's better to, on the day we make the decision, we make the decision not closing, but, like, saying, okay, on this day, basically, like, you only have, like, one last week. I feel like that's usually nicer than basically

Yeah.

Alex Stokes: That's what I meant. Maybe I didn't frame it well.

Ansgar Dietrichs: No, I probably.

Alex Stokes: And so.

Ansgar Dietrichs: Didn't understand correctly.

Alex Stokes: Yeah, so… yeah, like… For example, say we decided mainnet today, then by next ACD, that would be the deadline for non-headliners. Right, so you have that extra week. Does that… okay, that makes sense. Yeah, there will be time. The point will not be, oh, hey, by the way, surprise, this is, the deadline. And it's passed. There'll be time, before that happens. So… There's that. Okay, otherwise, there were a few kind of miscellaneous things around, other concerns, either with the process of ACD itself. Or some, yeah, various EIPs or names. Anything else on Glamsterdam before we move to that?

Okay, so then the first one… this is a follow-up from last week. There was this… proposal here, from Lullivan, I think is how you say your handle here. And it introduces this concept of a champion, that would essentially be point of contact for, getting an EIP into a specific fork. There is a number of comments here going back and forth. On some of the details. And ultimately, I think the language has changed a little bit. We had kind of wanted to get this merged in before today, so… We haven't, and I wanted to try to get final comments today. Yeah, well, then I see you're here, I don't know if you have anything to add.

Marc Garreau: Yeah, hey, this should be very brief. The… The suggestion last week was to more formally define the champion title as the primary point of contact, and that a PFI'd EIP needs to have that primary point of contact. Or a soft requirement for one. There was some hesitation on the usage of the word champion, because it, potentially gets overloaded as the word champion is used in EIP1, sort of ambiguously, so I've just simplified the proposal Two… down from three sentences to one, basically, in order to get… PFI'd into, starting with Glamsterdam. you should specify the primary point of contact. That's the end of the story. So this is just a… meant to be a logistics, Improvement, like a… hopefully a… Communication friction reduction.

So I hope that's, straightforward and agreeable.

Alex Stokes: Makes sense to me any final comments here? With anyone at present. Otherwise, I'll take a look at the PR. But yeah, I think we're probably in a good place to merge. So yeah, I guess then today… If you have any final comments, take them to the PR, otherwise it'll be merged very likely within the next 24 hours, and we'll move that along. Okay, next up, there was a comment here from Kev. So, okay, I think this is actually just a very narrow process thing, but essentially. With EIP7870, this was around the minimum hardware requirements, EIP… So just to move it from… Let's see, from interview to live. Okay, so it's just moving it through the EIP lifecycle process.

And I believe we just need to, like, agree on AACD that we're doing this, so it can be referenced. That's apparently what the editors requested. So yeah. Any… anyone have any issue with that? Otherwise, we'll just go ahead and move it forward. Okay, that was easy. It's just changing the lifecycle status, so it's not really a material change. Next up, H-star. So, ABC caught up? is calling out that H-star needs a name, which I agree. And he proposes to have the name set by Passaka going live on Mainnet. I don't think we'll have any issues there. I will share this link. So this link here, there's a sort of informal poll on different names.

And, yeah, I would… Personally think just use this for signaling and go ahead with the most popular option. Which right now is called Etios. So, yeah, if you have strong opinions on the name, I suppose take it to the ETHM Magician's thread. And then from there, yeah, we'll get this sorted and a few ACD calls. Just so there's a name and we can move forward with that. Okay. That was everything on the agenda today. Anything else people would like to discuss? Otherwise, we will wrap up a bit early today. Okay, that's great. Then, yeah, in terms of immediate next steps, we have the Holeshky BP01 coming up in just a few days, so watch out for that.

And otherwise, we'll move forward on Glamsterdam, and yeah, I will see you all next time then. Thank you.

Lightclient (Matt Garnett): Thanks.

Marius van der Wijden: Thanks, bud.

Fredrik Svantes: Thanks, bye.

Ansgar Dietrichs: Thanksgiving, bye.

Justin Traglia: Hi, everyone.

Pooja Ranjan: Thank you.

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