Glamsterdam Repricings #7

Transcript

Jochem Brouwer: Hey, I hate it.

Ben Adams: Yay.

Jochem Brouwer: Right.

Dragan Rakita: Hello.

Jochem Brouwer: Where are you?

Maria Silva: Okay. Sorry, I was a bit late, and I think the call would only start after I join, I guess? Sorry for the delay. Yeah, I wrote a message in the threads, see if more people join, and then we can… we can kick off. And we have a big docket today, so let's see if we can cover all topics. I'll just share the agenda here, so everyone is aware. Maybe we can wait one more minute, and then we'll… we'll go.

Okay, so maybe we can, kick off. I don't see more people joining. So the first, topic on the agenda is EIP8037, so the state creation does cause increase, and for here we have a couple of updates, and then a couple of open topics, that I wanted to discuss, so… First, just an update, the Steel team has released the latest, spec, so this one now, doesn't have the… refunds for self-destruct. The EIP on that is not yet, updated, so it's something I'll, I'll do. And maybe I can share my screen so it's a bit easier to go through. Essentially, this is the… the new release. So I… I… I do have these two PRs on the… on the, on the EIP. The first one was to focus on, the, open issues we had from BAL devnet 6.

But this one still needs to be updated to remove the… refunds from Self-Destruct, and then the second one was more about updating the parameters, the… the exact numbers, and there's two components to these. So, first is fixing the cost per byte to a value that would be, like, the closer to the… what we actually do on the final Amsterdam fork. And the second one is just changing some… Parameters to make them more consistent with the state access, cost increase, and also the 2780, so the intrinsic transaction gas. Changes, And I think one thing I wanted to bring up on this one, so I haven't yet, I'm not sure if you all

have seen the numbers, but I think it would be nice to have, like, a discussion on if the level of increases look alright. So, what I ended up doing is, Maybe I can just… Air… What we have here? So, essentially, now, we are targeting a growth of 120 gigabytes per year, so this would be, like, a worst-case state growth. With a block limit of 150. So what this would mean is that I would expect, maybe in the beginning. Right after the… the fork, for us to have lower, limits, so it will be actually a bit overpriced. And then at the end, or closer to the next fork, it would be more towards the bigger block limit, so it would be maybe slightly underpriced, so we could have, in theory, a bit higher than this growth rate. But again, this is, like, a worst case.

And, with this sort of, Numbers, the level of increases we would see would be… So maybe I can show it… Where is it? It's here. So I have for a new account, this would be a 7-time increase for a new slot, a 5-time increase, and for a contract deployment, an 8-time Increase. This seems like a lot, but you then… you kind of turn it into a cost in ETH, based on the base fee we have right now, which we still expect the base fee to go down with the increased, with the increased, block limit, and, it's actually not horrible. So yeah, I'm curious to see, like, if you have any opinions on these. Are these… do these numbers seem okay? So this would be a cost per state bite of around $1,500.

And also curious, like, just to… just to double check, in the current spec, are we already using these, or are we still using the old cost per byte?

Stefan Starflinger: For Paradefinite 7, I think I updated it to this new version.

Maria Silva: Okay, perfect. But yeah, curious to hear your thoughts here, or… If there's no strong opposition to this, I guess we should just keep with this, and then update if there are any concerns. Go, Ben.

Ben Adams: So… Proposal, we're doing the 64 kilobyte. deployment. Would that be a problem with, the block gas size.

Maria Silva: I don't think so, right? So we are increasing the blog size. So this should be… So this cost has both the new account costs, and then the majority of it is actually the size of the contract. So, if we were just to assume… let me just see… So this is a 2.5 times increase, so 37K times… to 5, so it would be around the 92K. So, it should be fine, I guess.

Ben Adams: With that.

Maria Silva: Between the blog post.

Ben Adams: Does that mean if you deployed a 64 kilobyte contract? You'd use an entire, Entire, yeah, full block. So nobody would be able to do any other state. That'd be true.

Maria Silva: Let me see, I would… if we had the 1… 1,000 block limit, yes. Oh, sorry, okay. Go, Jocham!

