All Core Devs - Execution #225

Transcript

Justin Florentine: Good morning, Fusaka!

Ansgar Dietrichs: Can you all hear me?

Justin Florentine: Yes, we can.

Ansgar Dietrichs: Okay, well, that's, Yeah, I destroyed my laptop over DevConnect and still don't have one, so I'm on a loaner device, and the loan device decided to do a big macOS update overnight, so… It's all a bit, picky. Anyway, I think… are we… would we be ready to go live?

Josh Davis: Whenever you are.

Ansgar Dietrichs: Okay, and just one quick check, for the scoping part of the call, there would be a document again to screen share, if maybe someone else could do the screen sharing again, that would be… Great, I'll… I'll post the link in Zoom chat once we get there. But yeah, then we can… we can go live.

Josh Davis: Alright, you are alive.

Ansgar Dietrichs: Awesome. Welcome, everyone, to AllCoreDevs 225, if I didn't miscount. M… We have two main issues for today. One will be, Fusaka, looking back at the last fork. First, of course, congratulations, everyone, to a overall very successful hard fork. And then we'll get back into Glamsterdam scoping. For Fusaka, we have… A document with a quick summary of incidents that happened around for Fusaka. Do we have someone on the call to briefly present that? Yeah, Terrence, if you want to go first regarding the prison situation?

Terence Tsao: Yeah, so over last night, about, like, let's see, 9 hours and 4 minutes ago, EPOC411440, the participation, or the target vote, dropped to 79%, so this is the recent issue that like, previously, as we know, to validate an attestation requires you to reconstruct the target state, right? And this is the state of the target checkpoint, advanced to the targeted park. And normally, this is very cheap, because of attestations share the same target. But attestations from the lagging node, the node that's catching up, or forks. can force client to regenerate the old state, and which is expensive, and this maybe does better on some client implementations. So to basically avoid this, we added a heuristic in Capella, right? And then the heuristic stated as such that if the target epoch is the current epoch, we just use the head state. If the target epoch is older, then we will check if the target is basically a real checkpoint and generate if needed, right? But this introduced a subtotal bug in Fusaka, which we fixed earlier.

that head state may not be compatible with the target state, right? And then, because of this fix, we added some refactor that we kind of widened the scope on what we consider a valid checkpoint, but we also added a future flag to essentially gate under that, right? And this kind of recreated the same issue we saw in the Capella outage that notes from receiving older attestations from the previous EPOC are generating state heavily, causing them to miss attestation duty. So the current phase recommendation is to add that feature of use that feature flag, which we had in multiple posts and threads, and that will resolve the issue for now. And we're also working on a long-term fix, which we should have a release out, next week. And we also have a formal post-mortem to be released next week as well.

Yeah, that's an update from us.

Ansgar Dietrichs: Sounds good. Any other comments, or anyone else, that wanted to talk about anything regarding the Prism? Incident in particular? Otherwise… there were… Very small other minor issues mentioned. in, this incident document that, I think connects to also linked in chat. is there anything, that we should address on the call here? Or are these things we can deal with async?

Dustin Brody: I guess I'll just mention, in terms of the Nimbus Nethermind one, and Nixo's link, this appears to be… as mentioned, it may be a build issue, it's… I would say this is not a… A productive or appropriate forum for that. It's not… it's not clear if it's another mite issue at all. It's still being looked at.

Ansgar Dietrichs: That's good. Yeah, and what does I see? You just joined, just in case you have anything specific you wanted to add as well, but yeah, we just got an update from Terrence already. Otherwise, Barnabas, if you're on the call, could you give a just a quick update of the current, mainnet state? Are we looking?

Stefan Starflinger: Barnabis can't talk right now, but I'm happy to kind of give an update that Fusaka went very well in the fork. It's just the prism issue was pretty much the only thing that happened for us in the middle of the night, but we had the Australians and the lab team working on trying to understand What's, what's going on with the attestations? And I think, Terrence already summed it up pretty well. Otherwise, there's not much more from us.

Ansgar Dietrichs: Yeah, and it looks like participation back to very healthy levels. Yeah, overall, of course, I think this was, again. Very quick and amazing responses by everyone involved. Thank you all very much. Okay, is there anything else regarding Tusaka, then, that we should address on this call? Okay, yeah, Alex, did you prefer to mention BP01, just so people have it top of mind?

Alex Stokes: Yeah, yeah, really just… just mentioning the BP01s coming up, so it's in about a week, There's not anything anyone needs to do, but it should raise up the, the bulk counts, so… Super exciting, and more just something to have everyone… have on everyone's radar.

Ansgar Dietrichs: Good. Yeah, then… For the next, agenda point, just… there's a few housekeeping items for today's call, and I split them into urgent and non-urgent, so that we talk about the urgent ones before going to glam system scoping, and then the other ones only if we have time. So for the, more brief time-sensitive ones. first, all could have timings regarding future calls, not the one, coming up right after this one, in two weeks, but, but after that, both on the ACDC and ACDE side, there was questions around the holiday period, maybe to already briefly address. In particular, Alex, and you mentioned possibly cancelling ACDC on December 25th, is that already locked in? Like, what's the status there?

Alex Stokes: Yeah, I think we should. It's a holiday. Pretty much everywhere.

Ansgar Dietrichs: Yep, okay. So, everyone be aware that we'll likely have… that we won't have an ACDC on December 25th. And then the question more relevant on our side here is for the week after, so that's January 1st. Obviously also a holiday in many places. The question is, what do we do there? whether to keep or to cancel. Of course, on that ACDE side, we have a lot of continued scoping work, so the question is, is it worth keeping the ACDE on January 1st, or do we want to cancel it, or do we maybe try to, for example, see if we could borrow the ACDT on the week after or something? to replace ACD. Do people have?

it looks like in chat that January 1st, at least, people really want to cancel as well. So then I would say, unless people disagree, that we decide to cancel January 1st ACDE, but I'll look into potential replacement candidates to not just have that be canceled without a replacement, and then on ACDE in two weeks, we can… Make potential decisions around a replacement. Okay, that's that housekeeping item. And then, the other one was, Fossil. Didn't really quite fit into Gramsadan, because it's actually more about specifically not being in Gramsadan, potentially, but in the hard work after, there was these continued discussions about the potential a need for a credible pre-commitment, to… to have fossil, in HSTA, if we don't put it into Gromsadam, and whether there's any process, mechanism that could help with such a credible commitment. Alex, I think you had a topic you wanted to bring up from… from the ACDCs out there?

Alex Stokes: Sure, yeah. So, yeah, we've been talking about this on the CL side, for a couple weeks now, and… Essentially, it wasn't clear how to move forward last call, and, like, one point that was made was to also get a temperature check from the EL. So, that's really all I wanted to do today. We'll just try to understand… Yeah, how people are thinking about this over here. You know, should we try to scope this for HECA? Should we, you know, just think about the headliner process and how fossil there? How does it square with Clemsterdam? And all of the above?

