All Core Devs - Execution #222

Transcript

Ansgar Dietrichs: Awesome. Welcome, everyone, to… All core devs number 222. What a nice number. I am stepping in for… filling in for Tim today, who will be gone for the next few All-Codevs until the end of the year, and then he'll… he'll be back to… to take back over. Yeah, we have, I think in a, like, not too full agenda for today, just quite a few items, but they're all relatively minor, so let's just get started. So the first up will be a few Fusaka items. The first of which is any definite updates. Do we have, any definite updates? Anyone here?

Parithosh Jayanthi: Yeah, so earlier today, we launched a Fusaka ShadowFock, sorry, a Seporia Shadow Fork, and so far, it's been, pretty… uneventful, I guess. There… yeah, we've already gone through Fulu and BP01, and BP02 should be in, like, half an hour, and we don't seem to have any missed blocks or any problems. We've only done a consolidation so far. We're gonna still do top-ups and exits to make sure that all of that looks good as well. But while working on that, Barnabas found a few issues with, with the BPO schedule that he's also trying to, bring up on, ETH R&D, but I will let him continue with updates and, bring up that topic, I guess.

Barnabas Busa: Yeah, so the general problem is that, As we start, including the named forks in the blob schedule in the Genesis.json file, this will make the this will make, basically, the generation of the Genesis file very, very complicated, due to the different, values, the BPO values can be set. Because as soon as we start adding Amsterdam and Istanbul and Bangkok and whatever else future work we're gonna have, we're gonna need to have, logic for, using the latest BPO values that are currently used, and on top of that, add the, the named, fork in there as well, even though that those named fork values will change no values whatsoever, because on the CL side, those named forks cannot, adjust the bloat values anymore.

So, they are basically redundant fields, and I'm proposing that we should probably get rid of the Osakov field, as well as Amsterdam, and all future forks as well.

Ansgar Dietrichs: Any comments on that point?

Marius van der Wijden: Yeah. I… I have argued against this, multiple times, because I think it's… it's much better to be very expressive. With how the… how these configurations… like, it's better to be expressive about the configurations. Than to, like, implicitly… Forced the… users to know, okay, like, I don't know, now we have two… Two named forks, but none of them have, have any blob schedule, so I need to look 3 folks back to the last BPO to see what… what… blob schedule to apply to the current fork, and that is one of the things, and the other thing is that we are limiting ourselves to never do BPOs,

sorry, to never do, blob schedule updates, on, named Fox, and I think that is also something that… I don't know. Like, we never really discussed this, and it's… It's… very… It's very weird that, the, that the CR teams have made that decision that they cannot do blob schedule changes on named Fox anymore.

Barnabas Busa: But they can. So, like, you could… you could have a block schedule change as well, but you would just basically schedule, Amsterdam, and you would schedule BP06 on to the same time slot on the ES side, and you would schedule on the same epoch on the CR side. You would just not use the exact same name to schedule the, lobster schedule change.

Parithosh Jayanthi: So, maybe there's a bit… there's a bit of a diff that we need to explain. So, on the EL side, you're very explicit. I agree with you, Marius, you can look at one place where everything is scheduled, which is how it is today. But on the CL side, that's not the convention. So, in the CL, if there's a fork, and you don't append the value with the fork name, then you reuse the value from the previous fork. So what would happen today is we would have a blob change with Pectra, and then you apply all the values for the BPO125, And then… it's sort of implicitly understood that Fulu has not changed the blobs, but if we decide to change it at the next fork, then

Glamsterdam would have a pending as well, so we've… it's somehow really weird in the CL logic to do it, and the easiest way to sort of prevent that is to say we're only touching the blob schedule with BPOs. And then it's consistent again. And that way, it would be consistent on both sides.

Marius van der Wijden: Yeah, I don't like it, but it seems that I'm the only one arguing against it at this point, and… It's not really a big change, so I guess we can just do it.

Parithosh Jayanthi: Also with, Dustin's point, even in the future, if we intend to change the blob parameters, we don't have to schedule it at the same epoch as a fork, we can just schedule it 10 epochs later. If we want to.

Ansgar Dietrichs: And just as a clarification, sorry, I have no context on this, would this be something that we would then also already change now for the Fusaka rollout, or… or, like, going forward?

Marius van der Wijden: There's not really anything to be changed, right? It's just how the client, Interact with the… With the… with the… with the config that they are given.

Barnabas Busa: Whether you're expecting specific values in specific, fields or not.

Ansgar Dietrichs: Okay, and… but the config… the config for Fusaka itself wouldn't change? Or, like, the… sorry, okay, yeah. I see. Okay, so then do we want to… like, it sounds like Marius is the… like, was the only one? I mean, I saw Raul in the chat with some reservations as well, but do we just want to make a decision now, or is this something we want to keep discussing?

Raúl Kripalani: I would just like to point out, yeah, I misunderstood what Marius was saying. I agree with Panda… Panda Up's suggestion here, but I also wanted to bring up the fact that the EIP… that was the original intention, that the CL would list all all blob parameter changes, regardless whether they belonged in a regular fork, a name fork, or a BPO fork, in the blob schedule, and it's actually… there's a statement in the EIP as well, it might have been overlooked, but… but yeah, I just posted it in the chat.

Parithosh Jayanthi: Also, this won't really relate to any changes that has to happen for Fusaka. This is just, at most, would affect, the block-level access list branches, which are DevNet branches anyway.

Ansgar Dietrichs: I see, makes sense. Yeah, sounds like the majority of you was to… should then go with that, right? Of course, we can continue to discuss offline, given that there's no direct fault implications, but yeah. Okay, then, I would move to the next point, which is the Holeshky status. Is there anything… To report from that site?

Parithosh Jayanthi: Yeah, so the BP01 went live, I want to say 2 days ago, and I think there was, one… a peer-to-peer thing on Lighthouse that's still being triaged, I guess, or already has a fix in a future release, where they were losing some peers around the BPO boundary. But other than that, I don't think there was anything to report. Yeah, I would be interested to hear what the client team's monitoring has said, though.

Ansgar Dietrichs: Anyone here that can speak to that?

Dustin Brody: Sure, I can describe, so… essentially, we've run into… we, Nimbus, have run into… some resource issues on, WoCore machines. It happens to be that the way… and this didn't show up on both Fusaka, DevNets, because they were run on… with more resources, relatively speaking, but effectively, we don't… the way… the way we happen to run our testnet nodes, they don't have that many cores, and because at… and somewhere around the 9 to 15, BPO, change in Hawashki. They started consuming enough CPU time, and we've benchmarked this, and it just… how much time the library takes to do this is not really Nimbus-specific. this part of it, but it takes, like, 4 seconds to do… to reconstruct on the supernodes, and…