Jochem Brouwer: Yeah, so this number for the 24KB contracted plugin, that is only, the cost for paying for this creation, right?

Maria Silva: Yeah, only creation.

Jochem Brouwer: Yeah, okay, we also have to take into account that this does not… Not leave any room for internet codes or data. I think that's fine, because we… for deploying it, we would need, like, 100 million gas, so… that's fine, but yeah, then one block would have, like, this deployment.

Maria Silva: Yes.

Jochem Brouwer: Okay, cool.

Maria Silva: Go Ben?

Ben Adams: I'm… I am… Quite interested in, the proposal from… I can't remember the name slipping me… of, Not… not necessarily for now. For the proposal of deduplication, i.e. if the code hash already exists. You don't get charged. bug code.

Maria Silva: So, how would that help here?

Ben Adams: Pretty sure.

Maria Silva: Applying existing code, right?

Ben Adams: Yeah, so a lot of code is just copies of, already… code that already exists. So, for instance, if you are… creating a new Uniswap pool, it's… it's… it just creates an identical create 2 of code that's already on… on the chain, but you all get charged In this… in this case, for Uniswap. B3, Paul, I think you got charged 38. Million gas. Even though it doesn't actually deploy any code.

Maria Silva: Right. Yeah, I think that was the proposal that Carlos initially had, that was declined for Glamsterdam, but for sure, we can definitely try to revisit it for the next work.

Ben Adams: Yeah. The current proposal's, like, kind of junky. I don't think it's right.

Maria Silva: Right.

Dragan Rakita: Yeah, I think, if we… assume that we can read all the deployed contracts by the code hash. I think it's more complex than then we… like, it's… I think it's complexity a lot higher than… than the peaches. So, that means that everybody needs to take care of an amount of the bytecode, basically, there are inside the table, and to take care if delegation is happening or not. So I think it becomes really hard and complex to basically. to implement that. Basically, if the contract is already, deployed, Do not charge. The gas again. I like idea, but single complexity is higher.

Maria Silva: Right, and I think that was also one of the reasons why it was… it didn't went through. So yeah. But I would say, I think the worry of the contract deployments filling up a block, I think, should be alleviated once we do the full pricing. Like, if we had The price for state creation have an independent base fee. from the other costs, then we could even lift the block limit. Like, the block limit wouldn't need to take into consideration state creation gas, and that would actually help a lot, right? Like, now things would make sense, like, you only feel the space in the block with the regular gas, which is the actual in-the-moment execution costs, and then the state growth is fully controlled by this dynamic base fee that, kind of makes things more expensive as we hit… as we move away from our long-term growth target.

So I do see the potential issues of right now having this, but I think it will be… I'm hoping that it will be, like, a temporary quirk. Cool. Any more comments here? Okay, so I think what I will do… so, the release is out, so that's, good, so I will… merge these, parameters, then I will, finalize the fixes to the previous one, and then merge everything, so we have, like, a consistent, EIP, and then I'll let you guys know when everything is merged. I think theirs was also, a question on, adding a debug, like, add more debug information around, EIP-8037. I, I think, Stefan, you proposed this, PR.

Or you kind of, like, added these up, like, these… Proposal for, what it should be… Added. So curious to know if, like, is there anything we should discuss here, or are… People mostly align on what to do here.

Stefan Starflinger: Oh… I've iterated a little bit on it, and I think it would make sense to have such an endpoint. But I don't think that there is agreement yet on exactly how it should be, and if it should maybe be in the tracer. In the end, but I think, like, my proposal is pretty straightforward. It's not, I think, too, disjoint with the current implementation. So it would be a little bit faster, I would argue, than implementing a gas accounting tracer. But yeah, I'm curious to hear What clients think. Of the proposal.

Maria Silva: Oh, sorry, I was… Thinking I was opening one thing and opening another. But yeah, I'm curious also to hear is, like, how do you guys feel about this one?

Ben Adams: I interrupt when… We had, consensus issues, it was really hard to… Workout. Where the clients disagreed, so… I'm… I'm very… I'd be very appreciative of… Such a… such an API.

