All Core Devs - Execution #245

Transcript

Pooja Ranjan: Sorry for the wait, just wanted to confirm, Mark, if you are on the call, will it go live all by itself, and we are good just by using the stream code? Yes, I can see it going on right now. Cool, very well. Akash, are we ready? All right, thank you. Ansgar, you're good to go.

Ansgar Dietrichs: Perfect, then… hello everyone, welcome to All Core Devs… 245. Today is going to be mostly about Hegota, but before we get to that, first, briefly glimpse at them. So, in particular, my understanding is that there was a topic on ACDT this week, regarding EIP8253, which is this proposal to bump the non-s-of-zero nonce storage accounts, and there's some consideration to potentially even still, last minute, add this to the Glamsterdam scope itself. Is anyone on the call here with context on this that can summarize where things stand regarding this question, and, What the exact decision is to be made today.

Jochem Brouwer: Yes, I can give the context. So, EIP 8253 will replace EIP7610, I see Toni with hand, so we are, like, very late into this process. What I want to say here is that, at ACDT, we… well, I brought up this idea to add this to Glamsterdam. The reason for this is that this EIP is a mainnet-only fork. That means that for Hoodi and Sepolia, this fork is a no-all, because we only changed these 28 accounts. I just want to… to all just consider the possibility that we can… we can add this EIP to Glamsterdam. this is what we proposed on ACDT, and we said, okay, let's go back to this at ACDE so the clients can also think about this.

If the decision is that we will not do this in Glamsterdam, then that's fine, then we will do it in Hegota, as it is scheduled. But then I want to immediately bring up the point, let's then immediately CFI it, because this EIP, has replaced EIP7610, which has been SFI for Glamsterdam. And I think we should then immediately, well, maybe not even CFI it, immediately SFI this EIP in Hegota. Yeah, that's the context.

Ansgar Dietrichs: And Toni?

Toni Wahrstätter: Yeah, most clients were against doing that in Glamsterdam on ACDT on Monday. I think it's just too late to include an EIP at this stage. Also, the fact that it's mainnet only would basically mean we would not discover bugs on testnet, so I think, if we actually wanted to do this EIP, then the proper way would be to spin up a new definet that actually can do this transition. The main issue I voiced on Monday was that it interacts with BAL. We would suddenly have to also bump those accounts in the block-level access list. And… we would still have to do that in Hegota, but we just have more time to prepare everything and ball is shipped at that point. So, to me, it feels like…

a clear candidate for Hegelta, but I would… recommend against putting it into Glamsterdam.

Ansgar Dietrichs: Makes sense. Yes, I mean, my default take would, of course, be that this at this stage in the fork to still add something to Glamsterdam would require some exceptional circumstances, so just to double-check, Jocham, from your point of view, is there anything… very urgently, like, security critical about, doing this in Glamsterdam already, or would you also be fine with doing it in Hegota?

Jochem Brouwer: Yes, Hegota is fine. I just wanted, for the process itself, like, bring this up, because it would also be… I would also regret not bringing it up, and then thinking, okay, we could actually have shipped this in Amsterdam, but this is, like, totally fine. It's, it's not a security problem, so Hegota is great. But yeah, let's send SFIs, then we can end this discussion, and then that's great.

Ansgar Dietrichs: That's good. And then that last thing, just to confirm, that would mean that the 7610 would stay in Glamsterdam unchanged. Is that correct understanding?

Jochem Brouwer: No, this 7610 is to be moved from Glamsterdam. It has been DFI'd. I know it has been SFI'd, this EIP7610, but they found some problems, and then it was actually DFI'd. Yeah.

Ansgar Dietrichs: Sorry, my bad, yes. Okay, makes sense. Makes sense. Thank you for clarifying.

Jochem Brouwer: Okay, so can we then also, just for clarity, then, formalize the, SFI… SFI 8253, here?

Ansgar Dietrichs: For Hegota, I would wait to just… until we are in the Hegota decision block for today. I don't think there's any need to specifically fast-track the decision, right? Okay, perfect.

Ben Adams: Yeah.

Ansgar Dietrichs: Fed up?

Ben Adams: Yeah, I just… I'd just note… that this is the case, because it probably hasn't… I'm not sure if it was in the list of… GetHeader items.

Ansgar Dietrichs: I think it… is… which one is the PA number again?

Jochem Brouwer: H253.

Ben Adams: Oh, okay, it is, it is. It is, it is.

Ansgar Dietrichs: Yeah. And has one of the highest client rankings on average, so it's a pretty likely candidate anyway. Okay, perfect. Then, decision is to not, last minute add this to… to Glamsterdam. Then just quick question on Glamsterdam. Are there any other topics for today? Any… anything DevNet-related, or Tesla-related, or anything? We should discuss on the call here. Okay, then we can move on to the next agenda point, which is the Higota block. First up there, just a brief mention is a CL-side EIP that might still be PFI'd. Kamila wanted to briefly mention this?

Kamil Salakhiev: Yeah, thanks, Ansgar. Hello, everyone. Yeah, just a quick heads up with regards to Fast Payload Broadcast EIP, which we submitted last week. Yeah, we'd like to ask ACDE permission to PFI this EIP post-deadline instead of Blocks and blobs EIP. A new EIP is cleaner and more focused on the fast parallel propagation, which we think is important in the context of higher gas limits and potentially quicker slots. So, this is yield change, and apparently decisions should be made on the ACDC call. And we will ask for decision next week. Yeah, meanwhile, yeah, maybe leave below some links to the EIP and relevant Discord discussions, and some other discussions which we had, for example, yesterday on P2P call.

Yeah, that's it. Thanks, Veron.

Ansgar Dietrichs: Perfect. And yeah, as Kamil already said, the decision then will be made next week, but I think it's good for everyone to be aware that that's ongoing. Okay, then, let's come to the actual headquarter decisions for today. The first one is… briefly, frames transition… transactions. We left this, last call two weeks ago, by making the SFI decision. But never quite clarified whether this was intended to actually mean, that frame Transaction should now become a a headliner, basically like a retroactively nominated headliner for the fork, or just a normal EIP with, basically already in SFI status. I think my feeling was that the clients were all leaning towards headliner status, but I think it would be good to formally confirm this decision, so…

Is everyone here in favor of making frame transactions a headliner? Or anyone basically wants to speak up against that? I don't see any voices against, headliner, so then, yes. decision is made. Frame Transactions is going to be a headliner for Hegota. My understanding is that there's also still active work on, basically, on iterating on the spec, so the exact spec might still change, but FrameTransactions will be a headliner for Hecota. Perfect, congratulations. And then we can move on to the main scoping block for today. Before we go into all the EIPs that we asked the client teams to publish rankings for, we got rankings from all client teams, so thank you very much for that. But I wanted to first briefly go through the list of EIPs

that, specifically, like, are not on the list, just to double check that there's no kind of confusion about any of the statuses there, I posted a… an overview in the agenda, so if everyone wants to have a quick look. I'll just briefly, basically go through the list, and then afterwards, if anyone wants to speak up about any one of those items, or basically, if any of these statuses is confusing for anyone, then now would be your time. So, obviously, frame transactions will no longer be discussed as a decision, because it's already SFI'd. Then there is the foundations of EVM control flow, which is in itself just a meta EIP. There is a sibling EIP, which we will discuss, but this meta EIP will not in itself be discussed for scoping.

