Glamsterdam Repricings #1

Transcript

marek: Hey, Josh.

Maria Silva: And lowest one.

marek: Hello.

Maria Silva: I will suggest maybe we wait 1 or 2 minutes to see if more people join, and then we can start. Sounds good?

Justin Florentine: Sounds good. Besu Team's reporting in live from Portugal. Hello, everybody.

Maria Silva: Oh, really? Are you in Lisbon, or any other CP?

Justin Florentine: Here in Faro, in the south of Fortune.

Maria Silva: Wow! Oh, it's not the best time of year to be in Faro, but it's lovely.

Justin Florentine: West.

Maria Silva: So, I'll just, post the agenda. So you can see… And we still have a couple of people joining, but I think I'll just start by just going through the topics we are discussing today, and then if there's any other open topics people want to bring up, you are welcome to do so. So I will start with just… Showing, the current, timeline and to-dos for, for, for the EIPs. Then do a quick update on. the compute repricing, so 7904, and then also we have a few updates on the state growth, EIP, so AT37. And, finally, this is more of an FYI. that, Tony has, pushed today, a PR for, changing the specs for the data EIP, so 7976 and 7981.

So, maybe we can… we can start, so I'll just try to share my screen. And show you the to-dos. Okay. So this is a page that I will try to keep as much updated as needed. So here you have an initial Timeline for when things need to be done, by what date, so that we can, by interop, have everything ready, on the repricing side. And then here we have some… some goals for, the different, work streams that we are currently working on for February, but essentially, I just wanted to focus here on this first part so that I can give you, like, an overview of the key milestones and why things need to be done by what date.

So the… the… the first thing is, by end of February. we need to have the preliminary numbers on, the EIP, so these means, mostly the things missing are 7904, so the compute EIP, and the state access EIP, so the AD38. So that we can start running a backward compatibility analysis and start, engaging with the community with those preliminary numbers. Also, by the end of February, it's important for us to have all the tooling. ready to then compute the final numbers. And what does this mean? So this means that we need to have the balls optimizations in place, so that we can run our benchmarks, using… taking into account the optimizations. We also need to run things on the Fusaka fork, which, for the preliminary numbers, we are still using Prague.

So this will give us more, more accurate numbers. And besides having, like, all this tooling ready, we will also have the specs for the IPs, and this is more important for AT37, so by the end of February, because 8037 is… is the one with more open questions. The idea is to have the specs, closed, by that date. So, in March, we can start, Doing the benchmarks and analysis for the final numbers. And by the end of March, we have those final numbers, and we can have the definite width. balls and all the repricings, integrated. And then in April, that gives us time to then do testing, security analysis, and so, so forth. And I would say also during March, we will be doing more community outreach and, and,

collecting potential issues from the repricing so that we can fix them during April. So this is the… the general rollout, and I think this kind of stresses, again, the need for… by the end of February, we have a good set of clients with the main optimizations for block-level access lists done, so that we can benchmark them and make sure that the numbers we have. for all the EIPs makes sense. Does this timeline make sense to you? Do you have any comments, any feedback? Okay, so if not, you are also welcome to read this, async and, just, ping me with comments.

It would be super helpful. For… so then we can move to the next point of the agenda. So on the computes, VIP. So, as you… should remember, the initial EIP was a general repricing that was making all the operations that could be cheaper, cheaper. But during the discussion of the EIP's inclusion, we had this understanding of, let's reduce the scope of this EIP to focus just on a couple of operations that are current bottlenecks, so making things more expensive, and then don't change the price of anything else. And so… the, I've started to update the EIP, To be in line with that, so I don't think… I'm checking, I don't think I linked the…

Yikes. PR in the agenda. I didn't, but I will share in the chat and then share after also. But the… The general format is that now we are repricing only 13 operations. And I can maybe show you… how DEIP looks like. Let me just see if I can share my screen again. Okay… Okay, so, the way it is looking now is we are repricing these 13 operations. So, these are the ones that are performing worse than 60 milligars per second, and that the… so, and this is the worst client, so the worst client is performing at less than 60 milligars per second, and also,

