All Core Devs - Execution #243

Transcript

Pooja Ranjan: I nixo. Akash is here to stream the call today. Let us know whenever we are ready.

Nixo: Thanks, Pooja.

Justin Florentine: Good morning, Execution friends!

Nixo: Good morning, guys. Give it just a few more minutes before we get started.

Jochem Brouwer: Just the testing. Can everyone hear me?

Nixo: Sure, sure can.

Jochem Brouwer: Thank you.

Nixo: Okay, I think we can get started. Akash, are we ready?

Akash | ECH: Yeah, we are lied.

Nixo: Great, thank you. Welcome, everybody, to All Core Devs Execution Number 243, today's August 13th. We'll get started with some DevNet 8s, aka Plata Burget, updates from Barnabas.

Barnabas Busa: Sure. Mmm. We launched, just a couple of hours ago. We are currently still on… Fulu. We will have Gloas activated in about a week. So if you're running a… Validator, and you would like to test, Gloas, please make sure you make a deposit, into the network, and that your deposit will reach, before the Gloas, Goes live? Also, if you're running a builder, and you would like to test the fork transition. Then, make sure that you get onboarded before… Before we hit Gloas. It's also possible, of course, to get onboarded after Gloas, but just for the sake of testing before transition. Yeah, it's probably easier, or it's probably better to make the deposits before. So, blast will go live next week, Thursday, at 7.50 a.m. UTC time.

Yep, that's about it.

Nixo: Great, thank you. So this is a public testnet, it is… or DevNet, it is called Plata Berget, aka DevNet 8, and I posted a link in the chat for, the forecast DevNet page, that links the EthPandaOps, resources. The faucet is… is in there. Are the… so, are the gas repricing numbers final, then? Jocham… Joakim, do you have a… Great.

Jochem Brouwer: Yes, I want to share my screen about this. Can you see my screen?

Nixo: Yes.

Jochem Brouwer: Great. Okay, so the final question mark, gas repricing results. Before we do that, I want to first thank some people on the record, because these people deserve a lot of recognition for this. That's Maria. Maria has done the research, the interpretation, and the analysis of the gas repricing. Kamil from Nethermind, who has written the gas benchmarks tool. Rafael was with the benchmarker tool, Luis was with the actual benchmarks, and also Audi clients which have optimized their bottlenecks route during this benchmark and repricing effort. And also provided, like, a lot of valuable feedback for these EIPs. So, let's go to the… results, so the final, with an exclamation mark, Casper pricing results. The results are in the context of EIP 2780, EIP 8037, and EIP 8038.

We can comfortably sign off the numbers which were presented at ACD 90. There are some specific benchmarks now, which we will forward to the clients which they should look at, but these are not a problem, because these are still well within the safety limits of these repricing numbers. And what does this mean? The Nimbus as in the latest release of the EAST test, so test comes with indefinite test at version 8.1.0 are correct and final. That means that we do not need to re-release anything with changed specs, because the specs have not changed for these EIPs, which is this thing, so that's very nice. Clients do not need to change their numbers or their code.

We can comfortably agree to securely raise the block gas limits at the Glamsterdam to 200 million guests. Which means that it's more than 3 times our current limit of 16 million guests. And I'm happy, and thumbs up, and, very nice. So, yeah, that's what I wanted to present. Thanks everyone. Any questions?

Nixo: Great. If there are no questions, we will move on. To… Barnabas has, a solution for last, last call. There was concern, I guess last ACDT, there was concern that, raising the gas limit before, Glamsterdam risks the gas limit actually going up before all of these repricings are in. Barnabas, do you want to talk about 8261?

Barnabas Busa: Yes, so the general idea of 8061 is, that we're gonna introduce a new configuration parameter into the, see a config file? So, for… doesn't say it, it's, here, I just linked it. So, using this, assuming that we have fork Gloas, this would… this field would become, relevant. And here we can, basically hard-code the, gas limit schedule ahead of time. So, depending on whatever, gas limit schedule we would like to go with, We could just basically, Set up, set up that schedule, and then make a single release, for the main network time and gas limit schedule as well. All the clients that take consideration this extra perimeter flag will actually use it as their default, Gaslute Flag.

And guesstimate values. So, as I mentioned, it's an optional flag, so clients May choose to ignore it, and Then they would just default to whatever… They have hardcoded as their default value, and also, this should not… disable the possibility for users to override, their local customit values. So if you have a cl… you have a… A person that overwrites the local guesstimate value, then this should be ignored. But this is just for… Setting a future, same default values. That's about it.

