All Core Devs - Consensus #187

Transcript

Alex Stokes: Okay, everyone who's joined so far, I'm trying to figure out how to… go to the grid view, so I can just see everyone. But let's give people a few more minutes to join, and then we'll kick things off. How do I…

Pooja Ranjan: Do you see 9 checkboxes on the right top? on Zoom.

Alex Stokes: Yeah, this is it. Okay, thank you. There we go. This is better in case people raise their hands or something. Yeah, okay, let's, get started in just a few minutes. People are… well, okay, a lot of people actually have joined, even in the last minute. Let's wait, like, 2 more minutes, and then we'll kick things off.

Nixo: FYI, Alex, it starts automatically 2 after, now.

Alex Stokes: Okay, great. Then, yeah, let's just start in a minute.

Matthew Keil: I love you, Stokes, I'm so happy you're back, oh my god!

Alex Stokes: Thank you, thank you, yeah. It's a good call to be joining back to. I think it'll be a fun one today.

Will Corcoran: Yeah, Alex, I think George adjusted the settings last week, so it should be live now. It starts right at the time that the meeting starts.

Alex Stokes: Okay, now let's go ahead and get started. So, let me grab… the agenda here. So, yeah, everyone, welcome to ACDC number 187. This is issue 2222 on the PM repo. And today, we have Glamsterdam to discuss, and Hegota to get into, so… Let's go ahead and do that. To get started, yeah, I'm still catching up on some things, so yeah, just correct me if I'm off by some numbers or something, but I believe we've had devnet 11. And… it might be done now. I don't know if there's any follow-ups there. I think also we could touch on DevNet 8, I think it is. So, anyone have anything they'd like to share on the status of the DevNets?

pk910: Yep, I can give a quick update. So DevNet11 was the latest devnet launched, and it activated Glamsterdam on Monday. And the activation went perfectly fine. We saw no participation drop, all clients followed ahead. It went all perfectly smooth, basically. Lido and Optimism deployed the stack on it, and they also gave an early feedback that everything went well, so… We likely keep the network up for another week. If no one complains, we'll then shut it down, because, primary testing should still go to definitely, 8. Yep.

Alex Stokes: Okay, great, thanks. And DevNet 8, DevNet 8 is looking good, too.

pk910: That's it for devnet 11. Quick update. Yeah, that's what I just wanted to follow up with. On devnet 8, we were running JUMP attack till early this week, that had quite some impact on several nodes, primarily, Besu. We stopped the attack early this week, and basically all nodes recovered since then. Besu still had shown a lot of out-of-memory issues, and we finally switched to, SnapSync to get them back up. There were a lot of minor issues. We had some block production issues with Lighthouse, a reth-gasmit mismatch yesterday. But both were basically due to bad images, and were solved by rolling the right images down. Yeah, one more thing that we've, seen this morning, some unknown attacker started to do some heavy t-store spamming on the network.

Most clients did handle it properly, but again, Besu seems to be heavily affected by that, so we have seen block import times of around 7 seconds, which corresponds to a… megapas per second of around 20, which is quite bad. So, yeah, something to look into. I think that's it from the DevNet side.

Alex Stokes: Alright, yeah, thanks. And I'm assuming all the different client teams are aware of these issues.

Justin Florentine: Yeah, we are. We actually have two PRs in flight to address them already.

Alex Stokes: Okay, great. Cool. So… Yeah, there's nothing else on the DevNets. One thing we should certainly talk about today is the test networks. And yeah, maybe this latest data on the DevNets might adjust what we want to do there. But yeah, before we get to that, there was a question about MPLEX and Qwik, and some of the networking stack here. I don't know exactly where to put this, because I think depending on how we want to handle it, it could be a Glamsterdam thing or a Hegota thing, but in any case. Is Lukas on the call? Actually, wait, I think you said in a comment. Okay. Anyone from Teku, would you like to… Touch on this comment.

Stefan Bratanov: Yeah, it's, Stefan from Teku. Yeah, so we had a discussion internally with the team. And, what we… Like, basically our thoughts are that we… Don't want to deprecate NPLEX for Glamsterdam releases. And then, slowly, after the first glance enamelis, we can… not even only deprecate NPLEX, but also just completely remove TCP. But we would like for Glamsterdam to have TCP. enabled, just because right now we don't have the data, actually, how many people still use TCP. How many people use Quick? So… Just to be safe, we, would like to… Start disabling it after Glamsterdam?

Alex Stokes: Okay, and to be clear, so for now, for Glamsterdam, it would just be… Announcing that we are deprecating, not actually pulling out, say, Inplex.

Stefan Bratanov: Yeah, so we have Quick enabled by default. But, problem is, right now, Not every user has migrated, potentially, to latest versions. So… yeah, we don't have the data, and I think it's risky to just completely remove TCP from Glamsterdam. But after that, yeah.

Alex Stokes: Alright. Have you talked to other client teams, and or do other client teams now? Have anything to add here? I think this seems pretty straightforward, assuming we want to do it now. We've been talking about… Well, at least the NPLEX part. We've been talking about this, I think, for quite some time, and… Yeah, Qlik seems interesting, But, yeah, I think probably something for Hegota at this point. Daniel?

Daniel Knopik: Yeah, so… We have to… So… so the ongoing efforts, to deprecate MPLEX is… Yeah, has been ongoing for… Three years now. And, we, earlier in the year, agreed to deprecate it for Glamster Dam, and it's a bit unfortunate that it's now considered not ready. So that is, like, the first point I want to make. And the second point is, this is not, like, deprecating MPLEX is not deprecating TCP, because MPLEX, Yannux is still… Existing, in principle, and supported by a large share of the network. So… Yeah. I guess it's… it's… yeah. a bit disheartening to see that Teku is now pushing again for a delay after 3 years, and…

I don't… it's that confidence-inspiring that we will, like, ever get rid of this.

Alex Stokes: So, what's a good way to import today? I mean, yeah… So… Am I correct that we can separate Influx from Quick?

Daniel Knopik: Sorry?

Alex Stokes: Are they a couple… can we, can we, like, treat these separately? Can we, say, deprecate NPLEX and focus on that? Cause I feel like that's something we can do. Hopefully, for Glamsterdam. Then, separately, we can have the quick question.

Daniel Knopik: Well, the thing is, we need to communicate somehow. That is either TCP and MPLEX, TCP and Yamooks, or Quick. And deprecating MPLEX, like, having some clients actually remove it, without enabling quick. Would render some clients unable to communicate. So, but… So, Teku's… is Teku is quick and enabled by default, right? Bye now.

Stefan Bratanov: Yeah. Yeah, we have quick enabled by default. Yep.

Daniel Knopik: Cool. So I think…

Enrico Del Fante: But the problem is that our user space is… we don't know how… How many of the user base, or techo user bases, actually… change the configuration so that they are actually using WIC. Because you have to do your networking configuration. to do that.

Alex Stokes: And you're concerned about forcing the default on them when perhaps they're not working Environment's not set up for it.

Enrico Del Fante: Oh, yeah, the problem is that you find out when… when there is a problem.

Alex Stokes: Yeah, but… well, yeah, I was gonna say what Kev said here in the chat, wouldn't this be an issue for everyone?

Enrico Del Fante: We were also thinking about suggesting putting stuff into our… into all clients, saying. some, like, some warning, like we did during the merge, to check the configuration and say, if you, if you are not actively using quick, and you don't have peers on QUIC currently, you throw a warning, say, hey, please check your configuration, because in the… we're gonna deprecate TCP connections soon, so please migrate to QUIC. But unless you don't do that, it's kind of unsafe, because we are Blindly. We're blind.

Alex Stokes: Yeah. Okay, I do want to just be aware of the time on this topic, but yeah, potuz and Matt.

Potuz: Just a quick comment. I don't buy Enrico's comment of, like, not knowing how many people change their configuration. Just flip the flag now that you're gonna have Glamsterdam releases, and they are forced to use them. Make, quick by default. and then we can just quickly deprecate it on the first release after Glamster, and if there's no problems.

Matthew Keil: That was exactly what I was gonna say. Just make it by default, and then, with a warning that we're gonna deprecate soon after, and get rid of everything else, just use quick.