And that just doesn't work anymore with the one, one and a half effect, of course, so we're figuring out what to do with that. But it's definitely an issue with… a novelty to BPO1, as a result.

Ansgar Dietrichs: Okay. M… Yeah. Little to report from, book's always good. So, Then we can move on. I think the next point was Alex wanted to briefly talk about the blob submission API, if I remember that correctly. Alex, are you on the call?

Alex Stokes: Yeah, can you hear me?

Ansgar Dietrichs: So, yeah.

Alex Stokes: Hello?

Justin Florentine: Go ahead. Okay.

Alex Stokes: Thank you. Yeah, no, I didn't have any, audio issues, anyway. So this came up in the context of some of the roll-ups, getting ready for Sepolia. And the question here was just how different clients will treat, essentially, I think, what we're calling legacy blobs, or transactions, with the pre-Fishaka proof format and the new one. So I just wanted to check in, just so everyone's here, and I think we could just… Get a quick, update or status on how this works for each client, but essentially, yeah, when, do… I guess the question is, do any clients have support for converting between the old proof format and the new one? Like, let's say… There's the question of the fork boundary, but let's just say, post-Fusaka, yeah, what's the behavior here?

Marius van der Wijden: Yes, so, what we… we discussed this for a really long time, and I'm pretty sure what we ended up with is, at the fork boundary, we, We start converting, in the background, our own blob pool, from… from… from blob proofs to cell proofs. And… We convert all of the transactions that we get sent via RPC, from blob transaction, from blobproofs to sell proofs. And… I think we stop accepting… Blob… Transactions on the networking.

Csaba Kiraly: There we have a small window in which we are still accepting from the network. I think it's the hours or something.

Alex Stokes: And then, would you… at some point into the physical fork, stop converting on the RPC. I think that'll be the main thing for the roll-ups.

Marius van der Wijden: Nope.

Alex Stokes: Okay.

Marius van der Wijden: Like, not within, like, the next one or two releases would we remove that converter.

Alex Stokes: Gotcha. And I think Geth was special in this way, as in this is what Geth does, but I think other clients essentially just drop support. So it'd be nice if I could just… Get a confirmation of that.

Andrew Ashikhmin: Yes, for Aragon, we just dropped support of, blob, proofs, non-cell proofs, so, yeah, we are not as nice as Geth.

Alexey Osipov: Nevermind, we will, not, gossip, and, like, accept, such transactions with all proofs, right on, when Head is, post to Osaka. We will drop them from taxpool, but we'll allow re-entrance of the transactions. Of the same transactions, but with a new version. Of, the proofs. And, I guess, someone… maybe from Gask has, Some information about, with such conversion in, like, tough conditions when a lot of transactions are… In the pool, will such conversion lead to any luck of the client? Lots.

Marius van der Wijden: So we tested that, especially this case, on, on, I think, Holeshky, on, like, the last fork, the last testnet fork, and, yeah, basically nothing happened. We are… Only converting them in the background, and we are also limiting the conversion so that we don't over… overrun the node, but what we did, or what the Pandorops team did at the fog boundary, they sent a bunch of transactions, so that the… our mempool was full, and, yeah, we converted them, no problem. Let's see.

Alexey Osipov: And, you do not… okay, so you do not drop transactions for some time from the pool, just, start converting it. And if a new note is connecting, will you gossip transactions that are not yet converted? Still not converted, and have all proofs? Or… Or not.

Csaba Kiraly: Yeah, we are not sending these old proofs, so after the fork, we only send these new proofs.

Alexey Osipov: Thanks.

Csaba Kiraly: That was a question.

Alexey Osipov: Yep.

Ansgar Dietrichs: Okay, were we missing any client, or do we… Alex, did you?

Alex Stokes: Well, Bessu and Reth, but I think they have the behavior… That, yeah, others that think I've had, so… I think we're good.

Ansgar Dietrichs: And that was… that was all you wanted to discuss?

Alex Stokes: Yeah, I just wanted to know where people landed as of now. I'm talking to some other roll-ups just to make sure things are good on their end, and that should be enough for now. Thank you.

Ansgar Dietrichs: Awesome, and just one quick clarification, Marius, when you said you'd keep the conversion functionality until at least one or two releases after, in principle, not sure if this is at all relevant, but in principle, if there was any other users or so that would approach you to request extending the support a little bit, would you be open to that, or…

Marius van der Wijden: Yeah, we don't have a… we don't have a clear path to dropping that yet, anyway, so… We will be in contact with the L2s to drop it at a point that is convenient for everyone, but I… I would also urge the… the… Basically everyone that's sending blob transactions to update their code as soon as possible to to create those sale proofs themselves, because otherwise you're creating a proof, and then we have to recreate the proof and the note again, and so we're wasting a bunch of time. So if you want to get your transactions in faster, create the proofs yourself. The, the sale proofs. proofs.

Ansgar Dietrichs: Yeah, that makes a lot of sense. Awesome. Perfect, then I think that would… that's all on that agenda point. Then, anything else on Fusaka people want to discuss before we move on? Okay, then we have a quick single item, section, which is just scaling updates, where we have some brief comments from Jocham, I think, on, some… State access benchmarks that, that, that is looked into, is that, is that right?

Jochem Brouwer: Yeah, thank you, thank you. Yeah, so I wanted to talk about, Camille, and, Camille from NerfsaMind, and I, we are working on tooling. To run execution spec tests, against, like, state snapshots, like, mainnet snapshots. So we can actually also incorporate the size of the state in these tests to perform performance benchmarks. And this is, of course, very broadly applicable, because we can also, like, test for different gas limits. And what we actually want to do here, like, what our holy grail would be, is if we see a slow block. Then we want to check this block, see if there's anything weird going on over there. We will then isolate this behavior. And then we would replay this on top of, well, most likely, it could, of course, have something to do with the state it runs against.

And if we would then run it in isolation, we would also like to see that we can reproduce this slow block in isolation, so we can really take apart the client to figure out, okay, what is, like, the bottleneck here, so we can optimize the client. For these slow blocks, well, I think I've mentioned that many times already, but yeah, most of the times when a slow block is being reported, it has these very big sand transactions in it, so a transaction which interacts with Xen, which has a high gas limit. And we are currently testing this, and the… well, one of the current results is that if we do this on top of a mainnet state.

that we rerun this, like, a lot of changes to the storage of Xen, then we still do not see really problematic numbers here. So this… It either means that the tests are wrong, or our tooling is wrong, or that we are missing something else. But yeah, I just wanted to bring that up, that this is, well, the current research we are doing for the state access benchmarks.