Ansgar Dietrichs: Right. And again, the idea is more temporary check than specific decisions. Do we have… EL client devs with… Opinions on this topic. I see the Netherland team supports SFI in Fossil. a Facebook?

soispoke: Yeah, I don't want to be, difficult, but… I mean, I think a legit question will be… How many temperature checks? Do we need to have a bud force soon to… Move on and make progress at some point, because it… it does seem like we had… A lot, of… temperature checks, and I do feel like they… Converge, into one direction quite often, so… I would love for us to be able to make progress at some point.

Ansgar Dietrichs: Yep, that's a reasonable comment. I think from my side, I can only say that that's a little unfortunate, because this topic's obviously split between ACDC and ACDE, with more of the actual decision-making driven from the ACDC side, so that's why on ACDE, it always sounds like we're basically just asking for yet another round of input. But yeah, next one?

Nixo: I'm just gonna… I'm gonna say, after the Glamsterdam headliner process, I think we created an expectation of a public process that people can participate in and predict and, It would… it makes… ACD and, like, the government process feel a lot less messy, because people can understand what's going on, and I think that we should… continue to do this headliner process, so I think… in my head, the best path forward is CFI-only fossil right now, going through a headliner process, and then publishing this the headliner… process timeline. for everybody to see and understand that we are choosing the HECA headliners, And then choose it at the end of that headliner proposal process.

Ansgar Dietrichs: And tomorrow?

soispoke: Yeah, is there then a reason why we do these temperature checks? If it's sort of decided anyways that The clients expressing opinions about wanting it included just don't… make a difference? I'm just wondering, like, why do we do these temperature checks if at the end, like. I don't know, it feels like protocol coordination, or like… Other people just make calls about, yeah, you know what, there's gonna be a headliner process, and we're gonna do things a certain way. If that's the case, it's fine, like, but then we should do the temperature checks and sort of, like, the… gather opinions and have the teams come together, at that point. Like, it feels like we are repeating the same process over and over and over.

Nixo: I agree with that. I… I agree that, like, taking temperature checks every call is… it seems un… seems messy and redundant and not productive. And the reason I see behind… behind having a headliner process is because the clients are… The people who come to these calls. And generally people… other people do not Pay a lot of attention to these calls, and so… Having a published headliner process, especially after having set a precedent in Glamsterdam. Gives people an expectation that they know how to participate in this process.

Ansgar Dietrichs: Muck.

Marc Harvey-Hill: I think my feeling here is that we're not really bypassing the headliner process necessarily, but since there's been, kind of, very clear, enthusiasm from the community for Fossil, you know, in Glamsterdam, it's more like we're just kind of shifting it to the next fork. And just on an implementation level, I think if it's SFI'd and we commit to it, then, like, personally, I'm working on fossils, so, you know, I can actually start working on that, whereas if it's… still CFI'd, and there's a lot of… you know, will it go in or not? Then it becomes kind of… We don't know where to allocate resources.

Ansgar Dietrichs: Sounds good. Before the next, people, just wanted to briefly mention, yeah, I understand the criticism around this continued temperature check ping pong, but I do think this will be a decision that we will ultimately make in one week, on the ACDC side, so obviously everyone who feels passionate about that should also be on that call, so we can hear a few more opinions, but I would try to, like, timebox it to not have too much of a back-and-forth debate on this call. Yeah.

Carl Beekhuizen: I think the important part of the… The headliner process and why we should go through this thing is that Like, there's an opportunity cost to shipping? fossil here. I think most people here, or pretty much everyone here, wants some form of fossil. It's just like, is that… like, better than shipping everything else, and I think that's why we should go through the headliner process. I imagine that we're just gonna end up back at Fossil, because that seems like what the overwhelming support is, but I think we need to be considering what we are choosing to not ship by shipping fossil, and I think that's why it's very important we go through the full headliner process for this.

Ansgar Dietrichs: And Nico?

Nicolas Consigny: Yeah, my one comment that I wanted to make later on for the PQ precompiles, but it's the same here. We should definitely reflect that new process, if it is, like, enforced in the EIP1 and in the main EIP page. Because as of now, like, if you're a new contributor to Ethereum, you go and you check EIP1, you go and you check, the EIP, Ethereum.org website. And none of this, like, new process is specified, so, like, for the PQ precompiles that we will be discussing later, we have different, precompiles that we've been working on, and, like, some people showed up because they liked the EIPs and, like, proposed them for inclusion. These peoples are not the authors, and so we end up in a situation where, like, we are about to discuss precompice, but the authors didn't really ask for it.

So yeah, I think it's… it would be much clearer if we could just have this in one document. Currently, you have to follow forums, ACMDs, EIP1, then you have to find about the Meta EIP, and so it's an entire process that is quite long and quite difficult. And so, yeah, I think we did great with the new, forecast and the new… the new tools that are surrounding ACD, but this part should definitely be reflected in EIP1.

Ansgar Dietrichs: That's good. Do we have any further comments from the EL side? Regarding… The first narrowly the process here. Tamar?

soispoke: Yeah, sorry, it's actually an actual question. Like you said, a decision will be actually made next to ACDC, But I feel like… going through the normal headliner process is not that, so is there a way to clarify exactly, you know, if a decision will be made in the next ACDC, and what the decision will be?

Ansgar Dietrichs: So, I don't want to fully speak for Alex, so Alex, please feel free to correct me if this is wrong, but my understanding would be that on next ACDC, we just make a decision regarding the question of what special treatment process-wise do we want to give fossil, with respect to H star? So, like, do we want to CFI it, SFI it, how would that relate to the headline our process as it starts. Again, I think on the social layer, everyone already agreed that we all are pre-committed to having it in the next hardbook either way, but again, the decision of, like, how does it exactly kind of relate to the process? for H-star, that would be the decision that I would expect for next week.

Alex Stokes: Yeah, I mean, basically just how to handle it.

Ansgar Dietrichs: Okay, yeah, I also agree with people in chat that have the need to timebox this topic here, so I would say that unless there's any urgent other comments on this, then I would end that section here for now. And then we can actually move on to… Lamsterdam. And, Yeah, so for… for continued stem cell scoping, I went through the… both the individual client preference docs, and then also specifically just, like. all the discussion we had on last ACDE, which was 4 weeks ago, and assembled… like, a document 8, I just find that more useful than the meta EIP document, because it separates out the 40 EIPs into different categories. And then also with some annotations, around, potential CFI, DFI candidates. This is not a formal kind of status, process-wise, the candidate is just an annotation of, like, this seems to have either very strong support, or this has had a lot of skepticism.

