התמלול המלא של Execution Layer Meeting 243 [2026-08-13] | ACDE 243

Neither mind says yes. Yeah. Does that sound okay to you guys? It's purely on the CL. This is all OCL going forward in the gloss one word. yeah, so this should be a CL decision. do we have representatives from the CL here? Prism approved it. Do we have Lighthouse here? they approved the PR into the constant respect repo. okay, did Nimbus Teku and Lodestar weigh in at all? Lodestar implemented it. Great. Teku's ready. That sounds like a majority of clients. Great. I think the only one we haven't heard from is Nimbus, right? duh. Dustin is from Members. Yeah. Dustin, are you I understand it. If the if this is in favor or not. Call it a skeptical neutrality. I mean, look, if as long as it's optional, it's not worse than nothing, I guess. But I but one of the main motivations of this being able to do this kind of staging of gas limits. So plus twenty epochs, plus forty epochs, whatever. I mean, I I know those are schematic numbers and realistically if one wanted to undo that part way through, one would space them out much farther than that, I sure. But even the qua quasi-realistic numbers multiplied by that by ten or more, there's there's not going to be enough time to do the kind of redeployments across across these fleets in a way that wouldn't already be possible with centralized fleet management on some of the larger stakers. so i am I understanding correctly that if a majority of clients are on board with this optional change, that we are safe from the gas limit changing before Clamsterdam in any case? Well we're safe before Cramsterdam anyway. I mean that's sort of none I mean, presumably none of this happens before Kramsterdam. I mean But the question is after Glamsterdam does this is there any advantage, is there a safety advantage in in this decoupling and I'm not particularly convinced, but as long as it's optional, then it's also Well, gif if it's a comforting illusion that people like, then that's fine. I think we should spend no more time on this, please. Okay, great. then we will move forward with with this change. Okay. Kev, are you on the call? hello. yeah, so I just wanted to get opinions from ELs as to how much history they'll be expiring at G Star by default. the question comes from the fact that there's a non-significant amount of two terabyte node operators, and if you don't aggressively Prune history, you're hovering somewhere around 1.5 to 1.8 terabytes. and with 8037, the expected state growth at 150 million gas is roughly 120 gigabytes a year. so it seems that we need to expire history at GSTAR. and yeah, I wanted to get some thoughts on what is the default value that people are going for. On Nethermind side, we store history up to the merch right now, but I think we will drop soon and I would really like to drop at least to Dankun or more because you know like this call data thing and how history history was used before we shipped for a blobs. Yeah, so that's from Nethermind, but probably I would aim even more, like maybe last six months. is Aragon on the call. yeah, so now by default we store the last two hundred sixty-two thousand and something blocks by default. that's EIP eighty-five fifty two. sorry, eighty two fifty two. Well that's about mass and gaff if you're and if Matt's on the call. I think we can find a reasonable cutoff point. I'm not sure what's a good one, but I kinda agree with another mind there. Like Yeah. So we like I think we already have implemented like fork minus one. and we have a PR for rolling history expiry within the like larger than the last a hundred K blocks. okay, so different clients will be doing different strategies. Raf, are you on the call as well? yeah, but I'm not sure what the default is. I don't think it's probably to drop more history. Do we want to hear from Bezu? yeah. I was reading what they wrote in the chat. Bezu currently only drops pre merge blocks. so five months looks like is what you guys might default to for Gamstadam. okay, cool. Yeah, I guess we can potentially just assume that at minimum it will be five months. Ben says we should coordinate to same or syncing history will an issue. yeah, that's a good point. Yeah, I I I don't really mind what the standard is, but it does seem like we need to do it if we're increasing the gas limit for the two terabyte node operators. And I'm guessing the fact that w were there any blockers to this or am I missing something? Like some out of protocol distribution strategy that is needed, or is are we all fine? Seems like most clients do five five months or fork minus one. Right. I see. yeah, definitely we should probably spec this somewhere. I don't know where would be the best place, just to make sure that it gets done for a G star. believe we do have a history expiry channel in ETHRND. yeah, there is a can we then decide on what the norm should be in that channel, have a conversation about where that should be spec'd. Great. so let's converge on a a single number for history expiry in the history expiry channel on Ether and D and decide where that should be spec'd. Does anybody have anything else on Glamsterdam? Great. If not, we will move on to Hagoda. so the the deadline for proposing EIPs was on August 6th. There were quite a number of EIPs that came in last minute, so we have a number of EIPs that will be presented today. one note is that each EIP needs to have a clear champion for people to go Talk to this EIP, talk about the EIP too. if an EIP does not have a clear champion, which most do, when they're brought to the call, we just assume the champion is the person who who proposed it and it brought it to the call. If there's no one to talk about it on a call, then we will not merge it into PFI. so if you are interested in one of these EIPs that has been proposed already by the August 6th deadline being in the in 8081 in Hagoda, then it needs to have a champion. what do clients feel about having a preference list in two ACDE calls in four weeks? the ask is by September