The difference between the worst and the second worst is not too large, so this means that these operations are not something that could be optimized is mostly, like, an underperforming, or an operation that is difficult to be performing better. And we already talked with the Besu team about this, and all the operations that are worse than this. Or, to put these more specifically, all the pure compute operations, because we still have the state operations, but the pure compute operations that perform worse than 60… Million gas per second and are not here are things that the team is, Signal that they could optimize by… By the time of the fork. Again, these numbers are still not final-final, and the reason for that is that, first, this was run on the Prague fork, not Fusaka.

And we still need to run this again with Prague, then also doesn't take into account block-level access lists. Optimizations, so maybe some numbers will actually be, much different after we take that into consideration. And third, there are a couple of tests here that seem to have increases that are So as an example, like, for Keccak, the message size is not… an increase, and even ADDMOD is not having an increase, and the reason for that Is that likely there's some caching or some, thing in the test that we need to double-check? And so this is… this final number doesn't match the worst-case block we are seeing, in the other tests. And so there's… there's still some… some work, to do here and to verify, but this is

more the shape of the EIP now, so you have just a couple of operations and pre-compiles. Things are becoming more expensive, and, instead of just having, like, a single, like, a reprice where everything becomes cheaper. Any comments or questions?

Justin Florentine: Yeah, sorry, I have a question. So, from what I understand, add mode, for example, stays the same, but div and SDIV are, like, 3 or 4 times, Right. More expensive? So, what's the… what's the… what's the rationale? Because now, DIV is more expensive than even mill mode.

Maria Silva: Yeah, so I think this is the point where we need to go back to the tests and make sure that the runtimes we are seeing are correct, but this Numbers are completely coming directly from the benchmarks. So, it's… it's… it's… there's no, like, rationale behind it, is we are measuring how much a block of these opcodes takes to run, then we estimate the cost of a single opcode running based on So we exclude, like, the… the fixed costs of setting up these blocks, so we try to isolate as much the other opcodes and just get to the… how much a single opcode takes… takes to run. Then we check what is the worst-case client, and then we transform that from

Runtime to gas using the conversion rate of the 60 million gas per second. So this is how these numbers arrive. And so… So the fact that, for instance, ADDMOD doesn't have an increase while DIV and SDIV do, this is the point where we need to go back to the text and make sure that things, make sense there.

Justin Florentine: Thank you.

Maria Silva: Ben?

Ben Adams: Sorry. Just to follow up on MULMOD, I'd look at the, 256-bit. Mods, because they're used as the output for… Mmm… Yeah, they're used for some of the outputs, and they're quite common, and they're also significantly worse than With small muds. Also, I'd want to raise, point evaluation is increasing, and that… is… The number in the, blob base fee. Floor, so… That should have a knock-on on tests, because it should… If we're to follow this through correctly, it should, increase that. That floor price.

Maria Silva: Right. And do you think that should be a desired, Knock… knockout effect, or shouldn't it be?

Ben Adams: I think it should be a desired knock-on effect, because it's meant to capture The cost of doing the point evaluations, so… Yeah. Right. If we're… if we're increasing. I mean, it's… it's, it's a… it's a low floor anyway, so it's not… Not, like, a huge increase. Boat.

Maria Silva: Right.

Ben Adams: To stick to the formula, it should… it should use the updated value.

Maria Silva: Okay, so that's… that's a good point, and maybe I will add it, to… to… to the EIP, so it doesn't, So we don't miss it when we are doing the specs. Any more comments? Okay, so I'll stop. Sharing, my screen. And then we can go to the… Next item in the agenda, so 8037, can I check, is Francisco in the call? I think so. Okay, so, Francisco, can you give a quick update on the specs for 8037? You worked on them, like, a few weeks ago, so you could… if you could just give us, like, a view on what is done, and in your view, what are the open questions?