Dragan Rakita: I think the state gas is valuable. But does it mean that we are adding new field to our seat? And… if you're not adding new field to receipt, that means we need to execute, not just return receipt, but execute reception to get receipt back. I think this is the, I think adding… field for state gas makes sense, but I wouldn't add other fields, like cumulative gas, regular gas, and everything else, because everything can be assumed from the state gas.

Stefan Starflinger: I see that point, but also, like, this isn't, like, something in the normal receipt call, I just want to say that's, like, a debug, a new debug method that didn't exist before. So it shouldn't conflict with the existing receipt, call. And it should provide more debug information that… and I think it's better if it's declarative, and we don't have to derive everything. and implicit than if everything is implicit, so that's why I was a little bit more verbose in the proposal, because if you look at it, and you don't know exactly how to derive each of the fields. then I think it's more valuable. And it shouldn't be more effort in the implementation.

Dragan Rakita: If this is the point, then I would just add the two traces. I'm not exactly sure what's the format of the tracer, but if there is some output at the end that, like, summarizes the gases of basic data spend, I would add it there. Because it could get confusing if there is some additional RPC that Adds additional field to receive that receipt doesn't have. And only way to get the fields is basically to execute the section. It can get confusing.

Ben Adams: I mean, that… The downside of that is the prices are… Pretty big. Good. If you just wanna… Check the Gospels.

Stefan Starflinger: And my goal with the proposal was that you shouldn't have to re-execute the transaction. That was actually my aim, but I guess that might not be the case.

Dragan Rakita: Yeah, this is not the case. It's basically additional field if this additional field needs to be side their seats. If it is inside receipt, then should be omitted from the receipt route, state route? Not state route, but receipt route. So yeah, there's complication there.

Ben Adams: Yeah, I think you'd need to re-execute, so it would only work at… Recently, huh? Basically. Well, unless you have an archive name.

Dragan Rakita: I don't know the traces by heart. Does… do Tracer have, like, the last JSON output that specifies the end gas that's used? If there is something like that, maybe that's a good place to add those fields.

Ben Adams: Yeah, but then you have, like, every single opcode, and… potentially stack, and… Yeah, it's a… This is a very big.

Dragan Rakita: Yeah, I see.

Luis Pinto: But it's just an extra field and number, I think the worst ones are the storage and the memory. But yeah, as long as clients are consistent across execution, that they show the same… state gas, should be okay. I actually like, as well, the tracer approach.

Ben Adams: Okay, but my, my, okay, so my main issue is you have a consensus issue on the block. So you have to do… Trace block. Which is, in order to find out where you've gone wrong, which transaction's gone wrong. So you have the… Maximal possible trace in order to do that, which is, like, potentially… Hundreds of megabytes. Whereas if you had it as just receipts, you could say, oh, I went off on this transaction, now I can trace That individual transaction, for instance.

Dragan Rakita: Just idea, should we add additional fee to the Traces API to specify just get me output of execution? Omit topcode level. Or something like that. opcode call, I will just get me output. I'm not exactly sure, I'll ask the team after this, just to, like, figure out what they think is better. But I don't think the putting field decider seat is a good idea.

Maria Silva: Okay, so, maybe to move forward on this, we can continue to iterate async, so it seems like there's no… clear resolution here, and then we can probably… maybe this is something we can bring if we have some time on ACDT next week. Would that be okay? Okay, perfect. So before moving on to the other EIPs, I just wanted to have, like, a A quick check, like, how are client implementations going on? Going for… BAL devnet 7, and how are we in timelines for launching the DevNet? Yeah, I don't know, Stefan, do you want to start with DevNet, and then maybe we can go client by client and ask for the ones that are here.

Stefan Starflinger: Yeah, sure, on my side, I'm preparing local testing now, so I've set up the Hive tests, the Hive Test Quick, and the long one, the quick one should be running now with the new test release as well. So we should have results on health.ethpandaOps.io soon. And I'm, I will be starting kurtosis testing, I think, Today, but it would also be good to know how far clients are. Perfect. Maybe so. Yep, sorry.

Maria Silva: Yeah, maybe, Ben, do you want to start?