10th. So this list of PFIs should be final. at least by the next call, hopefully today. and so that gives clients two to four weeks to come up with a preference list. Any opposition. Great. then if EL clients can come up with their preference list by September 10th, that would be great. and we can move on to PFIs. I'm gonna ask the champ the proposers of each of these p EIPs to take no longer than four minutes because we do have 17 to get through. we're gonna start off with a few That were proposed by Halcomine, aka A B C 123C. apparently he can't be here today, so I am gonna push on that. if none of these are spoken about on a call, we cannot PFI them. we cannot merge them into 8081. So, does anybody want to speak on behalf of the EIP 7971? Hard limits for transient storage 8058, contract bytecode deduplication discount. Seventy six nine decreased base cost of tea load tea store or seventy-nine seventy three warm account right metering. and there's a fifth one as well. 8360 T create opcode. Can you put them in the chat or go slower or something? Yeah, sorry. I will write them in the chat here. Okay, those ones. If not, I will message Helkmine and ask him if he wants another chance to talk about them on the next A C D E. Otherwise, I will just close the PRs to merge them to eighty eighty one. we'll move on to some by Jalkum. we have we'll start off with EIP seventy-nine twenty-three linear page-based memory costing. Yes, I will share my screen again and I will present them all three within the same slides, and I will time box myself to nine minutes for this. so how do we do this? I will present the EIP, then I will stop four slides to ask if there are any questions and then we will move on. okay, so let's start. first the notes that let me also post these EIPs. Yeah. the notes that EIP seven nine twenty three and EIP EIP four five nine twenty are PI five together with Charles Cooper. he is a Viper compiler developer and this is a big rework is from the EVM compiler community. I wanted to provide that as context. So let's move to the first one. This is EAP 7923. This is linear page-based memory costing. And what does it do? The current EVM prices prices the memory allocation quadratically. You can see the memory allocation from the yellow paper costs below. So you can see the quadratic element and the notice here that this A is the amount of words in the EVM, which are thirty-two bytes or five hundred and twelve bit worse. Wait, that's actually a mistake because it is two hundred and fifty-six, of course. this was done, I believe, in Chainstart to prevent a denial of service attack on a node memory. And this was because in the Chainstart on Frontier there was no EIP 7825, which is the transaction gas limit cap, which we shipped in Fusaka. So it would make sense to actually cap this thing with this like this quadratic gas cost pump so you bounce your memory allocation by the by a square root square root relation. so why do we want to do this? This

is like a fair guess pricing of the EVM memory because we believe that the quadratic bound can be removed due to the implied EIP 7825 transaction execution gas limit bounds because we should be careful since the EIP eighteen thirty seven now introduces both execution gas and state gas but we are talking about the execution gas and the execution guess is still limited to the EIP seven eight twenty five Pound of sixteen point seven million. So from my side, there's actually some report which I'm currently writing. I want a report on the maximum reachable allocatable EVM memory within these transaction limits. This is currently within one call frame, approximate three megabytes. But this is of course not the worst case what we could do here, because we can of course spawn multiple call frames to benefit from the linear gas cost. of these call frames. So I want to update the EIP spec and that is the EIP 7923 to also remove a memory cap which is implied by the current spec of this EIP. this will also simplify this EIP and I will also write this report on the maximum allocatable EVM memory if we will introduce this this linear memory cost and I want to deliver this via if you additions in two weeks so before the next ACDE. yeah. Questions? Okay, I guess not. Well, I took the first one in three minutes, so that's nice. okay, the next one is EIP two three two nine eight, this removal of refunds. Marius already asking, isn't EIP three three two nine eight pretty outdated? Yes, it is, but we can just solve it since EIP. and if we really want it, I can also just fork this EIP and create a new one. But the the intention of this is to remove the refunds. So what is it? We currently have only a few spots in the EVM where we have refunds. As of Fusaka. This is the storage set which we set from a non-zero storage value to a zero value. And this is the EAP seven seven two. So this is the the account well the the the tx type four transaction type which creates a delegation of to existing accounts because if your account already exists, you get a a revamp at the five at the end of your transaction because currently you pay twenty five thousand gas. For upfront, so as intrinsic, and you get twelve thousand five hundred back in case if your account already exists. and now my mouse is not working. Wait, it is. I did not check for Glamstam. If there are any new reasons introduced, but I believe that these are like a marginal and not there. So why do we want to do this? This gas cost calculation is well, I would say extremely complicated because we also have like call data floor gas. And the question is when do we apply this refunds? So we apply them before the floor gas, after the floor gas. Of course, this is well specified, but this is just not so obvious. so that's not points. and where does this max max cap apply to? So is this like the floor gas? Is it the execution gas, etc., etc. This is well specified, but it still complicated, I would say. these refunds are also not super effective because EIP three five two nine, the reduction in refunds, this has been activated in the London fork. Is this capsule reference at only 20%. this introduced like a divisor, which is coefficient five. And before this, this was actually 50%. So you could get 50% of your transaction gas used back in refunds, which is of course very nice. But this was used slash abused by the guest token for the people who remember this. And in Glamster we also have this EIP seven seven seven seven seven seven eight. Which is the broadcast accounting without refinance to already ensure that well we I would say we somewhat deprecate revamp already. and this ID is originally for state EVN, so you clean up after use, which is like a very nice idea, I would say. but I would say it is fin line not interesting anymore to clean to do cleanup after use, also after Glamson and Fork. And this is the very nice part because this simplifies EVM because we just throw out all these complicated rules. Okay, questions. I see LED times points. Yeah, it's indeed a very very nice thing because it just simplifies things. Then was question how many reference tests will this remove? I don't know, but I would say a lot because I think I can speak for the execution specs that this is also complicated to test and like in many edge cases. And I see that the dragon has has his hands up. yeah. there is two types of refunds. There is refund for the clearing storage, there is a refund when you reset something to the original. I think the the clearing part should be removed and we should stay with the part that resets the value to original value. That means that we if we have only that reset refund, that means we don't need to cap it one fifth. We can remove this kind of of cases there. But I think the main problem is about getting refund by clearing storage, basic going from X to zero from original X to zero. so maybe to ask you want to keep this. I want to remove only that refund because I think that refund is problematic. Refund that we have when you do A to B, B to A, basically you refund gas because you're you're reverting back to original value. I think that should stay. I think it's like good c in calculation. Yes, I I think I actually agree with this. and indeed I want to remove this storage refund, and maybe also see like how we can can somewhat simplify this. because I also do think like I mentioned as EIP seven seven two, but I do believe that that this should get like some kind of refund, but maybe in like a less complicated matter. I propose that we discuss this async. Okay, cool. Thanks a lot. All right, I will move on because now I only have one minute for the pay up code, which I will sadly go above. But I had four minutes, so it can go to self. Okay, so the pay up code, what is this? the question is how do you currently send Ethereum to an external foreign untrusted account? And this means currently that you must execute code unless you use like this very