Enrico Del Fante: Sure, no problem. It's already like that. Its bite is not… force deprecating MPLEX before Glamsterdam activates. After that, It's okay.

Alex Stokes: Okay, do you want to do it that way, then? So, with Glamsterdam, everyone will be quick by default. Yeah, it'd be nice to have a warning. Say if you detect there's pairing issues. then clients are free to deprecate and Plex after Glamsterdam, once it's live. Okay. Cool. Anything else on this topic, or will that make us happy for now? I mean, there's… I don't… let me just check this corner one time. Yeah, I think that'll cover it. And… Should that employee, we merge, the spec PR that Justin has here? 3866 after Glamsterdam, because then it will reflect the fact that we've deprecated NPLEX. Does that sound good to everyone? Okay, one thumbs up. I think this car hasn't open for a very long time.

But hopefully it's, acceptable at this point. Okay. So… Yeah, there's some more discussion in the chat here, but it sounds like we have a good plan. Does someone raise a hand if we need to revisit this? So, okay, in that case then, yeah, it sounds like that's pretty straightforward and won't really impact Glamsterdam timelines, Which is good, that's what I wanted to clear. So then now… okay, I do want to talk about the fork dates. It seems like we agreed either last week or even, this week on ACDT that we would fork Sepolia to Glamsterdam on October 6th. And let me just grab this here. So… It sounds like everyone's in agreement here. I guess this is your final, final chance, if you want to change something.

I guess in particular, given the latest information on the DevNets from PK. That wasn't, I think. the most, heartwarming outcome, so I don't know if this is worth revisiting, but I assume it's not. So, are we all good with, the Sepolia fork date? of October 6th, which is very soon. Okay. I'll assume that's good, because no one's saying anything. So, yeah, that means a couple things, like, I believe, we'll want to get a blog post out, just with the fork timing. We also want client releases, so this is where I would like client teams here to chime in. Do you have client releases out already, or will you very soon, like this week, for Sepolia?

A week before… You tell me, Terence. Is that enough time for your users, historically?

Terence Tsao: Yeah, I mean, Sepolia is fairly, like, centralized by nature, so…

Alex Stokes: That's a good point. Okay. Then, in any case, are we okay with the timeline? Yeah, basically just have releases out as soon as possible.

Terence Tsao: Well, it's mostly the blog post, right? When do you guys think to do the blog post?

Alex Stokes: Mike, that could be done… Tomorrow at the latest. Like, that won't take very long. That should have already been out, I think. So something we should do ASAP. Otis, then Fredrik.

Potuz: Just a comment, if… if we are going to fork soon, I would… Strongly advise clients to have a ready, good circuit breaker for the P2P stack on DevNets. It might not need to be the same as the… I'm sorry, for DevNets. Might not need to be the same for Mainnet, but on DevNet, it's just trivial and cheap to… to, like, dust the entire chain by sending high bids, so please have good circuit breakers. We're not gonna work without circuit breakers on DevNets.

Alex Stokes: Yeah, do we not already have this, put us? I imagine… I would hope for.

Potuz: I don't think Fred…

Alex Stokes: We would have already been doing this on DevNuts.

Potuz: I don't think we have, we have all clients having circuit breakers, especially none that are banning per builder. I think most circuit breakers, like, just fall back quickly to To… to local building, Only after a lot of blocks have been missing?

Alex Stokes: Okay, well, this is a good point. Yeah, try to do this, and… as long as enough of the steak on Sepolia has this, then it should be okay. T.M. Fredrik and then Tony.

Fredrik Svantes: Yeah, I just want to say that… By doing this, we're… just so people are aware of it, that we are bypassing the… Protocol upgrade process, which do state that we should have or there must be at least 14 days between client release being ready and the first testnet going live. The reason for that is that Those 14 days? Have been used for internal security reviews, and… Adding the release-ready clients to the bug bounty program. As well as, you know, potentially doing some external security reviews, and by… Lowering the window to 7 days, we… Don't have as much time. to… to review… I'm guessing it's… may be more acceptable this time, because, as terence mentioned, Sepolia is more centralized, so if something do go wrong, then we can probably…

Rescue it easier. But, yeah, I just wanted to flag that it's, Yeah, that's the reason.

Alex Stokes: Yeah, we have those two weeks for a reason. Thank you for flagging that. I think it's a good point. I would say if we're comfortable with the shorter time frame for just Sepolia, I do… at least I hope it will be okay. Maybe a path forward is just to have clients say. Hey, try to get your releases out as quickly as possible, and, you know, if that takes… let's see, it would be, like… let's call it maybe 10 working days. That's one week before, but if you can do it sooner, you know, that's obviously better, because it'll just give more time for more eyes. So…

Fredrik Svantes: Yeah, as soon as… as soon as the release is ready, they can be included in the Bug Bonsai program.

Alex Stokes: Okay, so yeah, please try to get a release out sooner. If anything, I don't even want to say one week, which would be the 29th, but 29th at my latest, please try to get it out sooner. I think that will do for now. And… Yeah, Marius, to your question, that's what we're discussing right now. Like, The fork should be ready to go for the 6th. And that basically means client relations should be out. Face up. Tony, you'd hide your hand for a minute.

Toni Wahrstätter: Yeah, I had a comment, not to the dates, but to what you said earlier. I was wondering why we would, be stricter on the definite when it comes to the P2P circuit breakers, because I've been using a few builders to test EL things, and having, like, strict circuit breakers would make that impossible. I think we should just use the same circuit breakers that we have on mainnet.

Potuz: Well, because I can just spin up a thousand builders, rotate them, offer very high bids, and not produce payloads. for free. And I just dOS the chain for free. I expect this to happen. Any teenager can do this.

Toni Wahrstätter: Yeah, but it's also possible on Monet, like, that's how…

Potuz: Yeah, but it may not.

Toni Wahrstätter: Like, if you can take the… Right, but if the attack works, then… It might be worth it, even if it costs money.

Potuz: Yes, but that's not a problem, that's just the market. You can do this today. So today, I can buy a block, I am paying Ethereum to buy a block, and produce an empty block. That's something that is fine, and we live with that. I can do this today on Mainnet. But on DeathNet, this becomes trustless, and it's not something that we want to accept. Because it's free.

Toni Wahrstätter: Yeah, I'm not thinking of… I'm not thinking of attacks like this, I'm more thinking of an attack like I buy a payload, I wait a few slots, I release it into a different payload, I try to DOS the proposal of this different slot by releasing a completely different payload way too late. Causing the EL node to reorg back to that state, and then execute the block. There are, like, scenarios like this that I try to test. And for that, I'm always, like, missing my payload, because I'm releasing way too late.

Potuz: that's… that's fine, and we are going to carry those kind of tests. Both we're doing this on DevNet now, and we're going to do this on testnets. But, I mean, facilitating this kind of testing by allowing anyone to come in on a testnet that is free to get ETH, and honestly just take every block out by just outbeating everyone? It sounds crazy to me. We… users are relying on these testnets to actually test their infra. We cannot make it, like, have zero payloads and ruin everyone's testing on these testnets.

Alex Stokes: Yeah, I mean, that makes sense in general. I think we just try to do what you asked, put us, which was, yeah, everyone do their best to have circuit breakers in place. Again, as long as we end up with A large chunk of the stake in place and time. Should be okay, and address this issue. And… yeah, then we can keep things moving. In part because I also want to touch on the Hoodi fork. And, yeah, essentially, just the more we delay Sepolia, the more Hoodi's delayed, the more maintenance delayed, etc, etc. Okay, it sounds like everyone's good with Sepolia. There's a set of PRs that go with this, Yeah, so I can work on these today. So, like, a blog post for everyone, there's ETH clients repos that have various data in them.

And then also the Meta EIP, so… Assume that will all be handled today or tomorrow. Then we'll get client releases out ASAP. Again, absolute deadline would be the 29th, but please, please, please try to get them out sooner. That will just make it much easier to do a security review. Everyone okay with that? Okay. And there was a question now of Hoodi, and when we want to schedule Hoodi. I think there might have been a question, again, either Monday this week or last week, about scheduling them together. I don't know if we want a couple of these things, but in either case, I did want to float a date for Hoodi. I think there was a suggestion… a suggestion of either the 26th of October or 27th would just be, I think it was 3 weeks from the 6th. I can double check that on the calendar, yeah.