Ben Adams: So, also at the fork back, I mean, do we need to give a specific… Epoch, because they also will be switching the, engine API they use. So it could just be, here's the default for that parameter. That's now being passed.

Barnabas Busa: Yeah, so, like… from Gloas forward, this EL is passing the target values to the EL. Or what is the question?

Ben Adams: Yeah, so it's the… the CL's passing… I mean, there's a distinct… they're switching the API they're calling, also, is the point. So, it's a very distinct switchover. So we don't need to necessarily specify the epoch, just say, here's the default that you're gonna pass. And lastly.

Barnabas Busa: Yeah, but, like, this… this would decouple, basically, so what we could do is we could say we have Gloas fork epoch at XYZ, and then XYZ plus 20. We want to have this gas limit. Plus 40, we want to have a different gas limit, so we could… do a stepwise, step-up all the way till 200 million, going from 60 million, and that you could not do with just the EnginePI.

Nixo: Great. Kev, do you want to, talk about history expiry? I think the concern was whether or not clients are ready to expire.

Barnabas Busa: Before we move on, I think it would be good to make a decision whether, this is the right approach, or if anyone has any concerns about this. Yeah, does that include…

Nixo: Can we get some affirmatives, actually? from clients? Nethermind says yes. Yeah, does that sound okay to you guys?

Marius van der Wijden: It's purely on the CL.

Barnabas Busa: This is all OCL, going forward in the Gloas forward.

Nixo: Yeah, so this should be a CL decision. Do we have representatives from the CL here? Prysm approved it. Do we have Lighthouse here?

Barnabas Busa: They approved the PR into the Consensus-back report.

Nixo: Okay, I did Nimbus Techu. and Lodestar weigh in at all? Let's where I implemented it. Great. Typhoon's ready. That sounds like a majority of clients. Great. I think the only one we haven't heard from is Nimbus, right? Oh. Oh. Duh.

Barnabas Busa: Dustin is from Nimbus.

Nixo: Yeah. Dustin, are you… it…

Dustin Brody: Yes.

Nixo: In favor or not.

Dustin Brody: Hmm… How does skeptical neutrality? I mean, look, as long as it's optional, it's not worse than… Nothing, I guess. But… But one of the main motivations of this, being able to do this kind of staging of, gas limits. So, plus 20 epochs, plus 40 epochs, whatever. I mean, I know those are schematic numbers, and realistically, if one wanted to undo that partway through, one would spaced them out much farther than that, I… sure. But even the quasi-realistic numbers, multiplied by that, by… 10 or more. 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.

Nixo: So, 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 Glamsterdam, in any case?

Dustin Brody: Well, we're safe to fork Glamsterdam anyway. I mean, that's sort of… none… I mean, presumably none of this happens before Glamsterdam. 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… Look, if it's a comforting illusion that people like, then that's fine.

Marius van der Wijden: Aye. I think we should spend no more time on this, please.

Nixo: Okay, great. Then we will move forward with, with this, change. Okay, Kev, are you on the call?

Kevaundray Wedderburn: Oh, hello. Yes, I just, wanted to get opinions from ELs as to how much history they'll be expiring at Hegota by default. The question comes from the fact that there is a non-significant amount of 2TB 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 Gloas at 150 million gases, roughly 120 gigabytes a year. So it seems that we need to expire history, at Hegota. And yeah, I will need to get some thoughts on What is the default value that people are going for?

marek: So, on Nethermind site, we store history up to the merge right now, but I think we will drop soon, and I would really like to drop at least, to Dancun or more, because, you know, like, this cold data thing, and how, history, history was used before, we shipped, for, blobs. Yeah, so that's from Nethermind, but probably I would aim even more, like, maybe last 6 months.

Kevaundray Wedderburn: Is Erigon on the call?

Andrew Ashikhmin: Yeah, so now, by default, we store the last, 262, south end and something blocks by default. That's, EIP… 8552… no, sorry, 8252.

Kevaundray Wedderburn: Good.

Andrew Ashikhmin: That's about, months,

Kevaundray Wedderburn: And Gaff, if you're… I don't know if Matt's on the call.

Felix Lange: I think we can find a reasonable cutoff point. I'm not sure what's a good one, but I kind of agree with Nethermind there. Like…

Marius van der Wijden: Yeah.

Felix Lange: Sure.