weird pattern. This is like a great pattern and a self destruct pattern, because this allows you to inject Ethereum. Into an account without executing code. this is not nice and this is also like very expensive. And we also have PFI'd EIP 4758 for Agota. Nixo, I already want to mention because you said these EIPs need a champion. If there is no because I don't know when this EIP was PFI'd, but if there's no champion, then I will champion this EIP for this specific purpose. okay. yes, so the executing of foreign code, it also wasted gas if you were to use the normal way to send EV. This is via the call of code. so you will do a call and you would send value with this. but you would also waste the gas because if your only intent is to send Eve, then you don't want to execute any code, you just want to send this EV and be done with it. And of course another pattern would be to use web Ethereum, but well, this also complicates things. So why do we do this? This Opcode massively simplifies also the security risk assessment of contract audits because if you send Ethereum, you already you already have to to to audit for the pack that you are going to execute for encode, which is not nice. this also creates this logical alternative for the scrape two or the scrape plus self-destruct pattern, which aligns with deleting or deactivating self-destruct in EIP four seven fifty-eight. And I personally believe that this upcode should already be There since Team Start and Frontier. And if my mouse works, yeah, I will say shoot it. yeah, questions? and I see that Nix so mentioned that this was already proposed. Okay, sorry, then I don't want to propose it again, but I will champion this as well if there's no champion anymore for this year. All right, thanks. I took ten and a half minutes, if there are no questions. All right. Thanks, Jacob. we can move on to Dragon's PFIs, eighty thirty f eighty eighty three fifty-eight net gas metering for account changes. yeah, this CIP basically discounts the gas used for when you have call opcode with value. It checks if the target of the call was changed before and call the and checks if collie was changed before. That means we can save like four K of gas if both of of are changed. Additionally that's the because of the gas stiffen that we have inside the calls, it adds minimal gas that needs to be sent to the caller. And at that in calculating how much gas needs to be spent on the collie side. That's basically that's optimization. anybody had questions around this? That's the first stepy. don't know exact number. Okay, if no questions on this one, you can move on to the next one, eighty-three seventy-four persist warm access across. This is the next one. this is about not reverting access lists. I think future we will have I think future we will want to have like access across all the blocks. I think this is like first small step towards that. I the in in essence is if you are al the load loading account of the s or the storage, you don't want even if revert happens, even if the hold happens, you don't want to basic you're not like deleting that storage from the cache. So it's most more accurate for that account or storage to stay in the X list. That's basically the IP. any question on that? If not, we can move on. That will be it for me. I know. do you have any actual implementations for 8374? I just remember from back when I was doing EVM stuff that those were some of the most finicky and flaky tests and was being written because of the the way reverts work when you're trying to do anything clever. I just want to know if you have any scoping on how hard it's gonna be support to support both modes across multiple forks. Mm. I don't have anything, but from looking at the code is basically just skipping that loading. I think the ball cleared a lot of those cases because we have a lot of fetch cases that need to be implemented with the ball, depending if you have enough gas to load something or not load something. So I think this is those kind of fetch cases are like cleared. That's why I think it's These should be smaller change. But I mean that's that's great if you only have to support post Hegata, but when you need to have a VM that does Glancer Down and Hegaton in the same binary, it can be problematic. I don't know. I mean it's basically but I just want to raise a concern that this might be bigger than it looks. Yeah, but this basically should be do you create if the Hegata is activated, do you create journal entry or not? Or d on even if you do reverts, do you skip The the I think all the clients, all the VMs have separate hash met for the access list. It's basically don't touch, don't remove anything from it. Right. But when you're trying to do clever optimization things, those become very fragile. I'm just, you know, I'm not not gonna just wanna put in people's mind that this is bigger than it looks and it's probably started early. Okay. Okay. Any more questions on this one? Okay. next we have eighty three sixty-eight. This one was proposed by Maria. she I think is not on the call today. but Tony, do you want to say anything about this? if Yeah. I can I can quickly provide a heads up for that EAP. It's a very simple one. It's basically a recalibration of the constant we introduced in eighty thirty seven. And it's needed because if you remember we in Salbot we took out this dynamic recalibration of the of this variable. So we agreed on if we want to scale the gas limit, we have to touch that constant again, but it's a very small change and depending on what we do with the gas limit in Hagatter, we should CFI it in the meantime. And yeah, this is then with the data repricing EAPs, basically the EAPs we think we might need to push toward six hundred million gas limit. Because apart from that, I think we are mostly mostly ready. Thanks. Thank you, Tani. and Maria may take the opportunity to talk about it on the next A C D when she's able to attend. There are