Ansgar Dietrichs: Sounds good. So basically, if I understand this correctly, because I heard that, from some of the test cases there, there were some, relatively, slow-performing, numbers, right, around some of these cases, but what you're saying is that, at least right now, it looks like this might just have been a, discrepancy in the testing process, and not necessarily, correctly Expressing real, kind of, performance bottlenecks?

Jochem Brouwer: Yeah, somewhat, so what I'm actually saying is that if we run these tests in isolation, the numbers there do not look super bad. But if we look at slow blocks on mainnet, especially those reported by, how is it called again? Like, we have a Grafana dashboard, which has slow blocks. And these are being accumulated from the lab, from Ivebender Ops, and… I think so far, I've only seen blocks with these Xen transactions in them. And this begs the question, like, maybe the result is that we do not have… we cannot reproduce these results in isolation. But that will then mean that these nodes, when they are live on mainnet. There is something else going on, but it simply causes, like, a…

Well, not… yeah, somewhat like, yeah, a majority of these nodes are performing like slow blocks. Which we can't yet reproduce, so… Yeah, that's the current state of this research.

Ansgar Dietrichs: Okay, then I added it basically exactly backwards, but okay, awesome, perfect, then I think that's… that's a good, good point for… for follow-up work, but, yeah, thank you, thank you for supporting this.

Jochem Brouwer: Yeah, I see one question from Ms. Yang. Yeah, we are running this on, I don't know the EIP number, but, like, the specified hardware specs.

Ameziane Hamlat: Okay, so when you say in isolation, what does that mean exactly? It just means that you are running that specific block on top of that snapshot, but the snapshot has, like, the whole database, all right? The whole blockchain and state. State, database, right?

Jochem Brouwer: Yes. Yeah, so what we actually do here is, for these, well, these specific Xen situations, is, our hypothesis is that this has to do with, the storage rights to Xen. So what we do is we create a test which should actually perform worse, because what we will do here is we will fill the entire block We have storage rights, and we even optimize, like, this contract to do the storage writes to, well, to squeeze out even more storage writes than what would happen in the block which we have seen. And then when we run this, and by running this in isolation, I also mean we're starting… we are starting our client. And… without DevP2P, like, we are not going into the network, we are just only starting plans to run this specific block.

And if you do that, we do not see, like, this execution bottleneck. or, well, not, sorry, not a bottleneck, but we do not get, like, these slow results as we would see on mainnet, which is, like, being reported by multiple different nodes, that this block is slow, but if we run it again. Which we would just say is, like, an even worse case than the mainnet block. We do not get the results which we would expect.

Ameziane Hamlat: Maybe one test that can be interesting is to run, all the time, one node on the same hardware specs that is basically running the mainnet. And then when we have, like, one slow block on that, like, with that hardware, we can pick up that slow block and run it on the same hardware in isolation. Because from what I understand, like, the blocks that… you get from, I think, from the network, from Ithpond.Ops team, can, you know, can run on different hardware types, right?

Jochem Brouwer: Yes, okay, yeah, that's also a very good point, of course, that this could also be hardware-related, yes.

Parithosh Jayanthi: Yeah, I think part of the reason we don't want to over-index on just nodes that we run is then you're kind of canonicalizing an architecture and optimizing for a specific architecture. One of the benefits of relying on the contributor data set is We… we are basically getting all types of nodes that people run real… in real world, on mainnet, as free data points. But yeah, it is harder to reproduce, of course.

Jochem Brouwer: Yeah, and one question, actually, about that, because I could not see on the lab, we can see, like, the contentless layer clients, but we cannot see the execution layer clients, like, their types. Is that correct?

Parithosh Jayanthi: We should have the data on a database. Maybe we can ask on a thread, and Sam or Andrew should be able to pull it out of the.

Jochem Brouwer: Let's do that, let's do that. Yeah, sounds good.

Ansgar Dietrichs: Awesome. Any other comments now by Kodvs on this? Otherwise, maybe, Jocham also, where would the best place be for people to jump into that kind of work and conversation?

Jochem Brouwer: Yeah, just, either send me a message on Discord or Telegram, or… yeah.

Ansgar Dietrichs: Okay. Then I would move on to… The glum slump section? We have a few items here, first a few general ones, and then, regarding ERP proposals. So first, on general, do we have any… DevNet updates, so primarily that's a block-level access list, Tony, are you on the call?

Toni Wahrstätter: Yes, I can provide a quick update on blockhead access lists. So we had a breakout call yesterday, things are, in general, looking quite good. Beso, GEF, RAF, and NetherMind are very, very close to being interop-ready, I would say. So, it's just a matter of time, getting those clients to interrupt, and… Aragon is also, getting there. Regarding DEFNET, I would pass to Stefan, who has, better insights, what the next steps, are there.

Stefan Starflinger: Hey, can you hear me? So…

Ansgar Dietrichs: Yes.

Stefan Starflinger: Generally, I've been trying out, individual kurtosis testnets, with just individual execution data clients, and I've been able to run, Geth, Bazel, and RET, just one client, each time, but I haven't been able to run any clients, like Nix, like Bezu and Wrath, I haven't been able to run them together, so I'm still trying to get that to working with clients, and never mind, I haven't been able to run There is a small issue with the Genesis, and I posted that into the block-level accesses channel. But in general, I think we're getting very close, maybe next week, if the interrupt, starts to look a little bit better.

raxhvl: Let me also give you an update on the state of tests. We released our latest test a few weeks ago, with about 26 tests. Since then, we've been tracking test results for cat, netheramide and red. And they're roughly passing about 80% of the tests. There's a particular test which is failing for all three clients, so we double-checked it to ensure that is okay. Bessel is also passing tests locally, but fixing an issue with the hive. So I think those… Should also be available, so that's 4 clients in total. Since then, we've matched a few more PRs, and there are about 54 tests. ready for BAL. Some of those tests, have variations, so in… in total, we have about 154,

Scenarios that we're testing, so we'll have these ready in an upcoming release soon.

Ansgar Dietrichs: Sounds good. And sorry, this is a dumb question. Was this… is this, buckler boxes specific, or… Tests across the…

raxhvl: Yeah, yeah, yeah, specific to block the Nexus, yes.

Ansgar Dietrichs: Okay, perfect. Anything else on BucketBox lists?

Toni Wahrstätter: Yeah, maybe one more thing, just to add, there's still one thing, one PR open around 7-7-02 about handling The authority tracking there correctly? This isn't merged yet, but, it's about to be merged very soon, so it's correct in the EAP, but it's not yet correct in the specs, and… I got a PR open there, and Philippe and me are working on this right now.

Ansgar Dietrichs: Sounds good. Katya?

Katya Riazantseva: Hello, yeah, we also started working on metrics for, level access lists. That would be great if some of the clients at least started implementing, or we can communicate on this. So probably… If not for DevNet 0, but for DevNet 1, we could have something already. Thank you.

