Execution Layer Meeting 245 [2026-09-10] | ACDE 245

Akash Kshirsagar: Hello everyone, welcome to Alcodevs245. Today is going to be mostly about Dakota scoping, but before we get to that, briefly Klamstertam. So in particular, my understanding is that there was a topic on ACDT this week regarding EAP 8253. which is this proposal to bump the nonce of zero nonce storage accounts. And there's some consideration to potentially even still last minute, add this to the GlamSaturn 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? Yes, I can give the context. So, ERP8253. We'll replace EAP 7610. I see Tony with hand. So we are like very late into this process. What I want to say here is that at HDT, we, well, I brought up this idea to add this to Glemson. The reason for this is that this EAP is a mainnet only fork. That means that for Houdi and Sapolia, this fork is a no-op because he only changed these 28 accounts. I just want to consider the possibility that we can We can add this EAP to Glamsteadam. 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 Glamsteadam, then that's fine. Then we will do it in Haggota as it is scheduled. But then I want to immediately bring up the point, let's then immediately CFI it because this EAP has replaced EAP 7610, which has been as a fight for Glamsteadam. And I think we should then immediately, well, maybe not even CFI, immediately SFI this ERP in Haggota. Yeah, that's the context. And Tony? Yeah, most clients were against doing that in Glamstertam on ACDT on Monday. I think it's just too late to include an ERP 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 want to do this EAP, then the proper way would be to spin up a new DEF net that actually can do this transition. The main issue I voiced on Monday was that it interacts with BALS. We would suddenly have to also bump those accounts in the BlockLiveAccess list and we would still have to do that in Hegotar, but we just have more time to prepare everything and BAL is shipped at that point. So to me, it feels like a clear candidate for Hegotar, but I would. recommend against putting it into Glamsteadam. Makes sense. Yes, my default take would of course be that at this stage in the fork to still add something to Glamsteadam would require some exceptional circumstances. So just to double check Jochem from your point of view, is there anything very urgently security critical about doing this in Glamsteadam already or would you also be fine with doing it in Iguota? Yes, Iguota is fine. I just wanted for the process itself, like bring this up. Because this would also be, I would also regret not bringing it up and then thinking, okay, we could actually have shipped this in Glamsterdam. But this is like totally fine. It's not a security problem. So Agota is great. But yeah, that's an SFI. Then we can end this discussion and that's great. That's good. And then that last thing just to confirm that would mean that the 7.6.10 would stay in Glamsterdam unchanged. Is that correct understanding? No, this 7.6.10 is to be moved from Glamsterdam. It has been deified. I know it has been as SFI'd, this ERP 7610, but they found some problems and then it was actually deified. Yeah. Sorry, my bad. Yes. Okay. Makes sense. Makes sense. Thank you for clarifying. Okay. So can we then also just for clarity, then formalize the SFI in A253? For Hegotah, would wait to just agile VR in the Hegotah decision block for today. I don't think there's any need to specifically fast write the decision, right? Okay. Perfect. Yeah, I just, I just note that this is the case because it probably hasn't. I'm not sure if it was in the list of go to items. I think it is. Which one is the API number again? It's two five three. Okay. is. is. is. Yeah. And that's one of the highest client rate rankings on average. So it's a pretty likely candidate anyway. Okay. Perfect. Then the decision is to not last minute at this to Amsterdam. Then just quick question on Glam-Sedam. Are there any other topics for today? Anything devnet related or testnet related or anything we should discuss on the call here? OK. Then we can move on to the next agenda point, which is the Hegotablock. First up there, just a brief mention is CL-side EAP that might still be PFI'd. Kamil, you wanted to briefly mention this? Yeah. Thanks, Hans-Gard. Hello, everyone. Just a quick heads up with regards to Fast Payload Broadcast EAP, which we submitted last week. We'd like to ask STP permission to p5 this EAP post deadline instead of blocks and lobs EAP. A new EAP is cleaner and more focused on the fast payload propagation, which we think is important in the context of higher gas limits and potentially quicker slots. So this is CL change and apparently decision should be made on the ACDC call and we will ask for decision next week. Yeah, meanwhile, maybe leave below some links to the EAP and relevant discord discussions and some other discussions which we had, for example, yesterday on P2P call. Yeah, that's it. Thanks everyone. 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 Hegoda decisions for today. The first one is briefly frames, transitions. 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 headliner, basically like a retroactively nominated headliner for the fork or just anomaly IP with basically already in SFI status. I think my feeling was that the clients were 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 Egota. My understanding is that there's also still active work on iterating on the specs. the exact spec might still change, but frame transactions will be a headliner for Egota. Perfect. Congratulations. And then we can move on to the main scoping block for today. Before we go into all the EAPs 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 EAPs. that specifically are not on the list, just to double check that there's no confusion about any of the statuses there. I posted 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 to anyone, then now would be your time. So obviously, frame transactions will no longer be discussed as a decision because it's already SFI. There is the foundations of EVM control flow, which is in itself just a meta-EAP. There is a sibling EAP, which we will discuss, but this meta-EAP will not in itself be discussed for scoping. Then there is two EAPs 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 side cars, EAP 8146, and the other one is the independent CLEL sync. which is EAP 8237. So those two are still in consideration for the fork, but will be discussed and decided on the ACDC side. Then we have six EAPs that are withdrawn or basically either were withdrawn by the proposer or just ended up being auto-DFI because they have no champion. I'll not go through all six of them, but there's a list. And then one last one that I want to briefly call out is one where their status is still open, think there might have been some confusion around the exact situation of the ERP, which is ERP 8360, the TCreate opcode, which was basically the idea of having ⁓ a way to ⁓ create a temporary contract just for the scope of a transaction. The discussion there last, Orkodex, was to basically keep this topic open because there was some concern still around the the changes in Gramsadam 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, the priority list, lists that all the clients published. we will not discuss it today and we will make sure that by two weeks from now on all CODEFs there's clarity around whether this is still in contention in any form to make sure that CODEFs have everything they need to make a decision on this one. And does it all sound right? there any confusion or any contention around any of the EAPs I just mentioned? Maria, you have your hand up. Yeah, I just want to add a comment on Tcreate. my understanding is that it should be CFified. So it was my understanding from the last ECD 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 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 don't see why it needs like a... different status, but maybe I can reach out. We should reach out to them just to come. I Milos is here. Yeah, it's Milos. Helkemi will not be able to join this course. As far as I understood, he doesn't speak English. But yeah, I can champion for this EAP. If there is any delay, I will still be promoting the gastro-refills, but this is another topic. About the creator, I agree that should be included. OK, then what we will do is we will async, just clarify the status of whether it's also this specific AP or 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 default forecast list that everyone ⁓ made their initial rankings on. Sounds good. Any other comments to these EIPs? not 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 T-Create next week. So on what next call? then that's 38 EAPs for today. It's 37 EAPs. That's a lot again. It's I think a little bit less actually than in 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 for us to go through the forecast list. Anybody wants to follow along? I'll share the link in the chat here. Maybe I'll actually, let me share this link, which is already the one that specifically has the view. Okay. So we created this little presentation mode just to have the EAPs grouped more publicly. So we can go through them section by section. can see here, so we have five pages total, five pages with groupings for the EAPs, 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. My proposal would be the following for process. I would say for each of the five pages, we briefly go through the piece that belongs to the category. have, would, unless this is too verbose for people, but I would briefly call on each client to just give their 30 second take on basically like. their opinions as they also displayed in the rankings, and then would see if we have already enough of a clear opinion to make some decisions. So for example, on this page, you can already see that the code control UA delegation is a clear candidate for DFI, so a set delegate so that we basically can start making decisions here. yeah, like I said, I see the message that maybe this is unnecessary. We can also immediately, like 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, yeah, go ahead. mean, we could, are there some obvious ones that we can defy and accept and then, and then we can do the more either or ones as giving opinions. Yeah. So for the like more that have some kind of majority AIPs, would focus on the minority voices and discussion quick. like discussion like that. So for example, here for 7906, example, Nevermind and Rev have kind of our outliers compared to the rest, right? So yeah, that's how I would focus. Yeah, that actually seems reasonable. And there are some EAPs that you have to have more broader discussion. Sounds good. So basically, just to give a rough feeling, think basically anything below 1 in this Algrid 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 EAPs would be the two candidates and they are more on the other pages. Anything between one and 2.5 is basically EAPs 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 EAPs. This page is not representative because Frame Transactions 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 indication. But of course, in the end, every decision individually will be up to discussion and codefs. So then I would start by just basically asking whether there's anyone who wants to speak up in support of either set delegate, VIP, or the code controlled UA delegation, because those two would otherwise be the first DFI decisions here on this page. Tony, you say the screen share is the wrong page. I'm a little confused. Can you say what you're seeing? Yeah, I'm looking at an account obstruction EAPs. Is that what we... ⁓ OK. I thought we were supposed to see all the EAPs that would now do like DFI decisions. Yes, we're just doing it's five pages just so that you don't have to stay at 37 EAPs at once. We're five pages that are grouped topically. I see. Perfect. And on each topic, it's then within the categories. You can always see, for example, the first group of three at the top, they are ordered. Okay, Johan, do you want to speak up to one of the two EIPs? 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. 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 EOA 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 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 discussion for this as well? Or do we want to first just go through the all five and do DFI? And Maria? This isn't just an opinion, but I feel like we should do the CFIing because then we can already start working on those things. If we just do the DFIing, 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. Sounds good. So then the idea would be, let's do the clear CFIs today. Let's do the clear DFIs today. then we have, for next call, we have other one-on-ones decisions. And we already know how much scope we will have left to fill. Can make a counterpoint here real quick? DFI is a decision. And I don't know that something being CFI 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. Right. So I guess my point is just spending some time on CFI 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. OK, so then actually I think the obvious choice is just to through all five pages, make DFI decisions first. Hopefully we are done in five 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. OK, perfect. So then we already did the two obvious DFIs for this page. Then we can go to the second page. This one is EDM features. And here we have a few obvious candidates. I'll do them in groups, so we have time to discuss. first, the lowest two, ⁓ they basically had absolutely zero. Let's do the lowest four. Those two really had zero support. So EAP 2488, deprecate the call code opcode. EAP 8219, check arithmetic opcodes. EAP 8182. private ETH and ESC20 transfers and EAP 7645 alias origin to sender. Those four EAPs, they all had a rating of 0.0 to 0.8 and 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 three more here on the page that I think We could decide to ready DFI today. They are at 1.2 and 1.3. 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 EIPs 7979, call and return opcodes for the EVM. Then EIP 792-3, linear page based memory costing and EIP 8163, reserve the extension opcode for other EVM chains. Does anyone want to speak up to about any of those? Jochem? Yes, I want to make a general point about EVM only ERPs. I think this is a symptom of a problem that we might have in our... Yeah, I don't know. I don't know how to call it. Like our ACD ecosystem maybe. Because so ERP 7979 is an ERP from Greg. Greg has also made ERP 615. He has been... working for years to get these features into the EVM. And the thing is that I believe that, so I checked, think that the Gaff and Netabind had an explanation by their ranking was, I think Gaff and Netabind actually have the ranking as BG4 EAP 7979. 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 EAPs 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. And then specifically, because I will also put that collapse comment into the chat here. I would ⁓ like 7923 and 8163. I'm okay with this. I propose 7923, but 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 EAPs. Thank you. Greg, you have your hand up. You are muted, Greg, if you are talking. There we go. Can you hear me? Yes, can. 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, Lucas 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. 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 EIP 7979 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 what 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 of code, 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, we could make the DFI decision. But of course, if clients feel strongly, we can also just make the decision today already. I Yeah, go ahead. I think, I think Charles is here for 793. Hello? Yes, we can hear you. Okay. Yeah. IP 7923. 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 end of the memory. And that's because we have what's called the translation look-aside buffer since like the seventies. 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. Yeah. And I think we will have this a lot that we will start to get to your piece that are pretty clearly leaning DFI. ⁓ but maybe not as clearly, maybe as the ones that we've already DFIed 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 EAP from Marius. Or maybe if it's like, ⁓ on this EAP, 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. if any client has such an opinion on this memory EAP that we just heard from Charles about, now would be the time to voice it. 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. The current memory model of the ⁓ EVM is kind of crazy. So I am quite supportive of this one. Yeah. 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, there's a very strange formula you can use, but it's not very intuitive. So obviously, Ben, I think your opinion then seems to differ to some degree from your team opinion. Otherwise, though, are there... No, doesn't, sorry. We put it in B tier, which is nice to have, but not priority. that's actually exactly on our opinion. We would like to have it, but it's not a big... So we don't want to compromise anything on this, but as a feature, we would like to have it. Yeah, I've gotten that for a few forks now. I think we have, in terms of forks scope, we will only be able to unfortunately include EAPs where there's at least some clients that have it at S or A tier. Again, I'm personally sympathetic to you here because I actually like the EAP, 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 that 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? Maybe we can prototype it. I'm not sure if we'll manage to squeeze it into weeks, but that might be interesting. 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 seems unrealistic. So would NetherMind be interested in basically like spending the next two weeks to have a more fine-grained opinion on this? I see Atheros is still voting for DFI, so I'm not sure if that's worth it. Or I'm trying to balance just its priorities and okay, probably not worth it then. Yeah, that seems like that's where it's going. Dragun? Maybe it's worth deifying a lot of AIPs and seeing how much space do we have at the end. Because these kinds of AIPs that are in between, better to decide about them after we know what we want to include. I don't have anything against this AIP. I would change a little bit how the constants are made, how the page is increased. but it's not priority for Higota. It's more like if you have space and time to include it to the end. Yeah. And of course, don't think process-wise we should default towards basically having many EAPs that after DFI we end up promoting to CFI after all. if we basically end up having one or two EAPs 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... I mean, maybe we can just... delay the decision on these, go through DFI, everything that's defiable, and then come back and say if we have too many or maybe we don't, if that makes sense. But I think this is exactly the type of EAP where we already have DFI. I mean, we have DFI from several clients and then we have an element basically saying, 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. I think in the interest of just Getting to a smaller set of EAPs, would say we go ahead with DFI. yeah, 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? Okay. I guess two DFI's and one delay. 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 we're in the NPF 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 OK. Then we make that decision. So we have decided to delay on the other EAP. So that's 7979 will be a delay, and 7923 is a DFI. Last question then, just because I 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? Can you hear me? Yes. Hello. So I would like to answer the feedback that arrived for 8.163 reserved extension. There were two voices that claimed that this is okay to ship in the next fork. The issue with this is that this EAP is just, it's basically a no-op for the EDM, 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 area without this kind of commitment on the Ethereum L1. So this is my answer to this feedback. is there anyone that would like to speak further to this idea of shipping it in the next port? Right. So the question is, for example, could we, we could say that the responsibilities on the champion to basically buy next call come up with a list of, of L2s that say that they all would appreciate the CIP 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 what people want to do? It is reasonable to not identify it from my point of view. And the issues like in two weeks. It's certain that there will be a committed design that uses it. It's like a chicken and an egg problem. You cannot have a committed design or like research does is already underway that uses it without. I think just to briefly, I think we do have the delay decision in chat. 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. We get 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 actively appreciate this ERP because that would give us the room to explore, experiment, whatever it is, but specifically some signal that shows significant interest in this. think that that is necessary. Otherwise, by two weeks from now, it will be a DFI. Okay. So then we have the decisions for this category. We delayed two of these. between candidate EAPs 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. 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 five EAPs, we have three that are 1.2 or lower. So just to read them out, have EAP 8.1.1.5, batch priority fees at end of block. And then we have EAP 8.1.8.8, last written block for accounts and slots. And we have EAP 8.3.5.8, net gas metering for account changes. All of these. I see, for example, Nethermine specifically was actually ranked two of them relatively high. So does maybe on the Nethermine side, anyone want to speak up about these? Batch priority fees at the end of the block. We really like that because after Baus, think one of the next problems is to optimize builders and this helps building blocks in parallel a bit. And it's relatively cheap. We consider it more like a technical debt. Right. The other teams were quite negative, think specifically EtherX and Geth were relatively negative. is there anything that would change your guys' mind on this? Are you pretty set on rejecting the CAP and the other two? Anyone from EtherX? EtherX, the car? Dragon? I mean, yeah. Not from EtherX. Yeah, sorry. I think this is nice CAP. It is optimization that basically reduces the ball because there is no beneficiary chain between the two sections. This is still like optimization, the small optimization on the ball size, on the gas, on builder. It's nice AIP, but it's not critical. So if we have space in Higota for this kind of AIPs, I will like to put this inside that scope, but for now maybe to delay the decision. But yeah, depending on the other client's positions. Right. mean, I will again say the more we can DFI, the faster the overall scoping will be. And if we have... So being done early, that gives us time to see if maybe we can open up some more room for a second round of inclusions if we want to late in the process. So I would overall lean towards making GFI decisions. so it still sounds like given those ratings. So basically, do people, let's maybe start with the 1.0. They were both even somewhat worse rated, like EAP 8188, last written box for counted slots, and EAP 8358. And that gas metering for count changes, is there anyone specifically that wants to speak up against DFIing them right now, those two? Then I will say we just make the DFI decision for those two now. Okay. And then for the third one, DAP8.115, 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, think we could delay if there's interest in keeping that conversation alive. Could we maybe again, from the guest side, maybe also have someone? We'll give an update of how set you are on rejecting this one. don't really want to speak for the team, but I think it's like a lot of complexity in this auto EVM layer. And it has, it has a lot of implications around, yeah, consensus rules. I just don't think it's worth it for what it does. Okay. Anyone wants to try to convince Geth here? 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 Nethermine side, would it be okay with you if we make the DFI decision? It does seem like you're pretty alone and you're interested. Yeah, it's not a heal I would die on. So it's a very nice AP, but it's not that something major in any way. 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. OK. 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 ZKEVM preparation. This is the section below. There were three EIPs, but there's one EIP that's low enough that we can briefly discuss DFI, which is the last one. EIP 8200, 8200, EV ammification. Do we have, it's obviously right at the edge for an ADFI today. So do we have anyone who wants to speak up in favor of keeping that one in consideration? Ben? So this is not in favor. I think it's quite an interesting EIP and, but 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 how those work. 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. 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 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, would want to see performance measurements because the whole point of these pre-compiles is performance. so there is, is it ETH proof? I'm not sure if Kev's on the call. He can maybe give better clarity. Somebody who's running a competition where people submit. formally verified EVM bytecode. And there's a, it's like a nerd's night competition and it's getting pretty fast. It's not, I don't think as fast as the precompile, but it's reasonable at the moment. So I think it, needs time to, time to brew. So we know what that bytecode is basically. There we go. Pre-compile fast. Yeah. So we love the idea. We kind of agree with the stance that, 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 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. Yeah, it makes sense. Kev? Yeah, I was going to say that that wouldn't be possible since you'd need to be able to calculate the gas cost for the pre-compiled without running it. Yeah, that makes sense. Thanks. And how do I pronounce this? Ivan, Ivan. Hey. On Etherex, we think these EAPs are interesting. If we are going to a CKVM in the near future, it's good to have them sooner than later. I agree that we still need more numbers. But I think two big features these EAPs have is automatic repressing. So you can reduce prover vector attacks. And also you remove some complexity for CKVM teams to remove the need for implementing pre-compiles to handle these specific operations that they don't have on Kev's numbers, at least of the last year, any use on Ethereum. Yeah. I would say it seems 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 artworks. Does that work for you from the Etherex side? Yes. mean, if most of the teams aren't convinced and we can't do anything on two weeks to convince them to change their minds, yes, mean, it's us against the world. OK. Yeah. Then I would just say on this one specifically as well, I think the other two we can discuss at later time. But I think this one, so EIP8200 EVMification. And I would say we DFI it for today for, for a quarter. Okay. Sounds good. Then we can go to the next page, page four or five. we are getting, getting close to the end here. This is only five ERPs total two sections. call the performance engineering specifically the data reprising bundle seems to have at least a 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 ERPs that are clear DFI candidates. One of them is EIP 7862, delayed state route. And the other one is EIP 8372, normalized state gas limit. think specifically on 8372, I saw some discussion. 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. I know that this is sort of uncommon, but I would really like to ask for the decision on normalized state limit, state gas limit. So 83.72 and the CPSP recalibration. So 83.68 to be delayed until Glamsterdown 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 EAPs or one or the other. And so I would ask to delay the decision on these after until Clamstertum ships and we have some time to observe how demand reacts to EIP 8037. Yeah. before, unless as 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. mean, of course, one of those EAPs, 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 later stage, just so we signal that they are taking up the space in the fog. I think it's very dangerous to basically keep the fog 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? 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 Glemsted on fork. And then we can see if we need to do this rebalancing or not. OK. 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 a big difference between those two EIPs and what... What would it take to keep you open-minded about potentially having that second year P as well in like potential CFI state basically or should we do it today? Can I just mention that? So essentially what I will say is that it's not necessarily that we want to do 83, 72. It's not that we want to complicate things 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 Glamstead. And 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. Yeah. And I would also add in terms of complexity, I think it looks more complex than it actually is. So like both the IPs are just doing a one-time recalibration of a variable. It's just the way that 83.72 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, we are essentially doing the same thing. We're just recalibrating. cost per stick bite. So I mean, it changes two variables instead of one, but it's not, I don't think it's much more complicated. Makes sense. Tony? Yeah, just wanted to add the same that Maria just said. It's very, it's a very simple change. And to me, feels like both EAPs are EAPs that usually pop up when we are already launching DEF nets. And then we have to CF item late in the process, like very small changes that need some empirical data to be understood. So my feeling is we should just include them at a very late definite and see how glum-sum goes. Makes sense. OK, I mean, do see some, Elton, chat some willingness to potentially reconsider 8372. Again, it was just one of the lowest ranked EAPs of all EAPs. So yeah, I think that 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 potentially DFI or CFI. Does it work for clients? seems like it, Marius? Yeah, I think for us, it was clear we have to choose one of the two. And we chose the one that is, in our opinion, simpler, but without having seen how GlamSlam plays out. So ideally, we would just have both. But I think in the process it's quite clear. have to make a decision between those two and we have to make that decision now without sufficient information. 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. Makes sense. The Draga? Yeah. Similar notion from, from Red here. We choose the simple one because. Depending on how the GlamStill 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 block gas limit lot higher, then we need to like change the gas state for all of the opcodes. So yeah, I think 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. Okay, sounds good. So then we will not make a DFI decision on 8372 for now. And then as we discuss 8368, 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, will not. DFI 8372. 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 Bezu as the only client with a positive ranking. Anyone from Bezu wanted to speak up about delayed state route? I can say something. It was more regarding performance. Karim, you're really faint. You pull your mic in. Is it better? Yeah. Okay. Now I said it's more regarding performance because ⁓ Today, state route 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 route of the previous block. So we'll have this window to do that. And like that, we can remove the state route from the hot path. But if other clients don't think it's a good optimization for this work, I will not fight. So to have a quick against. So for us, the truth isn't really that big of a problem most of the times. And post-ball you can do it in parallel, which is even less. So unless there are metrics post-ball that really show that this is a problem, would deify and consider only if we have some considerable proofs that is still a big deal. And this also has some repercussions for broader ecosystem, which I would like to avoid for now. I just want to add also... Today we are working on binary tree, so we'll have more intermediate node, maybe more IO for the state root. So maybe the impact will be better, bigger. So it's something we should measure. Maybe not for this fork. Maybe we need to have more information before trying to implement it. don't know. But yeah. OK. So then it does sound like the decision for today would be to. DFI it with the understanding that, we might revisit this at a later fork, potentially in combination with binary trees, and also that there is a chance that if Glam-Sedam shows basically that there's an unexpected load there that could be addressed with this EAP, 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? Sounds good. OK. So then we are DFI in EAP 7.8.6.2, delayed state route. OK. Then I think we are ready for the last page. So six more ERPs, miscellaneous. There, I think we have several DFI candidates, starting with the first section, execution data and indexing. maybe take them one by one because they're both relatively big features. So ERP 7807. SSZ execution blocks. We have relatively unanimous client. rejection, but we do have EtherX with a positive rating. So maybe starting by having EtherX briefly give context to their position. We think it's a good idea. We also think that maybe we can hear from our clients to see why they don't like it. I'm okay with not having it in the fork if that's the general decision, but would like to hear why. Yeah. Any other clients that would want to briefly comment on their take on SSC? execution box and why they are opposed. Well, I mean, I guess there's some gradations to the client votes, but at least why they have a critical rating, maybe specifically from the worst, like the teams with the worst ratings, Geth and Dread. Yes, I can, I I can go. I think it's for me personally, it's a similar, similar rationale than that I brought forward with another, with a few of the other changes, the impact. is very low for users or like the benefit, 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 agree that in theory it's a, 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 Lukasz is saying in chat is just crazy. Like we would need multiple months to figure out what are all the things that are breaking because of this. Yeah, makes sense. All you're saying makes sense. And Czaryan? Yeah, just to add to that, current API is not broken. It works when it becomes broken, when we need change something, then we can evaluate it. now it works and it's fine. It's not bottleneck. It's work as intended. That was, yeah, reasoning. Okay. So then looking at overall the client opinions, it seems like we can make the DFI decision today. Anyone who wants to object. Okay. So we are DFIing EIP 7807 as the execution blocks for Hegota. Then the other one from the section that we can at least briefly see if, if we have enough of a unified opinion for a DFI decision today is EIP 8304, 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. Well, it's my EP, so I'm going to speak for myself. so the thing is so far from what I gathered from other people is that some people see this as important and then some people don't. Those who care about it generally from those people, I generally had 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 hard to compare to others a bit because it's never super urgent. But over the long term, think Ethereum will be way better if we have this, not just because of the provable ⁓ RPC, but also because on-chain provability. there's now a design for native UTXOs that could use it also. L2 chain communication could use it. I think this is something that's valuable and there's never a perfect time to include it. And I don't expect like future force to be less crowded. So 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 deified right now, but maybe discuss it a bit further. Yeah. So that's... Thank you. Yeah. So basically the question would be for the clients that have had more negative opinions, specifically the clients, of course, with the lowest tier, that's Beiso and DRETH. What are your takes on this EAP and in particular, basically how much would it take for you to change your opinion specifically for Hekota? So basically how worth, how much value is there in delaying the decision to potentially give the GETH team, give results 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 AP? Sure. Beisu is pretty, I don't want to say intractable, but it really, 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. And from the red side? Yeah, I didn't see a lot of value in this. In general, it seems a lot of work. to add the long indexes and everything around that. So yeah, I'm not sure. Yeah, so I'm just trying to see regarding the decision today. Without any value judgment, feels like 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 base opinion was stronger than the right opinion. I don't know, salt. or anyone from the, from the geth team, is there maybe something, some immediate on the spot attempt you might want to make to convince Beth, or at least give it one more decision cycle or otherwise I think we would, if, if Esu has no path towards changing their minds, then it would still justify DFI today. Yeah. I mean, I think maybe this thread that's going in in chat, I can just say it loud. I think that the SSZification 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 and 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. 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 say, hey, we will really benefit by this. This would didn't change our minds. mean, I think this is like the same argument that was made for fossil. You know, ideally no one uses fossil. And in general, I don't think that when fossil was chosen as headliner that 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 the theory 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 be building the functionality necessary to provide a trustless experience to users. If this is the case, then I would lean on deifying it for Hegotta and maybe including one of the next forks when this becomes a bigger problem. Right. Yeah. Again, I think... Just given that in the end, will reject the ERP 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 hardfork. 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 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. is there... Is there someone who would want to either basically have a concrete plan for how this can change over the next two weeks or otherwise thinks that DFIing is inappropriate given the current circumstances? Yeah, just wanted to add. if I understand correctly, like, ⁓ Basel's main concerns were like complexity and whether it's valuable enough. And honestly, yeah, I mean, Last time when I proposed 7.7.45 for Glamstadom, I kind of had the impression that some people from Beysu saw the value in that proposal. so honestly, I'm not sure if you guys have looked into the state of this AIP now, but I mean, it's 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. 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. Yeah, I honestly don't really understand why you have this very hard stance on this, but yeah, I I just wanted to say that this is way better state than the previous one and yeah, maybe. So I 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. 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. Okay. So I will say then though, I think if we delay, they would have to come with a clear commitment also from the basis side to engage in this discussion. I mean, it sounds like that that would be the case. And then also from the, from from the red side to be open for some more conversation, because that's, those are the two brokers 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? Sure. I'd like to hear from other clients too, just to see if they maybe have a nudge in any direction. 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 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 combinations of puref, it would be very good. On itself, it moves just a needle in the lock space, so it's not as impactful. But we're fine with it, just didn't find it as a priority for Haggotha. So this is based more on priorities rather than on anything else. But we are fine with it. Okay, so then I think just in the interest of time, we can make a delay decision on this one today. So ERP 8.0. three or four trustless lock and a transaction index will not be DFI 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 counted for DFI is EIP 8.094, ETH VHASH. lob aware mempool. we have someone as Shaba, I saw you immediately raising your hand. Is that specifically to this EIP or in general to the section or something else? No, specific for this EIP. So because I'm the developer, I was already anticipating that it's something that was proposed first together with Sparsberpool and then we rolled actually many of the features into Sparsberpool. So in its current state, the Delta, which is I think is not that much. So I think No, ⁓ I'm, I agree with the, with the 0.8 in the sense of deifying it for now. So we don't have to spend too much time. 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, Joao, if that's okay with you, you still have your hand up that 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. Okay, then it is three 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 DFI's though, at least that's good. Then maybe just briefly for expectations, think for two 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. And make another pass for the DFI candidates that we have delayed today. Those also 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 EAPs that might be the most on the edge of going either way. I think we are making decent progress. Hope we can continue this. Any last comments, Justin, you have your hand up? 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? Yeah, that's a great, great prompt. So actually what I would then ask is that A, all of the EAPs that we delayed 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 EAPs with the highest ranking. 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 one, two, three, four, five, six, seven, eight EAPs at 2.5 or higher. At a minimum, everyone should be very up to date. Especially if you are one of the clients that specifically has not rated these EAPs highly, you should come to the core prepared to explain exactly what your concerns are and have a clearly pre. agreed a position as a team on like what would change your mind. How hard is your know or like how hard are your concerns on this? I think those eight 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 eight of those ideally. Is that a reasonable expectation to set? I mean, I guess I will just set it. So that's the expectation. Can you post that on the next meeting agenda? Sounds good. I will do that. Maria, last comment. I think for the EAPs 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. if, if, if they already have. those opinions, which I think they do because they created the tiered list, then it would be nice to just go through them async and then we can more prepare on the next call. Yeah, that's even better. then ideally, I would ask we have two weeks until the next call. if over the first week, so 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 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 Forkast know about updated positions and we can reflect that in the rating so that ideally we already have minimized the gap on these ERPs 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 DEF CON, which I think would be amazing. Awesome. Thanks everyone and see you all in two weeks.