no questions on that one. We'll move on to Chava's EIPs. We have eighty seventy seven, ETH hash, blob aware mempool, and eighty ninety four announced transactions with non Thank you. Yeah. Yeah. So in that description I was actually mix mixing up the numbers. So as Ansgar noted to me. So eighty nine eighty nine four is the blah blah blah mampool. I will start with that one. yeah, thanks, Ansgar. So what to know about this one is that here the goal was to make the mempool more efficient by avoiding a nasty redistribution of traffic in case that is is by fee for blob traffic. the machinery that was described is very similar to what we were then putting into spa's bob pool so I think maybe ninety percent common. So I'm actually still thinking whether to remove this EIP or focus on the differences. I do think that we should do have the the LBF cheap. I think we can bolt most of it on top of the the current version of the Smashbot pool. a few changes might still be needed. So I was PFI ing it because of the goal. but it might be that we managed to do it. simply as possible pool. If the change is needed, then it will be done in this EIP. They are the one. So the other one, which is called 8077, which is the so what's the rational there? in the MAM pool for transactions, we basically now have two levels of messaging. One is at the level of the whole transaction, the other is just at the level of transaction hashes, which has no information at all about what that transaction is. we have a little bit of metadata. about the the type and the size, but that's it. That still does nothing about what that transaction is. And that creates problems if and when we want to scare the mampole. Now if we want to go up with with the gas We might also want to scale the public mempool. I've seen different opinions on this, but I I I would like to have a public mempool which is scaling nicely with these numbers. And then we have the problem that nodes only see hashes and have no idea what's behind those hashes. So either they randomly pull hashes or well, they randomly pull hashes, they don't have any other choice. So the what is proposed here is to add, besides the hash, add some metadata. To the announcement so that nodes can do more intelligence decisions in the mempool logic. I think it's needed for scaling. let's see what people think. I just mentioned metadata. there are different variants here. metadata can be nonsense, just non cyses cannot be. it's it can be adds and nonce. there were also discussions on including fees or not. it's also to be said that there are small transactions where if you add this metadata, you are basically having all the content. So at that point you would just push the transaction. That is also that transaction size. So this is what what makes sense is very much transaction size dependent. I see lots of text in the in the chat, but if yeah, if there are questions actually happy to answer. Otherwise we can move on and I will lead through the chat. Nobody wants to ask any questions, we'll move on. to Dano's proposed EIP eighty three fifty five precompiles for ML DSA verification. And where's chat? Let me post this. the prom window. Ragmond, that's better. And here's the presentation link. So I'm proposing MLDSA precompiles. I'm proposing just the simple FIPS 204 variant of it, which is the one that basically you're gonna find very easily places to implement it. So my first part of the argument is that MLDSA is the most widely used by far post-quantum cryptography algorithm today, and it probably will be for years. it's been finalized in August. there was a competitor that would be really great for blockchain called Falcon. Unfortunately, that is stuck in standards never never land. who knows if it'll get out. And the other alternative, SLHDSA, is only recommended for firmware signing. And my understanding is that the XMSS variants are much more favored within Ethereum there. The cloud management systems on Google and Amazon already have full support for for MLDSA. Azure and Oracle are lagging, but there is external solutions such as Thales that you can use. But another big thing is hardwork security modules. If you don't want to use cloud, if you want to plug something into your computer, those are the big names for HSMs that you can plug into your computer and get. But I think a more telling thing of how widely used it is. TLS 1.3 uses it, X509 uses it. Web Auth n the current draft uses it and they use the FIPS for the two formulations. So from this, this is probably the best news for people implementing this is clients should not be writing this cryptography. Every single client language out there and ones that would be relevant have MLDSA built in, or by the time Hegataships will have it built in. Goes is still in the release candidate.NET, Java shipping at the baseline, Rust has some really high quality libraries, although they not might not be core, the reference implementations in C. Node.js has put it in the 2470 and it's starting to show up in browser natives. You can, of course, compile your Rust program into web, into the various JavaScript web formats. It's kind of big, so you'll want to use the native format there. And if we're using the standard that the rest of the world uses, we don't have to worry about corner cases like what happened with Kachak. So we don't have to bring our own cryptography with it. We just use what exists in place. So we don't have to bring megabytes of our of our of our WASM code. interrupt test vectors already exist for these because it's the standard. And they include the type of implementation errors that caught us in the early days when we were implementing our own SUCP256K1, with ones where they had you know tests that were multiple things were wrong, but we thought they were testing only one. So these test vectors that they have available, test these common implementation errors, they're properly isolated. So if you don't have all the