Ansgar Dietrichs: Awesome, thank you. And then, in terms of governance updates, or feature updates, any… anything from the EPBS side, obviously that's more consensus layer side work, so just… just checking, is there anything, execution layer side, that… Would warrant an update? Otherwise, yeah, as Alex is saying, there's a breakout, I assume you mean for EPBS, right? EPS breakout tomorrow?

Alex Stokes: Yeah, I was just… Yeah, we have the breakout tomorrow, if people want to attend there.

Ansgar Dietrichs: Yeah, and I think one of the topics raised on last October, so maybe for those that were not on there, there were some questions around, The unconditional payments, specifically, whether there should be some sort of, and splitting it into separate EAP or something, yeah, if that's a topic that interests you, tomorrow would be the breakout. Yeah, awesome. And I agree with Justin in chat. Great work all on these kind of glam-side dumb features already. It seems like we're already well into the work on this fork. We haven't even gotten Fusaka out the door, that's… this is… this is great. Yeah, then Glamstam, next, well, I had testing updates, but I assume that's already covered now with the Black Lives specific testing. Was there anything else on testing, for Glamstam beyond that, that we should cover, or… I assume this was it?

If nothing else, then, the, then for the rest of the call, we just have a few more, updates on other… on proposed EAPs and new proposed, EAPs for the non-headliner section of Amsterdam. Just before we do that, A reminder, we had said that basically when, once we set the mainnet date for Fusaka, we will basically freeze the proposal window for… For Gramstadam, we haven't done it yet, but obviously we're getting close to that point. And then on that last Orquadevs, on the ACDC side, we specifically, like, clarified the details of, like, what the exact timeline there looks like, so the idea is that whatever point in time we actually do set the mainnet dates for Fusaka, that… then basically that will trigger, like, one last week of, proposal window for…

for non-Hightline ERPs for Ram Saddam, and then basically the deadline there would be then one week. So basically, the QRFs, the Okadavs call, one week after that. In a date setting one. That way, hopefully, people have time to get in U.S. Moment proposals. With that out of the way, we have three, people that wanted to, to briefly talk about, some of these proposed ERPs. The idea would be that in next, ACDE call, so in two weeks, we would really go into the discussion, More, more generally about, what kind of the non-headliner section should be focused on, but for now, it's still just about just informing people about the individual proposals, so it's not necessarily meant as a governance discussion section or a technical information section. First up would be Maria, who wanted to briefly talk about an update on the repricing ERPs. Maria, are you on the call?

Maria Silva: Yes, hello. I'll just quickly share my screen. I have a few slides to help with the discussion.

Ansgar Dietrichs: It's still loading.

Maria Silva: Okay, can I…

Ansgar Dietrichs: We can see your speed.

Maria Silva: Perfect. Okay, so I will just give a quick overview on the repricing ZIP, so we have quite a few now. And just to say that, before we release the IPs, I wanted to just give an overview of why we are even doing repricings. So the… the first point is, like, we know that EVM operations don't have harmonized costs at the moment. So, for instance, on the compute side, we have operations that take show different, performance in terms of million gas per second. We, on, for instance, state creation, not all operations have the same cost per byte created, so, this creates, a situation where we have, like, specific bottlenecks, that sort of, limit us on how much we can scale, instead of just having everything, harmonized. The second point is that even

if the costs are harmonized at resource level, the relative cost of resources, will likely change with, balls and EPBS. So, for instance, we may have more time for execution, but the state growth, we don't want it to increase at the same rate, so we want to keep state growth stable while giving more space for… for compute. So the relative cost there also changes. And finally, as we increase the gas limit as we are scaling, this will put pressure on these persistent usage resources, which are mostly history, growth, and state growth. So there… there… we also need to take this into consideration when we are doing the… the repricings. And, now on to the proposed EIP. So I just want to say that, EIP8007 has the full list, so if you ever want to check which EIPs are changing pricings for Amsterdam, you can check there.

But this is mostly an informational EIP, so we are not, this is not the bundle, like, we are still discussing them one by one, and considering if we should include one by one, it's just a place where you can have a quick view of all the IPs and their status in the governance process. And so on to the various, EIPs. So first, on the compute and memory side, we have, 7904. This is the big repricing on compute, operations, that is, So we are using, benchmarks on each operation to harmonize their, costs, and also, this will likely lead to a decrease in most, compute prices, with, likely some, exceptions on some recompiles. But essentially, this is a massive, reprice on, compute operations, and

most of it will be, making them cheaper. We have, 7667, so this is updating some, operations, based on the hashing cost for ZKVM proofing. So this is sort of, an EIP that, it's not directly to… It's not directly related to increasing, scaling, but it… it's something we might need down the line when we are moving to the ZKVM, and it's something we need to… to also account when we are working on the 7904, to make sure that these changes make sense and are consistent. And finally, we have 79… 2, 3, and here, Charles is going to give an update, but essentially, we are introducing a new model for memory, and also updating the price accordingly.

On states, we have 8032, which, Guillaume will also give an update next. And essentially, this is just repricing S-Store in a way that, takes into consideration the size of the contract storage. So essentially it's making larger, S-stores to larger, contracts more expensive than to smaller contracts. And then the next two EIPs are, the 8037, which is changing the state creation cost, so this is, targeting state growth, and it's, proposing an increase of around 10x on the state creation costs. And also adding an independent metering for the co-deposit components, And 8038, so this is focused on state access costs, and also it's sort of connected with the tree-based storage, but it's doing a more holistic reprice on all state access, and also taking into consideration

If, it's your all three, is included, then, they will kind of work together, so the… 8038 will simply change the constant part of SSTOR, and leave the dynamic part with the contract size scaling, consistent with, with, with that EIP. On data, we have two. We have 7981, that is, introducing a floor to access lists. And also, 7976, that, is further increasing the cost for call data. A point here that is important, so we have For data and state growth, these essentially are mostly independent resources from the execution and state access resources, and so it's important when we are setting the values here to make sure that things are consistent with a certain ghazi meat anchor, let's say. So,

We are not introducing more mispricings. And finally, we have two more general or accounting EIPs. So, 2780 is proposing to reduce the intrinsic costs, so essentially making eTransfers cheaper, but also adding a component for account creation. So when an e-transfer is creating an account, essentially it will be more expensive. And then finally, 7778, that, proposes to remove the refunds, from the block limit accounting. So, they will still be a refund to the transaction, but they will not count for the block limit, so this should help us remove some Some, worst-case blocks that are making those cases not, as worrisome. So on the next steps, First, it's just, making sure that we are considering all mispriced areas, and, and see if there's anything else we should be adding, before the, the deadline for, EIP proposals. So if you have, any thoughts on these, just,