Then there is two EIPs that are cross-layer, but we decided to have both of them basically live for the decision-making and discussion on the ACDC side, so they will not be discussed here on ACDE, which is, one, the block access list sidecars. Eip8146, and the other one is the independent CL EL sync. which is EIP 8237. So those two are still in consideration for the fork, but will be discussed and decided on on the ACDC side. Then we have 6 EIPs that are withdrawn, or basically either were withdrawn by the proposer, or, just ended up being auto-deFI'd because they have no champion. I'll not go through all of six of them, but there's a list.

And then… one last one that I wanted to briefly call out is one where the status is still open. I think there might have been some confusion around the exact situation of the EIP, which is EIP 8360, the t-create opcode, which was basically the idea of having, like, a way to create a temporary contract, just for the scope of a transaction. The discussion there last AllCoreDevs was to basically keep this topic open, because there was some, concern still around the changes in Glamsterdam and the consequences there. My understanding is that this is kind of, like, in some in-between status right now. It was not part of the scope of the, of the, Priority lists, t-lists that all the clients published, so we will not discuss it today, and we will make sure that by two weeks from now, on AllCoreDevs, there's clarity around whether this is still in contention in any form, and make sure that Code Devs have everything they need to make a decision on this one.

And does it all sound right? Was there any confusion or any contention around any of the EIPs I just mentioned? Maria, you have your hand up?

Maria Silva: Yeah, I just want to add a comment on TCREATE. So, my understanding was that it should be CFI, so it was my understanding from the last ACDE on the grounds that, so I… maybe we should reach out to Alchemy if he's not here, but my understanding is that he and And, and another dev, I don't remember his name, they would be championing this EIP. And they feel strongly that it should go in, so I… I don't see why it needs, like, a… a different status, but maybe it's… I can reach out, like, we should reach out to them just to… to conf… oh, I think…

Milos | enso: Bye.

Maria Silva: Milos is speaking? Yeah, yeah.

Milos | enso: Yeah, yeah, it's Milos. Alchemy will not be able to join this course. As far as I understood, he doesn't speak English. But yeah, I will, I will… I can champion for this, EIP. I will still be, if there is any delay, I will still be promoting the gastrofields, but this is another topic. About Decreate, I agree that should be included.

Ansgar Dietrichs: Okay, then, what we will do is we will async, just clarify the status of whether it's also this specific EIP, or some, some, whether there were some intentions to potentially make adjustments, and… get back to all the clients about a request to form an opinion by next call, so we can then have it be part of the scoping discussions. But it was not part of… The, the default forecast list that everyone, Made, made their initial rankings on. Sounds good? Any… any other, comments to… to these EIPs, otherwise not regarded, otherwise we can move on to the actual, list of, EIPs to be discussed. Okay, then we can move on. Now, that leaves us with 37 EIPs. 38, actually, it looks like we will indeed consider TCREATE next week, or not next call, so then that's 38 EIPs, for today it's 37 EIPs.

That's a lot, again. It's, I think, a little bit less, actually, than Amsterdam, so that's good. My hope is that today we can already start by having some initial early DFI decisions, so that this number can start coming down. For the specific, approach here, I, would ask Mark if you… are you on the call? To share your screen. First, to go through the forecast list. Perfect.

Marc Garreau: Anybody wants to follow along, I'll share the link in the chat here.

Ansgar Dietrichs: Maybe I'll actually… Let me… let me share this link, which is already the one that specifically has the view. But yeah. Okay, so, we created this little presentation mode just to have, have the EIPs grouped more, topically, So we can go through them section by section. You can, you can see here, so, so we have 5 pages total, 5 pages with, with, with groupings for the EIPs, 37 total. You can see to the right always the votes per EL client, and in the end, the average, using this forecast aggregation mechanism, which basically just assigns Numeric, values to the individual votes. M… My proposal would be the following for process. I would say for each of the five pages, we briefly go through the EIPs that belong to the category. We have… I would… unless this is too verbose for people, but I would briefly call on each client to just give their 30-second take on

On basically, like. you know, their opinions, as they also displayed in the rankings, and then would see if we have already, like, enough of a clear opinion to make some decisions. So, for example, on this page, you can already see that the code-controlled EOA delegation is a clear candidate for DFI, so is set delegate, so that we basically, we can start making decisions here. Mmm… if, I mean, yeah, like Trent, I see, I see the message said, maybe, maybe this is unnecessary, we can also immediately, like, I just, I think… This is the only way for the section to not just be me talking all the time, and… Okay, let's try this for… oh yeah, go ahead.

Ben Adams: I mean, we could… Are there some obvious ones that we can DFI and accept, and then… And then we can do the more… Either-or ones, as giving opinions.

Ansgar Dietrichs: Yeah, Lukas?

Łukasz Rozmej: So for the, like, more that have some kind of majority EIPs, I would focus on the minority voices and discussion, quick, like, discussion like that. So, for example, here, for 7906, for example. Nevermind and Rev have… kind of are outliers compared to the rest, right? So, yeah, that's… that's how I would focus. Okay.

Ansgar Dietrichs: Yeah, that actually seems reasonable. Okay, then let's…

Łukasz Rozmej: so many EIPs that, you know, you have to have more broader discussion.

Ansgar Dietrichs: Sounds good. So, basically, like, just to give a rough feeling, I think, basically, anything below 1 in this EL grade rating is pretty much a auto DFI candidate. I will, of course, ask if there's anyone who wants to speak up before we make the decision, but here on this page, these two EIPs would be the two candidates, and they are more on the other pages. Anything between 1 and 2.5 is basically EIPs that we might accept, depending on discussion, and then anything above 2.5 is a very likely inclusion candidate. There's only a handful of EIPs this page is not representative, because FrameTransactions is the headliner, so these are unusually popular. Otherwise, there's not that many above 2.5. So that maybe should give you a rough, at least, indication, but of course, in the end, every decision individually will be up to discussion and codevs.

So then I would start to… start by just basically asking whether there's anyone who wants to speak up in… in support of either a said delegate, EIP, or the code-controlled EI delegation, because those two would otherwise be the first DFI decisions here on this page. Toni, you say the screen share is the wrong page, I'm a little confused. Can you, can you say what you're seeing?

Toni Wahrstätter: Yeah, I'm looking at an account obstruction EIPs. Yes, this is not the… Okay, I thought we… we should… we were supposed to see all the EIPs that would now do, like, DFI decisions.

Ansgar Dietrichs: Yes, yes, yes, we're going… we're just doing… it's 5 pages, just so that you don't have to stay at 7… 37 EIPs at once. We're going 5 pages that are grouped topically.

Toni Wahrstätter: Right, I see, perfect.

Ansgar Dietrichs: And on each topic, it's then within the, within the categories, it's… you can always see, so for example, the first, the group of three at the top, they all… they're, they're ordered, but… but yeah. Okay, Johann, do you want to speak up to one of the two EIPs?

Jochem Brouwer: No, one suggestion, can you please call out the EIP number when you state these things? Because then we are 100% sure that the EIPs that you were calling out are actually the EIPs that you mean.

Ansgar Dietrichs: Yes, that's a really good idea. So, we are talking about two EIPs right now, which is EIP 7819, the set delegate instruction, and EIP 7851, code-controlled EI delegation. Those two would both be DFI as a proposal here, unless someone speaks up now. Okay, then, those two are the first two DFI decisions. While we're on this page, I would, what I wanted to briefly ask, Do we want to already today consider making CFI decisions? You can see the three of the most highly ranked EIPs in total, the top three EIPs here. Would people want to already go into CFI discussions for this as well, or do we want to first just go through the all five and do DFI?