Ben Adams: I, we've just, merged… just before the call to BAL devnet 7, and also our master branch, the… 710 changes. Because they were… They did produce different results, I believe, too. That brings, like, a little better. Perfect.

Maria Silva: Okay.

Ben Adams: Anything else to be expected?

Maria Silva: Right, cool. Dragan, do you want to go next?

Dragan Rakita: Yeah, I was mostly passing 7.00 version. I had problem with Saddestruct, but 710, I think there is problem with authorization list. I think we should change that. Yeah, I have… I have changes in the code. And… Yeah, I think, I think the new spec release should be made.

Maria Silva: Okay, so is that this thread that you started, latest test, introduce additional check?

Dragan Rakita: Yeah. Basically, the… I need confirmation from the Steel team, but we shouldn't check the… if code exists or not. We should just check if code hash is 0 or not. Do you like different tracks?

Spencer Taylor-Brown: So that this would be doing an entirely different check, instead of doing both checks.

Dragan Rakita: Yeah, you will… you would just… you, as I've seen it in the spec code, you're loading the account, you're loading the code, and checking if that code exists. But what I am… But what the AIP is saying, you need to check only code hash 50. Kietrac empty. that's… yeah, I think this is the bug. And additionally, the… But I said, I CC'd you, Maria. I think we should check if the authorization address is zero. That means that delegation is going to be removed. This means if this happens, we should refund the bytecode.

Maria Silva: Right, yeah, I will definitely add that to the EIP with the fixes for self-destruct.

Dragan Rakita: Yeah, those two things are missing.

Maria Silva: Perfect. Luis and Daniel, do you want to go next?

Daniel Lehrner: Yeah, I can give an update. So I'm working on the 7.10 release of the test, and I think we are down to 3 failing tests, so most of the changes have been done. I'm debugging the… The remaining 3. Currently. So, it looks… yeah. By tomorrow, I don't know, we either change the tests, we make these changes to the specs that Dragon mentioned, and… If not, I just implemented how the specs are right now.

Maria Silva: Okay, thank you. Spencer and Felipe, do you have anything on your side, or are you guys good?

Spencer Taylor-Brown: I think we can, chat async, about the issue Dragan mentioned in the thread in the Steel server, and then we can, I think it's like a… tiny change, so I think… I think we should build to just add the change. I think maybe change one… one or two tests, and then retag.

Maria Silva: Perfect. Sounds good.

Felipe Selmo: Yeah, yeah, I think that's good on my end, too. I think this change might be semantically the same in the spec, the way it's written, but I agree that, like, we should check the code hash instead. Yeah, maybe, maybe async is best. To follow up here. Dragon.

Maria Silva: Perfect. Good. So, should we move on to the other topics, or is there anything related to EIP-8037 that, anyone wants to bring up? Okay, so if not, then I'll just give a quick update on 2780, so the intrinsic transaction gas reduction. So I have, this PR open to update the EIP. And essentially, what it's doing is, aligning, and I can show you the… current draft, so I still need to update the rationale and, the rationale section and the motivation section, but the specs are mostly done. So the main changes here were, aligning how

The parameters are defined with both AD37 and 8038. And then also updating the values with the current values we have for rights and accesses. So, essentially, what I did here was, based on the current gas prices, like, we don't have Like, a specific gas cost for, for instance, an account, right? But we can derive it from what a call costs. if you have a call with value. And so I had done already these, derivations within 8038, and so what I did in this EIP was just move those into the this EIP, and then updated the values. I also simplified the bit the way that the intrinsic costs are now computed, so a key thing was, based on current benchmarks from state access, the cost of loading a contract versus an EOA,

It's not that difference? That different, I mean. And so the, like, having the separation between the different costs, if the account has cold versus doesn't have cold, would, was actually a bit tricky, because you needed to load the account before charging it. And so there was, like, some complication where you would charge the worst case, and then, After you load it, you kind of, like, Update the volume. or I'm… maybe I'm… it could be, like, you charge the minimum, and then you kind of add on top if the account has called something like this. But essentially, there was, like, some complication, because you needed to load the account before knowing how much you would charge. And so I think we should only have that if there's actually, like, a clear