reach out to me, and I'm happy to… to… to discuss it and support, any more EIPs that need to… need to be drafted. We also are working now, with, opcode benchmarking, and this will help us set the final parameters for some of the EIPs, and also updating a few parameters that need, updating. And also, we need to make sure on this step that, again, as I was telling, to have the alignment between the various EIPs and making sure that things are consistent and make sense. And then after this, we'll… the next step will be to start implementing these new price changes in all… in all the clients, and then running as benchmarks, so we make sure that,

The worst-case scenarios, are covered, and we are not introducing more mispricings. And also, another big part here is, like, this is one of the biggest repricings that we've done in a lot of time, so it's important for us to really investigate backward compatibility issues and making sure that we are not introducing anything that could break. Important contracts, or… Yeah, and so here on, on this point, like, if you have any thoughts on what could break, also please reach out to me, so we can, we can work on these together. And this concludes the presentation. I was not seeing the shots, but I will stop Now, the slides and…

Ansgar Dietrichs: there were, again, maybe just read them out to you, there were two, I think, main questions. Well, one is just where practically, Charles was asking what the best way for people would be to reach out to you for feedback on these topics.

Maria Silva: Yes, so I'll say, Telegram is a good, a good place, so I can… put my handle if you don't have it, in the chat in a bit. But yeah, just Telegram is probably the easiest.

Ansgar Dietrichs: Sounds good. And then, Matt specifically asked you, you already touched on this a bit, on the question of backwards compatibility. Is there already ongoing work? Like, is this maybe different ERP by ERP? So what's, what's the current state of this, basically?

Maria Silva: Yeah, so I think on a couple of the IP IPs that were, either making things cheaper, usually the analysis was there's not, a lot of concerns there. I think the biggest concerns are actually on, probably the state's, state growth and state access ones that will have an increase, and on there, we do have some analysis planned, but, it's still ongoing, so we don't have any results yet. Guillaume, do you have anything to add here?

Guillaume Ballet: Now on this topic, I have something to… I mean, I want to talk about, EIP, yeah, okay, let me, let me proceed. I have two, two things going on. The first, the first one is that, 20, 2926 is not in the list, and it is a, it is definitely addressing, the state growth in terms of code. And, I'm also quite surprised to discover AT37, which is very redundant with 2926. I've also seen a, and unfortunately, Carlos is not here today, but Carlos was asking me to review something that I thought was going to be, AT37. When, you know, is, is it still, is it still evolving that, And this is the supposedly definitive version.

Maria Silva: So, your sound broke out a little bit, so you are asking about, right. 37.

Guillaume Ballet: AT37, yes. Okay, I'll just, I assume that was Telegram, taking over the sound, let me turn it off. Yeah, so two things. The first one is that 2926 is very redundant with AT37, and it seemed to me that AT37 was going… I reviewed a document by Carlos, who unfortunately is not here today. that was… to be, I thought, the future version of AT37, so I'm just asking, is it the final version?

Maria Silva: this… this version is… is the most updated version. We may need some parameter changes down the line, but these should be the… the… the… and some… some more, So, improving sections on specs and backwards compatibility issues, but this should be the final EIP. I would say that the main difference there is that this EIP is not only focusing on contract code, but it's also focusing on other components, like account creation and so on and so forth. And I think we can make both VIPs compatible, so the… the… the… the biggest thing is, like. 8037 is really focusing on an harmonization of state growth in general for all operations that, touch or increase state. And I think both VIPs are kind of… they work together, so you can have both, or you can have just one or the other, so it's… I don't think it's, like.

If you have one, you don't need the other. They are kind of, So they… they… they have implications to one and the other, but they are not, exclusive, let's say.

Guillaume Ballet: Yeah, okay, I would still like to get, but I will talk to Carlos. I'd like to get to the bottom, because I reviewed something on Tuesday that was quite different, so I'd like to make sure I understand. But yeah, okay, we can take that offline.

Ansgar Dietrichs: But any other, comments on, the presentation? Or any of the individual, repressing your piece? Okay, and yeah, I saw Maria now put her telegram handle in the chat, so you can find it there. Then, I think we'll move on for now, to the next item, where, Guillaume, you'll be up again, talking about EIP 8032. Sorry, so before, before that, just one more, I saw Tony had a sent-up, sorry about that.

Toni Wahrstätter: Yeah, I… sorry, to interrupt. I just had a question, like, how would we best proceed with the repricing EAPs? Usually we have, like, client teams shortlist, their preferred EIPs. Yeah, should we… is there some different process involved, because it's, like, a bundled, repricing thing?

Ansgar Dietrichs: So, just… just to clarify, I think Maria did a good job summarizing this already. Basically, here this… why there is this extra information on ERP, which was a bit of an experiment as the form factor, but… and there is no specific bundling. So, obviously, some of them make sense together, and we can point this out and talk about this a bit more, I think, in two weeks, but in principle, we can pick any and none and all of them, basically whatever we choose. In terms of process, specifically, my idea was, and I'm happy for feedback if people think this is a bad idea, my idea was to say, start the conversation properly next, ACDE, so in two weeks, around

And what should be the priorities? How much room do we think we have in Amsterdam? Like, what is the different categories of the ERPs that basically were proposed? So to have some sort of baseline of what do we expect Amsterdam to look like, and then on that basis, have some ERP-specific discussions, and then move to the step of having client teams, assemble their preferences. so basically, like, today still focus purely on just the technical presentations of the individual ERPs. Does that make sense for people? If not, of course, this could be adjusted. I like the most reasonable approach to me. Sounds good. Then I would for now stick with it, but again, also feel free to…

reach out to me, we can, we can discuss, some alternative processes as well. But yeah, then, for now, Guillaume, you're up.

Guillaume Ballet: Yeah, okay, I hope you guys can see my screen, or my window. Yeah, I'd like to talk to you about EIP8032, which indeed stems from all the conversations about state access or state-related operations repricing. So… there are very, simple goals for this thing. We want to limit the state growth. We also want to make sure that no individual contract, and there's really one that we're thinking of when we say that, oops, is… their individual growth is reduced. And then, of course, we would like a smooth transition as much as possible. So, yeah, like, the idea, there's a big math formula inspired by the yellow paper, but it's very simple. You just, notice.

Write down, into the account what was the maximum depth that, was written to previously into this account, into this account storage tree. And then, we target an activation depth, which would be, targeting that same contract I was talking about, but maybe other contracts if they happen to grow just as large. And then the new gas cost for writing, so… for writing, which is a store, would be, would be simply to take the delta written in the account, which is loaded at the beginning of the block execution, and then you have this constant value, which is today's value, or any value that is decided after the repric… repricing EIP. And then, you just get, the delta divided by this, delta 0, power of 16, and then you take the, the floor, like, the… the smallest, integer.