Maria?

Maria Silva: Oh, this is just an opinion, but I feel like we should do the CFI-ing, because then we can already start working on those things. If we just do the DFI-ing, then we are delaying work for the next two weeks that could already start. So, if it's easy to CFI, then I think we should do it.

Ansgar Dietrichs: Sounds good. So then the idea would be, let's do the clear CFIs today, let's do the clear DFIs today, and then we have, for next call, we have all the more nuanced decisions. And we already know how much scope we will have left to fill out.

Justin Florentine: Can I make a counterpoint here real quick? DFI is a decision, so by doing that first, we are making decisions.

Ansgar Dietrichs: Okay.

Justin Florentine: And I don't know that something being CFI'd is obvious is always obvious. I think DFI is a much more obvious, thing for everybody to agree on, but… Happy to have consideration from everybody else on the call.

Maria Silva: Right, so I guess my point is just spending some time on CFI-ing things earlier has advantages for or the speed in which we move forward. So, yeah, just… If we can not delay those decisions, I think it would be good.

Ansgar Dietrichs: Okay, so then, actually, I think the obvious choice here is just… let's just go through all 5 pages, make CFI decisions first, hopefully we are done in 5 minutes or 10 minutes, and then we can just do a second pass and we talk about the actual CFI decisions. Does that make sense for everyone? I would go with that, unless there's objections. Okay, perfect, so then we already did the two obvious DFIs for this page, then we can go to the second page. This one is, EVM features, and here we have… a few, obvious candidates. I'll do them in groups, just so we have time to discuss. So, like, first, the lowest two are… they basically had absolutely zero… well, let's do the lowest four. Those two really had zero support. So, EIP,

2488, deprecate the callCode opcode. EIP8219, checked arithmetic opcodes. EIP8182, private ETH and ESC20 transfers, and EIP 7645. alias origin to sender. Those four EIPs, they all had a rating of 0.0 to 0.8, unanimous rejections by all client teams. Is there anyone on the call that would want to speak up for any of those before we make a DFI decision? Okay, then I would say it's a DFI for all four of those. Now we have, 3 more here on the page that I think we could decide to already DFI today. They are at 1.2 and 1.3. I just… let me maybe bring them up, and then we can have a temperature check, whether this is worth basically discussing more, or to make the DFI decision now.

So these are EIP7979, call and return opcodes for the EVM, then EIP 7923, linear page-based memory costing, and EIP8163, reserve the extension opcode for other EVM chains. Does anyone want to speak up to, about any of those? Jochem?

Jochem Brouwer: Yes, I want to make a general point about EVM-only EIPs. I think this is a symptom of a problem that we might have in our, yeah, I don't know… I don't know, like, how to call it, like, our ACD ecosystem, maybe. Because, so EIP7979 is an EIP from Greg. Greg has also made EIP615. he has been working for years to get these features into the EVM, and the thing is that I believe that… so I checked… I think that Gav and Metabind had an explanation why their ranking was. I think Gav and Metabind actually have the ranking at B for EIP7979. But the usual reaction is that it is not important. And the problem is that if there are things that are not important for us, which are client developers, there could be EIPs which are actually very important for the EVM.

So here is, like, a blind spot, and we should be aware of this, because something might not be imported for the protocol, but be very important for the EVM. Then specifically, because I will also put that, put that comment into the chat here. I would, like 7923 and 8163. I'm okay with this. I propose 7923, but that's… that's fine. But 7979, I… would not like to make this decision today, to also reflect on how we can make it possible to also ship EVM EIPs. Thank you.

Ansgar Dietrichs: Greg, you have your hand up?

Jochem Brouwer: You are muted, Greg, if you were talking.

Greg Colvin: There we go. Can you hear me?

Ansgar Dietrichs: Yes.

Jochem Brouwer: Yes.

Greg Colvin: Okay, thanks. Yes, I've been at this for years. As far as I know, we are the only smart contract VM that does not support calls and returns, and there's a reason for that. We're almost the only VM which does not Support calls and returns, going back… to the 70s, 60s, maybe even 40s, and there's a reason for that. It's not all that useful, for a lot of things if you're just writing an interpreter. If you're trying to do anything with the EVM code, Luke has tried to write compilers, and found out you can hardly do it at all. Anyone who's trying to prove that EVM code is correct, do almost any kind of analysis that simply requires extracting the control flow graph.

absolutely basic analysis, it goes quadratic. It's a denial-of-service vulnerability on-chain, and it's simply impractical off-chain. We need this. It's just embarrassing that it's not there. And… this works. It works. It's very simple. It's… Very little code. We've implemented it. We've tested it. We've had it ready to ship. Over and over. There's just no reason not to do this. our champions, I'm the last one left. the second… Important champion, Max, he passed. Martin, he moved on. Brooke, he's moved on. The EOF team, they've moved on. We just need to do this. It's just not that hard to do, okay?

It's just not that hard. It was proposed last time, it's like, we don't have the resources, too many other things, let's do it next time. It was one of the first PFIs on this fork. Since then, it's been buried in other PFIs, so again, we don't have the resources. Can I wait till next year? Well, it depends on how my diabetes is going. Depends on how my epilepsy is going. It depends on what else I need to do to earn a living. So, please, let's just… Do it. Thanks.

Ansgar Dietrichs: Thank you, Greg. I think, looking at chat, I see quite a bit of support for delaying the decision on this EIP then, and making sure that for next, call in two weeks, we have compiler teams present as well to discuss this in more depth with. So then my proposal would be to now basically specifically say we will not make a DFI decision on EIP7979 today, and we'll definitely also not make a CFI decision today, so basically, specifically, no decision on this EIP today. Anyone, strongly opposed and would want to make the decision today? Okay, and then regarding the other two EIPs, I put in chat as well, I personally, would just want to briefly voice support for delaying the decision as well on the extension opcode, because I think the main,

stakeholders here are other EVM chains that, might not be present today. We can make sure that they will be present in two weeks, and if there's no specific convincing arguments, then in two weeks, we can make the DFI decision, but of course, if clients feel strongly, we can also just make that decision today already. Mmm… Yes.

Ben Adams: I think.

Ansgar Dietrichs: Yeah, go ahead.

Ben Adams: I think… I think Charles is here for $7.93.

Charles Cooper: Hello?

Ansgar Dietrichs: Yes, we can hear you.

Charles Cooper: Okay, yeah, EIP7923, I've discussed it on its technical merits before, so I'm not sure how much… We want to go over that. I think it's, very important for a lot of reasons. The main one is to have a modern memory model for the EVM. The current model is obviously inadequate, because it's quadratic. There have been other proposals for, I forget the number, but, for some other linear… costing for the EVM memory, but I think that you really want virtual memory, and the reason is so that compilers can, allocate memory at any Point in the memory space. All modern languages outside of the EVM have what's called heap and stack. And that's the call stack, not the operand stack.

And the way you're able to implement that is because you're able to grow memory from both ends, because it's equally, on, like, regular computers, it's equally, costly or cheap to use memory at the beginning of the memory or at the end of the memory, and that's because we have what's called the translation look-aside buffer. Since, like, the 70s, so I think it would be… Would unlock a lot of use cases. For languages that are designing on the EVM, and for users as well. I'm happy to take any questions.