So the idea would be, before we go and discuss all the EIPs that are not yet on either side of that, that we start by maybe the ED. potentially easy decisions. I do apologize, I only published this very, very last minute before the call. which was not a proper process, I should have… should have published this much earlier. But if we… do we have someone that could, share their screen and… Have the document open.

Josh Davis: Yeah, if you post it, I'll share it.

Ansgar Dietrichs: Yep. That's… I put it in chat.

Josh Davis: Cool, just give me a second to configure the things with the strain as well.

Ansgar Dietrichs: Yep, boys.

Pooja Ranjan: Josh, would it be helpful if I share my screen and you continue with streaming?

Josh Davis: Yeah, no, I think I've got it here. Maybe for next time, though.

Ansgar Dietrichs: Yeah, thank you, and my apologies for ambushing you live on the call with this. Perfect. So, the idea is that, if you can scroll down a little bit, they are in yellow, these marked, yeah, exactly. So, basically, the first few sections, we'll get to this a little bit later, but they don't have yet clear CFI DFI candidates. The first section that does have them is the general, repricings. And the idea here is not that, again, for each one to just highlight. Why… why it is marked this way, and then if there's maybe anything… Yeah, so basically, like, if we just go on the list to start, specifically the block accounting without refunds seem to be actually one of the most clear candidates for inclusion of all, seemed to have universal support, so I was just curious, do people feel ready today to make a CFI decision on

EAP7778, the… Block gas limit accounting without refunds. And I'm not sure if I want to… for every single client on each topic. Maybe for the CFI candidates, is there anyone that would object, any client that would object to a CFI decision here? Otherwise… then I would say… 47778, we make a CFI decision now, and it's… In the hot book. Okay, you can see some of them have a question mark. The question mark is just, if there's still any unresolved issues that might preclude a full decision on today's call, but they are a strong candidate, so 7971 overall, that's the, the, global cut for T-Store.

That had, some concerns around the kind of abstraction compatibility. Otherwise, people really liked it. Is there an update on the… Account abstraction concerns, do we feel ready to… Make an inclusion decision, or does this require help? One more round off. Iteration to resolve these issues. Sorry, that's… yeah, I should be a bit clearer about this. There's EIP7971, the hard limit for transient storage. if there are no concrete, opinions, then I would…

for now, basically postpone the decision, because, again, it still has one unresolved issue, which I would say would preclude CFI. Also, Justin, I see in chat the question, how many ERPs are we planning to CFI? Basically, I would, for now, just do individual one-off decisions. I would expect that going through this list, we will not end up with more than a small handful of decisions. And then afterwards, maybe have a… take a step back and… See where we're at, or… Yeah, I'd be happy, happy to have comments on alternative process, if that doesn't make sense.

Justin Florentine: Yeah, let me just clarify why I'm asking. So, like, I have the Bayeswood Team's tier list up in front of me, and I'm looking at that, and so if you say, okay, this one, should it be CFI'd, and I see it as maybe in the A tier, but not the S tier. Should I agree with the CFI situation or not? this is what I'm… I'm trying to… I'm trying to figure out, like, how many of these CFI quote-unquote votes do I need to apportion, because I would like to save them all from my S tier, selections. I'm just trying to kind of square how this is gonna work.

Ansgar Dietrichs: Right. Yeah, Barnabas in chat saying that we should not maybe have a strict number limit. I can… if we… if we… so basically, like, in the… in the document, I have, I think, 4 clear CFI candidates that I saw, and 5 with a question mark that maybe had something still to be resolved, so that's already 9 ERPs. Most of them are, though, like, very, very small, like the SWATNAM opcode, that should be pretty self-contained. then the main, other sources of potential APs that, did not… were not on that list yet were specifically around repricing, just because there were unresolved issues. and, possibly around contract size. So that, I think, maybe is overall… The kind of the,

the sources of likely, ERPs, so… but yeah, I don't know. I personally would just continue on with the list for now. But I'm also, you know. leading the scoping process for the first time, so I'm just going with what feels reasonable to me, and I'm happy to correct costs. But I… in the interest of time, I would, for now, just move on with the idea here. So, like, I would say with… for the highlighted EIP currently, 7971, I would say, given that there was last time unresolved account protection, concerns, that we are, for now, postponing a decision, and, refer that back to the EIP champion to address these concerns, until the next call. Then we have on the list a DFI candidate that is EIP8011, the multidimensional gas metering, that can be highlighted.

They are specifically, DFI… Because, kind of, people's clients overall felt that it was overly complex for now, and, premature, and probably better fit for future hard work. Are there comments on this? Do we feel ready to make that DFI decision? And in particular, there was one, comment, I think, by Anders, pointing out that for specifically just state growth, like, basically once we'll talk about the, the repricing solution to state growth, it could be that we would want some very lightweight, kind of, minimum version of multidimensional metering if we want to consider an alternative approach today to the currently selected EAP, or proposed EAP, but I would still say that that should be separate, not

And not… not just reusing AD11, so I personally would post that we just make a DFI decision now, And… Yeah. So basically, is there any client opposed to DFI-ing 8011? I did talk with Maria, because there's a question that she has a champion on the call today, and she's okay with AT11 not in Amsterdam, so then I would say Precision AT11DFI. Yes. And then, Tony, by the way, just to address your comment, the idea is, again, process-wise, we first go through the CFI DFI candidates, because that's hopefully easy wins, and then go through all the sections that, are still… have more open questions.

So the next, next one on the list is the, the one right under, under this, AT32, size-based storage gas pricing. So, clients generally spoke in favor of this one on the call. the reason I still put a question mark there is just that there was an ERP that does make pretty significant changes and came relatively late in the process, so I just wanted to check with people how much they've looked into the details here, how comfortable there with the majority of the IP, and if we are ready to make the CFI decision. So that's 8032 size-based storage gas pricing.

Łukasz Rozmej: Is this the one with relatively complex migration?

Ansgar Dietrichs: My understanding is that there is a migration step, 8. I don't… I'm not sure if it's complex or not. Do we have, anyone on the call that has looked into this?

Dragan Rakita: I think you will need to know the size of the current storages per contract, so you need to extract that information from somewhere. I think that's the migration.

Łukasz Rozmej: Yeah, but… I think this is… hand-waving on the quite big concern over the CAP.

Dragan Rakita: Yeah, same, in my opinion, AIP seems complex to do. And I would rather skip it.

Łukasz Rozmej: Yeah, unless we have a very good idea how to… how to do that, I'm also not sold on… Well, CFI is considered, so… We can consider it, but I have reservations.