gain, or, like, it's very different in terms of performance, and so far, it doesn't feel like it is. If After optimizations for state access stabilize a bit, if we figure out that actually there is a big change, then we can maybe change it again. But at this point, the implementation is a bit simpler. One of the bigger consequences here is that if you just translate the current formulas to the values I had, so I think one thing is, like, the previous EIP was attributing a cost of account rights that was too low, based on what the… how it currently costs for calls and things like this. So when we… when you actually use the… the… the current costs, the…

the total that you get for, like, for instance, a need transfer to an existing EOA is actually already $23K. And so, I think… Yeah. I don't think this would be doable, so we need to kind of figure out How we changed this, so… I think one point is, so… First thing is, like, the way that this transaction-based cost is derived is based on this… He's… Like, we are essentially breaking down how what the basic cost of a transaction is doing, and so we have, like, an easy recover type cost, and then we have an account access and an account right for the sender. And I think, first thing is, like, these now cost 3K, But I would expect this to actually be much lower. And one reason is, like, based on the compute benchmarks we are doing, easy recovery would actually be much, much cheaper. And we are not changing this value for this fork, but

We could have a different transaction-based cost here, if we just assume, like, we'll benchmark these, and this would be Like, a value that is derived from benchmarks instead of just getting it from op codes and current costs we already have. So this could be one source of things that get cheaper Another thing is, on the account rights, the current performance for clients is very, very bad, but I would expect, actually, this to be the one that gets the biggest boost from the state root calculation. So this is one of the areas of EIP-8038 that I would expect the biggest improvement, so it could also be that we can do some… More reduction here. But yeah, I think, like, now I'm, I'm pushing for,

Luis and Johann, they are, working on these also so we can have, like, tests, that run on top of state. That we can use to then benchmark, these, ETH transfer costs, and so we can get, a better view on, how should we price these things. But yeah, so this is, like, the current status of this. Yeah, Ben, you have your end. Do you have anything to add here?

Ben Adams: The, the name of the IAP is… essentially wrong. Since it's reduced. But I do think it's a problem. If we go higher than, 21K death. Because people were complaining it would be a problem if we went lower, but going higher is even more problematic.

Maria Silva: For sure, for sure. And I… that's why I'm pushing for… for the benchmarks, like, I'm still optimistic that actually this should be lower. If it's not, this could actually be a reason for us to target the lower anchor, and not doing the 100 million gas per second. Yeah, because I don't think it's feasible that these things get… like, they transfer to existing OAs get an increase, And if this is the actual cost, then I think we have a problem.

Ben Adams: And also on… There was a no-code code. Differentiator, and you're saying that they're the same? But… That seems strange… I understand empirically it might be the same, but it does seem strange, because one… Cluster load code. start up the EVM, run a little bit of EVM, And… Finish versus one that's just increasing the balance. So, maybe ELs are missing an optimization there. Are they, like, always trying to run some code? Even if it's empty.

Maria Silva: So… to make it clear, what I'm… what I'm specifically saying is, like, when we measure the access costs for, and we do this, like, in EIP-8038, we are doing this with things like balance, calls. Xcode size, Xcode hash, like, these sort of opcodes. When we measure on that level, then If you are targeting an account with codes versus an EOA, it's not that they are the same, they are not the same, like, contracts still are a bit more expensive, but they are not, like, super more expensive. Like, I… the numbers I'm seeing right now, I don't think they… justify the added complexity to the EIP. But this could change, like, as I've… as I think you are all aware, like, the optimizations are not…

yet close to be ready for state taxes, and especially for the state route calculation, I feel. And so… things could… could change down the line, but I think from what I'm seeing right now, I don't think there's a benefit. Like, the benefit doesn't… justify the complexity, I feel. Does it make sense?

Ben Adams: Yeah, potentially.

Maria Silva: Yeah, but I'm hoping that we can start seeing some results on benchmarking for ETH transfers, so that then we can maybe have, like, a more grounded discussion here. Go, Johan.