Ansgar Dietrichs: Yeah, and I think we will have this a lot, that we will start to get to EIPs that are pretty clearly leaning DFI, but maybe not as clearly, maybe, as the ones that we have already DFI'd, and where there's someone speaking up in favor, so I think in these cases, it would be really valuable if some client teams could give an indication. Either their mind is just set, this is not a priority, I saw a comment like that, for example, about the control flow EIP from Marius. Or maybe if it's like, on this EIP, we would just want to hear from stakeholder X, or we would want to see this Y to potentially change our minds, I think that would be really valuable. So, if any client has such an opinion on this memory EIP that we just heard from Charles about.

Now would be the time to voice it.

Charles Cooper: I want to also point out that the EIP has been specced in a way that is both easy to implement and doesn't require a very large change to the EVM. There's no new opcodes, there's no change to opcode semantics, it only changes the gas model.

Ben Adams: The current memory model of the EVM is kind of crazy, so… I am… I am quite supportive of this one.

Charles Cooper: Yeah, and I also want to point out another benefit of the EIP is it makes it more predictable. how much memory a transaction can use. Right now, you… there's a very strange formula you can use, but it's not very intuitive.

Ansgar Dietrichs: M… So, obviously, Ben, I think your opinion then seems to differ to some degree from your team's opinion? Otherwise, though, are there…

Łukasz Rozmej: No, it doesn't, sorry. We put it in B tier, which is nice to have, but not priority. So, that's actually exactly on our opinion, that we would like to have it, but it's not a big priority, so we don't want to compromise anything on this, but as a feature, we would like to have.

Charles Cooper: Yeah, I've gotten that, for a few forks now.

Ansgar Dietrichs: Right? I think, we have… in terms of fork scope, we will only be able to, unfortunately, include EIPs where there's, at least some clients that have it at the SLA tier. Again, I'm personally sympathetic to you here, because I actually like the EIP, but I think unless there's at least a chance that client teams will fundamentally change their minds. Is there anyone… are there any client teams who would basically like to get two extra weeks to think about the linear page-based memory costing, at least? Or do clients still lean towards making the DFI decision now?

Łukasz Rozmej: Maybe let's postpone it, maybe we can prototype it? I'm not sure if we managed to squeeze it in two weeks, but… That might be interesting.

Ansgar Dietrichs: I think the only reason, like, if NetherMind specifically is interested in basically, like, potentially changing their minds and wanting to put the resources behind it, then I think we'd be happy to delay, but I don't think just saying maybe someone prototypes it, I don't think that that seems unrealistic. So what Nethermind be interested in, basically, like. Spending the next two weeks to have a more fine-grained opinion on this?

Łukasz Rozmej: Hmm… I see ethrex is still voting for DFI, so I'm not sure if that's worth it. Or I'm trying to balance just disparities, and… Okay, probably not worth it then.

Ansgar Dietrichs: Yeah, let's… It seems like that's where it's going, Dragan?

Dragan Rakita: Maybe it's worth DFI a lot of EIPs and seeing how much space do we have at the end. Because this kind of therapies that are in between. Better to decide about them after we know what you want to include. I don't have anything against this EIP. I would change a little bit how the constants are made, how the page is increased. But it's not priority for Hegota, it's more like if you have space and time to include it at the end.

Ansgar Dietrichs: Yeah, and of course, I don't think process-wise, we should, like, default towards basically having many EIPs that, after DFI, we end up promoting to CFI after all, but if we basically end up having one or two EIPs that have a lot of progress in the weeks after DFI, and in the end, we do feel like we have room after all and want to revert the opinion, I think that that is feasible. So…

Ben Adams: I mean, maybe, maybe we can just delay the decision on these, go through DFI everything that's… DFIBL? And then come back and say, if we have too many, or… Maybe we don't. If that makes sense.

Ansgar Dietrichs: But I think this is exactly the type of EIP where we already have DFI… I mean, we have DFI from several clients, and then we have NetherMind basically saying, it could… it could be, it's not a priority for us, it could be, but we are not even… we're also not sure we want to spend the resources. So I… I think in the interest of just getting to a smaller set of EIPs, I would… say, we go ahead with DFI? But… Oh, yeah, I mean, ultimately, I just only want to aggregate opinions here, so if people prefer to delay, we can also delay. Can we have maybe one more, kind of, brief wave of comments in chat about delay versus DFI, just so we can have a rough temperature check on…

Lightclient (Matt Garnett): DFI?

Ansgar Dietrichs: Okay, I guess two DFIs and, one delay, so then… I would go with DFI, if that's okay with people, just because, in the interest of making decisions, and yes, I think the understanding can be that DFI… means that if, in the end, we have room, we can always revisit whether we want to, like, lift one or two of these DFI DIPs back into the fork, but the default is that it's not going to be in the fork. is that okay? Then… yeah. Seems like that's okay. Then we make that decision, so we have decided to delay on the other EIP, so that 7979 will be a delay. And, 7923 is a DFI. Last question then, just because I guess I spoke up in favor of delaying, 8163. Is there any client team interested in delaying, or would we want to stick with the DFI decision today?

Piotr?

Piotr: Yeah, can you hear me?

Ansgar Dietrichs: Yes.

Piotr: Hello, so I'm, sort of, would like to answer the feedback that, arrived for 8163 Reserve Extension. There were two voices that claimed that this is okay to ship in the next fork. Like, the issue with this is that, this EIP is just… it's basically a no-op, for… for the EVM. But it's, having a commitment to… There being an opcode that is reserved for extensions enables research, and it is hard to commit to a research idea or some design that requires a new opcode in an alternative EVM. Without, you know, this kind of, commitment on the Ethereum L1. So, this is, like, My answer to this feedback, and is there, any…

Anyone that would like to ex… like, speak further to the, to this idea of shipping it in the next fork?

Ansgar Dietrichs: Right, so the question is, for example, could we… we could say that the responsibility's on the champion to basically, by next call, come up with a list of L2s that say that they all would appreciate this EIP because they specifically have ideas of what they would want to do with this? And if that list is impressive enough, then clients might change their mind, otherwise not. Is that a reasonable approach here? Or do people want to DFI today?

Piotr: It is reasonable to not DFI from my point of view, and The issues, like, in two weeks, it's not… certain that there will be a committed design that uses it. It's like a chicken and egg problem. You cannot have a committed design Or, like, research that is already underway that uses it without,

Ansgar Dietrichs: Piotr, I think, just to briefly… I think we do have the delay decision in chat, so then, yes. But I do… I would just say that, it, again, the default outcome here will be that this will be DFI'd, so it's on the champion to… just get some… aggregate some signals by L2s. The signal does not have to be… this is specifically what we're planning to do with it, but it has to be… yes, we would appreciate… actively appreciate this EIP, because that would give us the room to… to explore, experiment, whatever it is, but specifically some signal that shows significant interest in this. I think that that's necessary, otherwise by two weeks from now, it will be a DFI.

Okay, so then we, have the decisions for, for, for this, category. We delayed two of the… two of the… of these in-between, candidate EIPs and rejected one. And then we can go to the next page. Next page is EVM pricing related. Of course, these are somewhat arbitrary distinctions, but I tried my best to do some topical grouping. So, on this page, we don't have any that are quite as low-rated as the others, but we have several that are basically, at least in this borderline DFI region. So, let's start with the main EVM pricing block. So out of those first 5 EIPs, we have 3 that are 1.2 or lower, so just read them out. We have EIP 8115, batch priority fees at end of block, and then we have EIP8188, last written block for accounts and slots.