Marius van der Wijden: So we, like, I think we already have implemented, like, fork minus 1. And we have a PR for rolling history expiry within the, like, larger than the last 100… K blocks.

Kevaundray Wedderburn: Okay, so different clients will be doing, different, strategies. Raph, are you on the call as well?

Dragan Rakita: Yeah, but I'm not sure what the default is. I don't think it's problem to drop more history.

Nixo: Do we want to hear from Besu?

Kevaundray Wedderburn: Oh yeah, I was reading what they wrote in the chat, Besu currently only drops pre-merge blocks. So 5 months, looks like, is what, you guys might default to for Glamsterdam. Okay, cool. Yeah, I guess we can potentially just assume that at minimum, it will be 5 months. Ben says we should coordinate to same, or syncing history will be an issue. Yeah, that's a good point. M… Yeah, 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 2TB node operators. And I'm guessing the fact that… 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?

Nixo: It seems like most clients do 5… 5 months or fork minus 1?

Kevaundray Wedderburn: 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 Hegota.

Nixo: I believe we do have a history expiry channel in… ETH R&D. 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 single number for, history expiry and the history expiry channel on ETHRND, and decide where that should be specced. Does anybody have anything else, on Glamsterdam?

Great. If not, we will move on to Hegota. 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 to. 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 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.

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 Hegota, 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 PFI should be final, at least by the next call, hopefully today. And so that gives clients 2 to 4 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 proposers of each of these, EIPs to take no longer than 4 minutes, because we do have 17 to get through. We're gonna start off with, a few that were proposed by Helcamine, aka ABC123C. Apparently he can't be here today, so I am going to push on that. If none of these are 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, 7609, decreased base cost of T. Load T-Store, or $7973, warm account write metering.

Oh, I know there's a fifth one as well. 8360T create opcode.

Marius van der Wijden: And you… Put them in the chat or go slower or something?

Nixo: Yeah, sorry.

Marius van der Wijden: Had to…

Nixo: I will write them in the chat here. Okay, those ones. If not, I will message Helcamine and ask him if he wants, another chance to talk about them on the next ACDE. Otherwise, I will just close the PRs to merge them to 8081. Okay. We'll move on to, some by jochem. We have, we'll start off with EIP7923, linear page-Based Memory Costing.

Jochem Brouwer: Yes, I will share my screen again, and I will present them all three within the same slides, and I will timebox myself to 9 minutes for this. So, how do we do this? I will present the EIP, then I will stop for slides to ask if there are any questions, and then I will move on. Okay, so let's start, first on notes. That's, let me also post these. EIP. The notes that EIP 7923 and EIP 5920 are preified together with Charles Cooper. He is a Viper compiler developer, and this is a big reroute from the EVM compiler community. I wanted to provide that as context. So let's move to the first one. This is EIP7923. 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 32 bytes or 512 bit words. Wait, that's actually a mistake, because it is 256, of course. This was done, I believe, in Frontier to prevent a denial-of-service attack. on node memory, and this was because in the chains.orgier, there was no EIP7825, which is the Transaction Guest Limit Cap, which we shipped in Fusaka. So, it would make sense to actually get this thing with this, like, this quadratic, gas-cost pump, so you balance 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 gas pricing of the EVM memory, because we believe that the quadratic bound can be removed due to the implied EIP7825 transaction execution gas limit bounds, because we should be careful.

Since the EIP 8037 now introduces both Execution gas and state gas, but we are talking about the execution gas, and the Execution gas is still limited to the EIP7825, bound of 16.7. million. So, from my side, there's actually some report which I'm currently writing. I want to report on the maximum reachable, allocatable EVM memory within these transaction limits. This is currently within one call frame, approximate 3MB, but this is, of course, not the Worst case, what we could do here, because we can, of course, spark 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 EIP7923, 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 allocated EVM memory,

If we would introduce this, this linear, memory cost. And I want to deliver this via EVM editions in two weeks or before the next ACDE. Yeah. Questions? Okay, I guess not swell. I took the first one at 3 minutes, so that's nice. Okay, the next one is EIP3298, this is remove of refunds. Marius already asking, isn't EIP3298 badly outdated? Yes, it is, but we can just solve it since EIP end. If we really wanted, I can also just fork this EIP and create a new one, but 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 there's the EIP7702, so this is the, the, account, well, the…