Yeah, are we ready to go ahead and pick a date for a hoodie? Okay, Matt says he wants to wait to see Sepolia. Which isn't the worst idea. It just puts more time in to things. if we… here, yeah, Matt, what are you thinking? Like, what is WavePoint.

Matthew Keil: I mean, it'd be nice to see…

Alex Stokes: Like, one week, or longer?

Matthew Keil: It'd be nice to see a smooth fork transition, both on the CL and EL. Is all I'm… I'm saying before we schedule Hoodi.

Alex Stokes: Yeah, yeah. That's fair. But then it's like, yeah, do we want to have, like, an observability… let's say observation period of one week, or just a few days? Anyone here have any thoughts on this? Because… so there's an ACD on the 8th. So that Thursday after the 6th? And… what we could do in that case, then, is we could pick… the Hoodi date… I mean, even before, so let's say by, like, the 1st, you know, there can be a, you know, concrete date with all these PRs and all these different resources that can be ready to go. Such that on the 8th, we can basically just say, yeah, if Sepolia went well, everyone gives a thumbs up on that ACD.

Then, we're live, client relations can be out. Yeah, hopefully soon. I'm looking at the calendar while I'm trying to work through this. Like, say we did that, client releases were out by the 13th. And then that's 2 weeks until the fork if we targeted the 27th? Would that be enough time? For a Hoodi.

Matthew Keil: I mean, we could do a party like we did for, what was it, with the fish, and do it at DEFCON, and we do the fork at DEF CON together, we can hold hands.

Alex Stokes: Hmm… I would say not to do that. At least that'd be my strong suggestion. Just because Devcon can be distracting, and if something does go wrong, it's suddenly… we're not doing DEF CON, we're doing fork fixing. This has happened in the past, and it's been… not fun. So… I think we should avoid that week. And… that being said, also trying to figure out… Yeah, how to schedule these things to move things forward. Let's see… Yeah, POTUS, wait, can you speak a bit more to this? I think you're just saying… I assume they'll be ready. Yeah, I mean, I assume they'll be ready, right? So, like… Like, we won't schedule Mainnet until we see Sepolia and Hoodi, right? So…

Potuz: Yeah, but it… We are not… we're not really testing the actual builders that are the ones that we're using on… on mainnet, and it'd be nice to test them with them already ready at the fork, because that's what's going to happen on Mainnet, and we haven't been doing this on DevNet.

Alex Stokes: Hmm, okay.

Potuz: I hope to do this on testnets, at least.

Alex Stokes: Right. I mean, yeah, that's a good call. So we can do this on Hoodi, at least, and, you know, if we pull it together, also on Sepolia.

Toni Wahrstätter: What exactly wasn't tested there?

Potuz: just direct connections to builders, that's going to be, like, most of our blocks on mainnet, and we're not testing this neither them depositing before the fork and trying to build payloads after the fork, and having all validators, or most validators, actually connecting and calling them. I think even CL clients, I'm not sure how many of them are actually calling already on the builder API. So I know Prysm and Lodestar are, I'm not sure other clients. And this is really how we build our blocks, so we really need to test this, and it's completely under-tested now.

Alex Stokes: Oh, it's been tested on DevNuts, right?

Potuz: It is being tested on DevNets.

Alex Stokes: Yeah, but then you just want the integration of, like, quote, production, yeah, software.

Potuz: Yeah, we need at least Titan ultrasound, the normal builders, to actually deploy. Otherwise, we're gonna go without knowing what's gonna happen.

Alex Stokes: Yeah, so… I don't know how many of them run on Sepolia. If there are some, then we can start this now with Sepolia. I think we should definitely do this for Hoodi. So it's a good call-out. I think, though, that won't really change too much. From today.

Matthew Keil: I mean, just from a messaging perspective, like, do they realize 10,000 of us are gonna call in the same epoch and, you know what I mean, and try to open sockets all at once?

Potuz: No, that's not true. No, wait, wait, why would you do that? You only need to call 32 or 64 maximum.

Matthew Keil: That's a good point. Okay, take that back.

Alex Stokes: Okay, so, yeah, these have been good points to flag. I think then what we can say today is we move ahead with the Sepolia fork on the 6th. we… Sorry, let me just check the calendar one more time. A lot of logistics I haven't done ahead of time. So… yeah, if anything, we can have, like, a tentative plan for a Hoodi next week. As in, sure, like, I can even come and just propose a concrete time. Of course, that's pending Sepolia. And the point here is just to have these things pipelined, such that what we can do then is Sepolia fork on the 6th. Give it a day or two, such that by the ACD on the 8th, if everything looks good, we go ahead and say yes, Hoodi's happening, say, on the 27th.

That gives… call it a month, then also to get the builders, ready for testing on Hoodi, and then we should all be good to go. That gives us those few days after the 27th, you know, whenever that fork happens in that week, to observe what happens with Hoodi. then DEFCON happens, and… From there, yeah, we'll be in a good place to figure out mainnet. Sound like a good plan to everyone? Okay, got some thumbs up, cool. And, yeah, I don't know what sort of AI will produce some artifact after this, but yeah, I'll make sure that that gets written down somewhere, so that we can… Use it to move forward. Cool. So… let me grab the agenda here. Okay, I think this was all I had for Glamsterdam.

Any other Glamstrame comments we should touch on right now? Otherwise, we'll move to Hegota. Okay, thanks. So now with Hegota… so… yeah, my understanding is that we've, done the PFI process, so now that we have all these EIPs. For non-headliners, clients have put out their rankings, and those have, yeah, they're at least up now. Before we go directly into scoping, where I will have a suggestion on just how to approach the process overall, because I think there's something like 20… 23, CLE IPs that we'll have to work through. So that's, yeah, a moderate number. But before we do that, there was a request to go ahead and PFI 8411,

From Kamil here. I don't… is Kamil on the call?

Kamil Salakhiev: Yeah, I'm here, hello.

Alex Stokes: Okay, hey. Would you just want to give, like, a super… well, I don't know, maybe people already know 8411, but maybe just, like, you know, a few sentence summary? And… yeah, then the ask is, yeah, just to go ahead and PFI it so we can consider it for HEGOTalk.

Kamil Salakhiev: Yeah, can I have a few minutes just to give a context and explain what this maybe is?

Alex Stokes: Trick.

Kamil Salakhiev: Sweet. Yeah, hope you can see my screen. Yep. Okay, yeah, it's a new EIP, just, yeah, I would like to quickly go through Some timeline to explain the… motivation and some… give some context. So yeah, originally we proposed 8142, which is blocks and blobs, to be PFified for Higota. Yeah, that EIP proposed reusing data column subnets for payload broadcast. Then we iterated quite a lot, and Yeah, we updated the EIP, we replaced the networking scheme so that we are not reusing data column subnets, introducing new payload data column subnets, and also replacing KZG commitment scheme with Mercury commitment scheme. But yeah, that doesn't matter, because eventually we decided that much cleaner would be just to create a new EIP that would be purely focused on the

fast payload broadcast, and so here we are, yeah, we just would like to propose ACD and ask permission to PFI this Hegota instead of the originally proposed Blocks and blobs EIP. Yeah, the motivation is still the same. Yeah, we'd like to… Well, we can see the execution payload topic to be inefficient, payloads are large messages. Well, we don't have payload, topic today, but yeah, the blocks are around 100 kilobytes today, and in the past, we observed blocks of size 1MB, so that gives some numbers for what we can expect for payload messages. And, yeah, gossip-sub is not efficient for that large message processing, so we have store and forward delay. Yeah, so before we can propagate the message, we have to download it in full.

We have in-flight duplicates, so it's very hard to cancel A message that was already sent on a wire, even if the receiver already received the message from someone else, that creates some wasted bandwidth. And we think that, yeah, the urgency is growing with upcoming forks, so Glamsterdam increases gas limit, which implies larger payloads, and Yeah, there is a proposal for quicker slots, which cuts slot time from 12 seconds to 10 seconds. And importantly, we think that current… this new EIP's fundamentals will be, yeah, eventually applied in some other large messages. For example, for Bulse, there is EIP8146, it may be in LeanVM proofs eventually. And, yeah, kind of building this segment… segmented message broadcast machinery today.