And we have EIP8358, net gas metering for account changes. all of these, so I see, for example, Nethermind specifically was, actually ranked, two of them relatively high, so just maybe, on the Nethermind side, anyone want to speak up about… about these?

Łukasz Rozmej: Yup… Batch priority, fees, at the end of the block. We really like that, because after BAL, I think, one of the next problems is to optimize his builders, and this helps Building blocks in parallel a bit. And it's relatively cheap. We consider it more like a technical debt.

Ansgar Dietrichs: Right. The other teams were quite negative, I think specifically, Ethrex and Geth, relatively negative, so is there… is there anything that would change your guys' mind on this? Or are you pretty set on rejecting the CIP and the other two? Anyone from ethrex, ethrex on the call? Dragan? I mean, yeah. Not for me, sir.

Dragan Rakita: Yeah, sorry, I think this is nice EIP. It is optimization that basically reduces the ball, because there is no beneficiary change between the sections. This is still, like, optimization, the small optimization on the ball size, on the gas, on builder. It's nice EIP, but it's not critical. So, if we have space in Hegota for this kind of EIPs, I would like to Put this inside that scope. But for now, maybe to delay the decision. But yeah, depending on the other client's positions.

Ansgar Dietrichs: Right. I mean, I will again say the more we can DFI, the faster the overall scoping will be, and if we have scoping done early, we can… that gives us time to see if maybe we can open up some more room for a second round of conclusions if we want to later in the process, so I would overall lean towards making DFI decisions. Mmm… Yeah, so it still sounds like, given those ratings, so, Right. Do we… so basically, like, do people… Let's maybe start with the 1.0, they were both even somewhat worse rated, like, let EIP8188, last written blocks for counted slots, and EIP8358, and that gas metering for count changes. Is there anyone specifically that wants to speak up against DFI-ing them right now? Those two?

then I would say we just make the DFI decision for those two now. Okay? And then, for the third one, EIP8115, it does indeed seem that there's quite a bit of chatter also in chat. So this one, I don't know, like, this one I think we could delay if there's interest in keeping that conversation alive. Could be maybe, again, from the GetH side, maybe also, have someone We'll give an update of how sad you are on rejecting this one?

Marius van der Wijden: I don't really want to speak for the team, but I think it's, like, a lot of complexity in… this outer EVM layer, and it has, It has a lot of implications around… yeah. Consensus rules, and I… Just don't think it's worth it, for what it does.

Ansgar Dietrichs: Okay, anyone wants to try to convince Kathy, or otherwise, I think we would also DFI 8115? is that… just to check, because it's the first DFI decision where we have a client pretty strongly in favor, at least? Like, so, from the Nethermind side, would it be okay with you if we make the DFI decision? It does seem like you're pretty alone in your industry.

Łukasz Rozmej: Yeah, it's not a heal I would die on, so it's a very nice EIP, but it's not at something major in any way.

Ansgar Dietrichs: Okay, then I think we make the DFI decision on this one as well now, 8115 DFI, and again, if there is room in the end, we can always check if we made a premature decision on any of these, but then it's DFI. Okay. I will then, for now, not touch on the EIP above, Persist Warm Access Set, just because that's a bit higher rated, and we still have a lot to go through, so I would keep this for later call. So then let's go to ZK EVM preparation. This is the section below. There were 3 EIPs, but there's one EIP that's low enough that we can briefly discuss DFI, which is the last one. EIP 8200, 8200, EVMification.

Do we have… it's obviously right at the edge for DFI today, so do we have anyone who wants to speak up in favor of keeping that one in consideration? VIN?

Ben Adams: So this is not in favor, but I do… I think it's quite an interesting EIP, and, But there's a… there's a competition at the moment that's being run to, like. work out better EVM bytecode to replace things like Modic, XP, and so forth, so I think it's just a little bit too early. And we can see… see how those work.

Ansgar Dietrichs: Okay, Then, last call, anyone wants to speak up in favor of potentially reconsidering, otherwise it seems like it's going to DFI for this one?

Greg Colvin: It should probably go to DFI, but I think it's generally a good idea. What I didn't see there were any performance measurements, and when I tried to When I tried to EVMify the validation code for static control flow. I simply could not make it fast enough, even with absolutely heroic EVM programming. So I would… for any of these, I would want to see performance measurements, because the whole point of these precompiles is performance.

Ben Adams: So, so there is… is it ETH proofs? I'm not sure. If Kev's on the call, he can maybe give… better clarity. Somebody's running a competition where people submit formally verified EVM bytecode. And there's, it's like a nerd snipe competition, and it's getting pretty fast. It's not… I don't think it's as fast as the precompile, but it's, reasonable at the moment. So, I think it needs time to, time to brew. Yeah, so we know what that bike code is, basically.

Ansgar Dietrichs: Yeah, maybe.

Ben Adams: Okay, precompile fast.

Justin Florentine: Yeah, so we love the idea, we kind of agree with the stance that, yeah, it's not quite ready yet. One thing we did want to bring up to the whole group, though, is that what keeps us from, you know, reverting these to native implementations in the future as we're all trying to furiously optimize our clients? We just wanted to flag that as a risk.

Ansgar Dietrichs: Yeah, makes sense. Kev?

Kevaundray Wedderburn: Yeah, I was gonna say that that wouldn't be possible, since you wouldn't… you'd need to be able to calculate the gas cost for the precompile without running it.

Justin Florentine: Yeah, that makes sense. Thanks.

Ansgar Dietrichs: And… How do I pronounce this? Ivan? Ivan?

Iván | ethrex: Hey, on ethrex, we think these EIPs are interesting. If we are going to a ZKVM in the near future, it's good to have them sooner than later. I agree that we still are… we still need more numbers, but I think two big features these EIPs have is automatic replacing, so you can reduce prover vector attacks. And also, you remove some complexity for CKVM teams to remove the need for implementing precompiles to handle these specific operations that are… that they don't have on Cap's numbers, at least of the last year, any use on Ethereum.

Ansgar Dietrichs: Yeah, I will say it seemed like, overall, people were actually quite open to this, just not in Hegota, so I would still lean towards just making the DFI decision now, but it seems like we will likely revisit this for future art talks. Is that… does that work for you from the ethrex side?

Iván | ethrex: Yes, I mean, if most of the teams aren't convinced, and A week… yeah, two weeks… we can't do… we can't do anything on two weeks to convince them to change their minds. Yes, I mean… It's… it's us against the world.

Ansgar Dietrichs: Okay, yeah, then I would just say on this one specifically as well, I think the other two we can discuss at a later time, but I think this one, so EIP8200, EVMification. then I would say we DFI it for today, for Hegota. Okay, sounds good. Then, we can go to the next page. page 4 or 5, so we are getting… getting close to the end here. And this is only 5 EIPs total, 2 sections, I called it Performance Engineering, Specifically, the data repricing bundle seems to have at least moderate to solid support, so these are more CFI candidates, at least later in the discussion, but on the… in the other section, there are two EIPs that are clear DFI candidates.