this DX Type 4 transaction type, which creates a delegation of two existing accounts, because if your account already exists, you get a refund at the end of your transaction, because currently you paid 25,000 cash For, upfront, so as intrinsic, and you get $12,500 back in case if your account already exists. And now my mouse is not working. Wait, this… I did not check for Glamsterdam if there are any new refunds introduced, but I believe that these are, like, marginal or 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, cold data floor gas, and the question is, when do we apply these reasons? Do 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 those points. And where does this max gap apply to? So is this, like, the floor gas? Is it the Execution gas? Et cetera, et cetera, et cetera. This is well specified, but it is still, complicated, I would say. These refunds are also not super effective, because EIP3529, the reduction in refunds, this has been activated in the London fork. is, this capsule runs at only 20%. This introduces, like, a divisor, which is coefficient 5. And, before this, this was actually 50%, so you could get 50% of your transaction gets used, back in refunds, which is, of course, very nice. But this was used slash abused by the gas token, for the people who remember this.

And, in Amazon, we also have this EIP7777778, which is to broadcast accounting without refunds, to already ensure that, well, I would say we somewhat deprecated this refund already. And this idea is originally for state EVM, so you clean up after use, which is, like, a very nice idea, I would say. But I would say this FenLine's really not interesting anymore to clean… to do clean up after use, also, after, gloves 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 lead Dance points, yeah, it's in this a very, very nice thing, because it just simplifies things. Danno's 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, like, in many edge cases. And I see that Dragon has a hand up.

Dragan Rakita: Yeah, there's two types of refunds. There is refund for the clearing storage, and there is refund when you reset something to 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 if we have only that reset refund, that means we don't need to cap it one-fifth, we can remove this kind of cases there. But I think the main problem is about getting refund by clearing storage, basically going from X to 0, from original X to 0.

Jochem Brouwer: So, maybe to ask, do you want to keep this?

Dragan Rakita: 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 region value. I think that should stay. I think it's, like, good in calculation.

Jochem Brouwer: Yes, I think I actually agree with this. Indeed, I want to remove this storage refund. and maybe also see, like, how we can somewhat simplify this. Because I also do think, like I mentioned, there's EIP7702, but, I do believe that this should get, like, some kind of reprintment, maybe in, like, a less complicated matter. I propose that we discuss this async. Okay, cool, thanks a lot. Alright, I will move on, because now we only have one minute for the payout code, which I will, sadly go above. But I had 4 minutes, so it can go to itself. Okay, so the payout codes, what is this? The question is, how do you currently send ethereum to an external foreign-interested account?

And, this means currently that you must execute code unless you use, like, this very weird pattern. This is, like, a crate pattern and a self-distruct 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 PFite EIP4758 for our GoTa. 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 guess if you were to use the normal way to send EF. 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 gas, because if your only intent is to send EF,

then you don't want to execute any code, you just want to send this if and be done with it. And, of course, another pattern would be to use webbed 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're already, you already have to audit for the fact that you are going to execute foreign code, which is not nice. This also creates this logical alternative for the Squid 2, or the Squid plus self-destruct pattern, which aligns with deleting or deactivating self-destruct in EIP4758. And I personally believe that this opcode should already be there since change. and Frontier, and if my mouse works, yeah, I would say stupid.

Yeah. Questions? And I see that Nixo 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. Alright. Thanks, I took 10 and a half minutes. If there are no questions. Alright, thank you.

Nixo: Thanks, you're welcome. We can move on to, Dragons, PFIs, 8030… 80… 8358 net gas metering for account changes.

Dragan Rakita: Yeah, this EIP basically discounts the gas used for when you have call-up code with value. It tracks if the target of the call was changed before, and callee… and tracks if call E was changed before. That means we can save, like. 4K of gas, you bought are changed. Additionally, that's the… Because of the gas dependent that we have inside the coils, it… It's minimal gas that needs to be sent to the cooler. And add that in calculating how much gas needs to be spent on the quality side. Mmm, that's basically… that's optimization. Anybody had questions around this? This is the first therapy.

Don't know exact number.

Nixo: Okay, if no questions on this one, you can move on to the next one, 8374 persist form access.

Dragan Rakita: Yeah.

Nixo: CrossFit.

Dragan Rakita: 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. ED, in… in essence, is if you are already load… loading account of the… or the storage. You don't want, even if revert happens, even if the hold happens, you don't want to basically… you're not, like, deleting that storage from the cache. So it's more accurate for that account or storage to stay in the XList. That's basically the ABI. Any question on that? If not, we can move on. That'll be it for me.

Nixo: Danno?