would be, I mean, very useful in future, so yeah, we can iterate faster. with the next forks. Yeah, really briefly what this EIP actually is. Yeah, we're just splitting the payload into 64 pieces. Yeah, we build the Merco tree on top, we have Merco root commitment in the… well, we include it in the bid. We replaced execution payload topic with payload chunks topic. we attach, yeah, marco proofs to each chunk message. And importantly, yeah, we are not introducing any new EIP2P changes, we are not adding a res recording, we are not introducing 128 new topics that we proposed in Blocks and blobs, so we just want to keep this EIP really simple. But even with this change, yeah, well, in my simulations, and there were a bunch of other previous

work that confirms that as well. Yeah, we observed that we can already gain quite a lot. So, yeah, if we just replace this Vanilla gossip sub with the full message broadcast with chunked gossip sub, yeah, for example, in my simulations with 4,000 hosts and 1MB payload, the P95 latency for broadcast drops from around 6 seconds to around 2 seconds. We can squeeze much more if we just, yeah, introduce maybe a resume coding, introduce dedicated path traversal for each chunk, for example, by having dedicated subnets for each of them. But, yeah, that's, extends the scope. Yeah, we just want to keep the scope simple for Hegota, and yeah, in future we can iterate on top. Yeah, you can read more about,

some more research and some other stuff that we can build on top to actually optimize stuff. For example, there was post from Caba, there was a lot of work done by potuz, Raul, and many others that, yeah, was around about this. And yeah, that's all I had for today. Yeah, happy to hear opinion from clients, so thanks.

Alex Stokes: Well, yeah, let me jump in here really quick. So, just to be clear, both, I think, for myself and then to everyone else. The ask is just to PFI it such that we can consider it as a non-hemliner EIP for Hogoda, right?

Kamil Salakhiev: Correct, yes.

Alex Stokes: Yeah, okay. So yeah, like, just again, to make this super clear. That would mean that it is then, in the set of EIPs, you know, clients will need a week to go think about it and put it into their rankings, Yeah, unless that's already clear, but I think we'll need to take some time for that. So we're not deciding on it going into Hegota necessarily today, just… yeah. We're deciding, can we consider it? Okay. So as long as that's good… oh yeah, Kamil?

Kamil Salakhiev: Yeah, I think some clients already kind of mentioned that in their tier lists, so…

Alex Stokes: Yeah. Yeah, I think I saw at least one. But yeah, so I'm just trying not to get ahead of ourselves before we jump into scoping. Then on the EIP itself, I did have a question, because you mentioned erasure coding. This would be for it's compatible with anything we want to do there, right?

Kamil Salakhiev: Well, it's not backwards compatible, I mean, we need a fork for that. I mean, we're making change to the bit, we're introducing a new field.

Alex Stokes: Yeah, well, I mean more, like, if we do… like, if we do… 8411, can we, like, add more stuff on top later?

Kamil Salakhiev: We can, but it's not… for example, introducing a resure clinic will not be backwards compatible in full, I mean, we can.

Alex Stokes: This is something we could change, too, yeah.

Kamil Salakhiev: We can change some stuff, definitely there could be some implementation details which each client can work on individually, that… but yeah, on a wire, I mean, for Consensus… yeah, there are some optimizations that we can do that would not require a fork, but in future, for example, if we want to introduce erasure coding, I would rather have a separate EIP for that.

Alex Stokes: Ahmad.

Kamil Salakhiev: Yeah, I see a hand from Toni.

Alex Stokes: Yeah, Toni and Chopper?

Toni Wahrstätter: Yeah, I just wanted to add, the EIP is also very much a simpler subset of the Block in blobs EIP. So, to me, it feels like, Should be fine that it comes a little bit later, because it seems like clients, there's little appetite to ship Block-in blobs. But the CIP does make a lot of sense.

Kamil Salakhiev: Yeah, exactly. Well, these blocks in blobs, I mean, yeah, it was… the blocks themselves, they were a bit of disruption, I mean, yeah, which is why. I mean, the more we were iterating on the blocks in blobs EIP, the more… the less it was about blobs, and more about just payload broadcasts, which is why, yeah, we have this dedicated EIP. And from Caba.

Csaba Kiraly: Yeah, from my side, I just wanted to, yeah, that the goal is to be a fight, so that we can do the technical discussion without process. Complexities. And then, on the… Whether that Azure code or not, it's LEDE. The thing that we need here is to… to… to make sure that we have the additional commitment in the bid, and that's, that's… we regard that as the vehicle to… to send it around, and then from there, there are the details of whether we are good or not, and which scheme we use, and all those kind of things. I have a long lineup, which is going through, like, 20 options. And we can definitely go into more detail on that later, but…

We need that kind of change in the bid structure.

Alex Stokes: Thank you. So, yeah, and again, just to be clear, this is just on the PFI question. I… Well, yeah, My take is this seems fine. Ansgar had a comment here in the chat with a number of thumbs up. So, yeah, anyone have an issue with PFI? And, you know, kind of just to make… the process clear then, we'd DFI it today, we wouldn't, I think, be able to make a decision on it today, so then that would be a future call as part of the actual scoping decision, but it then would be in the set of possible non-headliners. Got another PFI seems fine. Okay. Okay, yeah. Seems to go to people then. So yeah, we'll go ahead and PFI it.

Then, the ask after this call will just be to have client teams, take a look and weigh it into their other rankings, and ideally even update their rankings. With this EIP. And then we will handle that on a future call. Okay, thank you, Kamil. So, now we can turn to… oh yeah, Ansgar, did you have a comment on this?

Ansgar Dietrichs: Yeah, just because I'll put it in chat, I would just directionally maybe ask that we… it doesn't have to be, like, a strict, this EIP gets decided after literally everything else, but I think at least… like, for example, I would not love if we would make a decision on this EIP in particular, say, already in two weeks, because I think while it is similar, like, it's basically a somewhat modified subset of BlockN blobs, but I think the considerations also around forward compatibility and, and say, for example, specifically the Why Now, it's all a bit… different, it's different enough that I think having sufficient time to really look into it would be really valuable, so I… I would just maybe ask that shared understanding is that we will make the decision on this EIP more towards the end of the scoping process. Yeah.

Just wanted to say that.

Alex Stokes: I mean, seems reasonable to me. I think that's a reason to ask. I guess on that topic, are there… is there, like, a breakout call for this work, or something like this? Because, yeah, the… Yeah. Okay.

Kamil Salakhiev: I think there is a Discord thread, yeah, where I will share the link in the chat, where you can jump in and discuss more. Yeah, we discussed that on P2P call, about the EIP itself, so… from the technical perspective. Yeah, I can share all the links.

Alex Stokes: Okay, thanks. Yeah, cause I… It might just be me, but I haven't had time to look at this too closely, so… yeah, it'd be good to… Have a place where we can learn more, and yeah, use that as a path to move this forward. In the scoping process. Okay. So, now we'll turn to, Hegota scoping with the non-headliners. So… Yeah, again, there are… let me pull up the forecast here. Looks like there are 23 EIPs, which is quite a large number of them. In terms of starting. What I would suggest is that we try to do what we can today. If you go by the client rankings, there are… you know, batches of EIPs that I think pretty much everyone agrees that we DFI.

There's something like two that we seem to have nearly universal support for, via the client rankings. So, I think for these, it seems like we can go ahead and make those calls today. Then from there, there's a number of more ambiguous EIPs I think… those will ultimately need more discussion, and so I would at least ask that we just handle those, at least on the next call, and… Point being, it might take multiple calls to get through this, we'll just have to see how it goes. But in that case, let me… Let's see… I was talking to Mark, he offered to help screen share. Let me try, Mark, because I think I can just do this here.

Oh yeah, Terence, you have a comment?

Terence Tsao: Now, there's one thing that I realized, and it's probably my fault for not reading this correctly. So basically, from our stance, we have this EIP that would give it, like, a very high tier, but then we say only if the EIP conditioning does something else, right? So basically, one example is this BOS withdraw credential retirement, that basically the EIP does two things. First. you basically block the deposit through the deposit contract. Second is that it… I think it forced, ejects 0x00 Validator, and for us, we really, really love the first part, we don't like the second part, so we basically say that we will give this an A tier if it only does the first part. But today, it does two parts, so I think it may be more like a