Down, from this number. And multiply by another cost, constant. The idea is that everything that is below this delta zero will not see its cost changed at all. And everything above, so that contract, will be, will see its, its cost, increasing exponentially. And, yeah, how does the transition happen? It's just that from one block to the next. At the end of a block, you just look at, for each account, when you recompute the storage root of this account, you just update the value, the delta value of this account, the maximum depth. And then… You don't update it with a new value, you just gradually increases one by one, so that the cost of those contracts that are already much larger than the limit.

increase somewhat progressively. I mean, it's going to be, probably 9 blocks, but it's still, it's still going to be a bit smoother. And, yeah, maybe we can modify this, conversion to… sorry, this rule to be even more, disincentivizing of the state growth as a whole. So, do the same thing, but add a gamma, which is the total state size, and we do have, at least in Geth, we did implement something to keep track of the total state growth. It's not exactly what we need, but it's close enough that we could modify it to be that. And then we would have a second term in that equation. Where not only the specific contract will be penalized for growing the state, but even those who are not this big contract, but have to suffer from a larger state growth.

they will see their costs rising up, so it's much more dynamic. And of course, we can modify those constants as machines get more powerful, as states, maybe if we implement state expiry. We could also decrease them. So yeah, that's just an idea, but it's not part of the EIP at this moment. So just wanted to also say what it's not. It doesn't tell us what the gas costs are gonna be, so, some of those EIP, like, especially AT38, AT37 maybe, and all those EIPs that focus on the gas cost itself, this is not… this is orthogonal to that. It also doesn't work on limiting account creation per se, it's just the storage size. I would say 2026 addresses

The… the code size aspect, but yeah, there's nothing for account creation. And yeah, like I said, the code bloat, yeah, that's 2026. I have one last slide, yep. It's what is left to be done, so I did implement that in Geth. It's still in draft mode because I haven't figured out the activation yet, but it doesn't really matter for testing. And, what we would like to do is get the constant value, so, piggybacking on what Maria was saying, try to, try to see if, we could, use EIP, any of the EIP in 8007 to, to figure out what the values are. And also, decide on the gas formula. I presented two, so pick one of the two. Yep, that's… that's it for the presentation.

Ansgar Dietrichs: Thank you. There were a few comments in chat. Specifically, one, one conversation was around. how do you… how are you thinking about using the worst case for pricing? Is this not vulnerable for attacks, where someone can basically, like, maliciously create one really, like, deep sub-branch in a storage tree, and then forever that contract has to pay more?

Guillaume Ballet: Yeah, so, I mean, this is more explained in the EIP, so let me refer you to the EIP. But, no, you can't really do this, because the activation depth is going to be 9, so that's pretty expensive to get, to get this, this depth. Voluntarily. Because it's, like, the storage slots, are stored you know, the keys are hashed before, so to be… to be able to get that deep, you're going to have to create either a lot of keys, which is going to be expensive, or do a lot of proof of work to address… to reach that depth. So, no, it's not an attack.

Ansgar Dietrichs: Makes sense. And then one more conversation, but there were several different people talking about it, but I would summarize it maybe as, if you have multiple accesses, then if they're in the same storage tree, even if it's a bit deeper, then they amortize, basically, because they are in the same tree and partially share the same branch, whereas If maybe you now incentivize, which in principle is a good thing, people to split it up into several contracts, so that in each contract it's less steep, but then they no longer basically have this amortization. So basically, do you think this is a concern, that maybe the efficiency gain, in a way, can be less in these cases? Or that basically it's kind of… yeah.

Guillaume Ballet: I didn't quite understand the question. What is going to… what would the efficiency decrease?

Ansgar Dietrichs: So basically, there's someone, like, so suppose, for example, said, was there an explanation why one contract of size 2S is worse than two contracts of size S? And of course, this is only relevant if they're actually being accessed. So imagine you have now someone, basically, that otherwise would have a contract of size 2S, now splits it up into two contracts of size S, and we have a block with simultaneous accesses into both contracts. And in the old world, that would have been just one… two accesses into the same storage tree of one contract. Is this more… is this new pattern more efficient now, or is it mapped?

Guillaume Ballet: I mean, if you want to do this, it's not going to be that much more efficient, because to access your second slot, you're going to have to call the contract, so it's going to be expensive to do this. But yes, you could do this, and in fact, this is more or less what we want, and the reason for this is because you… you would be able to expire, thanks. I mean, we're still counting on getting state expiry to work, so it would actually be exactly what we want, that people split their data into several contracts, but somehow. Doing the union of all the contracts, that's going to be very expensive, so it's going to disincentivize state growth, this way.

Ansgar Dietrichs: Sounds good. And then, of course, lots of people can also speak up, I don't need to read all these comments, but, Matt asked, how does this ERP relate to the unification of state of the state tree?

Guillaume Ballet: Yeah, I mean, if the question is, can this still work with a unified state tree? Yes, it can. And although I forgot how it was going to work, but we came up with a scheme to make it work, so that's not a problem. The other, I was thinking of something else. So, if you're talking about doing the transition, this is… this has no impact, because, yeah, it's not going to change the structure of the tree, and it's not going to block the tree from being converted into a different tree.

Ansgar Dietrichs: Sounds good. Any other questions, or any questions from chat that I missed that someone would want an answer from Guillaume? Okay, awesome. Well, thank you, Guillaume. I personally think this is a very interesting idea, although, of course, I'm supposed to be impartial. Then, next up, we have Charles with, several EIPs that, he wanted to talk about. Just given that, I mean, we still have 25 minutes of time, but I would ideally say that, it would be nice to try to timebox it a bit below that, to not, not, because it's four EIPs, but basically, like. keep it up by going through the intro, just so we still have a chance of ending a little bit ahead of time.

But yeah, Charles, are you on the call?

Charles Cooper: Yes, hello?

Ansgar Dietrichs: Awesome.

Charles Cooper: Can you hear me okay?

Ansgar Dietrichs: Yes, we can hear you.

Charles Cooper: Okay, I think a couple of these aren't that new, they've been proposed in previous works, so I won't go over them that much. There's 7907 and 7903. Which are alternative proposals. Which were, proposed for Fusaka. And they are about increasing the contract size, the EIP170 24 kilobyte limit. And in Fusaka. 7907 was rejected because it makes some changes to the state, which are maybe hard to reason about. 7903 is an alternative, which doesn't touch, state. assumptions about state at all. It increases the limit for init code. But that is… just runs once, and then it's never a certain state, so it's not an issue, really. 5920 is pay. which I've proposed again for Amsterdam.