Francesco D'Amato: Yeah, I mean… like I said, I haven't worked on it in a while, so it's not, like, a super, maybe up-to-date view, but I tried to, like, take a look again. So, I mean, what is there right now? I think it mostly matches what's in the IP, especially after we had updated that, table with the gas costs. I can link them later. I think there's, like, a few small differences in the IP in, like, maybe naming of some things, and maybe already there's some regular gas costs that are added there that are not in the EIP, but I think, like, yeah, most things are as in the EIP. I think the main questions I still had open…

We're, which, yeah, same as in DAIP, they're not really… it's not, like, things that really, like, came out of, kind of, you know, nitty-gritty of the specs, it's more like… this high-level questions of the EAP, is, like, the regular gas costs, like, for basically any time that we have an operation where we're kind of unbundling. state gas, and regular gas, there's a question of, like, exactly how to do it, and I think for most of them, it's fairly straightforward. Like, there's already a pretty clear distinction in how the gas costs were historically written. There's places where that's not the case. I think that chiefly, that's create. So for create, there's some regular gas costs, but there's not really anything that's

capturing, basically, the actual, cost of, of, making the new account, other than the, the… or rather, there, like, there is, but it's just this one number, GasCreate, that's kind of bundling both the state growth part of it, which is what we kind of want to split out into, state gas, and then everything else, so, which might be, I don't know, like, try operations and whatever else. And so this other thing, it's not right now named in any way, I think, neither in the IP nor in the specs, and it's not even clear, like, what it should be, like, numerically, like, what is this cost and, like, how does it compare to other costs that we have.

I mean, I guess it might be… Maybe somewhat comparable to… to, like a storage update or something like that, but, like, yeah, the precise way that we should come to this number, I think no one has really, like, thought to too much. So that's one question. Another question was around… Yeah, kind of similarly in this, like. How… well, once we split up… split out operations and we have the state gas component, maybe, like, in some cases, it's worth also revisiting. So, but yeah, I guess, very explicitly, like, basically, we have, in the S-Store case, the update case versus the, like, new slot case. And it's not clear that these should be priced exactly the same in regular gas. Maybe it's fine to just do that. It's, you know, maybe not the biggest difference in the world. But yeah, like, we can, you know, in… they're gonna be differentiated by the fact that one of the two has a state gas component, which

is about state growth, but even the regular gas component maybe should be different, because it's just not really the same to do a try insertion versus an update. So that's, like, yeah, another kind of small question, whether we care about this, and if so, then what is the right way to go about it? There was a question around receipts, which, I don't know, I have not followed, kind of, the parallel discussion on this, for the other EIP, so maybe, yeah, that one we should first, kind of. someone should, like, summarize what happened there, and then we can see how does it apply to, to the CIP. And… yeah, one last question, which I just noticed in the specs, was that basically, with this, like, reservoir mechanism for… for state gas.

Or, like, as part of this mechanism, and how it enables to enforce some kind of, transaction max gas limit. like, not anymore as a validity condition, but somewhat during execution. We were not, or at least I was not, I don't know how… I don't remember how Marius' prototype did, and I'm not sure if this is, like. Written in this way in the EIP. I was not enforcing this on intrinsic gas, or, like, intrinsic regular gas, which, yeah, I think should be the case. Like, I think this should basically be, like, checked for, The max of intrinsic regular gas and cold data floor gas cost. Upfront, so you should, like, just ensure that… the max of these two does not go over the cap. And then…

intrinsic regular gas should kind of be subtracted from… from, the… from this, like, 16 million number, or 16.7 million number, when you actually pass the… the… the gas that's, basically, like, the… the allowed regular gas to the… to the actual execution. this was probably too many things, but yeah, okay. If there's anything there that, made sense and people want to, like, try to zoom in into, let me know. Otherwise, I can write, like, a small recap in the chat.

Maria Silva: So I… so I think I have two questions there. So the first is on the transaction receipts. Is anyone here on the call, familiar with this? Open question, and can give more insights, or… Or not. If not, I'll try to…

Toni Wahrstätter: Yeah, I can… I can… I can provide some insights. So this was regarding EAP7778. and… There was the discussion if it should add a new field to the receipt, which would be the gas spend. Because, Because of 7778, the gas accounting for the block will deviate from the gas accounting that the user pays, so on the transaction level. And in the end, we reverted back to not adding a new view to the receipt. So everything stays the same there. And I would assume that 8037 would probably prefer. So, add a new filter receipt. From the 7778 discussion. Erigon was opposed to adding a new field to the receipt, because it added, like, a few weeks more work for them.