corner cases, you're gonna fail something. So the only new test we'd really need to write are tests that we know very well how to write, pre-compile bindings and gas costing. Those are things that we are very well experienced with. and finally, there are some divergences. There was a prior MLDSA pre compiled proposal, but there are some key things that I diverged with in this. the biggest thing being is the theme, I am sticking with FIPS 204. If the decision is a FIPS 204 thing, We go with it. We use the compressed key, not the 20k expanded key. we provide all security levels, not just MLDSA 44. it's important to note that this is a hedge in case there's more crypto analytic research that brings the security bits down. they keep hacking at it. and nothing's brought it down below level two yet, but you know, if we're gonna put stuff in here for potentially 10, 15 years, we need to be aware of that. we're also using the full width message, unlike MLDSA, unlike the SECP, unlike the ECICS ones, it hashes over the whole message, not just the hash of it. The hashing is built into it. So the API in this particular EIP accepts messages of arbitrary size. But in practice, we're still going to assign TX hashes. So we don't have to use the full-size messages. And finally, only the FIPS hash functions are used. So it's going to be all internal to these libraries. We're not trying to make an exploded version of this that we can run inside the EVM. This is meant to be a pre-compile. so those are, you know, in the interest of time, those are the high speed three-level arguments. So I think now's the right time for an MLDS pre-compile. And of course, this can be used for 8141. It can be used for online DAOs, is as a substitute for EC Recover. I'm not proposing that we put it directly in the transaction formats. I think that's a bit too far. So So Ansgar said, really low context comment, but the fact there was a power EIP indicates there's a non-trivial design space. How would we make sure that the version we ship now is the optimal one? So that design space was mostly focusing on the idea of implementing MLDSA in raw EVM bytes. And I think it was a valuable experiment to go through because it cost millions, you five to nine million if we used it as specified. So the design space there shows that some of the Compatibility, just you know, we would need to have a SHA-3, not a shack hash. And that would you know solve a lot of the problems there. But the EVM is just not set up for bit twiddling. Kevin asks, it's not clear to me that we need three new precompiles for different signature variants with different security levels. Not everyone is comfortable with with security level two. some people are gonna want the higher level security levels. I think the only reason we only have one security level of EC Recover. Is because our the the size of the registers in the stack was 256 bits. And the way you get more security and elliptic curve is you go up to 384 bits, and we thrash for years trying to figure out how to do that. So by bringing it as a pre-compile, I think we get it day one and it's clear how how we can use it. Some people are gonna want to use the 65 or the 87 variant instead of the 44. for a while there, Google didn't even ship MLDSA 44 in their trials. And Justin has his hand up. I noticed that there was a a section there on not including the hash inside the algorithm. And with like a lot of this PQ stuff, it's all about the space as far as like how do we wedge this into Ethereum with all the space that increases. Are there any other aspects of this that allow us to control the size of these signatures? Or the output of the precompiles? the output of the precompile is gonna be passfail. it's it's the message size. and the signature size and the key size. So the biggest thing that this recompile does that the old 8051 does is we use the FIPS 204 encoding, which is on the order of like, you know, two, three, four kilobytes rather than 20 kilobytes. And the reason that expansion was done in 8054 is to remove a bunch of bit swidling and verifying the signature. The EVM is not terribly efficient for large scale ships into odd sized bit sizes. So that was you know that was a optimization done to facilitate the EVM. but as far as as far as the sizes, I have one thing we could do is if there's ways to store the public key on chain, you could do validations by just providing a signature. I have unrelated to this, I have a change to the set delegate opcode that would allow you to set data on that and you could set your public key there. Or you could just deploy a contract there. Storing it in S load S store data is gonna be kind of expensive because you gotta break it down into thirty two byte sections, which is problematic. Thanks. I'm interested in that public key storage. I'll talk to you offline. Okay. Great. Thank you, Dano. we will move on to Anders proposed EAP eighty three seventy two normalized state gas limit. Can you see my screen? Yes, we can. Okay, great. So maybe I should yeah okay. Maybe I should expand it. Let's see. I can do so. Yeah, do you see it, Fulla? Yes. Okay, great. Yeah. So the problem we are facing is that we don't know whether users will spend 50% of their gas budget on state creation of the Glamstadam. And so ideally, we would have this situation where users spend around 50% on execution gas and 50% on state gas. And in this case, we can do this EIP 8368. However, We might find ourselves in a situation where demand for state creation is relatively low. In this case, we will be creating too little state gas at the cost that we have provided. We might also find ourselves in a situation where demand for state creation is relatively high. And in this case, we will be creating too little execution gas or buying too little execution gas because we will be suppressing execution via the max metering function. Of EIP eighty thirty-seven. And if we observe these two failure modes after

we have gone into Glamsterdam and as we are approaching H, we can instead then do EIP eighty-three seventy-two. And this EIP is very simple. It's just a one-time calibration at the fault boundary where we add another constant so that we can change the cost per state byte and at the same time normalize the limit of the gas, of the state gas. So if we are in this situation situation where we create two little state bytes, we would instead reduce the cost per state state byte and at the same time. also reduce the limit such that we can consume a correct amount of state bytes. At the same time, if we are in this failure mode here, we will be increasing the cost per state gas per state byte and at the same time expanding the limit such that we can consume more execution gas. And in practice, this is done by measuring the state gas used in normalized units. And I think I stopped there. So that's That's the the gist of it. Thank you, Andrews. Do we have any questions? Yeah, okay. I've I've I've I've maybe one because this also seems to imply that we then have some kind of creation target that we target a specific amount of state. I'm is this correct? Because I'm I'm not really sure if we if we want to to do that. Yeah, so it would be a target just like we have in EIP eighty three sixty eight. and we would be adjusting this target exactly the same way. But we would also be normalizing the the the the gas used so that we can target things more correctly based on observed demand. Yeah, okay, I see. This would indeed also more fairly price is. Yeah. Okay, I see. Thanks. Yeah, and so maybe as a reference I can say that we had an AIP eighty seventy five that does this automatically previously, with a floating price. And then you can ups adjust for all the failure modes directly. But here we we have this simple fixed fixed solution also then. Great. Thank you, Anders. we will move on to Ben's EIP eighty three seventy-five, EPBS mandatory burn of execution rewards or ember. Okay. So the idea is to reduce the security impact of unusually large execution rewards. It burns protocol visible execution value, but isn't explicitly trying to solve or measure all all math. say burn thirty percent or something. So there's still an incentive to pick, you know, the best bid. there's three pieces. universal Priority fee burn, external builder burn target, and a PDC observed floor. so at the moment nothing is burned, nobody declare nobody loses anything by declaring the MEV honestly. the builder competition keeps the declared bridge near true value. However, if we introduce a burn, every builder proposed a pair gains by declaring a low low value and side paying to to avoid the burn. And so we wanna we wanna keep it as as declared. So we we can't rely on what the winning pair is saying their their bid is. Self building only works off the priority fees, so and that's needed to to have a base floor. and then we introduce a PDC where the a new role for the PDC where they report