And that is the ability to send Ether directly to another contract. Without execute… without transferring execution context. 7923 is new for Amsterdam, and Maria mentioned it. It's about changing the quadratic Memory? Actually, I didn't realize there would be this much time today. So I prepared a presentation for 7791, which is the one I want to emphasize this call, but… so I'm just going through the other ones quickly. Yeah, 7923 is about changing the quadratic memory pricing. It proposes a paging model, so, like, I guess, most other computers in the modern age, We can make… the AVM have virtual pages, and this is super helpful for users and also compiler developers.

Who can then, use more of the memory space. So, for example, if you want to have a heap and a stack, normally, if you have, like, with this quadratic memory, if you start from zero, then you can only have one stack or a heap, basically. Whereas in normal computers, you just allocate them in completely different areas of the memory, and then they grow Separately. The one kind of contentious issue that I've gotten in private feedback so far is there's… this kind of LRU cache. Which is, to help pricing, basically. the 512 most recently accessed pages are cheaper to access because it reflects some reality of the underlying hardware, which is that if you have a thrash, so, like, either a cache thrash or a… what do you call it, a TLB miss.

That incurs extra, CPU time. And it tries to model that. But I'm… There's some discussion about this on the ETH interesting thread, and I'm a little bit open to changes. About that particular model. That part of the model. But in general, I think that having, page-based memory is… is good and important for the EVM. So, I want to… present on 7791, which is, I guess, the ETH. Let me share my screen. Is this visible?

Ansgar Dietrichs: We can share his… we can see his thing.

Charles Cooper: Great. I wonder how I can make this better. paper. So, making PowerPoints actually isn't one of my strengths, so this is mostly made by… the… one of the LLMs. But it, basically… Summarizes the IP and, I'm gonna go into some interesting parts about it. So, the gas to ETH is actually a very, simple Opcode. Basically, it takes… gas amount, and it pops up from the stack, and then it sends that amount of gas from the TX origin to the target. And the reason this is important is because… Basically. every protocol or smart contract author runs into this issue of, like, how do I get paid?

And there's a lot of… Problems with, getting paid. One of them… Yeah, where do I even begin? So… And then people come up with all kinds of different ways to get around this, like they launch tokens or whatever. So, some of the issues with, like, getting paid directly on-chain are that the payment… there's no way to pay directly from TX Origin to the contract that you want to pay. you basically have to, like, do payment hops. So, like, if you have a deep chain of contract calls, then you have to, like, forward message.value, or forward some token down the entire chain, until it finally gets to the target. And, that's just kind of… Bad UX?

Because you have to, like, do a bunch of calculation, you have to make sure that the right amount of message value is passed, and so on. So what this… The AP is trying to address that problem, so basically, it uses a concept that's familiar from UX, which is paying gas. Like, everybody kind of knows that in order to keep the network running, you have to, pay gas. And it uses gas to, like, kind of… Pay contract creators. So… Yeah. There's some kind of interesting technical issues that have been brought up with this so far. So, One thing is that… If you link it too close… Oh, I wanted to point out there's another important thing about using gas, which is that instead of ether, which is that it's kind of actually priced in terms of block space demand.

I don't know, very opinionated. Yes. So… whereas Ether is kind of… has its own value, or whatever, gas is usually actually priced in basically USD, so in some ways, its price is more stable, or it's, like, kind of… It kind of aligns contract authors with the chain, because when gas prices go up, people who are paid with gas to ETH get paid more. So, there's a few, interesting things about the design. That have been brought up. So, one is that, interacting with the burn is bad. So, basically. The gas consumed by gas is actually very different from gas that's, like, consumed by regular opcodes. So, gas consumed by regular op codes, it, like, reflects some computational complexity, whereas this actually just reflects how much somebody wants to get paid.

So, you don't want it to affect the burn, because there are kind of griefing attacks, like, you can just, like, send a bunch of gas to Ethan, and you can, like, change the base fee, or whatever. And it shouldn't, like, double accounting for, how much is sent to Coinbase or whatever. so, what we've done is we've created a separate gas ETH limit. Which is tracked separately from the regular gas, and that is a slightly more complex implementation, I think, but it kind of sucks. steps all of these issues with, like, how… Gases. Interacts with the rest of the protocol. Another thing is, like, how much gas are you allowed to send with gas to ETH? And, there's a problem that has been correctly pointed out, is that, like, you can…

It's like a grieving vector, like, you can… send an arbitrary… You can spend an arbitrary, you can do all kinds of clever things to avoid that showing up when you run eSimulate. So, the solution in this EIP is to, like, limit the amount of gas that can be spent. Or, the amount of gas that can be spent as action in gas, and that's kind of, like, some kind of reasonable Limit, but… And… but I think the most natural thing to do is actually introduce a new transaction type, which… Might be in the future, but a neutral action type by gas to use. Maybe even by account. But, basically we left it out of the CFP because, that could be more…

Complex in terms of, actually being able to ship the feature. So these are just some other things that are in the AP. That you can look up. Yeah. So… This is also, stuff that I already mentioned. I think the main thing is that it gets spent by TX Origin. Which is, like, kind of the natural… Party that should pay for, these kinds of on-chain payments. So, here we have some examples of apps, and I won't spend too much time because, I think everybody maybe kind of gets the point, and the time is limited, but… These are just some examples. So that you can, like, imagine what it can be used for. So one is, like, you have a DEX, you need to pay the protocol for the swap, and then you use gas to ETH, and then it pays the fee collector contract.

And these are… all kind of, like, actually in the same vein, which is, like, somebody created a smart contract, and you want to use it, and they get paid. This is another one. So, the Oracle Bridge callback, so you, like. pay in Oracle, or you pay a bridge, and then… sorry, you call an order call or a bridge, and then when you call it, the bridge or the Oracle operator gets paid. something kind of like a SaaS contract, so these are, like, pay-per-function, so you want to use some kind of functionality of this contract, and in this particular one, then… It does some… Whatever calculation, and then… Pays the maintainer address, and then… Finishes the computation and returns.

And so this allows for, like, very… What is it like? Like, micro service, like, super micropayments. Like, you can… Like, account for, like, how much should be paid at a very granular level. The gas cost model is kind of what you expect. It should, like, basically be the same as pay opcode. Yeah, I think this is a good place to end and take questions. There has actually been an… a draft implementation for REVM that was based on a previous, version of the EIP, which several of these issues came up that I discussed. And there's also an RIP, the 7767, which is… has been proposed by Vectra for, L2s to use.

And that is something that operates in a kind of similar way. Okay, let me take a look at some of these. questions. Interesting.

Ansgar Dietrichs: Yeah, totally.

Charles Cooper: Pretty, absolutely, yeah.