This is for the recall.

Ben Adams: Was that just adding a new field, or, Changing what the cumulative guess meant. I still think we should add a new field, because otherwise there's, like, this weird gap that you have to trace the block in order to… I mean, that's not even in tracing. To find why there's a difference between the transactions and the…

Toni Wahrstätter: Yeah, maybe you're right. Maybe, Not the field as the problem, but the semantics of what cumulative gas means in the receipt. Yeah, if someone from Erigon is here, they can clarify. Otherwise, we can find out. But you would say, Ben, like, adding receipt, adding fields to a receipt is not a big thing?

Ben Adams: No, it's a bit annoying, but no.

Francesco D'Amato: Yeah, I just wanted to add that, like, from the AD37 perspective, it's really, like, it's kind of a similar problem, that, like, now cumulative gas, it's unclear what it should mean. If it means something that's useful to users, like, something where you can do the diff and get the transaction gas used, like, the actual consumption of the transaction. Then it's gonna diverge from the block, cumulative guess? So, yeah, I mean, which, maybe it's fine, like, if the whole thing is just about users being able to do this diff, then, okay, we could just… interpreted that way. If not, then it should somehow… there should be something that's also tracking block consumption, then I think there have to be two numbers, basically.

Toni Wahrstätter: Yeah, I'm wondering if this even needs the receipt at all. So why would we even put something into the receipt? We can completely shield it from the user, because the user doesn't… need to know that value, right? Or do you… do you think users will be interested in how much, Gas they spent on a specific resource.

Ben Adams: I mean, it's… it's good that… for… Not necessarily for users, but for doing analysis to work out where… Where the resources have gone. Because otherwise, there's no way of… evaluating… What it is, and for people doing, like, accounting on… Using the data. Do you have to run a validator, or can you just use the data coming from the receipts and… blog. To, you know, work out. How much… how much state's increased, and all sorts of other things. Refunds are being given out where they are.

Maria Silva: Okay, so, so my understanding on this point is that, it's a trade-off between Making receipts a bit more user-friendly for the people doing… trying to analyze the exact cost conception versus the additional work of changing receipts. Is this a fair assessment? Tony, you were saying that you think this doesn't even need to touch these seeds?

Ben Adams: Oh.

Toni Wahrstätter: Yeah, this is just my initial feeling, that we might just not even need to touch the receipts, and it's all fine.

Ben Adams: I mean, one of… one of the reasons for ETH transfers amid a log is because The receipts are missing some data, so in order to… to get that data, you have to… Tracer block. And… If we don't put The additional data in the receipts were back in that place where we have new.

Toni Wahrstätter: Right. Right, but we don't tell users how much gas they spent on state creation today. So, from a user perspective, I wouldn't actually care if there is a new value in the receipt that tells me how much gas I spent on state creation, for example. I only care about the gas used. That I eventually paid.

Ben Adams: But we're not… we're not pricing it differently. Whereas now, we will be. You know, we're not differentiating state creation at the moment. Whereas after this, we are. So it might be, like, I only did a tiny bit of compute, why am I being charged so much?

Toni Wahrstätter: I'm not sure, I'm not sure, because you don't get a rational for how much you're charged today. So, in the end, what the user cares is how much is the user's account charged. No matter how we got there. This simplifies it a lot, because… We get away without those changes.

Maria Silva: Checking… it seems to me like the… the behavior that Ben wouldn't like to see is us just giving the regular gas spent. So, but if we had a sum of the regular gas plus the state gas, that would be Evalent what we have right now, right?

Ben Adams: Yeah, I mean, if the data can be… It doesn't need to be explicitly there, but if it can be derived, that's…

Maria Silva: Okay, so on, Francesco's points, I guess, like, the last point was the one that I didn't fully understand. So, the reservoir, points, and I saw that, Francesco, you wrote something here.