their best public bids that they saw. and then that forms a a second floor. And then the external bids need to be they need to burn at least a slight haircut off whatever's whatever the higher floor is. Yeah. That's that's probably probably all. as I say, it doesn't doesn't solve all old MAV, but it solves well, sorry, it burns it sort of flattens out the MAV that's that's available. That's already. There's a lot of conversation in the chat. Does anybody wanna Ask any questions. there's a question on st incentive for a proposal to create recreate today's self-build path. Use the builder path to avoid the burn. that's why there's that's why there's the PDC observations of you know what what are the bids to put a floor on that. and also the priority if we use cause a floor as well. So if there's extra on a side channel, you know, obviously we can't observe it, but at least they're paying what the minimum should be. and you have a risk doing it via a side channel. So hopefully it that that's also why it's why I'm saying it's something like thirty percent so that it's not onerous to avoid. Light client also had a comment. I feel like we should see how EPBS ends up getting used in practice before building on top of it. I worry that even with Glamsterdam, many builders will circumvent EPBS. To have a reply to that. Okay. That can be chatted about async, but if nobody has any questions they want to ask, we'll move on to the next EIP. this one's EIP eighty two nineteen, checked arithmetic opcodes. Yeah, hi everyone. so basically the main most basic DeFi operation, would argue, is like an addition. And if in Solidity you do A plus B, as most of you are probably aware, on EVM level you're doing something way more complicated because you're doing these safe mass checks. So what the CIP is basically proposing is that so much great optimization work has been done, but we can also try to optimize what is commonly being used by smart contracts, as in introduce Safe opcodes. So opcodes that do safe addition, save subtraction, save multiplication, and safe division. So as an example, there's the definition of safe addition here, where you compute the result, and if the result indicates that you did an overflow, you revert with zero zero, and otherwise you just continue. So you basically have an addition. If we check what this if we kind of look what this does when we compare to kind of Solidity and Viper with optimization enabled, first of all, what we're saving is we're saving a lot of execution gas because like on Solidity currently one of these additions costs 79 gas, Viper a bit less. So we have like a very significant execution. gas reduction for every addition plus we are reducing bytecode size plus we are reducing deployment costs because we are reducing bytecode size. so when I first or when yeah so why are we not doing certain things just maybe really quickly so the goal is really to have a single opcode for this checked arithmetic. So there were previous proposals for example to introduce an overflow bit or something like that. But then you still need to branch on that. That doesn't really kind of solve the problem from our perspective. and why should we revert? Because like currently that's what developers expect when they have a failing self destruct sorry, failing safe air arithmetic. And this is then kind of providing the functionality that that is needed in practice. if people feel like that's some of the early feedback we got, that four new opcodes are completely unreasonable and will never fly, then we would alternatively propose to introduce one new opcode, which would be this checked opcode plus a one byte intermediate, where then yeah, the the one byte intermediate tells what kind of safe addition it is. And The this would have the downside that of course the bytecode size reduction is not as significant. But then we could perform we could also do safe addition for some other data types, smaller data types. Yeah, that's basically gas cost we briefly benchmarked and more or less stays the same as normal arithmetic operations. Sorry for the noise in the background. So yeah, I guess what we're really interested in is whether people think it's a good idea, whether it's precare at all, and whether people think the four opquals is anyway unreasonable and that's why we should push for the one open question. Thanks. Yeah. So one thing that crosses my mind is that neither RISC-V nor WASM have checked addition, multiplication, basic arithmetic, and they don't expose the overflow fields either. If we're moving the EVM to RISC base, the one thing I think we should consider is is it wise to do things that aren't represented in opcodes in the target systems in the EVM? something we should think about. And my second question is kind of related to that. with the gas limits going up. And with the cost per bot per gas going down, is shaving off and engulfing our gas as essential as it used to be. Yeah, of course that's up for discussion exactly here. So I mean to me, yeah, going from eighty bytes to five bytes for what is probably I would argue the most important DeFi operation to me is worth it, but I I very much understand that this is yeah, point that can be freely discussed as. sorry, I don't fully understand the qu the question with the compilers. Can't delight some of the tricks. But the yeah, thanks for the feedback regarding for the other feedback in the chat. Yes. Thanks. Do we want to ask any questions synchronously? Anybody? Great. so those are all of the proposed EIPs for Hagoda. I want to move on to frames. So just as a as a another catch up, the situation with frames with native AA is basically on A C D E two thirty three. that was in March. There was consensus that native AA was important to include in this fork, but there wasn't consensus on the specific specific implementation of native AA. following that, there was a breakout call or two. and I want to restart the conversation