One of them is EIP7862, delayed state route, and the other one is EIP8372, normalized state gas limit. I think specifically on A372, I saw some discussion. I think also Anders left a comment on the agenda relatively shortly before the call with some more explanation around the EIP. So, yeah, if anyone wants to speak up about this before we make a decision, Maria, you have your hand up?

Maria Silva: Yeah, so, I know that this is sort of uncommon, but I would really like to ask for the decision on normalized state limit, state CAS limit, so 8372, and the, CPSP recalibration, so 8368, to be delayed until Glamsterdam launches. And the main reason is that I don't think right now we will have the information needed to understand if we need any of the EIPs. Or one or the other. And so I would… ask to delay the decision on these after… until Glamsterdam ships, and we have some time to observe how demand react to EIP, 8037.

Ansgar Dietrichs: Yeah, and before… Anders is here, if you end up as well, but before… before that, I want to just briefly myself say, in terms of process, I personally would recommend we make a decision still, and then at least consider making two CFI decisions. I mean, of course, one of those EIPs, I guess, needs a lot of client convincing to go to CFI, but if we were to get there, we could do two CFI decisions. And then potentially reject one or both of those at a later stage, just so that we signal that they are taking up the space in the fork. I think it's very dangerous to basically keep the fork perceptionally light, but have basically things pending.

Especially because we were speaking about potentially making the decision quite a few weeks later, I guess actually months after the main decision, so I would say I personally would prefer making the CFI decision if we had that intention. Anders?

Anders Elowsson: Yeah, exactly. So, I think that we should CFI both now, and then we will observe how these demand elasticities actually work when we do Glamsterdam and fork, and then we can see if we need to do this rebalancing or not.

Ansgar Dietrichs: Okay, so I will say, because… so, 8368, so the static CPSB recalibration does have a lot of support, so this one will likely be a CFI anyway. The other one, though, 8372, seems to be very strongly disliked by clients, so I think this is something we need to address now. Like, can we maybe get from some clients an explanation for why there's the big difference between those two EIPs? And what… what would it take to keep you open-minded about potentially having that second EIP as well, in, like, potential CFI state, basically? Or should we DFI it today?

Anders Elowsson: Can I just, mention that, so essentially… what I will say is that it's not necessarily that we want to do 8372. It's not that we want to complicate things. just… just because we like to make things complicated. It's just that we would… need to have a separation of these two variables in the case that we are not balanced in Glamsterdam. I don't think people maybe don't understand that we may end up in a situation where state and execution are not balanced, and that we are not sort of hitting the targets that we want. And so it's not that we want to do 8372, but that we maybe need to do it if we want to achieve these targets.

Maria Silva: And I would also add, in terms of complexity, I think it looks more complex than it actually is, so… like, both EIPs are just doing a one-time recalibration of a variable. It's just the way that 8372 does it seems a bit more complicated, but it's just… the formula is a bit more complicated, but the actual impact or implementation detail is… it's… we are essentially doing the same thing. We're just recalibrating, cost per seed by, so, I mean, it changes two variables instead of one, but it's not… I don't think it's… much more complicated.

Ansgar Dietrichs: Makes sense. Toni?

Toni Wahrstätter: Yeah, just wanted to add the same that Maria just said. It's very… it's a very simple change, and to meet fees, like, both EIPs are EIPs that usually pop up when we are already launching DevNets, and then we have to, CFI them late in the process. Like, very small changes that need some empirical data to be understood. So my feeling is we should just CF, CFI them, include them at a very late definite. and see how Glamsterdam goes.

Ansgar Dietrichs: Makes sense. Okay, I mean, I do see some, Elson chat, some, willingness to potentially reconsider 8372. Again, it was just one of the lowest ranked EIPs of all EIPs, so… So, yeah, I think then my request would maybe be to at least not make a DFI decision on this one today, so that we can then discuss it together with the other one. and then decide, about, about, potentially DFI or CFI. Is that… does it work for clients? It seems like… seems like it, Marius.

Marius van der Wijden: Yeah, I think for us, it was, it was clear we have to, like, choose one of the two, and we chose the one that is In our opinion, simpler, but without… having seen how Glamsterdam plays out, so… Ideally, we would just have both. But, I think in the process, it's quite clear we have to make a decision between those two, and, We have to make that decision now. without sufficient information, and we chose… and I think all of the client teams chose the simpler one, or the simpler worded one. And, yeah, I agree with that we should just give it more time.

Ansgar Dietrichs: Makes sense. Dragan?

Dragan Rakita: Yeah, similar notion from… from Rad here. We chose the simpler one because, depending on how the glamp system is going to behave, we probably will have some Recalibration of the gas values, gas limits, and everything around that. Maybe we want to push the blob gas limit a lot higher, then we need to, like, change the gas state. For those all opcodes. So, yeah, I think the… one of those should be included. It still depends on the future outcomes of the chain. If there is a bigger need for normalizing state gas limit, then we should include it, but I think for now, the 8368 is good enough.

Ansgar Dietrichs: Okay, sounds good. So then, we will not make a DFI decision on 8372 for now, and then as we discuss 8368, we can just discuss what the best process here is, whether we CFI both, or whether we choose one for now, or whether they should be unified into one EIP. But for now, in terms of the immediate DFI, we will not… DFI 8372. I have not heard anything about the other one, 7862 delayed state route, so this one would still be a DFI candidate for now. I do see Besu as the only client with a positive ranking. Anyone from Besu wanted to speak up about delayed state route?

Karim Taam: Yeah, I can say something, it was more regarding performance.

Justin Florentine: Karim, you're really faint, you can pull your mic in?

Karim Taam: Is it better?

Justin Florentine: Yep.

Karim Taam: Okay. Now, I said it's more regarding performance, because today, state root is taking a lot of time when we are executing a block. And with this proposition, we can use a window between two blocks, where we are doing nothing, to compute the state route, Because it will be the state root of the previous block, so we'll have this window to do that, and like that, we can remove the state root from the hot pass. So, yeah. But if other clients don't think it's, It's a good optimization for this work. I will not fight.

Ansgar Dietrichs: Good. Oh, yeah, go ahead, Lukasz.

Łukasz Rozmej: do have a quick against. So, for us, state fruit isn't really that big of a problem most of the times, and post-val, you can do it in parallel, which is… even less, so, unless there are metrics possible that really show that this is a problem, I would DFI and consider only if we have considerable proofs that it's still a big deal. And this also has some, you know, repercussions for broader ecosystem, which I would like to avoid for now.

Karim Taam: I just want to add also, today we are working on binary tree, so we'll have more intermediate node. maybe more I.O. for the state route, so maybe the impact will be better, bigger. So, yeah, it's something also we should, measure. Yeah, maybe not for this fork, maybe we need to have more information before… trying to implement it, I don't know. But, yeah.

Ansgar Dietrichs: Okay, so then it does sound like the decision for today would be to… DFI it with the understanding that, A, we might revisit this at a later fork, potentially in combination with binary trees. And also that there is a chance that if Glamsterdam shows, basically, that there's an unexpected load there, that could be addressed with this EIP, that we might still reconsider our decision, but that the default here is a DFI decision. Does that work for everyone? Anyone who wants to object to that?

Justin Florentine: Sounds good.

Ansgar Dietrichs: Okay, so then we are DFI-ing EIP7862, delayed state route. Okay, then I think we are ready for the last page. So 6 more EIPs, miscellaneous. Mmm… there, I think we have several, DFI candidates, starting with the first section, Execution data and indexing. So, maybe take them one by one, because they're both relatively big features, so EIP7807. SSZ execution blocks, we have relatively unanimous client rejection, but we do have ethrex with a positive rating, so maybe starting by having ethrex, Briefly give context to their position?