Francesco D'Amato: Yeah, I'm in the…

Maria Silva: Is transaction max limit enforcement.

Francesco D'Amato: Yeah, it's… yeah, it's about that. Basically, I just… at least, I mean, in my version of the spec, the… this wasn't bound in the intrinsic gas consumption, it was just bound in the execution gas. Like, we were just doing this, basically give up to transaction max gets limit. execution as, like, gas during execution, outside of the reservoir, so there would be, like. this, like, up to $16.7 million for execution, and then potentially a reservoir to draw from for state gas. But that's the only place where this kind of enforcement was happening, and so, for example, you could use much more call data than that, or just, I don't know, in principle, use during… for intrinsic reg… intrinsic gas stuff could go over the limit.

And yeah, I guess just the… the question is just agreeing that we don't want that, that we actually want to enforce it also for intrinsic gas. I mean, this seems clear to me, but yeah, I guess we didn't, like, explicitly discuss this.

Maria Silva: Okay, sounds good. So it seems like it's not as much as an open question, but it's something we should add to the EIP and the specs.

Francesco D'Amato: Yeah, I mean, I guess maybe, like, in terms of question is whether we… what do we want to do with the call data floor cost there? I was thinking this would also be enforced to be less than transaction max cost limit, like, as if the call data was actually priced at the higher, cost, like, for the purpose of this limit, but yeah, I guess that's… I don't know, just an opinion, it's maybe not obvious that that should be the case. And I mean, I guess in general, there's the question of, like, what is the purpose of enforcing this limit for, for, Call data and, like, these other things that are not really execution, but… I guess enforcing it is, like, the most consistent thing with the current spec, and I mean, maybe there's an argument that, okay, eventually, in any way is helpful to ensure that transactions cannot be too big in terms of call data.

Maria Silva: I think… I think that would make… would make sense to me. Okay, any more comments on this point, or should we move to the next one? Okay, so, moving to the next… I'm not sure, is Anders in the call?

Justin Florentine: Oh, no, go?

Maria Silva: Yes? Sorry.

Justin Florentine: Before we jump onto another one. I'll ask a question there. What about the refunds? And Mizanne posted the IP I was talking about. Should there? I wonder if that should be integrated with the state growth CIP, to split up the regular gas from the state gas. Should we subtract the refunds from the state gas? Instead, like, kind of integrating both the IPs in a way.

Maria Silva: Right, so that's… that's a good point. So, my intuition is that it would make sense to integrate them, but I think we need to… To think a bit more on this. I think, Francesco, you were going to say something, then you muted again.

Francesco D'Amato: Yeah, I didn't fully understand what you mean by discounted from state gas.

Ben Adams: As in… I… If you, if you write, if you write something… you're using state gas, but… sorry, if you create a new field, you're creating state gas, but if you delete something, you get a refund. Would that come? You know, if your net change is zero, in terms of added state issue.

Francesco D'Amato: Right, so I… the way I'm doing it right now in the spec for simplicity is to really just keep the current refund mechanism, so with the refund counter and all that, and it's applied, to the transaction gas used, at the end, which is… and transaction… consumption is, like, the sum of regular gas and state gas. So basically, like, you track state gas and regular gas during execution separately, but then for the purpose of figuring out how much the transaction actually pay, you just take the sum, and then take the refunds from there, like, with the same mechanism that we have today, with the, you know, 20% rule and all that. So it's, it's really actually completely unmodified.

from how it is today. Then, of course, we could be more… trying to do more, and, for example, really say that if you netted zero state, then you should fully get back the state gas that you received. It is a bit more involved, like, it would just require a bit more tracking to… during execution to make sure that you only do this, when, like, a call doesn't revert to… in which, like, state has been cleared or things like that, but it can be done. But again, I just chose not to do it because it felt like, in a way, almost like… out of the scope of the IP, like, trying to do something else, that… and, yeah, the one place that I am doing this in, because there… it worked out really easily, is the,