today about basically what clients think now about frames if it's the Native AAA implementation that we want to go after. Nethermind posted a stance that they have they are now behind frames as the specific implementation that we want to do with native AAA. Yeah, we'd we'd support it as headliner now. Great. does any other Does any other client want to say anything at this moment? They we don't need decisions today. Matt and Mark, I think we'll be hosting a restarting that AA breakout. but if any clients today feel like they can support frames as the specific implementation, please speak up now. August twenty fifth, E the clock, that's fourteen UTC. Those AA print those AAA calls are starting again. Marius? Yeah, I don't really want to speak for for the guest team, because I think it's it's clear that this this proposal is heavily championed by the guest team already. I think from a personal point of view, I was quite skeptical of frames when it was inf when it was first introduced, but the last couple of weeks and months have shown that in order to get everyone to PQ readiness, frames is a very important part of that. So that that slipped me very much in favor of shipping frames. Aragon, Basie, Rath, anyone to s anyone who wanna say anything about it? as far as Bayes is concerned, we are not in opposition to any of this and happy to work on Okay, great. yeah, so decision sequencing. Thank you, Anskar. the first decision should be is is framed specifically the implementation that we want to go after f after for AA, native AA. And then the whether or not to make that a headliner follows that. I think that first we should converge on whether or not it should be the specific limitation for that. We kind of need a majority of execution clients to be behind this. Right now we have Geth and Nethermind. Beisu is sounds like not in opposition. Reth is in my conversations with them taking no stance. Aragon I believe was supportive. Aragon, can you is anybody from Aragon here? Yeah, yeah, yeah. Okay. Etherex is in support. Do we want to lock it in as actually before before we hit that, I do want to highlight a conversation or a a comment that was made by an EVM somebody working with the EVM, they basically said, I want to flag the 8141 as a breaking protocol change to accounts, and chains that don't hard fork it can't run it despite several deep evaluations across different teams. The EVM ecosystem has not converged on frames, enshrining it on L1 without that convergent risks, large portions of EVM activity running an incompatible account standard with wallets forced to target two incompatible methods. and then they proposed 8130. I haven't looked into that as an alternative. However, it is too late to propose that as a standalone EIP in Hagoda. I will ask Matt if there has been any conversation about EVM incompatibility and how this is how this is being addressed. I think I think that might be on the call. Is that Chris? Maybe not. Yeah, I'm not familiar

with this person. They said they couldn't make it. Chris is on the call. I think like I'll I'll let base speak for themselves for eighty one thirty-one. Just to voice a little bit the side of L2s is we're very worried about throughput and DOS attack vectors within eighty-one forty-one. So we would be for eighty-one thirty or eighty-one forty-one, either way, for eighty-one forty-one for Like our L2s to support it, we would need some modifications. That is either the concept of a guarantor model, so someone that is willing to pay the gas if the transaction reverts, or to have static verify frames, and that's something we would need to support eighty one forty one for an L two. Hi, I think my mic's working now. Yes, we can hear you. yeah, so th that that was my comment there. 8130 was proposed earlier in the year. spoke on some breakouts. and yeah, basically just just kind of wanted to flag. I know this kind of we're moving moving towards these I I just wanna leave the door open for a final breakout with like an actual comparison because like 8130, if you do give it a review, does you know, can satisfy all of the like long-term goals of Ethereum. I believe it's a more complete post quantum standard. there's no follow-up EIPs required, other than you know, selecting a proper algorithm for post quantum, but EOA deprecation, seven seven two deprecation is all a part of the spec. We're we're launching it on Basin Arbitrum. that was after an 8141 deep dive. and just want to f like basically f like you know, do one more like deep comparison on all all of the potential metrics here and I I guess that's, you know, it's it's not here for today, but I can I I plan on, you know, joining the the the breakout calls with you know, comparisons on every kind of metric. Yeah. So the other thing is maybe I remember this wrong, but as far as I remember in March what we decided was that native AA itself would be proposed for inclusion, not a specific EIP. So while I'm okay with either EIP, I think it's healthy to have the discussion of eighty one thirty or eighty one forty one and I don't think the fact that it wasn't proposed should exclude it, considering how we decided to include it. So it sounds like there's there's rough consensus among clients, but not necessarily among ecosystem builders. can we say that since the the breakout call is on the 25th, can we aim to have a decision and have some of these concerns addressed on that call and then on the next ACDE on the twenty-seventh? make a decision about specific implementation, whether or not we go with frames, and we could well probably also make a headliner decision on that call. Yeah. I will note that eighty one forty one, as far as I understand, is still very much in flux. So it's kind of like I I I specifically as like off chain, I I I don't have a problem with eighty one forty one. I do have big problems with eighty one forty one as it's currently written. there are some talks to make it into something better, but like saying I you know I I can back eighty one forty one but not but not as it's currently written. there there are certainly things that can be made, including ideas it should take from eighty one hundred thirty, that would make it much better. Mislav has a question, what's the court complaint as it's currently written? So as it's currently written, it's very, very hard for so the general idea, right, is that Eddie one forty one is for a world where block builders are these entities that are very powerful because they gain a lot of money from block building. And in L2s that's not at all the state. Sequencers don't gain money from building blocks. So sequencers need to protect themselves against things like transactions becoming invalid after you want to include them and things like that. there are the current signature scheme is really I don't like it. And again There are a few problems with it. Maybe on that point, something that we stated from the start in this proposal is that for situations where the block building is highly centralized, like on L2s, you can impose arbitrary limits on on the transactions that you deem includable. And we spend a lot of time thinking about what is possible within such limits. So the proposal itself allows arbitrary sequences of frames and frame modes, given that by the end of the transaction the sender and gas payment is done, but this doesn't mean that you have to accept arbitrary transactions. You can fully control what you accept into the blocks. And so we feel like this property reduces the possibility of DOS. So that that I do like, you know, I I I think frames has improved in that regard. But what frames doesn't do well is it's still yes, like the default account mode is there. What eighty one thirty like allows is basically a much more general, flexible account for that for the good case. So L two UX, which is I mean you could ultimately argue L2s are for UX remains good. You get full key rotation, you know, fully pro programmable accounts, et cetera. and we're not left with like, you're L2, you can only do this and that kind of thing. Whereas I think the better approach is 8130 saying validation is declared structurally in the transaction. The nodes, be it L2, can then fast path any you know cryptographic signature they want to validate. And then L1, which is has the additional requirement to support fossil, permissionless paymaster, permissionless, you know, privacy systems for transaction inclusion, would have a larger authenticator set. And those we've already, you know, those have been scoped out and and and have examples in code already. And they do operate on a very similar model to frames. the only additional system here is the like key store, which does have like, you know, it is meant to be used for cross-chain syncing of accounts and everything as well. so it's not just you know, extra baggage. I do think like the key store, and I think other people have named it other things in