Jochem Brouwer: Yeah, about the… the benchmark part, I will address this after the call, because the specific case, or the specific suspected worst case that we want to investigate here is that the senders are all distinct, and that the receivers are also all distinct. Right. And we also want that the senders and the receivers are cold, in the sense that we have to load… we have to force-load them from the disk.

Maria Silva: It's correct.

Ben Adams: Can the EOA contract also use all distinct code hashes?

Jochem Brouwer: Yes, this is already part of what we will do is we will do this on top of YochumNet. We have deployed 135,000 contracts there, which are all unique. The only problem with that approach is that this is a jump test analysis contract. So the execution time of these contracts might, that involves the jump test analysis. This might… Make… the contracts coded targets run slightly longer than we expect, but I think this is a very good, case to test, because if it turns out that the pricing is then, well, good enough, I would say, which would target below $21,000, I think. Then this is fine, because this would then be the worst case, also with the added runtime for the jump test analysis, if that makes sense.

Maria Silva: Perfect, yeah, so I guess I'll… continue to give updates on these as they arise, but I think for now, I will… in terms of EIP, my goal is, to kind of, like, wrap up the… actually, I'm uncertain about whether I should already update the motivation and things, because I don't think… I mean, I don't want to change everything to say that there'll be a cost increase and then not having the cost… so having a cost decrease, at the end, and then we need to change it back, so… yeah, I'm kind of, like, tempted to keep the rationale and the motivation as it is, but yeah, I'll have a think about it. Maybe I'll just keep the PR open for now.

But yeah, so this is on 2780, is there any question or comment on 2780, or should we move to the next point?

Stefan Starflinger: I have one concern. It's that, the EOA transfers, they don't, charge, state gas without $27.80. So, that's kind of something we have to keep in mind, because right now 2780 It feels like it has a pretty big rewrite, and it's changing it, because the main… Reason for it was to reduce the intrinsic gas, which is not happening. And so, I don't know, it might be worth considering. adding to 8037, that EOA transfers Should, charge state gas, and not just having it in 2780.

Maria Silva: Hmm. So you, you are saying that in a world where we… so… Let me just open it again. So what you are saying is, like. Ugh, I shouldn't do this, wait. So, in a world where we actually get to, like, an EOA costing exactly 21, So I, I don't think the… let me just view file. So I don't think it's realistic for us to say that this would be… like, above 21K, because I don't think that's… that's… that's doable, so if either this is not the actual performance, and these can be reduced. Or, if this is the actual performance, then we'll have to reduce the targets so that we keep at the 21K. And so, in the world where this is 21K,

I think they're still… I would guess there's still the benefit of having e-transfers have a more, like, specific cost to them, that is not just the cost from state creation, but I agree that then maybe they're the kind of, like. benefit of this would be slightly reduced, so what you are saying is, like, in that case, you think we should drop this EIP and just move… like, we're still additionally charge state creation, but that would be now part of 8037. Is correct?

Stefan Starflinger: Yeah, I'm just wanting to reduce the dependency a little bit, so that, I mean, AD37 by itself has a big, kind of, worst case, where people just have the possibility to send EOA transactions, and not having to, use the state gas. And, 2780 fixes that, but, it's difficult to… to, like… really know if 2780 will make it into Glamsterdam or Hegota, because it's… it's taking the time, and I don't want to decide if or what, but I just want to make sure that We don't get into a situation where we have to ship 2780, because it's the only thing that fixes 8037.

Maria Silva: How does anyone… know about that. Okay, no strong opinions there. So I, I, I don't know, I still think that… if we reach that point, we should do that change then. I don't think we should pre… preemptively do it now. Like, if we figure out that it doesn't make sense to change anything on ETH transfers besides the adding state creation, then I'm happy to then update 8037, rather than doing right now, I mean, I'm… I… I still think this EIP is valuable, and I will push it to Florida.

Stefan Starflinger: Yeah, that's not what I'm saying. Like, I don't want, like, also, if we can get a better version of 2780 at a later time, I think that would be more valuable than having it rushed just to plug the hole that is in 8037, that's all I'm saying. I think it's valuable, just, I don't want us to have to rush it, either.