7702 refund when the account already exists. This is, like, before the transaction, and there it was, yeah, just very easy to just completely remove this state gas consumption. But yeah, I don't know, I mean, we could do this, just, it didn't seem necessary when, like, it seems like the current refund mechanism can work basically out of the box with this, essentially. If we're not trying to do, like, basically make it better for users.

Maria Silva: Okay, so maybe it's something we can think a bit more about and see if the added work, has benefits, or if we should just… I would say maybe as a starting point, we can just leave it at is, and then… Put it as an open question for… for later. Does that sound good, Louise? I think the Besu team is muted. Not sure if you are answering, but…

Justin Florentine: Yeah, yeah, I was starting to speak there. Yeah, well, at least I just threw the idea out there. To me, it looks like, from a conceptual point of view, a clean… it would be clean to… because these refunds, to me, look like incentives to the storage… to the storage side. It looked like… it would look like they could fit very well in the steakhouse. Remix. But yeah, it's something to think about.

Ben Adams: And remove… remove the refund from execution, so… And just have it on state gas, is that correct?

Justin Florentine: Sorry, Ben, you said repeated.

Ben Adams: Remove the… Remove the refund from the execution side entirely, and just have a…

Justin Florentine: That's a refund.

Ben Adams: and on… Right, thanks.

Justin Florentine: Exactly, exactly.

Maria Silva: Okay, any more comments on these, or should we move to the next agenda point? Perfect. So do we have endors in the call? He had a comment on an analysis he did. I'm not seeing him. No. And maybe I can just, link to it and give a quick overview. But essentially, so Anders was analyzing This question of, how the new… Way that we meter gas impact space fee, and then Resource consumption overall. And so he did this nice visual of these two failure modes. So once we have the max function.

to define, how full a block is. Essentially, you start to have this bottleneck resource. So. If a block is using more regular gas than state gas, then the regular gas is the bottleneck, and this is the resource that will then influence how much the base fee increases in the next block. And so. Depending on the relative demand between these two resources, essentially you can have these two situations, where in one case, the regular gas is the bottleneck resource, and so, In this case, the state creation is a bit lower than if it was being used up to the target. I say this failure mode is okay, because, I mean, we are still processing at max throughput in terms of other resources, and we are not growing state too much, so I think this failure mode is okay. I think the one that is a bit more worried, or worrisome, is the failure mode 2, where

Actually, the state gas is the bottleneck resource. And in this case, we end up… Having less, or using less. gas for regular gas than what we could, and so it means that our burst, or the compute resources and the state taxes resources are a bit underutilized. And so, and this has an impact on which, how much we price state growth. In relation to compute, and also what aggregation function do you use? Like, is the max the right function, or should we use another function? And I don't want to go into much detail here, but I'll also link to an analysis I posted, Today, that, actually, link to both analyses, if you want to check.

But essentially, here, in this analysis, I'm taking into consideration the possibility of different demands. For… or different demand values for regular gas and state gas, and how the different possible combinations of these two values would impact throughput and state growth under the different aggregation functions. And so at the end of the day, I think, we can have, I think this is something we need to continue to discuss and analyze, so I'll put here the analysis, and if you have, like, any comments or questions, I'll be happy to discuss it more in depth. Yeah, so I… I think this is what I wanted to present for these two

points, and just to clarify that, I think the… the view we take on these will have an impact on the final design for AT37, and how much we… so what is the increase, in… in state gas versus the regular gas that we defined there? Are there any comments on this point? Okay, If not, maybe we can just move to the final point. So, it's just an FYI that, Tony has, opened a PR for the data.

EIP, so 7976 and 79881. If you have any comments on those, and if you have time to check it and review it, it would be much appreciated. And… yep. I don't think I have more points on the agenda. Are there any open… yes, Ben?

Ben Adams: I'd just like to add an FYI on the 7… sorry, T780, which is the, transfer prices? Yes. So, in the ETH… Eth transfers a middle log. There is no prices for the log, it's essentially free, and That's because… ETH transfers are so massively overpriced. And in… 2780, we're bringing it all down and doing it by component parts. But… because of that, there's… there is no longer any slack for, you know, just putting the log in, so I'm gonna add charging for the ETH transfer logs. It's not a huge amount, but in… in principle, how it's derived, the… the prices, or the transactions and so forth. It's… it's based on…