Dragan Rakita: Additionally, it clashes a little bit with state creation, gas cost increase, AP8037. we… if we include the state creation gas increase, then this ARP becomes, less relevant, because we already, like, increasing the gas by n times. So, yeah. Maybe DFI, but… Consider it later is… it looks fine.

Ansgar Dietrichs: Okay, yeah, then, given that there are questions, I would, for now, by the way, just to, you know, just so this all doesn't seem completely arbitrary, like, so one of the reasons that this… I put this on the list is, for example, that Nethermind had listed this as as an A as well, so, yeah, Lukash, just so you don't feel like I'm trying to just push… push EFPs on people. But then I would postpone the decision on this one for extra two weeks, and I do see in the comment the question of, can't we just immediately DFI everything that that does have questions, I would say I would at least not do that with the ones that overall had pretty strong support. So, for example, this one had 3 A's by clients, only Aragon, from the ones that… from the teams that commented on it.

had it listed as D. So for an ERP like that, I would just wait for 2 weeks to… to give people more time to look into them, and yes, but… but anything that's already more often on the DFI kind of side, and then if there's questions, I would just default to DFI.

Łukasz Rozmej: So, our opinion on that was that we like the AP, like, idea, but the transition process sounds, Impractical at what the current is, and… Someone might convince me I'm wrong, but… But that's… that's the case.

Ansgar Dietrichs: Okay, sounds good. So the point here is someone needs to convince, Lukash and other people that, like, from the rest team as well, there seem to be concerns about the transition, so… Yeah, this one. No decision today. Then we can move to the, last three in this section, so the next one is… AT53, this is the high precision through milligars. Overall, there's two ERPs here that, both are about, head precision, it's this one, and then the last one in the section, AD59, both of those overall head client comments that while higher precision for, popcodes is useful, it's just not worth having an EFP in Amsterdam, so I would propose DFI. Is there anyone that really wants to save either of those two?

Earpiece. Otherwise, okay, I would say we lock in the DFI for those two. So that's, that's 8053 and 8059. both of those EFI. Okay, and then the one in the section that we didn't yet get to is the second-to-last EIP8057. That is Interblock temporal locality gas discount. That was the strongest candidate already from last call to make a DFI decision, even though we had said no decisions on that call yet. Just because it seems like clients really had to… were… Pretty convinced that that was not a good idea, so… unless everyone changed their minds, I would… Assume that that's… PFI by default. Okay, I assume this call, at least this section, will just be me, a lot of me talking, but at least we are coming out of it with a bunch of decisions, so maybe bear with me.

Okay, so then, yeah, we have basically, like, so the two that are delayed are the ones that have the question marks, those we will revisit in two weeks, and then the other ones actually follow the Canada recommendations, so that's… Good to see. Then can we scroll to the next section? Okay. So, on… contract, Besides, there was one ERP that did have relatively strong support, which is EAP7903, the removal of the init code size limit. The reason that that had a question mark is… That there was one client, let me, let me check. Yeah, Beso specifically had listed that as C tier. So I wanted to check, how people overall, specifically Basel, but also other clients, feel about it, because it did not specifically… it wasn't specifically discussed on last call.

how realistic is this SSCFI candidate?

Łukasz Rozmej: So… I think, never mind… Comments where that we are put… Potentially… unsure about the… Drum test analysis? But we would like to see some numbers. I think it might be, like. We might be overly cautious here about it, but yes, having some numbers would be good. So, I think CFI is fine, but again, before, like, scheduled, we would like to see some numbers.

Ansgar Dietrichs: Right, but given the limited scoping Ramson, I would personally, for now, only make CFI decisions when they are clear that there's pretty universal support, so… And then it seems like… We might not be there.

Dragan Rakita: I would say that the impact analysis is kind of… we're not sure what… What would happen if we remove that? So it's, like… It's better to stay, in my opinion. We can always remove it. The gas calculation is already covering the jump desk analysis, but it's kinda… the limit is there for Little bit more protection on the… Maybe some educators.

Luis Pinto: I… I wonder what's the benefit of that without increasing the contract size limit, which we obviously cannot do without the chunk-based code, VIP. So if there's… what would be the added benefit? If there is none either, where would just TFI?

Ansgar Dietrichs: And Greg?

Greg K | Lido: Yeah, I also have the same question, and I also posited that I think that… Yeah, perhaps someone else should verify, but I think that 7903 is kind of contradicted with 7907, which… increases the unit code size, but does not… the maximum size, but does not make it kind of infinite. So, I think that 7903 removes the limit completely, but 7907, what this does is, like, it increases the current limit, and also increases the contract size limit. So, among those VIPs, I think… Like, it's the same direction, but only one could be the final spare. You cannot have, for example, both… 7903 and 7907. So I think that these, like, discussion should be, like, Kind of together, right?

Ansgar Dietrichs: Okay, so yeah.

Greg K | Lido: Sometimes, but just, yeah.

Ansgar Dietrichs: No, it, Yeah, thank you. Then I think it's pretty clear we at least will definitely not make a CFI decision here. We will revisit it once when we talk about the general contract size, but it sounds even more that weird. leading towards not inclusion here. Okay, then we have, two more in the utility section. one of them is 7668, removal of, bloom filters. Right, this one, I wasn't sure whether to put a question mark. It seemed pretty universal support, but we also didn't hear many comments on the… on it on last call, so I would want to hear more active support for this before actually making the CFI decision, so… Does… do people have strong opinions on the removal of bloom filters?

Huh?

Carl Beekhuizen: I think this is one of the features where it doesn't really provide much benefit for anyone, and I think, like, most people agree that it should be removed, the question is, like, how does it fit in with the rest of the fork? So, if we have a fork that's rather empty, and we have the capacity for it, then I think we should consider it, but I think we should, like, defer this decision until we know What else we are trying to put in this fork? Because I think they're much higher priorities on this list.

Ansgar Dietrichs: Okay. That seems very reasonable, actually, especially because, again, this one just did not have that many comments yet on last call, so then… that's… postpone the decision. He might still be a candidate, but more as a filler beats on. also matches the comments in chat. Then we have, one more. That one seemed, actually, to have quite enthusiastic support, last time. There was 7708 ETH transfers emitting a lock, and I think we also had a specific extra comment and support, in the agenda GitHub issue. How do we, like… have… has anyone basically soured on the CRP over the last two weeks? Is this… is this something that, That we are ready to CFI or not.

Łukasz Rozmej: Again, here, I would love to see some numbers, like, what's the biggest receipt? After that, because then, especially if we decrease the cost of the transfers, the simple transactions, Then… What kind of receipts are we getting, right? That's a very good question, my opinion. And I haven't seen any numbers.