Danno Ferrin: 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 it was being written because of the way reverts work when you're trying to do anything clever. I just want to know if you have any scoping on how Card is going to be to support both modes across multiple forks.

Dragan Rakita: I don't have anything, but from looking at the code, it's 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 edge cases are, like, cleared. That's why I think it should be a smaller change.

Danno Ferrin: But, I mean, that's great if you only have to support post-Hegata, but when you need to have a VM that does Glamster Dann and Hagita in the same binary, it can be… problematic, I don't know, I mean…

Dragan Rakita: It's busy.

Danno Ferrin: I don't want to block it, but I just want to raise a concern that this might be bigger than it looks.

Dragan Rakita: Yeah, but this basically should be, do you create… if the Hegota is activated, do you create journal entry or not? or on… even if you do revert, do you skip the… I think all the clients, all the VMs have separate hash path for the access list. It's basically, don't touch… don't remove anything from it.

Danno Ferrin: Right, but when you're trying to do clever optimization things, those… become very fragile. I'm just, you know, I'm not gonna… I just want to put in people's mind that this is bigger than it looks, and to probably start it early.

Dragan Rakita: Okay, okay.

Nixo: Any more questions on this one? Okay. Next we have 8368. This one, was proposed by Maria. She, I think, is not on the call today, but, Toni, do you want to say anything about this? If…

Toni Wahrstätter: Yeah, I can, I can quickly provide a heads up for that EIP. It's a very simple one. It's basically a recalibration of the constant we introduced in 8037. And it's needed because, if you remember, we install Bot, 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 Hegota, we should, CFI it in the meantime. And yeah, this is then… with the data repricing EIPs, basically the EIPs we think we might need. To push towards 600 million gas limit. Because apart from that, I think we are mostly… mostly ready.

Thanks.

Nixo: Thank you, Toni. And Maria may take the opportunity to talk about it, on the next ACDE when she's able to attend. If there are no questions on that one, move on to Chavez. EIPs, we have 8077, VHash, blob-aware Mempool, and 8094 announced transactions with nonce.

Csaba Kiraly: Thank you. Yeah, so in that description, I was actually mixing up the numbers, so… As Ansgar noted to me, so 89… 894 is the blobman pool. I will start with that one. Yeah, thanks, thanks, Scott. So… What to know about this one is that here the goal, was to make the manpool more efficient by avoiding a nasty redistribution of traffic, in case there is, It's by fee. For blob traffic. The machinery, that was described is very similar to what we were then putting into, sparse BlockPool, so, I think maybe 90% 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 LBF cheap. I think we can bolt

most of it on top of the current version of the Smiles Bot Pool. A few changes might still be needed, so I was PFI it, because of the goal. But it might be that we manage to do it just simply as a possible pool. If the change is needed, then, It will be done in this EIP. The other one. So, the other one, which is called, 8077. Which is the, so what's the nada? In demand 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 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 scale the mempool. Now, if we want to go up with, with… Lukasz… We might also want to scale the public mempool. I've seen different opinions on this, but 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 they randomly pull hashes. They don't have any other choice. So what is proposed here is to add, besides the hash, add some metadata to the announcements.

So that nodes can do more intelligence, decisions in the mempore 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 nonsense cannot be. It's… it can be access and loans. 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 makes sense is very much transaction size dependent. I see lots of texts in the chat, but if, yeah, if there are questions, actually, happy to answer. Otherwise…

We can move on, and I will lead to the chat.

Nixo: Nobody wants to… Ask any questions, we'll move on. To… Danno's, proposed EIP8355 precompiles for ML DSA verification.

Danno Ferrin: And, where's chat? Let me post this. Nope, wrong window. Right window, that's better. And… here's… 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 MLDSA. Azure and Oracle are lagging, but there is external solutions such as Thales that you can use. But another big thing is hardware 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, WebAuthN, the current draft, uses it, and they use the FIPS 402 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 Hagita ships, we'll have it built in. Goes is still in the release candidate.net and Java ship it in the baseline. Rust has some really high-quality libraries, although they might not be core. The reference implementations in C. Node.js has put it in a 24-70. And it's starting to show up in browser natives. You can, of course, compile your Rust program into, 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. Interop 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, ZCCP256K1. With ones where they had, you know, tests that were multiple things were wrong, but thought they were testing only one. So these test vectors that they have available test these common implementation errors. They're properly isolated, so that if you don't have all the corner cases, you're going to fail something. So, the only new tests we'd really need to write are tests that we know very well how to write, precompile 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 precompile proposal, but there are some key things that I diverged within this. The biggest thing being is a theme, I am sticking with FIPS 204. If a 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 MLDSA44. 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. Yeah, nothing's brought it down below level 2 yet, but, you know, if we're going to 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 SCP,

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 DIP, 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 precompile. 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 precompile. And, of course, this can be used for 8141, it can be used for, online DAOs, 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, you know, millions, you know, 5 to 9 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 cache, and that would, you know, solve a lot of the problems there. But the EVM is just not set up for bit twiddling.