C or DFI tier in… in basically today's state versus, A tier, that's what we wrote it. But if you look at the forecast ranking page, it actually counts as an A, so I just want to throw that out. It may screw some, like, number here and there.

Alex Stokes: Hey, sorry, I was screen sharing, and I lost the mute button. Yeah, yeah, that's helpful, and I did want to get into that one, because that was 8365, right? So yeah, we should discuss that, but… Before we get there, I just wanted to run through kind of what I was thinking in terms of what I think would make sense today. So, essentially, yeah. So, can everyone see this forecast page? You're with the rankings?

Nixo: Yes.

Alex Stokes: Okay, thank you. So… Okay, like, just going by this, the way that I kind of look at this first pass is… We have these top two here, they have this little green box of a high enough average score via the client rankings here. Seems like those are non-controversial, and yeah, other than what Terence brought up, there was a scope question to get into around 8365, which we can do in a second. But, yeah, seems… And again, I'm not saying these are CFI'd, but I would propose that we start there, for today. So I think we can start there. And then also on the other end, we have all of these EIPs here that have essentially this little red box here.

There was not… Well, if anything, there was consensus on DFI for these things. So, I propose, in terms of actually working through the scoping, we would… do the two here that we can CFI. Then also do all of these that look like clear DFIs, which is everything 8237 and below. I will… strongly suggest we pull out issuance here, just because I think that needs to be considered separately, given the community impact, so I'd actually just ask to table 8363 today. But otherwise, I think we can go ahead and do this. There's, yeah, maybe 40 minutes or so left on the call today. I think we can do that. What that means, then, is there are these, like, more ambiguous EIPs with maybe more mixed support.

those I would suggest we tackle next call, you know? And again, it might take multiple calls to get through everything, but… That seems like a pretty smooth way to move forward, so… Anyone have any comments on that proposal? If not, we can go ahead and just get into it, and we could start with, these top two. I'm catching up on the chat. But also, I don't hear anyone. Oh, zoom in a little bit. It zoomed in on the Zoom UI. Hang on. There we go. Okay, sorry, is that better? I can make it quite big.

Justin Florentine: Much better.

Alex Stokes: Maybe like that. Okay, sorry about that. Okay, so, sounds like, we're on board with this process of just doing the things That, yeah, we can kind of clearly make calls on today. So let's go ahead and do that. We can try slide mode. Let me see what happens. The thing about slide mode is I don't know if it's gonna break it out… by rating. Yeah. So, we can do it this way. I think it might be easier, just given the way that I'm suggesting we think about it, just to go back to the other view. But, yeah. Because it kind of mixes these things. Let's hold off on slide mode, and if people think that it's useful, just, yeah, say something.

I think we might need it in future calls, but I think for today, we can move forward this way. Okay, so that was a lot of preamble, but then… Let me clear up my own screen. 8015. So, yeah, I honestly don't even know who the authors are. I guess I can keep screen sharing. Terence and Etan. Okay, so, yeah, I think essentially these just don't do anything today, and the EIPs just remove them. Pretty straightforward. It has pretty strong client support, so I would say we go ahead and CFI this one. Anyone… Once. To add anything? Yakhv?

Kevaundray Wedderburn: Yeah, I think Terence made a comment on the 8365 one.

Alex Stokes: Yeah, we're gonna get there next year.

Kevaundray Wedderburn: Oh, sorry, I misheard.

Alex Stokes: Yeah, 8015. So just removing these, I believe they're not even written to on the chain today. Okay, no one's saying there's any issues with this, so let's go ahead and CFI that. Pretty straightforward. Yep, okay, thanks, Tristan. Okay, now then, 8365, again, pretty wide client support here. I think this was NC, I think was the author? Yeah, I'm not sure if they're here, but… As many have pointed out, there was a question here around the actual scope of this one. And… yeah, I think, given the time, we have time to go ahead and CFI this, again, reflecting the client support, and figure out the scoping questions, yeah, before we even get to DevNuts. Would anyone like to speak to the scoping? I looked a little bit yesterday, and it sounds like there might be this EIP and a complement EIP, and then the question is kind of, yeah, which subset of features make the most sense.

Notice.

Potuz: Are you trying…

Alex Stokes: I think you muted yourself.

Potuz: Are you talking about the scope of 8015 or 8365?

Alex Stokes: Sorry, so… the… yeah, I believe we've all agreed to CFI 8015.

Potuz: Yeah, and that's fine.

Alex Stokes: That one's done.

Potuz: As, usage.

Alex Stokes: Yeah. Yep, yeah, so that one's good.

Potuz: Okay, so important.

Alex Stokes: Next, next year.

Potuz: of 8365, I think Prysm would DFI it, and it would change very much the scope, if we keep the scope… it would change very much the score if we keep the scope as it is. And I believe Lighthouse posted essentially the same view. That we… we are fine with… deprecating BLS at the fork, not allowing any more deposits, but we definitely do not want to force exits. So, I think this is not a… yeah. We strongly believe this. It's not… it's not a minor issue.

Alex Stokes: Okay. Yeah, I like so.

NC: So the opinions I've gathered, is that, yeah, I see a lot of support of removing the… the exit part from the EIP. But I just want to gauge, if any client teams or any researchers have made decisions on this, given that, XA is part of the EIP. And if I reduce the scope of this EIP, would they change their answer?

Alex Stokes: Yeah, maybe just unpack this a bit. So, yeah, the EIP right now… would also force exits of all 00 validators at the fork. And then the change, that sounds like there's… somewhat strong demand for, is just to drop that part, such that you can still no longer make 00 deposits, but otherwise, I think you just don't touch anything else. Is that correct?

NC: Yes.

Alex Stokes: Okay.

NC: But…

Alex Stokes: As authors.

NC: I see that a congregation.

Alex Stokes: Okay with that change?

NC: I'm okay if a lot of client teams show support, which I have seen there, there are. But I'm just, trying to see if there's any kind of team that's strongly against removing this exit part from this EIP.

Alex Stokes: Anyone?

NC: To Nixo's question, forced exit means that, the 000 Validators will be excluded from performing Validator duties. Their CL, their funds are, will still be on the CL side. Until they submit a BLS execution change. Then their funds will be swept into their execution address. In the meanwhile, they do not earn rewards, nor incur, occur… Or, incur any penalties.

Alex Stokes: Yeah, so I think part of the motivation here is that it's gonna make future PQ plans radically simpler, to go ahead and remove this mood of the credentials? Is there any issue on that front? Like, do we still have the same benefits if we don't force exit? I know.

NC: a…

Alex Stokes: Yeah.

NC: I would say the signal, for encouraging, people to switch to 001 or 002 will be weaker without force exiting these, validators. Because if you are only doing the deposit guard, it really doesn't touch Or, it doesn't touch their daily lives, like. It's just… it's mostly, yeah, it's not really… like, you're not, like, hitting them with a stick to encourage them to switch, basically.

Alex Stokes: I might be misremembering, but, what does this deposit card look like? I thought it was that you could still make a 00 deposit, but it would just burn your ETH, basically.

NC: So in the status quo in Glamsterdam, you can still create a new 000 Validators. There's nothing that rejects or drops them. So, the first part of this…

Alex Stokes: EIP.

NC: With this EIP, it would drop them. But the top-up deposits to exist, the 000 validators will still be processed as usual.

Alex Stokes: Hmm. Okay, in terms of time, it does sound like there's interest for this with the reduced scope, so… Is there a PR yet with the changes, or were we kind of waiting for this discussion?

Enrico Del Fante: Sorry, guys, what's the argument of not doing the exit?

NC: Some arguments I've, seen is that it might be too rushed, and we might not be given enough grace periods For… for those, people to switch. Before freezing their funds and essentially take away their ability to earn rewards, basically. And by reducing the scope, that means that maybe in a future fork, we do the forced exits, but not in the current fork.

Alex Stokes: Yeah, Terence, I feel like you're pretty strong on this, like, what do you see the difference being?

Terence Tsao: It feels like we're, like, committing to, like, a solution, but, like, without knowing what is the future roadmap of the PQ landscape, right?

Alex Stokes: Yeah. Can someone speak to that, actually? I'm also curious, like… I'm assuming somehow it's… I guess we're just worried about the BLS keys being… BQ… Sensitive, let's say. Put us in a cove.