the costs of the parts, so there isn't any slack to say, oh yeah, we'll just say these are free. I mean, it'll still be significantly cheaper than now. But that will be an… unless there's any objections, that will be a… Another component that's included.

Maria Silva: to me. Tony, do you want to add anything? Or do you have a different point? Race.

Toni Wahrstätter: a different point, so if someone wants to add something to Ben's point, I would just wait.

Maria Silva: Okay.

Jochem Brouwer: Oh, yeah.

Maria Silva: He'll come to you.

Jochem Brouwer: Yeah, yeah, I have one question. So, Ben, you were saying, because it's correct, like, the logs are currently free, I think, by the current spec. But if you do an EV transfer for, via call, they have to pay 9K, so if you have a non-zero, transfer, you have to pay 9K or maybe 5K, but at least this is priced in. But are you saying that you want to split up this 9K into, like, a specific component for the log and for the transfer, or…

Ben Adams: Well… 2780 also brings down the cost for calls, so the the transaction and calls are greatly reduced for an ETH transfer. So I'd put the… I'd add the log back onto both of them. If ETH is being transferred.

Jochem Brouwer: Alright, sorry, I confused these ERPs. I'm seeing you were talking about 278. Yeah, sorry, sorry, yeah.

Ben Adams: Yeah, so the 9K transfer cost per call comes down significantly also. But because… because it comes down for only what it's doing, we also have to add… we'll have to add the ETH transfer… sorry, the log cost onto that, because it's, you know, additional work that… Not in its pricing currently.

Jochem Brouwer: Yeah, yeah, I think that makes a lot of sense, because then it… yeah, you will basically split up the cost of this for the transfer cost and also, like, the login cost. Yeah, that makes a lot of sense.

Maria Silva: Okay, any more comments or questions on Ben's point? Perfect. If not, Tony, do you want to raise your point?

Toni Wahrstätter: Yeah, just as a heads up regarding EAP7976, this is the cold data cost increase. So right now, it's a very simple constant increase from… 10 per call data token to 15. But there's also this discussion Happening, if we should… harmonize the call data cost at the floor, which means we would change the ERP slightly, such that users Pay the same call data cost as today, at least, not hitting the floor, so 4 and 16. And then, if the call data cost outweighs execution, like in the 7623 model, Then, we charge $64.64. So the same cost per byte, because… At this point, basically blocks are getting so large that it doesn't matter anymore if it's a zero byte or a non-zero byte. Compression will not profit a lot from having a zero byte.

So, it makes sense to price them the same. And the nice effect this would have is that we would only hit this 10MB limit that we are always, talking about. I think it's in the engine API, but I don't even recall, that we only hit that limit when we are at 650 million gas. And otherwise, we would hit it at 150 million. So right now, for Devnet 2, there are already discussions, like, if we can even go to $150 million for testing, because some tests are not working anymore because of hitting limits. So it makes sense if we at least consider instead of going to, 15 and 60 call data cost going directly to 64.64, I already checked, and it looks like,

It's marginally more users that are affected, and more comprehensive analysis to be done, of course. But so far, it looks like the impact would be marginal, while we actually, yeah, get rid of this, max block size topic for a while.

Ben Adams: Would that cause a massive left edge, though? Because the difference… You know, if you grow up, of course, sorry. Cliff edge. So if you go over by, you know, one byte, and now it's cold data, suddenly your cold data

Toni Wahrstätter: No, no, the mechanism stays the same, as it is with 7623. So you would still have this floor cost, you would just have on one side the floor, the price being calculated by call data with the 416 pricing, plus execution gas, and on the other side of the max formula, you would have the call data, floor pricing. with the 6464.

Ben Adams: Okay.

Toni Wahrstätter: So it would not cause, like, a big jump, it would still be… Like, a steady increase.

Maria Silva: Thanks for… thanks for raising that, and I think, yeah, that… that seems to make sense, Tony.