Kevandri asks, it's not clear to me that we need 3 new precompiles for different signature variants of different security levels. Not everyone is comfortable with security level 2. some people are going to want the higher level security levels. I think the only reason we only have one security level in VC Recover is because our, The, the size of the registers in the stack was 256 bits, and the way you get more security in elliptic curve is you go up to 384 bits, and we thrashed for years trying to figure out how to do that. So by bringing it as a precompile, I think we get it day one, and it's clear how we can use it. Some people are going to want to use, the 65 or the 87 variant instead of the 44. For a while there, Google didn't even ship MLDSA44 in their trials.

And Justin has his hand up.

Justin Florentine: I noticed that there was a section in 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? Are the output of the, precompiles?

Danno Ferrin: So the output of the precompile is going to be pass-fail. It's the message size, and the signature size, and the key size. So the biggest thing that this precompile does that the old 8051 does, is we use the FIPS 204 encoding, which is on the order of, like, you know, 2, 3, 4 kilobytes. Rather than 20 kilobytes. And the reason that expansion was done in 8054 is to remove a bunch of bit twiddling. In 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 an optimization done to facilitate EVM. But as far as… as far as the sizes, I have a… 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 SLOADStore data is going to be kind of expensive, because you've got to break it down into 32-byte sections. Which is problematic.

Justin Florentine: Thanks. I'm interested in that public key storage, I'll talk to you offline.

Danno Ferrin: Okay.

Nixo: Great. Thank you, Danno. We will move on to, Anders' proposed, EIP8372, normalized state gas limit. Anders we can see your.

Anders Elowsson: Can you see my screen?

Nixo: Yes, we can.

Anders Elowsson: Okay, great. So, maybe I should… Okay. Maybe I should expand it, let's see. I can do so. Yeah, do you see it full now?

Nixo: Yes.

Anders Elowsson: Okay, wait. 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 Glamsterdam. And so, ideally, we would have this situation where we used to spend around 50% on execution gas and 50% on state gas, and in this case, we can do this EIP8368. 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 8037.

And if we observe these two failure modes after we have gone into Glamsterdam, and as we are approaching Hegota, we can instead then do EIP8372. And this EIP is very simple, it's just a one-time calibration of the fork boundary, where we add another constant so that we can change the cost per state part, and at the same time, normalize the limit of the gas, of the state gas. So if we are in this situation where we create too little state bytes, we would instead reduce the cost per 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 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.

Nixo: Thank you, Anders. Do we have any questions?

Jochem Brouwer: Yeah, okay, I've maybe won, because this also seems to imply that we then have some kind of creation target, that we target a specific amount of state. Is this correct? Because I'm not really sure if we want to do that.

Anders Elowsson: Yeah, so it would be a target, just like we have in EIP8368, and we would be adjusting this target exactly the same way. But we would also be normalizing the gas used, so that we can target things more quickly, based on observed demand.

Jochem Brouwer: Yeah, okay, I see. This would indeed also more fairly priced this. Yeah, okay, I see, thanks.

Anders Elowsson: Yeah, and so, maybe as a reference, I can say that we had an EIP8075 that does this automatically, previously, with a floating price, and then you can adjust for all the failure modes directly. But here, we have this simple, fixed solution also.

Nixo: Great. Dear Anders? We will move on to, Ben's EIP8375. EPBS, mandatory burn of Execution Rewards, or Ember.

Ben Adams: Hey. 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 old math. Say, burn 30% or something. So there's still an incentive to pick, you know, the best bid. This… Three pieces, universal priority fee-burn, external builder burn target, and a PBS observed floor. So at the moment, nothing is burned, nobody decloses anything by declaring the… Mev, honestly, the builder competition keeps the declared bids near true value. However, if we introduce a burn, every builder-poser pair gains by declaring a low, low value and side-paying to avoid the burn.