Iván | ethrex: We think it's a good idea. We also think that maybe, we can hear from other clients to see why they don't like it. You know, I'm okay with not having it in the fork, if that's the… general decision. But would like to hear, bye.

Ansgar Dietrichs: Yeah, any other clients that would want to briefly comment on their take on SSZ execution blocks and why they are opposed? Well, I mean, I guess there's some gradations to the client votes, but… Or at least why they have a critical rating?

Marius van der Wijden: Specific.

Ansgar Dietrichs: Typically from the worst, like, the teams with the worst ratings, Geth and ethrex.

Marius van der Wijden: Yes, I can, I can, I can go… I think it's… for me personally, it's a similar, sim… similar rationale. then… that I brought forward, with another… with a few of the other changes. The impact… is very low for users, or, like, the ben… sorry, the benefit is very low for users, but the impact is very high. So, basically, everything that has to… Read headers and blocks has to change. And then, afterwards, it doesn't have to change anymore. So, I… I agree that, in theory, it's a great change, that we have… we change it once, and then we don't have to have users change, the Outer structure ever again. But, I, yeah, don't see the benefits, and the blast radius, as Lukash is saying in the chat, is just crazy. Like, we would need multiple months to figure out

What are all the things that are breaking because of this?

Iván | ethrex: Yeah, makes, makes sense, makes all you're saying makes sense.

Ansgar Dietrichs: And Dragan.

Dragan Rakita: Yeah, just to add to that, current API is not broken, it works. When it becomes broken, when we need to change something, then we can re-evaluate, re-evaluate as you see. For now, it works, and it's fine, it's not bottleneck, it's worked as intended. That was, yeah, reasoning.

Ansgar Dietrichs: Okay, so then, looking at all the client opinions, it seems like we can make the DFI decision today. Anyone who wants to object? Okay, so we are DFI-ing EIP7807 as the Execution blocks for Hegota. And then the other one from this section that we can at least briefly see, if we have enough of a unified opinion for a DFI decision today, is EIP8304, Trustless Log and Transaction Index. They are specifically GetH is the one client that has a positive rating, so would be good to hear from the GetH team about their take on the EIP. Zsolt?

Zsolt Felföldi: Well… I… it's my EIP, so I'm, yeah, going to speak for myself, but, So the thing is, so far, from what I gathered from other people, is that some people see this as important, and some people don't. Those who care about it, generally, from those people, I generally have positive feedback, probably… others just don't see it as very urgent, but this is a kind of thing that will never be super urgent, so it's, like, hard to compare to others a bit, because it's never super urgent, but over the long term, I think Ethereum will be way better if we have this, not just because of the provable RPC, but also because on-chain provability, now it's… yeah, there's now a design for native UTXOs that could use it. Also, L2 chain communication could use it. So, I think this is, this is something that's valuable, and there's never a

perfect time to include it, and I don't expect, like, like, Future Force to be less crowded, so… Yeah, I still think that… I never heard any argument against it, why it should really be, like, deified, but Yeah, I would like to not have the DFI right now, but maybe discuss it a bit further, yeah, so that's…

Ansgar Dietrichs: Thank you. Yeah, so basically then the question would be for the clients that, have had more negative opinions, specifically the clients, of course, with the lowest tier, that's Besu and ethrex. what are your takes on this EIP, and in particular, basically, like, how… how much would it take for you to change your opinion specifically for Hegota? So basically, how… how… how worth… how much value is there in delaying the decision to potentially give the gas team, give the Zsolt time to convince you to change your mind. Do we have anyone from those two teams that could take on… speak on their… their take on the EIP?

Justin Florentine: Sure, Besu is pretty… I don't want to say intractable, but, really, it comes down to the amount of work, amount of gain, and where else it's going to fit in here. We don't really see that appreciating or moving in a direction that's going to change our mind.

Ansgar Dietrichs: And, from the rats side.

Dragan Rakita: Yeah, I didn't see a lot of value in this. In general, it seems a lot of work to add the… the long… log indexes and everything around that. So, yeah, I'm not sure.

Ansgar Dietrichs: Yeah, so I'm just trying to see, regarding the decision today, I mean, without any value detriment, it just feels like… you know, as long as there's no path to potentially convincing the clients, that would then make it a kind of still DFI today. I think right now it sounded like the Besu opinion was stronger than the Wrath opinion. I don't know if Zolt or anyone from the GetH team. Is there maybe something… some immediate on-the-spot attempt you might want to make to convince Besu to at least give it one more decision cycle, or otherwise, I think we would… if Besu has no path towards changing their minds, then it would still justify DFI today.

Lightclient (Matt Garnett): Yeah, I mean, I think… maybe this thread that's going in in chat, I can just say it aloud, I think that… the SSZ-ification of the EL, to me, is… Not really… like, drastically changing what's possible. I think it makes a lot of things nicer. In terms of, like, interacting with the chain trustlessly, but in general, like, a lot of… all this stuff can be done with RLP. Whereas with the Trustless Log Index, this allows RPC providers to give proofs about range queries over, like, certain events. In a way that, like, we can't… prove today. So, in that sense, like, it's providing trustless interaction to users who cannot you know, achieve that today. Whereas with the block data.

In the transaction data, we can generally, like, prove this with ROP. Is it as elegant as SSZ? It's not. But we can do it.

Ansgar Dietrichs: Dragan?

Dragan Rakita: Yeah, it does, it does allow, like, proofs on the receipts, but it's like, What users are going to use this? if there is some companies, or basically bigger users, bigger… somebody that interacts with Ethereum and says, hey, we would really benefit by this. This would, I think, change our minds.

Lightclient (Matt Garnett): I mean, I think this is, like, the same argument that was made for FOCIL. You know, ideally, no one uses FOCIL, and in general, I don't think that… when FOCIL was chosen as headliner, the… A lot of people were saying, like, we need to be using this on a regular basis. And I think people chose it because they felt that censorship resistance is a core property of Ethereum, and it needs to be offered, and we need to make sure that it continues to be offered. And I feel that, you know, using the chain trustlessly is the same thing. So, even if we don't have tons of people banging down our door to use the chain in a trustless manner, that doesn't mean that we should

Not to be building the functionality necessary to provide a trustless experience to users.

Dragan Rakita: If this is the case, then I would lean on DFI it for Hegota, and maybe including one of the next forks, when this becomes a bigger problem.

Ansgar Dietrichs: Right. M… Yeah, again, I think… I think, just given that, in the end, we will reject the EIP unless all clients withdraw their veto. So, given that right now we have two clients on a DFI, I think at least we would need to see a path for how this would change for this artwork. Right now, I don't really see a path for this. if there's willingness for people to somehow sit down, engage with each other, and there's a potential chance that this will change people's minds, I'm very happy to not make a DFI decision today, but otherwise, I just… I would just… go with DFI. Mmm… Yeah, so basically, yeah, is there… is there someone who would want to, yeah, either basically have a concrete plan for how this can change over the next two weeks, or otherwise thinks that DFI-ing is inappropriate, given the current circumstances? Zsolt?