Potuz: Yeah, so, the standard procedure for deprecation is Is to do a deprecation, and then another time for actually exiting. And agreeing on deprecating this right now, and… but at the same time, the protocol accepting deposits is contradictory. So I think deprecation is that thing. We're no longer accepting deposits, and then the next time that we actually enforce exits is the next fork. But also, it gives time to several thousand keys that are active today, that are validating today, because they were stolen. To try to… and they're earning rewards, to try to mobilize their stakeholders, probably ourselves. to see if we can find a solution for those kids. Otherwise, we're just rushing them on the next year without having them… giving them an opportunity.

Alex Stokes: down.

NC: Right, so the argument is, like, how long… Over time should we give them? if we do the announcement right now, if the EIP is CFI'd to the live day of Ekoda, that would be, like, 6 to 8 months. Would that be enough? Or are you saying… consensus.

Potuz: I'm saying that if we do this today, that would count as the deprecation time, but then at the same time, the protocol still accepts deposits, so we're not really deprecating anything. So I think the standard procedure to deprecate is you no longer accept anything, and then In a future epoch, you force exits.

Matthew Keil: you know, this is what I was just thinking. Is it possible, and we've never done something like this before, where we have a two-fork, a two-fork EIP, where it's written into the EIP as, as of now, that In H, we close the door, and then in I, We're gonna do the force exits so that there is a well-trodden timeline that people will be able to, to refer back to in order to get their keys sorted and get themselves ready to… before we exit them.

Alex Stokes: Yeah, it sounds like a number of people are kind of proposing something like that. maybe figuring out the exact I-Star details down the line, POTUS.

Potuz: Also, I want to stress that most likely, these keys are PQ-safe. They have never signed a public message, and we can just keep them as they are. They are PQ-safe. We can trust the signature from those keys because they've never signed anything public on the withdrawal credentials. So I don't see how this is a problem. We're gonna be frozen… freezing these keys right now, in Hagota, and by the time that we actually come up with a solution for PQ, then, well, we can trust the opening of those keys. They are hashed.

NC: That also means that, in the PQ world. We're still going to maintain these 000 validators and potentially design a new credential switch mechanism just to take care of these 9,000 validators.

Potuz: That's not true. That's only if PQ happens before we force exits, which is very unlikely, according to any of the expectations we have for PQ.

NC: Okay, so you're… okay, so you are proposing that forced exit is not Hegota, but I-Star. yes. Is that right?

Potuz: Yes.

NC: Okay.

Matthew Keil: And can we just write that into the EIP as it is, so that 8365 covers both situations? H star is the closing the door for new ones, and I-star is going to be the exiting of, exiting of any that are existing. And then that way, there's, like, it's documented that we're doing it in two forks. That's plenty of time for someone to react.

Alex Stokes: Yeah, it sounds like there's consensus for this, although I do have a question then, if we take out the forced exits and pagoda 8365? what's left in the EIP?

Potuz: the… the… the EIP still burns ETH that deposits into a 00 Validator.

Alex Stokes: I see, okay, so they, yeah, they wouldn't make new validators.

Potuz: By the way, so what Greg is saying is not crazy, but it can be discussed, perhaps, on the chat. We can just hardcode an epoch a year after the Hagota, if people are worried that we might backtrack for the iFork. We can just hardcore an epoch in which we just force the exits.

Alex Stokes: Maybe. Yeah, no, it seems like we want the optionality. Cause, like, I don't… like, we're not gonna go through this.

NC: I thought about this, and I'm actually okay with adding… it's just essentially, like, configure a variable. In EIP to… to… to start checking those exits.

Alex Stokes: So, in terms of moving forward today, it sounds like we have agreement on the path forward with this EIP. Kev said there's a PR, which is good. So, what I would suggest then is… yeah, again, it sounds like we're in alignment with CFI and the reduced scope version of this. So, then yeah, why don't then, in C, just get that merged and get 8365 adjusted. by the next call, and then we can revisit this on the next call, where I expect it'll be CFI'd. Does that sound good to everyone? Okay.

NC: Sweet.

Alex Stokes: Alright. Cool. So, yeah, then just to play it back, We lean towards CFI and the… iteration of 8365. We don't have that today. We expect to have it by the next call, next ACDC, where we can then go ahead and CFI that one. Okay. Cool. I feel like you're teeing yourself up, Kev, to say something. Would you like to say something?

Kevaundray Wedderburn: I don't know if we still need it to resolve this question.

Alex Stokes: Sounds like we're good, but… If you want to add something briefly, you can.

Kevaundray Wedderburn: Sorry, Francesco. Yeah, I guess what I read in the Discord as well is that, I see it conceptually as three different steps as we deprecate first. We exit next, and then we deprecate the BLS execution change, which basically means that the 0x0 validators can't actually do anything. We can choose to do the two, the two steps, or the two last steps together, which is pretty aggressive. But I'm not sure we should do the two first steps together, as people have, noted. to the PQ roadmap, we have been sort of speaking with a bunch of people in the ecosystem to figure out, like, what are the right steps in order to get PQ into the fork.

There is a plan out there that gets it in… Roughly around JSTAR, that we've been trying to circulate and get feedback on. Mmm… But it seems like Kind still DFI'd Hashtrain RANDAO. I would probably quickly say that even though that EIP is DFI'd, it would make sense to, maybe reserve some space, like, somewhat virtually in this fork to work on some of the plans that we have for PQ to ensure they're ready, at least for I-Star, because there's a lot to do at the moment.

Alex Stokes: Alright, noted. Cool. Okay, so… CFI8015, just this first EIP here. We expect a CFI be updated 8365, but again, we'll touch on that on the next call. And then, yeah, then my proposal in terms of moving forward today, because, yeah, we only have about, maybe, what. It's called 20 minutes left. There are a bunch of EIPs here where it was pretty clear that, there was not client support. And the way I'd read this is basically everything With the red box here, so, like, you know.4 or less of a average score. Growing by forecast. I would suggest we pull out issuance for today, because again, I think this is kind of a different discussion, just given its nature. It has, like, very wide-reaching community impact.

And, yeah, I'm just not sure, we're in a place to tackle that one today. So putting that aside, the rest of these, it looks pretty clear that we can just go ahead and DFI them all. Would anyone like to… Yeah, either support this, or, yeah, is there something we should talk about before doing that? Otherwise, that would be deifying… everything here on forecast, which is 8237 and below, except, again, we're gonna put this issuance, EIP to the side. Sorry I spoke.

soispoke: Yeah, I think… So I don't really care about SFI the box profiles one, because it's an informational EIP. As long as it's clear that it's, like… Also, basically, it's meant to be a bit of a spec to align on what we… how we want to handle, sort of, like, interactions between FOCIL and frames. So now that both are SFI'd, it fills, you know, we don't need to SFI this information EIP, it doesn't, like, Change anything, really, except that… it is, like, a good sort of, like, dock and starting point to sort of, like, try to agree on exactly how we… we handle frames and fossils. So, I'm not exactly sure how to go about it, I don't think it's, like, extremely…

clear what needs to be done, but at least, like, it would be nice if people agreed that we need to sort of, like. You know, change fossil, and change frames so that they can work together.

Alex Stokes: Okay. I mean, also, given it's informational, I'm not even sure…

soispoke: Yeah, exactly, that'd be like so. Yeah.

Marc Garreau: Just a quick logistics note there, too. Because it's informational, it was left off of the rank page, so clients were not explicitly asked to rank that. Lighthouse just… Gave an opinion on it, anyway.

Alex Stokes: Okay, thanks. Okay, so it sounds like… Oh, it was… do you have something to add? Okay. Sounds like then we're good to… Take no action on 8369, so we're good there. Sorry, it's a lot of numbers. Okay, there was a comment in the chat for 8321 next. Yeah, Enrico, I don't know if you wanted to add anything yourself. Let's see, 83… okay, this was the Akash and RANDAO. It was also something that Kev mentioned, so… Yeah, again, just going by the client rankings, there doesn't seem to be great support. However, if there's a PQ argument, maybe there's something to be said there. I think just going by what process we do have, this would be a DFI today. But, yeah, anyone want to argue for something else?