Carl Beekhuizen: Yeah, so… we don't have any numbers here. Part of this is because… Whatever this… whatever we do here, we will have to update the pricing of… this part of an ETH transfer to account for the new logs. Which we'll only know once we have more of the harmonization stuff, so, like, this ties into a lot of the repricing things, which we already decided we'd like to ship. So, I think we just need to assume that this will… like, be harmonized with everything else. The total amount of work that's required to be done here is very small, so… like, by node, so I think that… Like, from that perspective, there's not too much to worry about.

Like, this to me is just, like, this one weird edge case where ETH is, like, just much worse than pretty much every other asset for people trying to interface with the chain. And I think this is, like, a great way of like, reducing the delta between ETH and all other assets on-chain.

Łukasz Rozmej: One comment I also heard, I'm not sure about it, that because this is not from Genesis, it's less valuable, just adding at this moment than… But it's not really that valuable. But… because you still need the old way somewhere in… in indexers, etc. Well…

Carl Beekhuizen: I mean, yes and no, it's like… if this is the only data you consider, then yes, but it means running an indexer, like, forward, like, henceforth, you would be able to just be able to look at what comes in via these logs, and make deltas. There's a one-time calculation you need to do for all the stuff in history. I don't think it's worth us making clients implement this records compatible, like, like. putting this back towards Genesis, because I think that's just a lot of extra work, and I think for very little benefit, but I think we still get most of the benefits without it, but your point is definitely valid, that it is a little… like, you can't just look at all the logs since Genesis and know the values of everything.

But I think this is more about knowing about, like, new deposits and transfers and that kind of thing.

Zsolt Felföldi: Yeah, may I just quickly interject here? So, so I believe that, this could be very valuable, so right now, right now, it's, like, extremely hard to use logs anyway, so, if we, at some point, not sure if we glamster demo or not, but we do 7745 at the log index, then it's totally possible to just, like. I mean, create the new logs, the transactional logs, eTransfer logs from the fork, and also create the log index from the fork, but then just re-troactively re-index or the pre-fork chain history with the, eTransfer, new eTransfer logs for the, like, the old history in, like, the new index. So, yeah, I think, at least the way I hope, there is going to be some kind of log re-indexing anyway, so I think it's still very useful.

Ansgar Dietrichs: Right, so… Yeah, so there seems to be some remaining considerations around 7708. Do we make a decision today? On it, or… Do people want to… Look into those. And keep in mind, I think usually saying keep… look into those. In two weeks, we probably will not have more information than we have today.

Dragan Rakita: From Redside Sims, we… I think we support it and want to include it. It makes sense to have logs for the transfers. At least it is in the right direction.

Ansgar Dietrichs: Right. And given, like, every… every client had it in S or A tier? So that's why I put it as TFI Canada. In the, interest of… making decisions, given that, overall, I would propose that we do CFI it, just given that there's overall, like, I see several messages in chat arguing for CFI status. Does anyone object to certifying it?

Łukasz Rozmej: Well, the only downside is we are making EDA transfers, more pricey. Because we write more to history.

Zsolt Felföldi: Well, we do want this information, I mean, like… this is a work we should do, actually, so yeah, I think…

Dragan Rakita: There's a HEP in the core group that reduces entrusty gas for transaction. So those two should be, like, considered one another.

Ansgar Dietrichs: Yeah, so, as, as was already… as was said, yes, if we make an inclusion decision, then that means that any other EIP that touches the pricing of transfers will take this into account, and will basically, like, be marginally. more increased, Lukash, then my question is, would you be okay with CFI-ing it now? And then if, during the process, basically, like, we see that the numbers seem… More punishing than, than, than thought, that we, that we just.

Łukasz Rozmej: Yes, yes.

Ansgar Dietrichs: Not concluding it.

Łukasz Rozmej: Please see if I…

Ansgar Dietrichs: Okay, so then, CFI decision on this one. Then we can move to the next section, the, opcodes. So, first, a DFI candidate, 7791. gas to ETH, there was some… concerns around implications, that overall implications are just not… not well enough understood. It's… pretty big paradigm change to the EVM was proposed relatively late, so for that reason, it seemed… likely to DFI? Is anyone… does anyone want to argue against DFI? And I would say B, deify it. The next one, 7819, set delegate, the reason that's… on the DFI candidate list, we did not… it did not come up on the last call, but all clients that have expressed an opinion on it have put it into C or D tier.

That just seems to indicate it doesn't really have a chance for that, folks, so… unless anyone objects, again, DFI decision. Okay. DFI. And then we have one, I mentioned briefly earlier, 7843 slot num op code. steamed… For a potential candidate, it only is a question mark, because, some clients will only put it into B tier. Geth was arguing for it on the last call. Yeah, I just want to check. whether there's interest in CFI-ing it now, or whether this is more a filler EIP to decide at a later point.

Łukasz Rozmej: I think if we are… want to decrease, potentially, slot times in the near future, Pushing this in earlier would help to potentially develop some kind of, Ways of dealing with that later. on the EVM side.

Ansgar Dietrichs: Sounds good. Okay, then I would say we see a fire, is there any objection? Okay, then… CFI decision on this one. And next one, EIP7979. call and return opcodes for the EVM. That one… Seemed to… overall have no client support. Aragon was speaking out against it, but Nethermine specifically had expressed interest in it, so I just wanted to double-check with, Netherland, yeah.

Łukasz Rozmej: Just one argument for it, because there are, talks about potentially changing EVM to RISC-V, for example. Which… I'm totally not convinced. I think EVM has a benefit of being more domain-specific, and I think going to RISC-V might not be that good. But if we moved the EVM bytecode to this kind of call return opcodes. We could relatively easy transpile, compile, whatever we want to call it, JIT, whatever we want to call it, EVM bytecode to basically any other form. We could go to RISC-V, we could go to native x86, we could go to ARM, This unlocks potential optimizations of the… Of doing that. While keeping the whole, base language under our control, so… That's a big, big upside,

I think it's also… I have to agree that it's probably mostly… could be ported from EOF, so it's not… that much work. On the… probably, maybe even on the testing side, I'm not sure about tests. So those are, like, the four… four things. I'm not sure if it should go to Glamsterdam, but in general… so, sorry, to Glamsterdam. To… yeah, Glamsterdam, Glamsterdam. Okay, I'm confusing the forks now, too many forks. But, Yeah, but I generally see this as an alternative path to different ESA, like Riskli.

Ansgar Dietrichs: Right, and given that, all clients, except for NetherMind, had expressed skepticism on this one. Do you… would NetherMind be okay with us just deciding now to wait at least until H-star with this?

Łukasz Rozmej: Yes, yes, like I said, it's… we don't consider this as a super urgent, I just see a value of this path compared to the other one, and, it needs probably… deeper discussions.

Ansgar Dietrichs: Sounds good. So then I would just… Proposed to DFI it? 12% was another.