Zsolt Felföldi: Yeah, I just, wanted to add… so, so I, if I understood correctly, like, Besu's main concerns were, like, like, complexity, and whether it's valuable enough, and honestly, yeah, I mean, last time, for when I proposed 7745 for Glamsterdam, I kind of had the impression that, some people from Besu saw the value in that proposal, and so honestly, I'm not sure if, if you guys have, like, looked into, like, the state of this EIP now, but, I mean, it's, like, basically better in every possible aspect than that proposal, and also, it's in a much better state, because right now, all the, like, we have a proof-of-concept implementation that, that actually proves the achievable performance and everything, so I think

it is, proven that it's viable. I think that also kind of proves that it could give value. Well, I mean, what's valuable to who is relative, but I think, I think, it opens up a lot of paths. So, yeah, I'm… I'm just, I honestly don't really understand why, you have this very high stance on this, but yeah, I mean, I just wanted to say that this is way, way better state than the previous one, and yeah. Maybe.

Justin Florentine: So, I'll tell you what, I made a case earlier that 1.3 should be the floor. this is at 1.3, I think we can accommodate a delay. We're seeing a lot of people make points for a delay here in chat. We did look at the current state of the EIP, you know, we did recognize that it has changed. I think the thing that we would like to see as far as making a case is the fact that this can be done in a trusted fashion today, off-chain. And why that's insufficient. I understand the general arguments around trustlessness, you guys know me, you know that they resonate very strong with me. So, tell… tell our team why

It should happen now, I think. Would be the big thing. And, we could accept a delay decision today instead of a DFI.

Ansgar Dietrichs: Okay, so I will say then, blob, I think if we delay, that would have to come with a… clear commitment also from the Besu side to engage in this discussion. I mean, it sounds like that that would be the case, and then also from the, you know. from the RAT side to be open for some more conversation, because That's… those are the two blockers right now. Yeah, so then… I would be okay with… Making a delay decision here, just checking from the red side, would you be okay with delaying?

Dragan Rakita: Sure. I'd like to hear from other clients, too, just to see if they maybe You have not in any direction?

Łukasz Rozmej: So, we gave it B, so we are fine with including it if it has, other support, we are not blocking it in any way. We have external P… contributor PR with a prototype. In terms of, what do I think, or what do you think, it's nice to have, and, especially with other combination of pure ref, it would be… Very good. On itself, it moves just a needle in the log space, so it's not such as impactful, but we're fine, we just didn't find it as a priority for Hegota, so this is based more on priorities rather than on anything else, but we are fine with it.

Ansgar Dietrichs: Okay, so then, I think just in the interest of time, we can make a delay decision on this one today. So EIP8304, trustless login and Transaction Index, will not be DFI'd today, we will delay that decision. For two weeks from now. Just, though, for expectations, it's still a clear default DFI right now, given the client views. If that changes, over the next two weeks, then, we can have that discussion. So no decision on it today. Then, going to the last EIP to discuss, so we have the networking section, there's two EIPs, but the one that would be a candidate for DFI is EIP8094, ETH VHash. blob-aware mempool. Do we have someone else, Shabba, I saw you immediately raising your hand. Is that specifically to this EIP, or in general, to the section, or something else?

Csaba Kiraly: No specific for this EIP. So, because I'm D'Author, I was already anticipating that it's, it's, it's something that, was proposed first together with, sparse blob pool, and then we… we lulled, actually, many of the features into sparse blob pool, so… in its current state, the delta, which is, I think, is, is not that much, so I think, you know, I'm… I agree with the Zsa.8 in the sense of DFI it for now, so… We don't have to spend too much time.

Ansgar Dietrichs: Okay, any clients that would basically, like, still be interested in having more time to think about this, exploring this more? Or should we otherwise stick with the DFI? Yeah, if there's no comments, then I think, Chabotzo, if that's okay with you, you also still have your hand up, by the way. Then I think I will, yeah, we just go ahead and make the DFI decision, just because there was no… No client, wanting to reconsider. Mmm… Okay, then it is 3 minutes until the end of the call. I think it makes no sense to start any CFI decisions now, just because that would require a discussion as well. We don't really have the time. I think we went through quite a few DFIs, though, at least that's good. Then maybe just briefly for expectation setting, for 2 weeks from now.

Two weeks from now, we will then make a pass for the clear candidates for CFI, see how many of those we can CFI, make another pass for the DFI candidates that we have delayed today. Those also were… ended up being quite a few, and if we then have time, let's see, we might not have time for this, but if we have time, we can then also start to go into the discussion of these in-between EIPs that might be the most on the edge of going either way. I think we're making decent progress, hope we can continue this. Any last comments? Justin, you have Yannabe.

Justin Florentine: Yes, first of all, thank you. Great work, everybody. We really, really covered a lot of ground and made some good decisions. What can we do to roll into this meeting you just described, ready to rock and roll? Like, what kind of async work can we do that we can bring in instead of just staring at the same list minus DFIs?

Ansgar Dietrichs: Yeah, that's a great, great prompt. So, actually, what I would then ask is that, A, all of the EIPs that we delayed this, this call around, like, the idea is that basically either people have formed new opinions on this, have iterated on this by two weeks from now, otherwise we will just DFI anything that has not made progress, so that needs to be clear. And the other one is. if people could specifically look at the EIPs with the highest rankings. So, like, you just go through the list, on forecast, I'm just looking right now, if we don't group by category, there's, like, 1, 2, 3, 4, 5, 6, 7, 8 EIPs at 2.5 or higher. At their minimum, everyone should be very up-to-date, especially if you are one of the clients that specifically has not rated these EIPs highly. You should come to the call prepared to explain exactly what your concerns are, and have a clearly pre…

Agreed position as a team on, like, what would change your mind, how hard is your no, or, like, how hard are your concerns on this? I think those 8, they happen to have no team at DFI, so it should not be a clear block for anyone, but basically, so that we are in a position to make decisions on all 8 of those, ideally. Is that a reasonable expectation to set? I mean, I guess I will just set it. So, that's the expectation.

Justin Florentine: Can you post that on the next meeting agenda?

Ansgar Dietrichs: Sounds good? I will do that. Maria, last comment?

Maria Silva: So… I think for the Epps that have high support. And some clients don't feel… are not so sure about them. I think it would be nice if they could raise the issues async before the call. Instead of bring… because then the champions can do something to address that. If we only raise them during the call, then it will be a delay, and we need to do another call to then have the final decision. So if… if… if they already have those, opinions, which I think they do, because they created the tier list, then it would be nice to just Go through them async, and then we can more prepare on the next call.

Ansgar Dietrichs: Yeah, that's even better. So then, ideally, I would ask, we have two weeks until the next call, so if… over the first weeks, until next ACDC, basically, if clients could already look into and async kind of raise their concerns, so that we then have the second week to… To discuss these, so that we ideally come into next call already with active discussions, and ideally even updated positions at any moment, you can always let Forecast know about updated positions, and we can reflect that in the rating. So that ideally, we already have minimized the gap on these EIPs coming into next call. Thank you, Maria, that's a good proposal. Okay, then that's all for today. Thank you very much, everyone. I think this was great. A few more calls to go, but I think we are on track to be ready with scoping before Devcon, which I think would be amazing.

Awesome. Thanks, everyone, and see you all in two weeks.

Marius van der Wijden: What?

Justin Florentine: Thanks, Nixo. Thanks, Ansgar.

Jochem Brouwer: Thank you. Bye-bye.

Potuz: Bye-bye.

Kevaundray Wedderburn: Right.

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