Toni Wahrstätter: Yeah. I think I will say… I will create a PR for the 6464, and then in, like, 2 weeks, I will put it on the agenda again, and maybe we can already finalize it, because then it will be early enough, definitely.

Maria Silva: Sounds good. Anything else people want to discuss? Ashuri, wrap up. Yeah, sounds good.

Ansgar Dietrichs: Yeah, maybe just a very quick, question. I think we have… Remember, I see, you know, someone from OP Labs on the call, and also from L2Beat. I'm just wondering, if, from either side, basically, if there's any comments on… kind of, obviously, a lot of the L1 repricings might also end up, wanting to be taken over by the L2s, and so is there anything in terms of process as we go through, through these, through these changes on the L1 that we could do to help make this accessible for L2s? Is this already in a good place? I don't know, just anything in case, just in case either of you two, or anyone else here that maybe is also from the L2 side on the call would have any comment. Just curious.

Josh?

Josh | OP Labs: Yeah, I think things are. Yeah, I think at this time, there's not much action to be taken on our end. Obviously, there's a lot of the benchmarking work that's being done is I guess still applicable to… to us at OP, which is great. I think for us, the only things that we look at, primarily for, like, where divergence may happen, or where our additional risks may arise, is when looking at DA costs and, proof-system implications. Since those are really the… two major differences between what happens at L1 and what happens on OP stack chains. I think one area for collaboration, is to discuss, maybe among the teams that are working on benchmarking at L1, and some of the benchmarking work that we're doing on the OP stack. I would love to

maybe form some tighter collaboration there, since I think there's a lot of… I sense that there's a lot of repeat work that's being done, so… I don't know, maybe we, just align on the best place to share these findings, tooling, and just… Generally, deduplicate a lot of the work that's happening. That would be maybe the only ask at this point, but yeah, looking forward to attending these calls in the future, and I think, it's exciting progress all around.

Ansgar Dietrichs: Sounds good. That's a useful perspective, thank you. And, I'm not sure if anyone here on the call has anything right now to say in terms of, like, best place to share, kind of, collaborate on benchmarking? side questions. Otherwise, I think… I know that, this question has come up in the past, so I think we are kind of actively thinking about how to strengthen collaboration with our two stand, so… otherwise, I can also just, for now, note down that OP Labs is also very interested, and so once we have some thoughts, we'll reach out to y'all.

Jochem Brouwer: Yeah, maybe just to chime in, we are adding a benchmark test to the EAST testing suite. I'm not sure if OP Labs is aware of this. But this sounds something that can be directly integrated also in the benchmarks for the OP stack.

Josh | OP Labs: Excellent, thank you. Is this related to the, benchmarker tool that, I just happened to see was recently being developed?

Jochem Brouwer: Yes, yeah, exactly. Because it's, like, it's generic EVM opcodes benchmarks, and also an effort to run this on top of state, so also benchmarking the state-related opcodes, so on top of big state.

Josh | OP Labs: Okay, fantastic. And the EEST benchmark suite, I'm not familiar with the details, can that be run by external tooling as well? Like, does… I imagine just… does… do those tests, like, just craft transactions and then can be run by, like, an external orchestration tool? For example, we've been developing some things ourselves that we may want to use for this. Or does it require the use of the benchmarker tool?

Jochem Brouwer: So, the output of these tests, they can be converted to fixtures, so, like, the normal testing format. The only thing is that we are currently working on, If the fixtures are built on top of state, this is a little bit more difficult. But I think what we should maybe do is, on ETH R&D, if we could use the EL testing channel, for this. To align, like, the benchmarking efforts. To get there.

Josh | OP Labs: Okay, yeah, sounds good. Let's take this discussion there. Appreciate it.

Jochem Brouwer: Okay, I will open a thread there. Yeah, thanks.

Maria Silva: Perfect. Is there any other points, or… Questions? Okay, so, if not, thank you all for attending, and, yeah, this will… we'll have, the next call in two weeks. Bye bye.

Ansgar Dietrichs: Fantastic.

Toni Wahrstätter: Awesome, thank you. Bye-bye.

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