Greg Colvin: I had something to say about that. Put it on the agenda 3 weeks ago.

Ansgar Dietrichs: Yes, if you want to. Talk about that comment.

Greg Colvin: What would you… what was just said pretty much covers the technical reasons to put it in. The reasons… I would prefer to see if I, to some extent, are personal. I'm 71 years old. Every time we delay this, I'm getting older, and the evidence is, that, it will get delayed. And… At this point, at least 3 times, we have gotten, proposals to fix this problem, as close to In the code, and going into the upgrade, and then removed. So, I would much prefer to start to get this in sooner, so I can get to work. I want to what I want to do, and so the community trying to do static analysis can do what they need to do.

Because they… they will not even start to look at this until it's actually on the main chain. And, So, I'd like to at least consider it, just even to consider it now, and get that conversation going. Rather than… than kick it down the line, because I can't… I cannot predict that even 6 months from now, I'll be in a position to champion this. I don't know that there's any champions left. For this work, and it is such a small change, and that it is such an industry standard, such an industry standard operation, there's just no reason it should not be an EVM. That's it, that's all.

Ansgar Dietrichs: Right. Thank you, Greg. And just, yeah, as a personal note, I do… I do agree that there has been… I've been some of these And just that they've been so… have been very close to inclusion, at the edge of inclusion for a long time, that is personal… from a personal side, of course, for champions, very frustrating. So, I definitely understand that, Lukash?

Łukasz Rozmej: If I can say one more thing, because there's a question of the legacy bytecode. So, we tried to create ILEVM, which would do exactly that, transpire the legacy bytecode to native x86. It is possible, but due to… the size of the bytecode, that is basically one big method, right? One big function. No… no compiler later was put even try to optimize it. So, basically, That's the problem, so we can still support the old bytecode with the translation, but for example, we can price it out that it won't be practical for much use in the future. So, we do have kind of a backward-compatible way of going through things, but we would have to

Support some kind of transition of most things to the new format.

Greg Colvin: The EIP discusses that some, and these are the kinds of things to discuss as we consider the EIP. I'm really almost begging Let's consider it now. Let's not say maybe we will consider it much later.

Ansgar Dietrichs: So… just in terms of process, given that we did otherwise have clients indicating that they would want to at least not include it into Amsterdam, I would, at this point, then ask Did any client… would any client want to revise their opinion on this now? Otherwise, I would feel obliged to still go with the client decisions. But of course, if the client listening to this Would want to revise their… stance on the CIP, I'd be more than happy to hold off from the DFI decision. then I… I do think that… I mean, just process-wise, it seems like it's pretty anonymous text by clients to not have this in Glamstadam. I do think… It might be a good idea to try to see if we can have a way to… Pass this…

ongoing conversation about the CIP with clients before we get to the next… PFI phase for… for HSA, which indeed would only be 6 months down the road. So, if there's… I think it might be worth looking into a potential breakout process for this, to… to keep going.

Greg Colvin: Anything we can do to keep this rolling. Because otherwise, you know, pretty much… 9 years into trying to get this work done for Ethereum, I will… Have to say… Goodbye. It's not what I want to do.

Ansgar Dietrichs: Yeah. bam… I think that is a strong case to try to keep the process rolling. I would say, in terms of process, then I'll follow go and say we will re-DFI it for Glamstadam itself, and just make a note that we try to Keep this going, and not just revisit this in 6 months.

Greg Colvin: Yeah, I mean… Excuse me. Yeah, I'm sorry. So that means we get a breakout room going, or we, resolved to… to really get a discussion going on the magicians, but not just, you know, leave this sit for 6 months, or to have Some sort of consensus that, yes, 6 months down the road, we will have reviewed this and be ready to make… be ready to make a decision after all this time.

Ansgar Dietrichs: Yeah, I don't think we can make a formal commitment process-wise, but I do think that it would be quite helpful if people can go find the ETH Magician's post, so we make progress on this. And, Nick's on chat is saying. Okay. Protocol support can help facilitate this, to make sure that there's actual follow-up, not just empty words.

Greg Colvin: And then a breakout room is the process at this point, too. to get a core devs discussion going on this. Am I right?

Ansgar Dietrichs: I would leave that call up to protocol support, but Nick, so if you… do you have a… It does seem like there's interest in a breakout, indeed, in chat.

Nixo: Yeah, I think that's the right way to keep this conversation going.

Ansgar Dietrichs: Sounds good. So then we will have a breakout, and then, for us to be able to move forward now, I would just leave it at this. Greg, do you have anything more, or is that… does that satisfy? The situation for the moment.

Greg Colvin: Well, thank you, yes.

Ansgar Dietrichs: Okay.

Greg Colvin: then…

Ansgar Dietrichs: We have another ERP right under this one, ERP 8013. static relative jumps and calls for the EVM, also listed as a potential DFI candidate potential, just because, all clients had B, C, or D, votes, but there was no conversation about it last call, so I wanted to check back whether anyone has changed their mind on this one either. Otherwise, I would just DFI 8013 now. Okay, that's DFI. And then one last one in the section, EIP8024. That one was, I think, maybe together with the refund mechanism, the one that had the strongest support last call, that's the backwards compatible swap and dupe and exchange.

op codes, we have 3 clients that put it into S tier. And… and overall had strong support on Last Call Voice, and testing also saying that it would be a small change. I would propose we see if I had anything come up over the last two weeks, four weeks that would make that a bad decision. Casper, you're unmuted? No. Okay. Then, yeah, the decision CFI. That one will then be in the glamstam scope. Okay, can we scroll down to the next sections? So, on cryptography there, I think some of the early comments from Nico was related to cryptography, but my understanding is that that was regarding the… with regards to the post-quantum precompiles. Is that right, Nico? Can you… can you clarify that? So, given that those are not currently in the

DFI candidate list? We could skip this for now? Or was… were your comments also regarding the two that are marked as DFI candidates?

Nicolas Consigny: Yeah, so actually the two that are here are in the list. There is another one that is not in the list. Which is AT52, like… we wrote this one, and I realized, two days after the deadline that there was a deadline, so hence my comment on the needs to, reference these deadlines within EIP1. But the two that are, I think, yeah, both of them are, in the list, So we can definitely discuss them. And, yeah, I can go, maybe Dano has a… a point, too, to make, I assume.

Ansgar Dietrichs: Wait, but can you clarify? You're talking about 67… 7619 and 8051, is this the tool that you're talking about?

Nicolas Consigny: Yes, I think both of them, if I'm not mistaken, are… In the list.

Ansgar Dietrichs: Yes, but they're not CFI or DFI candidates for now, so we would… we can revisit this towards the end of the call if we have time. I assume we won't have time today, but…