Kevaundray Wedderburn: Yeah, I think it's mostly what I just said a minute ago. Yeah.

Alex Stokes: So it's good for PQ. but also potentially something we can do in I-Star.

Kevaundray Wedderburn: I would probably push for us to work on it in H-star. Okay. So that it's ready for I-Star, along with a bunch of other things, like, having new deposit contracts, even though we haven't PFI'd it… PFI'd these things. We have EIPs for them. It's just that we didn't get her in time. The most important thing I'd just like to clarify is having, all of the Validator PQ material registered on the Beacon chain, because if we have, like, an emergency, PQ comes earlier than we want it to. If we don't have PQ material registered for each validator, there's, like, no recovery mechanism unless the… And as we can do it pretty quickly.

Alex Stokes: Okay, yeah, that makes sense. So then in that case, we'll go ahead and, DFI… A through 21 today, but yeah, just have the general understanding that there will be PQ work that we want to do Yeah, there's legwork I want to start doing well before I start, so just keep that in mind. Yeah, I'm trying to catch up on the chat here. Yeah, so I spoke, are you… everything clear on 8369?

soispoke: I was just asking if there was a decision or not, and it seems like no.

Alex Stokes: Well, yeah, I mean, I think because it's informational. I'm not sure it matters if we, like, CFI or DFI, right?

soispoke: Yeah, I think it would be nice to at least agree that we need to converge on the specs for Solon frames. I think it's, like, implicit in the fact that we SFI'd both, but… Like, there needs to be actual efforts into making sure we all agree How to handle the… the interactions, and… yeah, that was sort of, like, supposed to start from this informational EIP and then bring changes to both Forceall and, like, both 7, 8, 05, and 8. one for one, and if, like, everyone agrees it's the case, it's good, like, we don't need much more, but it's, yeah, the dog served that purpose.

Alex Stokes: Yeah, I mean, yeah, there's comments here ranging from… Yeah, acknowledged, and it's just something we'll have to figure this out as we get into implementation of FOCIL and Frames. Or that it's, more of an EL or concern, so… It seems like today… We don't need to do anything. And to be clear, it's not that we're DFI-ing it, it's just more there's just nothing to do. It's more just, yeah, everyone be aware that there's stuff to figure out here. I think in terms of, like, actionable next steps, I think there's breakouts both for frames and FOCIL, so… Yeah, either… we take the CIP to those calls, or… yeah, we combine them somehow, but yeah, I agree, there's stuff to do here.

I think in terms of… making these scoping decisions today. This one's actually just kind of orthogonal to the others. So, everyone clear on that? So… okay, then we had DFI on… 8321, again, with these caveats about PQ and the work to do there. There's been some discussion of issuance here. Again, let's just table this for a second. Let's touch on the others, because I think they'll be pretty easy DFIs. I guess just to make it clear, suggestion would be to DFI 8237, 8341, 8367. We already have 8321. 8243-8146.

8375. Anyone have any issue with this? Alright. Got some thumbs up. Yes, 5 by DFI. It's a nice rhyme. Okay, so I think we're good there, and then, yeah, so circling back to issuance now. again, I think this one's a little special, just given… The fact that, you know, it's in part a core developer decision, it's also a much bigger decision with the rest of the community. I mean, you can see here, with, The client rankings, you know, there were 3 teams that were against, 3 that just didn't chime in. So yeah, and I think in part it's just because, yeah, it's hard to speak today to how we want to move forward on making this decision, just given the fact that it is much bigger than present company.

So, given that, and the fact that, yeah, we just have maybe 10 minutes left on the call, I feel like this might deserve a larger discussion than that. So, again, I would suggest that, we just table this one for today, And then it would… You know, just kind of go into this other bucket here of stuff we'll need to discuss in the future. So, in that case, if we're all good with that. I think that would clear us up for the work we need to do today. And, yeah, either we end the call early, or if someone would like to talk about one of these other EIPs we haven't touched on, there are some time.

So yeah, I'll give you a few minutes to think about that. I'm reading photos as common here. Can we try to get people that work on the… Okay. whoever we use can definitely try. I don't know, I mean, this is also part of the thing, it's like, I think this is just… This is a very big conversation that we need to have, but I don't think we're necessarily prepared today. Free to Clare… sorry, okay, I'm just gonna read the chat. You guys can… Take the mic if you want. Otherwise, I'll just kind of read it as I go. I think we should pre-declare…

Ansgar Dietrichs: Yeah, I mean, if you read it.

Alex Stokes: I mean, I…

Ansgar Dietrichs: I just basically wanted to say, like, ideally not just saying, we leave it pending. I mean, it's fine for now, maybe, but then…

Alex Stokes: No, I'm just saying for, like, one call. Like, I'm just saying not today. I don't… yeah, it shouldn't be forever pending, it's just, I think… Given all the constraints today, it's…

Ansgar Dietrichs: But then, can we make a decision? Will we discuss this in two weeks? Yes or no? I think it would be good… I mean, we don't necessarily.

Alex Stokes: Yeah, no.

Ansgar Dietrichs: decision life on the call, but, like, I think it would be really good if people have that expectation, like…

Alex Stokes: Yeah, and also, just so people know and can prepare. I think that would be good, personally. But I'm…

Matthew Keil: Two weeks ago.

Alex Stokes: It's gonna be big.

Matthew Keil: though. Like, when we're going through all the other stuff, it's gonna be a busy call. We've got 10 more minutes. It's already kinda deified. Maybe we spend the last 10 minutes and just get that one out of the way.

Alex Stokes: You're saying issuance is kind of DFI'd? Is that what you're talking about?

Matthew Keil: Yeah, and it's kind of… and, like. gonna be a lot of talk around the, like, I think short slots and some of the others are gonna be longer discussions for two weeks from now.

Alex Stokes: Yeah.

Matthew Keil: Oh, but…

Alex Stokes: would push back a bit, it just… I just think we don't have the right mechanisms to make it… like, to say anything on it today. So I'm, yeah, not trying to shut it down, also not trying to make a decision necessarily, but more just saying. we're not set up today to do this. Potus?

Potuz: My personal feeling on that EIP is that it's… it's an unfair situation in which the community members that are affected by this EIP are all overwhelmingly against, because, well, they're just gonna earn less. And we haven't heard at the other side, we just only have the opinion of researchers. making a point about LSTs, and we are… by and large, not capable of making this decision. So it seems to me, if we keep just, like, postponing this, we are eventually going to either DFI it or make a choice without really understanding it. Ourselves, we're not… This is not our topic. So that's why I really strongly propose the authors, or whomever is pushing for this EIP, to try to get people that are outside of our community, but that work on international money policy, that work on these classical topics that might

Might have an opinion Yeah, that is not directly biased.

Alex Stokes: Yeah, or just, yeah, I mean, putting aside bias, just more having… Contacts that we might not have here today. And, you know, just to drive my point again, I think these arguments all point to the fact that we are not going to make a call on this today. I… do, like, Ansgar's point of, yeah, not just leaving this in limbo? So, I think it would make sense to say next call, but that being said, I also think there's room here with what is saying, to have, yeah, maybe more expert advice. On the topic, in which case that might take more than one call, so… Point being is, yeah, if anything, like… We might want to work with the champions, just to figure out the best path here.

Enrico, then Ansar.

Enrico Del Fante: I just want to echo Bos and add a comment on your comments, which is, today we are not In the right place to discuss that, but it will be… it won't be anywhere, anyway, into… In two weeks. because I believe, like Paul said, he thinks it's a little bit outside our… our knowledge, and it's a broader and bigger… Topic that needs to be discussed in proper… in proper dedicated calls. like, we can be… we can be there as ACDC guys, but other people must be there too, and discussion are not technically driven, mostly.

Alex Stokes: Yeah. Right. I mean, yeah, what I could try to say today is I would ask to… give me until the next call, just to come up with a plan on how I'd propose we move forward here. Because also, yeah, like, I might be surprised, but I feel like this might take a little more legwork, than just 2 weeks. Ansgar, you had your hand, but I don't know if you had anything to add. You took it down?

Ansgar Dietrichs: Yeah, I was going to say very similar things to Enrico.

Alex Stokes: Okay. Yes, true.