Ansgar Dietrichs: chat's very mixed now, because we still have also some conversation from the previous presentations mixed in between. Yeah, first of all, thank you for the presentation. Like, just a quick side mention, one of the other, the ones, not this ERP that you presented, but one of the ones you mentioned, the memory pricing one is also tracked by this repricing candidates' informational EIP. So this is kind of part of that broader set of potentially doing some repricings. Concretely on this, on this specific EIP, the gas to ETH, one, do we have questions? I personally… I voiced some… some… not concerned, the concern is maybe just strong. I'm actually… I think it's interesting, but, like, it definitely feels like it's a… it's one of those i.e. subtle implication changes, so I… for me, it would basically, like, require, like, a high threshold of

And really understanding and thinking through the implications. But yeah, I'd be curious if there's comments. Ben, you have your hand up?

Ben Adams: Yeah, I think it's… I think it's quite interesting, Gasteeth, because people do try and do it in practice, say with tokens. In the end, I would like undesirable side effects where… you'll take a fee in ETH if it's one side of the trade, or you take a fee in tokens if it's the other side of a trade, for instance. But then, as a result of that, you have to dump the tokens, which, you know. People who hold the tokens, they're like, And then it also deals with the fact that if it's not something like a token swap where there's transfer of value. There are other contracts that… That's simply… Can't factor in some kind of payment.

In an easy way. And also, like, what is it? The… The royalty thing on, NFTs, that's like a… A sort of, trust me, bro, we will pay you, but you could, like. Bill Diane. This kind of mechanism. And then it sort of worked with Ether's money, I suppose.

Ansgar Dietrichs: That's a… that's a good point. Yeah, no, but I… I agree, definitely also, and that's why, yeah, it's definitely also very interesting. Yeah, anyone else also with any feedback on this ERP in particular?

Marius van der Wijden: Yeah, yeah.

Ansgar Dietrichs: assistant. I know.

Marius van der Wijden: Yeah, I had… I had two questions that I put into the chat. One is, what would the interaction with the current AA stuff look like? And the other one is, how would the… Transaction format need to change?

Charles Cooper: So the transaction format, it doesn't need to change, so it's not in the CIP, it could be added in the future, but basically, it would describe how much gas can be spent by the gas to ETH opcode in this transaction. And it's a way for the user to avoid being, griefed. But instead, in this version of the IP, it's just, there's a kind of a… a constant, I guess, a global thing, which is, like, it's just set to the transaction gas limit that's, normal gas, if that makes sense. I don't know if there's any interaction with… Any AA things? I don't… I don't think so, really.

Ben Adams: I suppose the issue would be if you bundled lots of transactions together, then… One of the transactions could take more gas than… You know, if it's saying, here's the gas for 5 transactions, and one of them Takes all of it. So it could be… that could be a bundling issue.

Charles Cooper: I'm not sure I understand about the bundling issue.

Ben Adams: Well, cause you're saying, I want to send this… My first transactions allowed to have one ETH, the second one, one ETH, third one, one ETH. But… The first transaction would take all of these, because the transaction as a whole This is something you could do in a gas fee.

Charles Cooper: Oh, I see. You mean how it interacts with the transaction limit?

Ben Adams: Or how it would interact with bundled transactions. Which, like, AI would discuss.

Charles Cooper: And… I'm not sure I see the issue. Like, that can be true for any kind of thing you do with bundling, right? Like, you might not have enough Gas to pay for all the transactions in the bundle. That isn't the same as, like…

Ben Adams: Yeah, it's because you're specifying the griefing limit. Per transaction.

Charles Cooper: Okay.

Ben Adams: But the transaction's composed of multiple transactions. So the first one.

Charles Cooper: Alright.

Ben Adams: can go up to the.

Ansgar Dietrichs: Yeah, and I would also say maybe.

Charles Cooper: I think that would be, like, a problem of simulation.

Ansgar Dietrichs: you know, one related concern that I would have is that I think we very specifically discourage these days the pattern of sending bounded gas into subcalls, because that makes assumptions… there's assumptions about details of pricing that we want to obstruct away with. That's abstraction, Which means that, in principle, kind of any, any transaction now is fully vulnerable to, to, to basically all the, like, like, like the gas being, being, being consumed for payment, like this. which…

Charles Cooper: Yes, yes.

Ansgar Dietrichs: You can already… oh, yeah.

Charles Cooper: It's a separate budget. So that's one of the more recent changes to the EIP, which is that it doesn't interact with the gas used by the contract.

Ansgar Dietrichs: But then how can…

Marius van der Wijden: If it's a separate budget, it wouldn't need the transaction type. Right.

Charles Cooper: The new transaction type would set the limit for the separate budget. But, like, let's say that you have a contract column that, needs 100,000 gas, but the gas ETH budget is separate. Like, gas ETH can separately consume 100,000 gas.

Ansgar Dietrichs: Yeah, I think we're getting now pretty into the weeds for the CIP, so we should probably take it offline here. But yeah, it's definitely… it's definitely an interesting concept. And again, there's probably a lot of skepticism you have to push through first, but it's very interesting, so yeah. Yeah.

Charles Cooper: Marius just said it breaks all gas estimation, but it doesn't. I'm happy to chat with you offline about this. What's the best way to…

Ansgar Dietrichs: Like, how… what's the best kind of venue for discussion on this EFP specifically?

Charles Cooper: I can make a Telegram group.

Ansgar Dietrichs: That's good. There's also, I think there's here on screen, there's a Minis Magicians, thread as well, on this API, as well.

Charles Cooper: and youth nutrition store.

Ansgar Dietrichs: Perfect. Maybe someone's gonna somehow find this and put us into the chat? That would be… Ideal, I'll also try to find it. Brownie finds for the first person to do it. Perfect. Charles, you've got your own brownie points. M… Perfect. Then, yeah. Thank you, Chadz, and I would, I would, kind of end that section for now, for here. Do we have, we have, in principle, 3 minutes left, do we have any last topics that were not on the agenda? Anything someone would want to briefly bring up? Otherwise, you can wrap here. Yes?

Marc Garreau: Briefly, just a housekeeping item, for… PFI'd EIP is going into Glamsterdam. We've recently agreed to collect a primary point of contact for those, so if we, the protocol support team, will default to selecting whoever opened the PR to PFI that EIP, but we'll ping each of those parties for confirmation. So those names and Discord handles will be… Likely displayed on… on forecast for the benefit of testing teams and Pandops and so on.

Ansgar Dietrichs: Sounds good. Yeah, that's a really good initiative. And Forecast in general, like, I said it off the air already, but, like, also for anyone listening, like, go check out Forecast, it's… it's amazing. Awesome. Then if there's nothing else, then thank you all. We ended up taking the full 90 minutes after all. As I said, in two weeks, we can start the Amsterdam discussion properly, and until then, have a good time. See you all then. Bye.

Justin Florentine: Nice debut, Nsgar!

Ansgar Dietrichs: Thank you. Bye, man.

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