Maria Silva: Yeah. I mean, I don't… I don't feel we are rushing it. I mean, I think we have everything in place to get the… the benchmarking ready. To me, it's more like the state optimizations are the things that are mostly blocking repricings now, more than, like, the additional like, the addition of this test for us to see the values. I think it's mostly, like, 8038 and 2780 will have, like. placeholder… values until optimizations are stable, and that's a reality we need to… we need to live with, but I don't think this is also a possibility to… it's also a possibility to not do him, because if we don't, then we cannot raise the gas limit, so…

Yeah, I, I, yeah, I don't… I don't see this being a big, like, blocker on the fork at this point. Does these make sense? Yeah? Cool. But yeah, so I think I'll just keep this PR open for now, and then, we can… iterating on it. Anything else for 2780, or should we move to the next point? Okay, perfect. Then on 8038, so I just wanted to give a quick update here as well. So I have, this PR that was, already merged. I can show you the… the general idea here was, again, in line with the updates I was showing to 2780, was just making sure all the final parameters for this EIP are aligned with both 2780 and 8037.

And the key takeaway here is that, again, we still don't have the final numbers, but there will be some rewrites on some, on some gas parameters, so it's not just, like, a repricing thing. And again, this is also because EIP-8037 and 2780 kind of also require it. But it's just making everything aligned, and I think my realization here was that we'll only get… I mean, I don't think we'll get numbers, like, in the next week or something, but it's still… I feel like it's… it still may… Valuable to sort of include already these changes. Indefinite, and then… Once we have the numbers, we just update the numbers, but the work of refactoring these parameters is already done.

And so the EIP is already updated. It doesn't have the values, of course, but for a DevNet, we could just use the current values and do just the… the mmm… The refactoring of the names and stuff. And then that would also align with 8037 and 2780. And… and yeah, this is the key thing. Another change to the EIP is, like, I've added these tables with, like, the different S-store cases, and what should be charged, and also for accounts, more of a description of what should happen there, and for authorizations as well. So I hope that then testing and specs will be easier to work out. And also, for the rationale, I'm just adding here more information about the benchmarks and how things are calculated, but that's… that's mostly it.

And in terms of benchmarking, I don't think there's, any major updates since the Since the latest, numbers we got after Interop, so my understanding is, like, clients are still working on their optimizations, and we'll have to wait and see how they… they… they perform. Right? And I think that also leads a bit into the DevNet inclusion discussion, so… My understanding, I'm not sure if I'm right, Spencer, but was it on ACDT we decided to continue the discussion on ACDC, or is it for the next ACDT?

Spencer Taylor-Brown: So my understanding from ACDT on Monday was that we were gonna chat about what to include async for discussion on ACDC. Mmm. Because I think Parry's running… running that call. And Barry also ran ACDT.

Maria Silva: Okay, okay, got it. So unfortunately, I won't be able to join ACDC tomorrow, but I… I think I've already put this in the thread. Like, I do feel that there's a benefit in including 8038 and 2780 with the current numbers, so that we can work on the… variable refactoring, and then once the numbers are done, we just have, like, constant updates, which should be much, much simpler. Yeah, curious to also hear your thoughts there. Gold dragon?

Dragan Rakita: Maybe we could even, like… Use the best case numbers, just to see that it is changed, and just to verify the clients agree with the change, and then update numbers later when we get better ones. I'm not exactly sure if this is just going to change some constants, or introduce some new mechanism, I still need to look in detail at 838. So, I think changing… to any numbers that is different than the current numbers, and testing that in the spec, then other clients, just pass the tests, would be valuable. I'm not sure if this is a good idea or not, but it's something that I'm thinking right now.

Maria Silva: Right. I say in terms of what actually changes, so I think a big thing is, like, the formula for a store, I think, is slightly different, because you have, like, previously we had this, like. Storage set that included both… a rights and the state creation, and then, like, there was, like, this thing where you would charge, like. In some cases, you would charge both, like, a cold axe, like, a right, and then a warm. At the same time, you write, like, you would also access… like, you also charge a cold access, so there was, like, some… some, like, options here in this table where you charge, like, an additional warm access in some cases. And so I think

