Execution Layer Meeting 246 [2026-09-24] | ACDE 246

Akash Kshirsagar: Good morning and welcome to ACDE number 246. Today is September 24th. We have Glam Amsterdam stuff on the agenda and lots of Hegoda PFIs to go through. We'll start with DevNet updates for Glam Amsterdam. Is there someone from the Pandas who can give a DevNet update today? Yeah, sure. I can give a short update. So we've successfully run through testing the gloss fork transition with in particular Lido and Optimism to make sure that we can get them to test a smooth fork transition since the previous ones were a little bit bumpy. And that was quite successful. Everything went smoothly and the DevNet has since been torn down. regarding DevNet 8 and Pether Berghett. We have Bezel still investigating a performance issue where they recently tested and are in the process of pushing improvements. So that should then work better under benchmarking load tests. And we've yesterday launched Frames DevNet for Higuota as well. Thanks. OK. So we are confirmed for the Sepulia fork on October 6. That has already been merged into the client specs. It was confirmed on ACDC last week. Releases, I believe, were supposed to be due on September 29, which is next Tuesday. Next Monday would be better, because the blog post will likely go out on Monday. Can we hear from clients what the progress is on client releases for that? Another mind release. I guess we can go client by client geth. next week and Aragon. E3X today, tomorrow. Great. Thanks guys. Okay, next item in the agenda is the Glamster Dam gas limit. Justin, do you want to chat about 200 million? Yeah, either. Yeah, so when updating the configs for Sepolia, it appears that we forgot about the gas limit schedule. I'm hoping that we can decide on this here and now so that CL clients can make releases for Sepolia. Ideally, this mirrors what we intend to do for mainnet. After proposing a few options on Discord, it seems that we most prefer to immediately signal 200 million at the glimpse of MFork. I just shared the link to the PR for that in the chat. What do we think of this and can we agree to this now? Or something like this. Hodes is asking, is it safe given what Paul triggered on DevNet 8? I don't know. I mean, isn't the plan to do it on mainnet? So shouldn't we be testing on Sepulia? Yes, we definitely should test whatever we intend to do for mainnet on Sepulia. Can you say more about POTUS' comment? Or can POTUS say more? Is Powell here? He can probably describe his attack, but apparently he's triggered blocks that take over eight seconds. And there are some clients reporting 13 to 14 seconds to validate some blocks. And we just can't handle that. That blocks us. Any payload that takes over six seconds is dangerous for afterglowats. valid one, Tony, valid ones. And the problem is, and Maria is saying about the benchmarks, but it seems that there's a disconnect between what's been benchmarked on isolation and what's actually happening on the DevNet. Are you referring to the get blocks? No, this is the jump desk attack. mean, there's a particular contract that Powell deployed on the DevNet and you just hit that contract with a lot of gas and then it produces a lot of valid blocks that take a long time to execute. And the problem is that if we, and this is even, it's even the lower bound. So on the DevNet, the builders are releasing the payload immediately. So these payloads are being seen at two seconds into the slot, three seconds into the slot, and still they take until the next slot to execute. And on an actual mainnet or an actual testnet, if we are attacked, these payloads are going to be released at six seconds into the slot, and they're definitely going to be executed into the next slot. We cannot handle that situation. Do we have time to do that before Sepulia, Tony? I'm wondering what Saber is saying regarding benchmarks have no actual network. To me it feels like we are just missing those tests. Apparently the test changed. And I don't think this has anything to do with network because the DevNet already is giving us a bound. These payloads are being seen very, very early. So it's irrelevant the issue of the network because as long as the payload takes nine seconds to execute, then of course it's going to be brutal even if the payload is revealed later. I'm not sure what attack you are referring to both those, but for the T store one, we are already integrating it. We have integrating it's it's into the benchmarking and it was an issue with Bezu that is being fixed. so that's my understanding. Like, I don't know what the new attack is with job tests. so I don't know if someone with more context can speak a bit more to it. Are the other DevNet machines representative? one question, I suppose. I mean, I would say they are representative. They might be even a little bit overprovisioned, I would argue. So is my understanding that this is a single contract or like a single attack that is causing issues, but otherwise this gas limit works? I think my understanding is that you first have to pre-deploy quite a lot before this attack becomes critical. Okay. So I think the question should be if we should have the gas limit at 200 million, but I think the PR is more for the fork transition generally how I think it's two parts. Like, do we want to let clients implement and have this kind of configuration that the CLs have kind of a jump in gas limit? after the fork and do we want to go to 200 million? I thought Maria said something in the past that we needed to increase the gas limit for some reason. Yeah, so I guess the reason for increasing it is because of the cost per state by so 80 37. If we take longer. So what we are doing now is that the cost per state by doesn't change with a gas limit, right? So this was a simplification we decided on it 37. And this means that from the fork, once the fork kicks in, that is the gas costs per byte for all state creation. if what happens is that if we take too long for the, the gas limit to reach, I would say at least 150, then essentially the gas limit is too small for some transactions and we could see like higher volatility on base fees. So I think it would be better to decide on the gas limit and then set it right at the fork. And then it will take four hours for the if we do the 200 million to take around four hours for the gas limit to slowly go up. And still we do see some or we expect some volatility in those four hours. But if we let it take more than that and the more time that volatility will be there. I think I shared an analysis in the past on Discord, but I can link it here again. One second. So I think I agree. This is two different discussions. So first is the discussion of is 200 million safe? And the second discussion is like, once we set the limit, how should it look like? And I feel strongly that it should look like you said at the fork instead of a phased increase. Regarding on what is safe, that I guess we need to look more into this attack and figure out if it's worrisome or if it's something we can fix. Otis, you have your hand raised. Did you want to say something? yeah. I wanted to lower down a little bit the tone. It seemed like I claimed that the chain would be destroyed. But actually, so what happens with these blocks that take a long time to execute is that if you time them correctly, you can reorg the next proposer, which is the problem because you get your payload included and then you reorg the next proposer. Your payload is canonical and you can just say you hold the other slot. you can just reorganize entire block. But this attack is very expensive. You need to waste an entire... You waste a lot of ETH in order to reorganize the next proposer and you don't get to reorganize the next block because you don't get to see the next payload. So it might be that it's fine. It's not that this is something that can persist. This is not an attack that can be kept over time. So we might be fine. shipping knowing that we might have this, but I think we want to be in a situation in which clients can handle the six seconds that are allotted because we are deciding on pricing based on that information. Okay, so is it reasonable to say that we move ahead with 200 million at the fork for Sepulia and write the tests? Wait, wait, it was never at the fork. I think we were scheduling it for a week after the fork. Who is we? I don't think we've agreed to that. it's I thought your PR was that? No, I mean, I made three different PRs. One was 24 hours after the upgrade. One was a phased and one was immediately out. I closed the first two. because of Maria's concerns. Saba, can you say more? Yeah, I just think it's not a good idea to do it at default because we are mixing signals from a bunch of directions. And the bump will bring in networking effects and all kinds of effects because of the rock size and so on and so forth. So I would just bump it with the amount that we kind of the replacing. gives us in some sense or what the pricing needs and then change it a week after or something enough time that things are settling and then we are changing it. Maria, you're saying the floor is 150? Yeah, I'd say less than 150 would be crazy and ideally 200, I feel. Why is it crazy? Because essentially we are we are increasing the creation cost by 10x in gas terms. And so there will be some transactions that actually require much more gas. I think like there's some that require like 90 million. And so that would mean that if you do much lower than that, then for a single transaction, already be at the target and then the base fee could be a bit crazy, I feel. And also not only that, but the fact that we are making the increases longer, would make the duration of the stability also take longer. So this is also what like to provide. So you are assuming stability and that it's longer. My problem is that we are potentially shooting ourselves in the foot by trying to do it all together when we can just split it out. yeah, but I think we should increase by the amounts required by the replacing. I have no idea how much is that. that- What I'm saying is like the value, what I'm saying is the value required is not that far from 200. So why not just do 200? I'm surprised to hear that, I don't know on that. Have there been any specific concerns about or specific incidents that you're concerned about? Immediately. We don't have an equivalent network on which we tested. We tested many things in isolation and that's really good. It's just, it's different from testing everything together. And if we don't want to do it like this on main net, then we don't have to do it like this on support. One thing is the transition. thing is the... And there's also the layer of the gas won't just immediately go to... to 200 million, the gas limit won't go to 200 million immediately at the block stated. It only starts trending upwards after that because there's still a voting mechanism. So if you see chaos in the network, that means you wouldn't have the voting mechanism kick in, so the gas won't go up. So I the gas only goes up if the network is stable. Yeah, I'm not saying it will fail. I'm not saying we have evidence it will fail. I'm just saying we have no reason to do it like this. Onska. Yeah, I mean, I just would say, I think from my point of view. If this is actually as serious as it sounds, then I think the implications are actually relatively serious, just also because to me, Glam Saddam is basically all about scaling. So if it turns out we would end up having overlooked something and that one thing basically is a 5x worse bottleneck than everything else in the fork, then I... Personally, I it's very plausible that we decide that we couldn't roll out Glam-Sydam like that. I mean, it's obviously very possible we might be able to do client optimizations, but if that was not possible, we might, I think, have to make adjustments to Glam-Sydam. Given that, I feel like we should double down on using test nets for actual stress testing and not... I feel like if we are now trying to basically be more gentle in our test net behavior, then I think we're setting ourselves up for potential serious issue on main net. bias, both in terms of the transition at the fork boundary, but then also the gas limit we target on the testnet. I would always aim towards more challenging conditions, because otherwise we're just risking mainnet. Yeah, agreed. Okay, given all that conversation, it sounds like the consensus is we do 200 million at the fork. Is that? people feel like that is the best way forward. I see the rationale also in that point, so we can go with that for me. Okay, great. Glad we have solved that. So we will schedule 200 million at the fork for Sepulia. Next item on the agenda is the CL block retention window. There was some conversation about this on ACDT. Is Tony here to talk about it? or Dan. Yeah, Tony said he might be here, but he might not have internet. Hey, I would actually ask Jihoon here who brought it up to ACDT. Otherwise I can give a quick overview. do see Jihoon on the call if he's able to speak. can motivate it in the meantime. So basically, Jihoon asked if we could discuss what the size of the CL block retention window should be for GlamStamp. Basically, 8061, which changed the exit and consolidation churn, changed like a key CL parameter. But we didn't update the block retention window, which was initially set to that parameter, which has now changed. So this is a CL layer issue. And related to this is that in Hegotter, there's a pfi.dip8383, which is reduced assist further. So a decision needs to be made on this. And then related to that is a PR from Nico. who wanted to align the bowel retention period exactly with this block retention period. So that would be the decision for today, but it depends on the value of the first question. So there was quite some discussion in ACBT on Monday. And the question is whether we can resolve one or both of those issues today. Yeah, I think there are multiple questions here. As Zen said, one is reducing CL's block retention period according to weak subjectivity period change in GLOAS. And if you were to reduce it, the next question would be whether changing EL's history retention period to match CL's reduced retention period. And besides that, the other question is, Nicole's PR increasing balls retention period to match history retention period, is 33,024 epochs. And from my understanding, today's discussion were to be focused on balls and history retention period, if I'm not wrong. And in the chat, Kev listed some questions. So we can also refer to that. Kev, do you have proposals on what these windows should be? so I think EIP 4444 was changed, to be 33,024 to match the CL retention window. if we change it to match 8061, I believe it roughly halves it. for the BAL window, believe Nico wants to make it equal to the 33,024. And if we follow AD61, that would be reduced. So I'd probably group it as follows. I'd say we should probably figure out if the bowel window should equal the CL window. Cause I think we agreed that the EL window would equal the CL window. If we say yes to the bowel window equaling the CL window, then there's a question of should we reduce the CL window according to AD61? So yeah. Yeah, so I'd say the first question is should the bowel window equal the CL window? I can't remember what the bowel window is right now. I believe it's like 3000 or something like this, probably safety decay of 10%. So we'd roughly be 10x in it, Yeah, roughly a 10x. Lukasz? Lukasz? So the bowels are... like a helper structure, So they are not really required by the network to function in any way or it might make catching up a bit harder for the nodes that are really, really behind, but they are not really crucial. So I wouldn't like to have too many of them, like two weeks, four weeks, whatever is fine. But having like multiple months of them is probably an overkill that I wouldn't like to mandate so that's why the time for ball retention was chose quite small. If I can add one more thing about reducing the retention window and aligning ELs with that, I would say it depends on the RAE files hosting strategies. I know that few organizations are hosting those files, nevermind it's one of them. And I asked our colleagues, do we have an automated way of updating them? And we currently don't, we will work on it. But if we reduce the retention window in the network to a month or something, I think that's more or less what's proposed. without automating that on all the hosting providers. Having some kind of alerting around that, etc. is then actually quite important. Because if we have a six-month retention window, every few months we can do it manually. But if we have a month retention window, probably have to completely automate it and have it very reliable. on all the operators. So those are my comments here. Marius? Yeah, sorry. So we recently come across this bug on definite age in Gath where Gath would basically, if you shut down the node for two weeks, we would, and started up again, we would start fetching the bells. And we would prioritize bells at the head. because they were pretty fresh and they were available. But what that would mean is that we didn't have any bales at the point where we are actually sinking. So we have the bales from the last three days, but we don't have the bales from the point where we're actually sinking from, so two weeks ago. And what happens then is is the only way we can catch up is if we go into full sync. The problem with full sync, like we're full syncing, the only way we can catch up is to linear execution. The problem with linear execution is that it's like an order of three X slower than parallel execution. And so what we ended up with is blocks that take like nine to ten seconds to execute because we don't have the bow. So if we keep this bow retention period as too short, then it is virtually impossible for someone to full sync because the more we increase the parallelism, the slower a single block will be. So right now, if the slot is 12 seconds and our block is an average 10 seconds in sequential execution, then it is still possible to catch up to that in like 10, 12th of the time. But if it's like, if the linear execution is 13 seconds, while the the block time is 12, then you will never ever ever ever be able to catch up in full speed. And so yeah, I think it would be really nice if we could have as long of a battery tension period as possible so we can allow for users to shut down their node for a day or two, install some updates, restart them again and catch up to the Otis, do you want to say that out loud? Well, mean, you guys are discussing how you guys think, but the point is that we need to serve those blocks. We need to serve them complete because otherwise we're serving invalid data. So someone needs to keep them. It's not, I mean, the spec requires us to keep them. So if you guys are not going to keep them, then we are going to keep them and then we're going to have them doubled. And that's going to be a deep change for us because at least two clients already just... drop everything that is EL related and we only keep the CL related data on our database. We're going to have to change this if the EL is not keeping them. But you potentially are reducing this window to around four weeks, right? So that's not a big deal in my opinion. Yeah, so the only ask from the CL, the only ask is that at least what the CL needs to keep should be kept on the EL. And then you guys can discuss whether or not you want to keep more. Yeah, sure. Marius, do you still have your hand up? No, sorry. Yeah, so just to be a bit more explicit, to ask the question again, should the bowel window equal the CL window? Just to say POTUS's question a bit more explicit. which would currently be, I believe it's like five months unless we decide to reduce the CL window according to 8061, which would then bring it to about two months. So yeah, I guess the first question it seems folks are fine with, like the bowel window equal in the CL window. Yes, to Tony's question, would be 33,000 epochs unless we decide to reduce it, which was the next question. And I think the reduction was to 14,000? Yeah, was like roughly half if I remember correctly. Marius? This is exactly where I would say, yeah, in principle, I would say it's nice to to have less windows. We have a bunch of windows. But I'm more of a Linux type of guy anyway. So I'm all for reducing the windows. The problem is if we are coupling two things that are kind of unrelated, maybe a bit related, and then we are talking about it would be nice to reduce that window on the CL. Then I think, yeah, but then we like, if we are making the conscious choice to have to only support one window for two different functions, then that window has to, or whenever we think about that window or changing that window, we have to think about both of those functions, whether they are still supported afterwards. So I think going from high months to two months is fine for me. But in the future, if at some point we say, this retention window should be, I don't know, three days, and now the retention window for the EL also needs to be three days, then I think at that point, it's really bad because we bundled these two concepts together that don't not 100 % the same concept and now we are changing the window based on one of those concepts and not based on both. So if I understand correctly, this is not blocking on test nets. So can we move forward by somebody, either Kev or Jihoon or Tony, posting a summary of this somewhere that we can align async? Okay, great. Are there any points on this topic that we didn't cover that we feel like all ELs need to fully understand the problem? Jihoon? Yeah, I just want to ask a question on reducing this window. So this window is something that EL does not have to perfectly match. is the minimum window that EL needs to support. And if you were to reduce this retention window, then my question is, when do we want to reduce it? Do we want to reduce it in Gloas? Or do we want to reduce it in Agoda? or can also discuss it in anything. It can be any time. It's not a hard fork at all. Okay, yeah. Then there is no rush in doing it, but we should align on something async and it is not blocking for gloss. Kev or Jihoon or Tony, where do you want to? just take on this in the ether and the discord somewhere. Yeah, we can open up a friend on the discord. Okay. Great. Is there anything else related to GlinchFam? If not, we will move on to Hagoda. So we have two categories of EAPs to discuss today. The first, are going to cover EAPs that were punted from last ACDE that were likely DFI's but needed some more discussion in the meantime. We will start with 8304. 8304 was the trustless log index. I believe that was a default DFI unless any clients have adjusted their recommendations for it. And that ask was specifically for Beisu or Reth. So if either of you guys have adjusted your recommendations for it, speak up now. Sorry, for which EIP? For the trustless log index 8304. We haven't changed our opinion. Same here. Yeah, I just wanted to say that, yeah, I understand this is like the trustless APIs are somehow not so much a priority for many people, but I think for the other further use cases, we will have much more synergy later. And so I will. keep working on this project regardless of this decision. So yeah, if anyone's interested, just reach out and yeah, let's discuss the async and make progress with it. yeah, just that. Thank you. So 8304 is DFI for Hagota and Joel will continue working on it. The next one we have is 7979. That is the call and return opcodes for the EVM. I believe we have some people on the call today who we have solidity and Viper and Greg Greg, did you want to say anything about it before. We've discussed it a fair amount before. I don't know if I want to spend a lot of time or any resummarizing it unless there's people on the call who really want to do that. In the issue itself, I've linked back out to what people would need to read to fully understand the proposal. and 8173 on foundations of control flow. I've tried to answer a lot of the questions that I've heard come up, questions I see in the chat after I finish talking. can't be reading what's happening there while I'm trying to talk. So I think that's there. In the proposal itself, I get into some performance measurements we did just on some purely computational examples. those show if you can compile, if you have this and you produce static properly valid code. 8337 is a proposal for actually showing the code is valid and a proposal that lays out the five criteria for what that would be. It then shows that yes, you can get modest increases just from an interpreter. If you compile the EVM code to a register code from a stack code to a register code, you can get like 2x performance increases on purely computational contracts. If you compile it down to machine code, you can see like 5x. If we were to add 64-bit operations, which we have proposals for but haven't moved forward yet, we can see like 50x increases. And this is compiling down to risk v code. doing zk proving on that risk v code, you get essentially the same performance increases. So we can see. 50x increases by starting with EVM code and compiling it down to risk of the code and then running a CK prover on that one. And I'd have to go back to the proposal to remember which CK prover we used. And when I say we, I basically mean me and Claude. And so there's that. The only new stuff is me and Claude basically generated prototype implementations for Solidity, Viper, Geth, and EVM1, put them together to do end-to-end testing of Solidity and Viper, and really leaned on Solidity. Had to fix some bugs, do a little patching to Solidity. we're able to basically run that whole thing. And all the solidity tests pass, compile down, pass, validate. So I think we've shown that this is not at all in the way of solidity. That's that. I'm gonna, before I call on Dragan, I'm going to ask if Solidity wants to speak. Yeah, hi, I'm on the Solidity team. So we shared our opinion in the if magicians thread, I posted it also in the chat. And to sum this up, are, so basically, of course, when it will be delivered, in the fork we will be using Tendo Unimplemented. yeah, and basically it's like, it has some properties we like and yeah, so that's the solidity opinion. Also, we didn't have time to discuss also the proposal. 8337 which looks like a natural follow-up of this but I have a strong feeling that it would be we would have much bigger we would be much bigger much much more in favor if it will if it will be included like after this change so yeah that's our opinion And Viper is Charles here. I don't think he could make it. He and I have had discussions on this one and a lot of discussions over the years. I know that if you ask him about the proposal, he will say, I like 2315 a lot better. If you ask him, will you use these? He will say, well, of course, that's not even a question. When he reviewed what, you know, what the code looked like using them. He's saying, yeah, that's a lot better. And you should try it on Venom. I bet we could get even more elegant output. So I can't say for sure that he likes it a lot or something. But I know for sure that he would definitely use it and thinks he could get better output. from his code generator if he had it. And that he really wants, he really wants in some proposal, some sort of jump fee or other sort of vector jump so that he doesn't have to use a dynamic jump for the initial selector. Okay. I'm going to call on Dragan first because he had his hand up and I skipped. 7979, yeah, we do support it. I think the code destination should be removed for OAP, but I've talked with some teams that do Solar, basically a solid compiler, and they would like to use it. So yeah, it is support from Redside. Does that mean that you're changing the score that you had initially given it? Yeah, I'm not sure exactly what we scored it. I don't think we deified it, but... There's a C. C. Yeah, I think it's fine with that. But we would like to see it in the hard work. Ben? Sorry, issues. Yeah, we strongly support this and think that, I mean, it's, I think everybody, as far as I'm aware, thinks it's a good idea. And it's just been for like nine years. like, well, you know, it's not, it's not urgent. It's not urgent. so, and that will just continue going on forever. So I think, I think we should get it in get it in the fort. because it will never be a better time. Here's from some other client teams. Maybe Basu. Yeah, so I think thank you for solidity for weighing in on that. That does change our opinion on it a little bit. We are actually, we have it at a B, I believe right now, and we are open to moving it to an A. We have anyone from Geth who wants to weigh in? If not, we will assume that Geth remains at a B. So that is two votes of support from Basie and Nethermind. Etherex says a DFI, but not strong DFI. Do we have any strong opposition to including this? or to moving it to CFI. Ansgar has some. Right. mean, I just wanted to, to say, feel like, and given that we're currently going through the list of kind of DFI candidates. I mean, also obviously I don't want to slow down the Ecuador process too much, but I feel like. To me, the choice right now is more between on these individual earpiece, A, do we today deify them or do we leave them up in this kind of like basket of middle, like kind of like middle of the road earpiece that are not clearly CFI or deify and we have to kind of like take them one by one at the end and move on. I feel like there's like this list of really strong CFI candidates and I would maybe go through all of the, have gone through all of those first so that we get a feeling for the overalls fork scope. And how much room we have before we then deal with all of these could go either way EAPs. So to me, like right now, it feels more like then the takeaway would be, we just don't DFI it for now. But I wouldn't then just immediately jump to CFI. But I'm also obviously like, I'm happy to have clients go either way. Just wanted to mention. Yeah, I'm getting strong CFI vibes from the clients right now. I think that it's fine if we CFI it and then we later decide to move it to DFI considering that DFI is supposed to be an irreversible decision for the fork. It's supposed to be like a definitive way to say no for a feature for a fork and we don't want to leave too many things in PFI at this moment because we only have two more calls to decide on everything. I am going to propose that we move it to CFI. Does anybody want to strongly? oppose that. Okay, we're getting thumbs up on CFI and move forward. Great. Let's see if I 79 79 and move on to the next one, which is 8163. That was a DFI candidate. We just wanted to hear from some L2s or other EVM chains. Is there anyone on the call who is from an L2 or or other EVM chain and wants to talk about it? Hi, I'm here. I'm from the Monad Foundation and yes, there was a request to produce examples of demand for 8163 and I posted them from our end in the EepsMagicians post. I found also some evidence that the other alt elements want or experimented with custom web codes, which is Tron and Rootstock. There was also was a message of support from the Arbitrum Nitro team that they would like to see a reservation made like this. And yeah, that's it. So in the conversation that has happened over the past two weeks and the comments that have been posted, I posted some Eath Magician thread in the Eath R &D Discord. Do any clients want to speak to changing their mind on this opcode? I believe that it was a no op from the L1. Ben? Yeah, we essentially don't do anything, but just guarantee not to do anything in the future. Correct. Bezu team, we like not doing stuff so much. We promoted this to S tier since our last call. So that's where we're at. From Aragon, we promoted it to the DTF. Did you say B as in boy? Yeah. From red side it should not be DFI maybe C or maybe even B We don't want to block this, this like knob. It's easy to do and it's like Befriend with others so it makes sense to do Given that this is an easy ask and doesn't add much to the fork scope, are we OK CFIing this? there any opposition? Okay, 8163 is the CFI then. Thank you. the next one was 8360. Where is this? Maybe not on you Okay, this is the T create opcode. Milos, do you wanna give an update on this? So the history of this is that it was proposed in time, but the original proposer did not bring it to a call. So it was not added to forecast rank, which is why it has few rankings on forecast. Yeah. So we made some updates. I will give some context. This is for TCreate, which is a new opcode for creating contracts that only exist for one single transaction. You can think about them as disposable contract or ephemeral accounts. They give some names. This is a use case that has been there since a while. I think Axel are... Socket were first doing it and nowadays it's widely used for payments and deposit addresses, cross-chain, intents, limit orders and stuff like this. It's currently possible by appending a self-destruct in a same transaction though the Amsterdam update doesn't. doesn't give gas refills anymore for Glamsteadam. And this should be kind of treated as a bug, in my opinion, because we are basically paying for a state that is not used. So basically, the idea is that we will have this that will cover the breaking change that was introduced with Glamsteadam. wait, but so. Yeah, I can name some teams that is zero-dev building on this, and so FlashNet and some others in the past. I think we're running on like 1,000, 2,000 transactions per day on Ethereum. It's a kind of a use case that scales better with price because they're disposable. So on Binance chain, there are like 10 times more, think, a couple of hundred thousand transactions per month. And in general, I think this is quite important because This basically moves this use case to either other channels or to a centralized approach. I'm championing t-create, but I think the main priority should be just having this use case enabled either with t-create or by restoring the gas refuse. But as far as I understood, the self-destruct will be deprecated soon. Does this EAP have dependencies that would have to go in with it? I think so. What are those dependencies? I think are listed in the EAP. Where besides, I guess the dependencies are here, but I don't know which ones of these are. So 7928 is already. Are there any AIPs that need to be like scheduled with Hagoda? Because these are all. I think Josh, Josh, Josh, I'm not a specter. You're You're welcome. Yes. Can people hear me? Yes. Yes. this EIP is like a standalone EIP. So no other EIPs have to be scheduled with Hergota to focus in. There seems to be some confusion because I some chat about tstore and tloads. That's also implied. But Sthorn Sload behaves as Tthorn Tload in the CIP, but that's just like EIP, but this is 1.1.5.3, so that's already part of the chain. And maybe to add like my own opinion here, like I see a lot of clients, they are against this change. I want to say that we are well, somewhat effectively deprecating and removing this feature of the EVM without giving an alternative. So we are essentially taking away an engineering opportunity from the EVM. What is now more actively being used. And I personally think that we cannot do that. We should have scheduled an alternative for this in Glamis then we did not do so. So that means we should do that now. Yeah, mean, to add on this, this kind of operation are having six times the gas cost for a state that is not consumed. It's very important for application that this basically gets done. to say, but it's like, it was made a process mistake by removing this, which is not a future use case. It's currently used by multiple companies. Yeah, I think some of the use cases of self-destruct can be covered by setcode from, which is going go in. But there are some extra ones that aren't covered. so I would be for this on the basis that it would mean we could completely get rid of self-destruct. After. Yeah, I'm thinking the same. The reason why we deify self-destruct removal is because there was no alternative in Higota. So if the Decreate can be an alternative to basically the current usage of self-destruct, then we should probably do it. The question is the same that was mentioned in the chat is, do you want to do it now in Higota? Maybe there are some edge cases around it. how to do it with gears, how to do it with new account, how to do it with storage. Maybe it's too much for GDOTA. I don't think so, to be honest, but it is a valid question to make. Yeah, I agree. Sorry, just to add on this. If it's too much for regota, I think the gas refill will need to stay until self-destruct is completely replicated. So what would happen? So this feature is being removed in Glamstradam and you're proposing it per quota. So what happens in the interim? It's not being removed in Glamstradam, but the gas costs sort of get prohibited in some corner cases. Yeah, I mean, the future is removed because the point of using it is that you get the gas back because you don't consume the state. So yeah, now it's just... Even adding the gas to serverless struct, I believe, adds some gas. So it's not a future anymore, because the point of the future is to have it ephemeral so you don't pay the cost for it, since it's a disposable payment flow type of use case. OK, so question for the teams that have not weighed in yet. Do we feel like you guys have? So wherewithal right now to weigh in or do you need more time to consider this? Ben and then Maria. mean, I'd say a downside of not putting it in and the change to the cost of self-destruct will mean that people won't use self-destruct and they'll just leave tons of contracts around because that will be cheaper. Are you? To be honest, I think the discussion of these EIP should be done together with the proposal of deprecating self-destruct because I feel like the decision we take there will also inform the decision we should take here. So I feel strongly that we shouldn't de-FI this right now, even if clients feel that they want to de-FI it. So I would ask for maybe pushing it to that the same time we have that discussion. OK, it sounds like, OK, so we're not ready to make a decision quite yet today. I would ask the champions of this EIP, Milos, to please engage with the clients and for the clients that haven't submitted recommendations for this to take a look. And on the next call, we can make a decision. Yeah, sounds good. Okay, Let's see, we can, okay, so there were two EIPs last call that were basically alternatives to each other that Maria has asked us to, or has said that basically we need main net data in order to make a decision on it, on whether or not we do 8368, 8372, or neither of them. And so basically these things cannot be decided on until then. And my understanding was that it was at least 30 days of data after GlamsterDAM. So my proposal is that we leave both of these in PFI with a note that we may need it after GlamsterDAM. Does anybody have a preference? The alternative is that we move both of them to CFI or one of them to CFI and just switch it out if the other one is needed. Does anybody have any opposition to just leaving these as PFI? Okay, I would just leave them there then. and we can move on. OK, so we can move to the highest rated EIPs and make decisions on these. I've asked the clients to flag any concerns, and Mark has added this nice spread feature, which shows that the higher number is the more contentious ones, which means that there's a bigger spread between people's opinions on them. So let's start with 7906. This is the highest rated one. Does anybody want to flag any concerns about this one? So, Yash? Yeah, not a concern per se. Hi, I'm a treasurer from firmware, but this would be really great for us offline signers, hardware signers. So just a strong recommendation for this. If there's no opposition, then we can move this to CFI. Great, let's move study 906 to CFI and move on to the next one. We have 8250. Which is a key consensus for frame transactions. Does anybody want to raise any concerns about this one? Great, then we can move this to CFI. I think this is a batch of account abstraction ones. So yeah, 8272 is the other one. Another frame transactions one reads recent roots for frame transactions. Makes sense to CFI these all together. for concerns as now. Great. Moving this one to CFI. OK, remove bloom filters. one. Wow, this is the third work it's been proposed for. Does anybody have any concerns with this one? This was, if I remember correctly, a dependency for another one, correct? I think Kev, this was a dependency for one of the ones that you proposed. sorry. Yeah, this is essentially moving technical that we do all these calculations. We send it across the network. Nobody uses them. So why do them and why send them on the network? Great. This is... Okay, this is an easy CFI then. Move on to 8368. CPSB recalibration for new gas limit. rated highly. This is the one that we are leaving as CFI. is. You're right. Sorry. 8253. bump nonce of zero nonce storage accounts. That one... Some people wanted to include it in Amsterdam at last second and we decided to go with a Haggata. We are responsible people. Does anybody want to plug anything with this one? Yeah, just stating this is the ERP7610 replacement. we SFI'd ERP7610 for Glamstam and then last minute we deified it and this is the replacement for it for you. Okay. Let's CFI that one then. Next one is 3298, remove storage clear refund and refund cap. Looks like Aragon and Etherex had lower tiers for it. Do you guys want to flag anything specific? No, nothing. just, we thought it was a lower priority. That's it. Okay. I get to be the good guy on Scarborough's the bad guy last call. I just get to be with the CFI decisions. Okay, that can be a CFI. And then 8131. This is the unified transaction content floor. And this is the last of the easy CFIs that I have asked clients to look at. does anybody have any flies with this one? If I transaction content floor. This is all A or B, so. OK, easy CFI. We have 14 minutes left, but I had not asked anybody to go through any of these. So basically, for the next call, I would just ask that clients look through the remaining, I think, 11 EAPs. And the champions. progress anything that they feel has changed since the clients made the recommendations. And then we will spend the next two calls going through those 11 EIPs. Does anybody want to say anything about the remaining ones? that maybe will give clients more color on them for next time. Great. Tony, which one is, or sorry, Ansgar, which one is that? The block access list by floor. I was just a suggestion. If clients don't feel like they're ready today to make the decision, that's totally fine. I personally just think they both basically go hand in hand in some sense. The idea is to, to overall have a more unified approach to data pricing. Like in Hegotta, to me, makes sense to do both of these. But I mean, yeah, there's more varied ratings. So I just wanted to bring it up as a potential if we wanted to use the time now instead of just ending. Yeah, Tani, do you want to say anything about the coupling of these two? Yeah, can you hear me? Yeah. Yeah. As Ansgar said, I think they should be seen as a bundle because if we only do one of them, then the worst case block size will stay the same. If we do both of them, then basically every byte that we have in the payload will be priced at the floor. Yeah, I think Klein should consider both of them. Okay, given that the recommendation is to couple them, are there any opposing views about just CIFing this with the other one? Does anybody feel like they need more time to look into it since this is not one? that clients were asked to look into before this called drug on? Yeah, I think it should be CFI'd. I think we marked the C because there is slight more complexity with measuring amount of items inside the ball. But it is interesting idea and we should in some way restrict the block size. Basically that was increased by the ball. So CFIing it now, it looks correct. Then we later we can talk about it when they're how to do it and what are drawbacks and everything like that. Okay, then CFI this one going once, going twice. You're fired. so I'll comment in the chat. Justin? Yeah, regarding chat, there's a lot of traffic on set code from. I wouldn't mind hearing from the crowd about the migration path that allows set code from to retire ECDSA keys. I have an entire... Well, it's tiny but explained with images how all of this works. But basically the idea is fairly simple. Here you have the link. You can pull setCodeFrom and you will go to a pure code wallet. If you still want for some reason with a code wallet the EOA filling, you can enable it with frames but it will not be native. If you want to have code in your EOA, you just need to use 7702. So set code from basically allows you to get rid of the EOA and get rid of the delegations and migrate to a full code slash post quantum account or smart account. And if you want, you don't want to go all the way and you want to keep your EOA natively, you can just use 7702 as it is today. So that is mostly it. I'd also like to highlight the second benefit of it, which is when deploying contracts, especially since we've increased the price of it, both in cold data and state gas. If you're doing something, say, like Uniswap v2, v3, where they create liquidity pools, which are identical code. They pay the full gas for the contract, though essentially it's just changing a code hash. with this, you could change it to only paying for a code hash. And one of the ways currently around it is maybe you do a proxy instead, but then you're introducing a double call. And also we've told people not to trust proxies. for sort of a dual benefit. You're gone. The reason why is DFI for us is basically we want to delay decisions related to the change of code, anything related to like after post-quantum thing, after the frames came. Because with frames, have new mechanisms that we need to figure out how they're going to work, how the user is going to basically use them. And The idea is let's delete set code from or anything that's related to AP7702 or setting code or anything other after frame scum. That was the reasoning for the DFIing. Not a strong one, but that's the thinking that we had. Nico? Yeah, I think it's a reasonable thing to do to just wait, but unfortunately, the timing is going to play against us here. Because that would mean pushing these two EITs to I star and then that clashes with a pessimistic or optimistic depending on how you view this quantum transition timeline. So if you take a scenario where like end of 2028, we're doing I star and then we are kind of playing, yeah, we're kind of playing with the risk that sometime in 2028, there is a progress and big headline saying that's two days near and then we would be in a very unfortunate situation. yeah, I do hear the arguments to just want to wait to see frames in actions before going through this, but it's, it then becomes a very risky bet. And this could be an emergency hot forks sometime end of 2020 beginning of 2029. That's. So yeah, basically, think this should go in A star, but yeah, for a timing reason. Just mention this is not strong opinion at all. It's like if people set code from is like even small change to the protocol. So if people clients want to do it, it seems fine to see if I And that would be also the same for 8151. Great, given that we have two more calls to make decisions about these now 10 EIPs. I was going to say we can delay it, but there is a comment that we should CFI it today with a lot of thumbs up. Do we have any opposition to that? Does anybody want to have more time to look into it? I think Beisu might. We have this at the C tier. We are finding these arguments compelling, but maybe not super. be able to more fully make that decision in some time. Ben? Yeah, there was a comment that it wouldn't apply to things like existing Uniswap contracts. And that is correct. But there's no safe way to do that because it requires all of the existing code to be known about. So you couldn't do like a set code hash because some ELs would say, yeah, I do have this code hash. Other ones would say, I don't. And so you'd end up with a consensus split. So that's why it's set code from because you're saying I'm setting my code hash to an account that already exists on chain and that can be verified. Whereas a code hash can't be verified that it's used by an existing account. And you might have that code hash in your code database. Nico, your hand still up? Sorry, was. I'm just going to punt this one to the next call since Basie said that they would like some more time to look into it. And we do have hopefully plenty of time, assuming that GlamStrandAM doesn't take up too much of the next two calls. So we now have 10 EIPs to look into. And I will post a list of those EIPs just to make sure that there's no confusion in the execution depth channel in etherind before the next call. We have three minutes left. Does anybody want to bring up anything else that we have not covered yet? Fantastic. Great job, everybody, today. Okay, see you guys later.