Jérôme de Tychey: Yeah, I appreciate the different comments here, regarding issuance. As was, suggested by several other organizations, we need to, come up with a way to get everybody on consensus on what should happen, and if anything should happen. Regarding the push forward on making a decision on the EIP potentially later, it's giving us time, the offers, to come up with a proper write-up on all the comments that were done, Regarding the, the, on the, ethereum thread, and also, to, convene to what should be the next steps, with the different parties that have voiced their opinion and have voiced wanting to participate on something broader. And as you mentioned, to, get, people that are not in the room, or didn't express their opinion, to actually, voice, what they think about this kind of change.

So, yeah, in a, in a process where, you want to, shrink the list as much as possible, as, as quickly as possible, issuance is, kind of, a people in the, in the shoe, but, we're working very hard to, make it, easy to remove and, toss around.

Alex Stokes: Okay, yep, sounds good, and yeah, Let me know if I can help with any work there.

Jérôme de Tychey: Yeah, and additionally, we appreciate the, EF protocol teams, mentioning it, to say that, yeah, this needs a bigger forum, and it needs to, something broader, to reach, broader consensus. So, yeah, we're working hard on the matter.

Alex Stokes: Alright, thanks. Okay, then in that case, let me just play back what decisions we made today. Oh yeah, Greg, I assume you have a comment here.

Greg K | Lido: Yeah, sorry, just… I didn't intend to talk today, but just in order to understand what are we expecting now to happen? So, we have currently 3 clients suggesting to DFI, and 3 clients not expressing opinion. So, just in terms of process, like, How could, finally, let's say. take a decision about this particular EIP, because this is exactly the reason that they had asked to not PFI this particular EIP, because it's… it makes Ethereum's change and this EIP looking equivalent, while this is not. So, one thing is discussion about changing issuance, which cannot be done in ACD, of course, and the… and this EIP, this particular EIP, is just one very, very special case of it.

So, I don't see what should we expect to happen in the next two weeks, and how could the final decision will be taken? Are we going to say client team opinion is not important at all, and we will create another process for this? Or, like, I just don't see… I'm okay with not designing today, I don't say, let's do something today, but I have no clue what is the expectation here to happen? Like, what… from the way that people are talking now, I expect that in two weeks, we are going to have rough, more or less the similar discussion. Like, we're not qualified, we don't know, like. So, is there some idea on how to move forward, or we'll just keep it?

Alex Stokes: Yeah, I mean, again, this is probably a conversation we need to have. My view is what we should probably do in, you know, say, the next couple calls. is figure out how we want to handle this type of thing as core developers, right? And I think, again, reflecting the comments we've had, like, this isn't just a core dev decision, right? And so… you know, like, one outcome could be, hey, we actually think we need this other forum. I don't know, people said something about ACDI, which I assume is ACD issuance, so… You know, maybe… this isn't necessarily, like, just an ACDC call to make, and maybe it's, like, in the, you know, allCoreDevs, pun intended, call to make, or… okay, moms are saying no ACDI. But anyways, like, that's just kind of, you know, straw man for what this could look like.

And I think that's something we could do in the next couple weeks on this call, is just figure out how we want to move forward here. In terms of how we make a decision. And yeah, I understand if it's frustrating that… It's not super clear today. But I don't have much more to… to give you. Ansgar and Kev?

Ansgar Dietrichs: Yeah, so, one more comment. I just, I do think… One thing that I do feel a bit bad about is that, like, I think many people are specific on this topic, following the ACD process, because by default, ACD is where decisions about hardfogs are made, and they… I think a lot of… a big portion of the community is worried about this change. again, I personally even speak as someone who actually thinks this might be a good idea, but again, I understand, like, many, many people are really worried about this, and I think they might see us not making a decision as somehow, like, maybe get the feeling, or maybe there's some sort of conspiracy that is trying to basically delay and then last minute push this in. I just would want to reiterate that this is very much not what's happening here. I think it's more that we're seeing that with this EIP,

I think as was obvious for everyone who paid attention, the fact that we just didn't really know how would even a decision-making process here look like, I think, caused a lot of extra friction. Like, when this was initially proposed, there was a lot of discussion about PFI timelines, and why would CR Devs even be the right group, and who else are stakeholders here, and I think all of these are just really, really important questions, and so I think the reason why I think we would want to have some proper time to figure out how to even think about approaches to this is less because it's still so up in the air what the fate of this specific proposal specifically for Hegota will be, I think it's actually quite clear, that we are very far away from any scenario in which this would go into Hegota.

it's really more that I think we just need to figure out, on a topic like this, what… What… how do we think about the general… governance, legitimacy, decision making, so that in the future, this will… either this, or topics like these will occasionally come up, and so I do think it really takes… like, I think just saying DFI now, and then just, like, moving on, then we will have the exact same problem again next time something like this comes up. So I really believe it's worth the time, but I just want to really stress that for anyone listening with a little bit less context on ACD, this does… this is very much not a… let's try to delay and then squeeze this in as some sort of conspiracy thing. Like, just really wanted to reiterate that.

Alex Stokes: Yeah, thank you. Bye. Hope no one reads it that way, because, yeah, that's not what we're doing. It's more just, given this type of decision, the space it needs. So there are a lot of hands. We're also at time. I guess, yeah, if people want to hop, they can. Otherwise, let's try to get to these hands, and then we'll wrap up. So… now we have Kev. Matt, and then my client.

Kevaundray Wedderburn: I had a different topic on 8333. I don't know if Matt was gonna talk about that. I was basically just trying to get 3 more DFIs before the end of the call. Matt, if you was going to talk about that, I can just quickly say it seems like it makes sense to also DFI that. If clients are still on the call…

Matthew Keil: I did just want to ask out loud to Ben, that there was telegraphing that 833 would no longer, be relevant when we get to a decoupled Consensus world, and if that's the case, yeah, we would… we would recommend DFI also.

Ben Edgington: Yeah, I agree, but I think we shouldn't make the decision now. We're over time, and next two weeks' time is fine, I think.

Alex Stokes: Yeah, I agree. White client.

Lightclient (Matt Garnett): Yeah, I just wanted to ask… kind of related to Ansgar's point, if… There's, quote, not really much chance that this issuance change makes it to go to why would we not be DFI-ing it right now? And in the meantime, figure out what the right process in the future for accepting and issuance changes, because I'm afraid that if we don't DFI it and we have this discussion. That in the process, will also start legitimizing And people will start accepting that this issuance change is happening, when I don't think that that's what the current You know, belief of the core Devs or the community is. So I think that those need to be very separate, and I think that we shouldn't…

Leave it op… the door open while we figure out what the right process to accept it is, to avoid, like, overfitting and figuring out a process that will accept that specific change.

Alex Stokes: I think the simple answer today is just that we've run out of time. And, yeah, like… That could very well be the outcome. Next call. Artists.

Potuz: I wanted to answer to Matt, and I am with you, Matt, that, core Devs after after all, they are going to read the room, and that they're going to try to do the best for the protocol, but in this particular EIP, you have over 90%… the clients that hold over 90% of the stake on mainnet didn't want to admit an opinion, and I think that in itself is an opinion that we are not capable of deciding this now. And even though it's likely that this is going to be DFI, it might be DFI in the next call, we could even DFI it now, we really need to have this discussion. This discussion needs to happen outside of Twitter, and we should…

Even though we might end up doing… making the decision, we really need to have the tools to make such a decision. And we really want this to happen. We don't want to every single fork that this comes up, saying, well, we're gonna just DFI it because we're not capable of doing this. This discussion needs to happen, and… well, we need to bring in the community members that are not on Twitter, yelling, but actually that come up with technical facts, or… Actual arguments.

Alex Stokes: Yeah. I agree. Otis. Yes. We're over time. Thank you, everyone. Let's see, I will make sure somewhere the decisions made today are recorded. We DFI'd a good number of EIPs. And made CFI progress on two of the others. So yeah, good work, everyone. And we'll pick this up next call. And also, just, yeah, final reminder, Glamsterdam, releases for Sepolia. Let's keep this moving, too. Okay, thanks everyone. I'll see you next time.

Kevaundray Wedderburn: Alright, see ya.

Potuz: Bye-bye, everyone.

Fredrik Svantes: Thank you. Bye-bye.

Marius van der Wijden: Bye-bye.

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