And so we want to keep it as… as declared. So we can't rely on what the winning pair is saying 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 introduced the PBS, where the… a new role for the PBS, where they report their best public bids that they saw. And then… That forms 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… Oh, Leo, as I say, it doesn't… doesn't solve all… all MEV, but it solves, Well, sorry, it burns… it sort of flattens out. The map. That's, that's available. Yes. Already?

Nixo: There's a lot of conversation in the chat, does anybody want to… Ask any questions.

Ben Adams: There's a question on… 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 PBS observations of, you know, what are the bids to put a floor on that. and also… the priority, if we use calls 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… that's also why it's… why I'm saying it's something like 30%. So that it's not… onerous, to avoid.

Nixo: lightclient also had a comment on… 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.

Ben Adams: Yeah, I don't… I don't have a reply to that.

Nixo: 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 EIP8219, checked arithmetic. op codes.

@ritzdorf / Hubert Ritzdorf (EIP-8219): Yeah, hi everyone. So, basically, the most basic, DFI operation, I would argue, is, like, an addition, and if you insidity 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 this EIP 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, safe subtraction, safe multiplication, 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 0, 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 editions costs, 79 gas, wipe 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, 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. It 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 arithmetic, and this is, then kind of providing the functionality that is needed in practice. If people feel like that's some of the early feedback we got, that four new opodes 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 one byte intermediate tells what kind of safe edition 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, this basically is gas cost. We briefly benchmarked and more or less stays the same as normal aeropedic 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 people care at all, and whether people, think the four-op cost is anyway unreasonable, and that's why we should, push for the one-off operation. Thanks.

Nixo: Danno?

Danno Ferrin: So, one thing that crosses my mind is that neither RISC-V nor WASM have checked, addition, multiplication, base arithmetic, and they don't expose the overflow fields either. If we're moving the EVM to risk-based, 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 gas going down, is shaving off and engulfing our gas as essential as it used to be?

@ritzdorf / Hubert Ritzdorf (EIP-8219): Yeah, of course, that's up for discussion exactly here. So, I mean, to me, yeah, going from 80 bytes to 5 bytes for what is probably, I would argue, the most important DeFi operation, to me, is worth it, but I very much understand that this is, yeah, a point that can be freely discussed, yes. Sorry, I don't fully understand the question with the compilers, can't… delayed some of the tricks, but the, yeah, thanks for the feedback, Regarding, for the other people in the chat. Thanks.

Nixo: Do we want to ask any questions synchronously? Anybody? Great. So those are all of the proposed EIPs for Hegota. 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, ACDE 233. 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 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 AA 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 AA.

Ben Adams: Yeah, we'd, we'd support it as headliner now.

Nixo: 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, will 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 25th, 8 o'clock, that's 14 UTC. Those AA calls are starting again. Marius?

Marius van der Wijden: Yeah, I don't really want to speak for the guest team, because I think it's clear that 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 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 put me very much in favor of shipping frames.

Nixo: Erigon, Besu Reth, anyone who want to say anything about it?

Justin Florentine: As far as Besie's concerned, we are not in opposition to any of this, and happy to work on it.

Nixo: Okay, great. Yeah, so decision sequencing… thank you, Ansgar. The first decision should be, is, is framed specifically the implementation that we want to go after 4A. Native AA. And then, the… whether or not to make that a headline or 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. Besu is… sounds like, not in opposition. Reth is, In my conversations with them, taking no stance. Erigon, I believe was, supportive. Erigon, can you, is anybody from Erigon here?

Andrew Ashikhmin: Yeah, yeah, Weston Fabio.

Nixo: Okay. E3x 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 comment that was made by, an EVM, Somebody working with the EVM, they basically said, I want to flag that 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 Hegota.

I will ask Matt if, there has been any conversation about EVM incompatibility and how this is, How this is being addressed.

Ben Adams: I think… I think they might be on the call. Is that Chris? Or maybe not.

Nixo: Yeah, I'm not familiar with this person, and they said they couldn't make it.

Lumi | Offchain Labs: Chris is on the call. I think, like, I'll let Bates speak for themselves for 8131. just to voice a little bit, the side of L2s is we're very worried about throughput and DOS attack vectors within 8141, so we would be for 8130 or 8141, either way, for 8141 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 8141 for an L2.

Chris Hunter: Hi, I think my mic's working now.

Nixo: Yes, we can.

Chris Hunter: Yeah, so that was my comment there. 8130 was proposed, earlier in the year. I spoke on some breakouts. And… yeah, basically just, just, kind of wanted to flag, I know this kind of, we're moving towards these… I just want to 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, 7702 deprecation is all, a part of the spec. We're… we're launching it on… Based in Arbitrum. That was after an 8141 deep dive.