Nicolas Consigny: Oh, okay. Okay, I see. Yeah, okay.

Ansgar Dietrichs: Okay.

Danno Ferrin: Should we just go ahead and DFI Falcon? There's good reasons to DFI it, but keep MLDSA open as a question.

Nicolas Consigny: I would agree with that statement, yep.

Ansgar Dietrichs: Okay, I mean, sure, I'm always happy to take unexpected DFI decisions, given that the people involved in this process are recommending this.

Danno Ferrin: Keep my notes in the comments, there's very good reason to wait on it.

Ansgar Dietrichs: Okay, so anyone who, for some reason, really wants to… is opposing DFI-ing a Falcon? Okay, then we DFI DIP7619 Falcon for Glamstadon. And we will discuss the other one in that section, later, but for now, we move on to the DFI candidates that we have marked, which is these other two, secondary signature algorithms and the P256 transaction support. Overall, on last call, there was a lot of skepticism around these two with regard also to the And… kind of future account obstruction strategy, things like that. The P256 transaction support had pretty, pretty universal, projection. The, 7932 did have.

It was, was ranked quite high by, by, by Bisu, if I'm not mistaken, so I did want to maybe double-check on this one. But otherwise, basically, both of those would be DFI candidates. So do we have anyone that specifically would not want to DFI? either of those two, and in particular, maybe for 7932, whether Beso Has it? Tesla opinion on this.

Justin Florentine: Yeah, our opinion on 7932 is really more of a PQ, preparation. step. So we see this as sooner rather than later. I don't know that we feel strongly enough that we'll fight hard against DFI, but we see this more as a CFI question mark.

Ansgar Dietrichs: Right, that's why I was bringing it up, because I think that that's exactly how I perceived the basic position. All the other clients seem to… think that Lamsdam would be premature, at least, on this point. So then I would… yeah, I would… Justin… yeah, would you… do you think, from the base side, it would be okay if we just push this one hot fog and we revisit this… this question for… for Ichtar?

Justin Florentine: Yes.

Ansgar Dietrichs: Awesome. Then I think we can… go ahead with the PlumsetMDFI decision on both of these. And… Yeah, and then there's one last section here, that's the other section with some miscellaneous EAPs. The first tier is, period, or the kind of periods related to proposals. 64… 04 and 6466. We talked about it, last call. And… overall, it seemed like clients did not feel like it was a priority for Glamstadam. I said, if, you know, if people change their minds, that that would have to happen until this call, so the question is, have people changed their minds here, or can we Do we want to go ahead and DFI these?

Barnabas Busa: Just one quick question. Is 7932 and 8030 handled together as… one decision, because as far as I know, we just made a decision for $79.32, but not for 8030.

Ansgar Dietrichs: Okay, sure, fair point. We can revert back, just to double check. 80-30, yes, I was intending to have it be a shared decision, but, that's obviously… there's no reason to do that. The main reason with 8030 was just that every single client that expressed an opinion, so everyone except for Rats, put it into D tier, which to me, implied, that it would not really have a chance in this artwork, but, yeah, is there anyone that would want to speak up in favor of 8030? Barnabas to use? I mean, do you have anything in favor of the AP that you'd want to bring up?

Barnabas Busa: Yeah, so the only reason I brought this up, because we just included the SAC256R precompiled in Fusaka, and it's just interesting to me that we do not want this P256, because it would be, like, the… completion of, finishing what we started in Fusaka, I think. Maybe I misunderstood the IP?

Ansgar Dietrichs: My understanding is that it's not just a precompile, but an actual new transaction type.

Carl Beekhuizen: Yeah, we… so we already… I think the reason not to do this is partly because we just shipped this in Fusaka. We already get most of the benefits from… like, of having R1… On-chain by what we did in Fusaka. This is just whether we want to support it more natively. So, to me, that means, like, it's only if we want to see, like, even more adoption of this, and don't like that you don't have a native R01 transaction type. Secondly, I do want to raise that 8030 does require 7932. So we do, if we're including 8030, we do need to include 7932 as well.

Ansgar Dietrichs: Anya and Nico?

Nicolas Consigny: Yeah, I… I agree with Carl. I think we have most of the benefits, thanks to the precompile, and… Adding this is, first, like, not very aligned with the PQ strategy, because basically we would make a lot of e-forths to include a new transaction type. To find a way to deactivate it. Maybe in one fork, because we were talking about the PQ precompile and PQ emergency plan at the same time. So to me, it really doesn't make sense. Both from a strategy and technical point of view. we… we have a cheap R1 precompiled. Also, like, the R1 curve is, Is, yeah, doesn't have, nothing under its sleeve, proofs, so, like, we can't really know, all the details of the parameters, so, like, activating it as a native, curve adds more risk.

So yeah, to me, I would say no to both, I guess.

Ansgar Dietrichs: Yep, then, I do think we are probably still in the same position to make a DFI decision, or did anyone… Want to change the mind here? then we go ahead with DFI. So then that gets us back to the two pure, EIPs. Did we have anyone that would want to speak up in favor of those? Then, otherwise, I'll, DFI… I'll propose we deify both of those. Okay. Okay, so then those of those elements are deified. And then one last, one that was a candidate here. is the sparse blot pool. Now, I wasn't sure, from glancing at the AP, whether this has any in-protocol changes, or whether this is a pure, kind of, out-of-protocol.

questions, so I'm not sure, also. how much people have already looked into this. Overall, it seemed like there was… Relatively strong support for this. Does it make sense to… Cfi this today. And Marius, maybe, if you can give some context?

Marius van der Wijden: Yeah, it's… it's out of protocol, but, I think it is very important. And it is not super easy, so, client teams Need to set aside some engineering time for it. I guess that is why it was… proposed to ACD, so that It can, like… It can be, bank teams. If we included client teams concept, set aside the engineer time. When thinking about the scope of the… of the fork. I think it is very important. For increasing the block… Coned. We will probably not be able to go to… the massive blob counts that we envisioned without this, so… Yeah.

Ansgar Dietrichs: And for all?

Raúl Kripalani: Yeah, so just to add to that, yeah, double-click on that, and specifically with, on the consensus layer, we're already… working on testing and interoping on the partial messages, side of things on Gossip Sub, and that basically is the whole idea of cell-level messaging. So with that, we will be removing peer-to-peer, like, all… network inefficiencies from the CL, where we're right now. Transporting data that, you know, the node already has, and… that will basically unleash the CL, but then the EL will become the bottleneck, because it is still fully replicating blobs in the mempool. So that will be… we predict that around 72 blob down, that will start becoming the choke point for the system. And that's why we submitted the CIP. It is, right now, I would say, like, 90% confident that this can be rolled out progressively, and, like, it can be an opt-in, and over time, in… within the, like, even before Glamsterdam.