the way I put it here, I think now is a bit more separated, like, you always charge… cold either, you either charge cold or warm, and then on top, if you are writing a new value, you charge storage write, and then you also charge the… state creation costs, which, now essentially just covers the state growth components. And previously, we had, like, some interactions between, like, a set would also be, like. We'll also include the access cost and the write cost, so I think these things were not separate, they were merged into the… into a single Per… it was single, gas. parameter, and now these things are sort of separated. So I think this is, like, the main difference. I…

We had, like, this storage right, which had both access and write, and now we just have these things separated. But yeah, but I tried to make it as clear as possible with this table, and cover all scenarios, but yeah, happy to also hear your thoughts. On the account side, the main difference is on Create, because now Create has this separation between what is the state gas cost, and then the execution cost, which I'm… I'm encoding into this create access, gas costs. And… yeah, the rest is mostly okay. I think for the… yeah, for the Xcode size, these also are charged an additional warm access, that was, not done before. And for authorizations, I don't think much changes, so I think it's mostly… Okay.

Dragan Rakita: I think a big question is how this aligns with previous mechanisms that we had.

Maria Silva: So, I think the biggest difference will be a store, I feel. But my underst… like, from… my personal opinion, I think it will be slightly easier to reason about, because now.

Dragan Rakita: Yeah, it is.

Maria Silva: access costs and the write costs are separated things. You don't have, like, these weird, GASP parameters that have these, two bundled together, so I think it would be a bit easier to… to sync. But yeah, but this to say that there will be some refactoring, so it's not just a constant change. constant value change. Okay, any more comments here?

Dragan Rakita: When are they planned? A glimpse to them, definite, next to authorities.

Maria Silva: I'm not sure, to be honest. I don't know, do you know, Stefan?

Stefan Starflinger: When water is planned? Sorry.

Maria Silva: To launch the next, Glamsterdam DevNet, so, DevNet.

Stefan Starflinger: So in the spec, it, definite… oh, the glass will be indefinite. I don't know exactly when Definite 4 will launch at the moment.

Dragan Rakita: Should we do it in bold DevNet or Glamsterdam devnet?

Stefan Starflinger: So the, two new EIPs, I think they would go into the Glamsterdam devnets that are not yet, because the idea is to have BAL devnet 7 as the last one. And the other EIPs, from what I've been seeing, but correct me if I'm wrong, are not as much, or not too much work. That, it should not be possible, or necessarily needs its own, El-specific Defnut.

Dragan Rakita: It's fine, it's a lot smaller scope than 8037, 8038 and… 278d is a lot smaller. That's fine.

Maria Silva: Marci, do you want to add anything?

Mercy Boma Naps-Nkari: Yeah, sorry, I joined late, so I don't know if the discussion, it has been pointed out, but I just wanted to get clarification on, the PR for the block, gets blocked receipt. So, the .io files, I wanted to know if, we are considering merging this. Because of the .io files.

Stefan Starflinger: I think at the moment, was it, with the receipts? The PR from me, the 800?

Maria Silva: Yeah, I think that's what Marcie's asking about, yes.

Stefan Starflinger: Yeah, I think we don't have an agreement yet on that PR, so it's still pending. on what exactly we will do. It seems there's also agreement to add it to the tracer.

Mercy Boma Naps-Nkari: Okay, because what I wanted to point out was, because I was trying to look over the PR and then add it to our next call for JSNROPC, and I noticed that, the .io files are sort of, manually generated, and I was trying to… I'm not sure if any client has it implemented yet, because for the .io files to be, generated properly, get needs to sort of, run it. I don't know if what I'm saying is making sense.

Stefan Starflinger: Yeah, yeah, it doesn't make sense, but it's not, I think we can… revisit that in a little bit, or you can add it to the… to the thread. I can share it, that information.

Mercy Boma Naps-Nkari: Okay. That's all, thank you.

Maria Silva: Okay, any more comments before we wrap up? Okay, if not, we can, wrap up the call. Thank you all for joining, and yeah, we'll see you, soon.

Jochem Brouwer: Thanks, Haul.

Spencer Taylor-Brown: Yes, thanks.

Stefan Starflinger: Thank you.

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