And just want to, like, basically, like, you know, do one more, like, deep comparison on all of the potential Metrics here, and… I guess that's, you know, it's not here for today, but, I can… I plan on, you know, joining the breakout calls with, you know, comparisons on every… Kind of, metric, yeah.

Lumi | Offchain Labs: 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 8130 or 8141, and I don't think the fact that it wasn't proposed should exclude it, considering how we decided to include it.

Nixo: So, it sounds like there's… there's… Rough consensus among clients, but not necessarily, Among, ecosystem builders. Can we say that since 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 27th? Make a decision about specific implementation, Whether or not we go with frames, and we could probably also make a headliner decision on that call.

Tsahi Zidenberg: I will note that 8141, as far as I understand, is still very much in Fulux. So, it's kind of like… I specifically, as, like, off-chain. I… I don't have a problem with 8141. I do have big problems with 8141 as it's currently written. There are some talks to make it into, something, better, but, like, saying, you know, I can back 8141, but not… but not as it's currently written. There are certainly, things that can be made, including ideas it should take from 8130, that would make it much better.

Nixo: Mislov has a question, what's the core complaint, as it's currently written?

Tsahi Zidenberg: So, as it's currently written, it's very, very hard for, So, the general idea, right, is that 8141 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 LTools, 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.

Felix Lange: 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 the transactions that you deem includeable, 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.

Chris Hunter: So that… I do, like, you know, 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 8130, like, allows is basically a much more… general, flexible account for that, for the good case. So, L2UX, which is, I mean, you could ultimately argue L2s are, for UX. remains… Good, you get full key rotation, you know, fully programmable accounts, etc. And we're not left with, like, oh, 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 has the additional requirement to, you know, support FOCIL

Permissionless paymasters, 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 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.

Felix Lange: 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 8141 that would prohibit you from using this type of account storage with 8141, 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 what I wanted… 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 A141, we also have, like, a bunch of other goals, and so we didn't want to… put… Just focus too much on this, like, how the keys will be stored in the end.

Chris Hunter: Yeah, 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, once you have that, like, the actual, like, execution of validation can be… I think Frames does support, like, the, like, end of… Transaction validation, which is something that 8130 doesn't support, so, like, you do have to have the… the validation is only at the start of the transaction.

Felix Lange: The process is pretty important, actually, to have these, like, transaction assertions and things like that, so we kind of… this is something that came into the 81441 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 8141 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 that A1 8130 doesn't… Yeah, it's not concerned with that.

Nixo: 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 25th. Please bring your concerns there, and I am asking, that breakout call to please come out with a conclusion to, the 27th ACDE, it sounds like some bridges can be built between these two, between these two EIPs. Does anybody have any comments, opposition? About that path forward. Matt?

Lightclient (Matt Garnett): Yeah, I just wanted to know, like. the ACD after this breakout? How will we decide What the path forward is.

Nixo: 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, Ansgar?

Ansgar Dietrichs: No, yeah, I mean, I just wanted to say, also, you know, because ultimately, I think… the decision will be kind of like an L1 kind of, like, side decision, so 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 there's small modifications, small extensions of frame transactions, that would just make it much easier to… to use, de-risked, on the L2 side as well. I think basically, like, using the breakout not just for, like, a general discussion around, should we do this, like, what our 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 that would be a very productive use of the breakout.

Lightclient (Matt Garnett): Yeah, I… I think that's a good goal. I think it is just, like, a bit difficult 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 8130. And the 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, L1 has different incentivization. So… at the end of the day, like, we need to do what is best on L1, 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.

Chris Hunter: Yeah, I'll just add, like, I think, everyone does want, native A on L1, and I, like, the long-term Ethereum goals, I'm very aligned with, and I, you know, I do want that. Like, no A, I would rather have 8141 on L1, absolutely. But I just, like, genuinely believe 8130 is a… can satisfy the same long-term goals in a way that, ultimately is, like, more performant and, 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 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.

Nixo: Okay, we are, 4 or 5 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 25th at 14 UTC.

Tsahi Zidenberg: Hello.

Nixo: Thank you, everyone.

Jochem Brouwer: Thanks, everyone.

Ansgar Dietrichs: Thank you. Bye-bye. Bye, man.

Chris Hunter: Thanks.

Parithosh Jayanthi: Lately?

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