some nodes can already start supporting it. We still have to conduct some assessment there to analyze any risk for, like, network partitioning and so on, or block pool partitioning, if… so this is not entirely clear yet. So, the rationale for submitting this is to have a clear checkpoint that the network should support this feature entirely as a whole by Glamstadam, but also to carve out some space in case we do actually, like, there is some… Some possibility that we do need, a fully coordinated rollout, just to… in case we detect some risks of partitioning.

Ansgar Dietrichs: Right, and that was the general question, on the last call, how we would handle, proposed ERPs that do not have protocol changes, that I put the other three that were in that category in the process box down there. None of them were, for now, like, the CFI candidates, because we wanted to first make that decision. I mean, Raul, as you're saying, this one here specifically at least has the potential to want to specifically be at the hardware boundary. M… I personally do think having non-protocol change EIPs in a hard fork to just signal prioritization can make sense. Yeah, process-wise, is this… does this include any changes on the CL side directly? So is this something that… is this a CFI decision that we would have to make together with the ACDC side, or is this an EL side only?

Raúl Kripalani: There are some engine API changes, specifically for the CL to communicate to the EL any custody set changes, and that is pretty much it. As well, to receive cells only. from the CL, but that's… from the EL, but that's actually coming sooner with V3. So it's really just the custody signaling side of things. So the change on the CL is very, very lightweight. I don't expect it to be… to be a blocker, and definitely not something that is consensus-breaking.

Ansgar Dietrichs: Sounds good. So then in terms of process, I think at least what we can consider here is CFI-ing it with the understanding that that's conditional on double-checking on the ACDC side, but because we have so much of this ping-pong, like, here, the decision would be on our side, and it's just a double-checking. Is there any unexpected concerns regarding that, engine API? So that would basically be, like, a one-week stay of.

Raúl Kripalani: Yes.

Ansgar Dietrichs: of a poll decision, but the question is, do we in general already have, even on the EL side, do we have enough support here? Do we have enough consensus that this is important, that we would want to make the CFI call today? We had, client-wise, we had, 1S and two A's for this, so that did seem to signal pretty strong, overall support. Maurice just spoke up in favor of it. M. I can, to step out of the coordinator role briefly, I can personally also express support, but… Is there anyone that would basically specifically prefer to not have CFI today? Okay, and I do think we make the decision today that, we basically mark it as CFI, conditional on double-checking on the CL site, in a week.

Okay, so then we, add through the list. Now… Good news is we made quite a few individual decisions, so this will cut down the list quite a bit. Thank you for sticking with me, this was a bit tedious, I understand that. Bad news is that we also now have, 4 minutes left. And we specifically did not talk about any of the sections that require continued discussions, that were not just decision-ready. I think in… because of… in the interest of time, what I will do is I'll just briefly walk through that list that I put up on the agenda that's also just my take on where there are open questions, so this is not at all necessarily, like, fully accurate or conclusive, but I do think the goal would be that in two weeks, we specifically focus on these open questions, no general purpose CFI, DFI discussions, unless maybe on the side if they come up, but really the focus on next ACDC… ACD will be to work through all of these individual questions.

I'll briefly go through them. So, the questions that we have is. On the repricing side, in terms of the core gas, repricing, so that is not the state growth question specifically, but everything else, in the core, in this proposed core bundle, there was pretty strong interest, Last call to consider unbundling this, and then in response, the champions, and that includes me, are working on a proposal to just basically regroup this in a more palatable Form, so by 2 weeks from now, we would have to have a basis for Of, of that work to, to discuss. repricings, on the state growth side, that was one… that's just the one EIP that we have proposed right now, 8037, but there were questions of, is this quite the right approach? And there were two alternative proposals. We have, a write-up by Anders. I will…

Post that in the chat. For people to look at, to compare these, the different ones. Also, by the way, Raul, your hand is still up, just, just to mention. So, so we have this right up by, by Andes on this point. Then we have the, topic of contract size increase. There's none of those had… it basically has two set… two alternative approaches. Neither of them had clear support, and it seemed like… we had, on the one hand, we had Geth and Guillaume that preferred the chunk-based mobilization, and then we had other clients preferring the existing approach that we had already considered for Fusaka. So that one, I think we just need to resolve. Do we want to do one of the two, or do we want to do nothing?

hopefully a decision in two weeks. And then on the… In the utility transaction block features block, we had, some… updates by Zolt on 7745. I will note that Geth and Zolt were quite interested in this EIP, but most other clients had concerns, so I'll post the update in… in chat, just to flag that we will make a decision there in two weeks as well. And then cryptography, post-quantum precompiles. This is also what Nico came here to talk about. I think, Nico, I see your hand is up. I will say that we don't really have the time to go into this for now. The question there basically is. for these is… well, we made one decision today. We made one DFI decision on Parkins, so the question on the other one is, is Glamstadlam the right time or not?

I do have… yeah, okay, then I appreciate that you took on the hand, because I think it's better to call… talk about it on next call. And then the last block of decisions we have to make is… for these three, non-protocol changing EIPs beyond the SPASM block pool, yeah, how do we handle those? So, all of these questions are listed on the agenda for today, so maybe people can have a look at that, and, I'll also Try to coordinate with people a little bit more, so in two weeks, we do have A good basis for decisions on this one. Mmm… Tony, do you… you have a comment?

Toni Wahrstätter: Yeah, do we… I mean, now it's almost too late, but do we also want to talk about the data repricing APs? If I remember correctly, like, 4 out of 5 clients? had the call data pricing at the S tier, so it might make sense to CFI. We have CFI DFPs that had way less support today.

Ansgar Dietrichs: Yeah, the problem is just that there were questions about the specific approach to these repricing APs, so whether we want to select them one by one, or consider them more as a grouping. I would, for that reason, hold off for now, although, yes, I think it seemed pretty clear that we will have a repricing in the fork that will touch data. So, I think that's clear, but, like, just in terms of process, because otherwise, if we open that box now… I mean, now we can't open it anyway anymore, but that's why we didn't bring it up on this call yet.

Toni Wahrstätter: Okay, no, that's fine. It's fine, we don't need to discuss that. Okay.

Ansgar Dietrichs: Okay, and then I just mentioned the housekeeping we didn't get to, H-star name, we need to make a name decision, there's a link, In… in the agenda, go and… figure that out, everyone. And then there are… comments that we should, clarify, kind of minimum hard fork testnet and maintenance rollout timelines on a future call. So all of that, hopefully, we get to in two weeks, but for today, that's all. Thank you, everyone, for your time. I hope it was worth all of these micro-decisions, and talk to you all in two weeks.

Toni Wahrstätter: Thanks, everyone, bye-bye.

Lightclient (Matt Garnett): Yep.

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