the past, like auth manager or something like that, but like that idea does bring a lot of benefits. Yeah, we were thinking about this trying to somehow make it possible to use something like that together with frames. And I still think it is possible. And if there is something in eight one four one that would prohibit you from using this type of account storage with eight one four one, then we should resolve this. But we do feel that the frames is the more flexible proposal in that you can the accounts themselves are like in charge of figuring out how they should be validated. But if there is some way for us to make these two things compatible, like having basically having the some kind of delegation that indexes into the account key storage contract table, then I'd also be in favor of adding that somehow. So I what I wanna mostly I made this comment because I wanted to say that yeah, I recognize that this idea is interesting and can be very powerful to have the standardized mechanism for storing the user keys. It's just that with A one for one we also have like a bunch of other goals and so we didn't wanna put just focus too much on this like how the keys will be stored in the end. Yeah. I I think with Like, you know, adding that key store system though, like does, you know, 8130 doesn't have any new opcodes, doesn't have any changes to the EVM. Accounts are portable. Like 8130 accounts will work on 8141. They just have their key information in the key store, and then they have to do the you know approve opcode or whatever. going the other way, like obviously we don't won't have an opcode. So like that those accounts kind of break that way. But yeah, w what once you have that, like the the actual like execution of validation can be I think frames does support like the like end of transaction validation, which is something that eighty one thirty doesn't support. So like you do have to have the the validation is only at the start of the transaction. Yeah, for us this is pretty important actually to have this like transaction assertions and things like that. So we kinda this is something that came into the eight one four four four one proposal kind of late and we are very, very This is for us this is like a very important goal to enable users to specify the post conditions of the transaction. And that's just one of the reasons why we feel like eight one four one gives you gives us a platform to do that. It is not just about making the signatures flexible, it is also about making the execution path more flexible. And I think this is something in eight one eighty one thirty doesn't yeah, it does not concern with that. Okay. I I'm gonna jump in here because we have one minute left in this call. I don't think that we are quite ready to lock this in because we have one one minute left and there's still quite a lot of conversation. So I am going to say that it is probably the best path forward if we go to this AA call on the twenty fifth. please bring your concerns there and I am asking that breakout call to please come out with a conclusion to the twenty-seventh ACDE. it sounds like some bridges can be built between these two between between these two EIPs. does anybody have any comments, opposition about that path forward, Matt? Yeah, just wanted to know like the ACD after this breakout. How will we decide what the path forward is? I would love if the if the AA breakout comes with some consensus between the the core devs and these ecosystem builders. it sounds like there's pretty strong pushback from the L2s. I think that Onskar. No, yeah, I mean I just wanted to say, also, you know, because ultimately I think the decision will be kind of like an L one kind of like side decision. So I I I would at least encourage with the L2s. I think a lot of the concerns are valid. I do personally like this direction of just you know, like if if there is small modifications, small extensions of frame transactions that would just make it much easier to To use de risked on the L two side as well. I think basically like using the breakout not just for like a general discussion around should we do this, like what are argument why don't we like this, but ideally some sort of like what would we want to see changed so that we could be more at peace with it. I think th that would be very productive use of the breakout. Yeah, I think that's a good goal. I think it is just like a bit difficult to to reach, you know, total consensus on this topic because it's obviously a topic that has existed for a very long time and people have different opinions on it. And I think, you know, we're arguing from different perspectives. Like base has already shipped eighty-one thirty and mainnet is not shipped anything yet. And I think that like base always has the you know, the incentive to argue to deliver the thing that they've kind of already delivered and have invested the resources in, whereas like L one has different incentivization. So at the end of the day, like we need to do what is best on L one. And I want it to be something that is supported across L2s, and I want to do what we need in frame so that people are happy. but at the end of the day, like it's gonna, you know, everyone's gonna be a bit unhappy. You know, that's just the way that controversial EIPs end up. And so we need to be ready for that. And you know, we spend a lot of time to get client teams to support frames. And there has been a lot of concessions and a lot of iterations. So I don't want to like lose the progress that we've made here and not change anything for Ethereum. Yeah. I'll just add like I think everyone does want native A on L one. and I like the long term Ethereum goals ever I'm very aligned with. and I you know I do want that. Like no A, I would rather have eight one four one on L one. Absolutely. but I I just like genuinely believe eighty one thirty is a can can satisfy the same long term goals in a way that ultimately is like more performant and it doesn't make compromises that are hard to come back from. I believe like having the validation explicit structurally in the transaction type does allow for just structural optimizations throughout clients. and and we'll continue to like even as we roll out maybe new validation mechanisms, it's much easier to have that explicit in the transaction. Okay. We are four or five minutes over, so I am going to defer this to the AA breakout. please come with some sort of conclusion from the AA breakout. Again, that's on the twenty fifth at fourteen UTC. Thank you everyone.