marek:Hey, Josh.
Transcript
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 (Besu):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 (Besu):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 (Besu):West.
Maria Silva:So, I'll just, post the agenda.
Maria Silva:So you can see…
Maria Silva: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.
Maria Silva:So I will start with just…
Maria Silva:Showing, the current, timeline and to-dos for, for, for the EIPs. Then do a quick update on.
Maria Silva:the compute repricing, so 7904, and then also we have a few updates on the state growth, EIP, so AT37.
Maria Silva:And, finally, this is more of an FYI.
Maria Silva:that, Tony has, pushed today, a PR for, changing the specs for the data EIP, so 7976 and 7981.
Maria Silva:So, maybe we can… we can start, so I'll just try to share my screen.
Maria Silva:And show you the to-dos.
Maria Silva:Okay.
Maria Silva:So this is a page that I will try to keep as much updated as needed. So here you have an initial
Maria Silva:Timeline for when things need to be done, by what date, so that we can, by interop, have everything ready, on the repricing side.
Maria Silva:And then here we have some… some goals for, the different, work streams that we are currently working on for
Maria Silva: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.
Maria Silva:So the… the… the first thing is, by end of February.
Maria Silva: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.
Maria Silva: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.
Maria Silva: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.
Maria Silva:We also need to run things on the Fusaka fork, which, for the preliminary numbers, we are still using Prague.
Maria Silva:So this will give us more, more accurate numbers.
Maria Silva: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
Maria Silva: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,
Maria Silva:Doing the benchmarks and analysis for the final numbers.
Maria Silva:And by the end of March, we have those final numbers, and we can have the definite width.
Maria Silva: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,
Maria Silva:collecting potential issues from the repricing so that we can fix them during April. So this is the…
Maria Silva: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.
Maria Silva:for all the EIPs makes sense.
Maria Silva:Does this timeline make sense to you? Do you have any comments, any feedback?
Maria Silva:Okay, so if not, you are also welcome to read this, async and, just, ping me with comments.
Maria Silva:It would be super helpful.
Maria Silva:For… so then we can move to the next point of the agenda. So on the computes,
Maria Silva:VIP.
Maria Silva:So, as you…
Maria Silva:should remember, the initial EIP was a general repricing that was making all the operations that could be cheaper, cheaper. But during the
Maria Silva: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.
Maria Silva:And so… the, I've started to update the EIP,
Maria Silva:To be in line with that, so I don't think… I'm checking, I don't think I linked the…
Maria Silva:Yikes.
Maria Silva:PR in the agenda. I didn't, but I will share in the chat and then share after also.
Maria Silva:But the… The general format is that now we are repricing only 13 operations.
Maria Silva:And I can maybe show you… how DEIP looks like.
Maria Silva:Let me just see if I can share my screen again.
Maria Silva:Okay…
Maria Silva:Okay, so, the way it is looking now is we are repricing these 13 operations.
Maria Silva: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,
Maria Silva:The difference between the worst and the second worst is not too large, so this means that these operations are not something that
Maria Silva: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.
Maria Silva: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
Maria Silva:worse than 60… Million gas per second and are not here are things that the team is,
Maria Silva:Signal that they could optimize by…
Maria Silva:By the time of the fork.
Maria Silva: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.
Maria Silva:And we still need to run this again with Prague, then also doesn't take into account block-level access lists.
Maria Silva:Optimizations, so maybe some numbers will actually be,
Maria Silva:much different after we take that into consideration. And third, there are a couple of tests here that seem to have increases that are
Maria Silva:So as an example, like, for Keccak, the message size is not…
Maria Silva:an increase, and even ADDMOD is not having an increase, and the reason for that
Maria Silva: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
Maria Silva: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.
Maria Silva:Any comments or questions?
Justin Florentine (Besu):Yeah, sorry, I have a question.
Justin Florentine (Besu):So, from what I understand, add mode, for example, stays the same, but div and SDIV are, like, 3 or 4 times,
Justin Florentine (Besu):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
Maria Silva:Numbers are completely coming directly from
Maria Silva: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
Maria Silva: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
Maria Silva:Runtime to gas using the conversion rate of the 60 million gas per second.
Maria Silva:So this is how these numbers arrive. And so…
Maria Silva: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 (Besu):Thank you.
Maria Silva:Ben?
Ben Adams:Sorry. Just to follow up on MULMOD,
Ben Adams:I'd look at the, 256-bit.
Ben Adams:Mods, because they're used as the output for… Mmm…
Ben Adams:Yeah, they're used for some of the outputs, and they're quite common, and they're also significantly worse than
Ben Adams:With small muds.
Ben Adams:Also, I'd want to raise, point evaluation is increasing, and that… is…
Ben Adams:The number in the, blob base fee.
Ben Adams:Floor, so… That should have a knock-on on tests, because it should…
Ben Adams:If we're to follow this through correctly, it should, increase that.
Ben Adams:That floor price.
Maria Silva:Right.
Maria Silva:And do you think that should be a desired,
Maria Silva: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
Ben Adams:The cost of doing the point evaluations, so… Yeah.
Ben Adams: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…
Ben Adams:Not, like, a huge increase.
Ben Adams: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,
Maria Silva:So we don't miss it when we are doing the specs.
Maria Silva:Any more comments?
Maria Silva:Okay, so I'll stop.
Maria Silva:Sharing, my screen.
Maria Silva:And then we can go to the…
Maria Silva:Next item in the agenda, so 8037, can I check, is Francisco in the call?
Maria Silva:I think so.
Maria Silva: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:Yeah, I mean…
Francesco: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
Francesco: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…
Francesco: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…
Francesco: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.
Francesco: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
Francesco: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
Francesco: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.
Francesco:I mean, I guess it might be…
Francesco:Maybe somewhat comparable to… to,
Francesco: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…
Francesco:Yeah, kind of similarly in this, like.
Francesco:How… well, once we split up… split out operations and we have the state gas component,
Francesco: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.
Francesco: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
Francesco: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?
Francesco: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.
Francesco:someone should, like, summarize what happened there, and then we can see how does it apply to, to the CIP.
Francesco:And… yeah, one last question, which I just noticed in the specs, was that basically, with this, like, reservoir mechanism for… for state gas.
Francesco:Or, like, as part of this mechanism, and how it enables to enforce some kind of, transaction max gas limit.
Francesco: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.
Francesco: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,
Francesco:The max of intrinsic regular gas and cold data floor gas cost.
Francesco:Upfront, so you should, like, just ensure that…
Francesco:the max of these two does not go over the cap. And then…
Francesco: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.
Francesco: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?
Maria Silva:Open question, and can give more insights, or… Or not.
Maria Silva:If not, I'll try to…
Toni Wahrstätter:Yeah, I can… I can… I can provide some insights. So this was regarding EAP7778.
Toni Wahrstätter:and…
Toni Wahrstätter:There was the discussion if it should add a new field to the receipt, which would be the gas spend.
Toni Wahrstätter:Because,
Toni Wahrstätter:Because of 7778, the gas accounting for the block will deviate from the gas accounting that the user pays, so on the transaction level.
Toni Wahrstätter: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
Toni Wahrstätter:8037 would probably prefer.
Toni Wahrstätter:So, add a new filter receipt.
Toni Wahrstätter:From the 7778 discussion.
Toni Wahrstätter:Erigon was opposed to adding a new field to the receipt, because it added, like, a few weeks more work for them.
Toni Wahrstätter:This is for the recall.
Ben Adams:Was that just adding a new field, or,
Ben Adams:Changing what the cumulative guess meant.
Ben Adams: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…
Ben Adams:I mean, that's not even in tracing.
Ben Adams:To find why there's a difference between the transactions and the…
Toni Wahrstätter:Yeah, maybe you're right. Maybe,
Toni Wahrstätter:Not the field as the problem, but the semantics of what cumulative gas means in the receipt.
Toni Wahrstätter:Yeah, if someone from Erigon is here, they can clarify. Otherwise, we can find out.
Toni Wahrstätter: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: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.
Francesco:Then it's gonna diverge from the block, cumulative guess?
Francesco: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…
Francesco:interpreted that way.
Francesco: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…
Toni Wahrstätter:need to know that value, right? Or do you… do you think users will be interested in how much,
Toni Wahrstätter:Gas they spent on a specific resource.
Ben Adams:I mean, it's… it's good that… for…
Ben Adams:Not necessarily for users, but for doing analysis to work out where… Where the resources have gone.
Ben Adams:Because otherwise, there's no way of… evaluating…
Ben Adams:What it is, and for people doing, like, accounting on… Using the data.
Ben Adams:Do you have to run a validator, or can you just use the data coming from the receipts and…
Ben Adams:blog.
Ben Adams:To, you know, work out.
Ben Adams:How much… how much state's increased, and all sorts of other things.
Ben Adams: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
Maria Silva: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.
Maria Silva:Is this a fair assessment?
Maria Silva: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
Ben Adams:The receipts are missing some data, so in order to… to get that data, you have to…
Ben Adams:Tracer block.
Ben Adams:And… If we don't put
Ben Adams:The additional data in the receipts were back in that place where we have new.
Toni Wahrstätter:Right.
Toni Wahrstätter: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.
Toni Wahrstätter:That I eventually paid.
Ben Adams:But we're not… we're not pricing it differently.
Ben Adams:Whereas now, we will be.
Ben Adams:You know, we're not differentiating state creation at the moment.
Ben Adams:Whereas after this, we are.
Ben Adams: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.
Toni Wahrstätter:No matter how we got there. This simplifies it a lot, because…
Toni Wahrstätter:We get away without those changes.
Maria Silva:Checking…
Maria Silva: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
Maria Silva:Evalent what we have right now, right?
Ben Adams:Yeah, I mean, if the data can be…
Ben Adams: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,
Maria Silva:points, and I saw that, Francesco, you wrote something here.
Francesco:Yeah, I'm in the…
Maria Silva:Is transaction max limit enforcement.
Francesco: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,
Francesco:basically give up to transaction max gets limit.
Francesco:execution as, like, gas during execution, outside of the reservoir, so there would be, like.
Francesco: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.
Francesco: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: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
Francesco:the call data was actually priced at the higher, cost, like, for the purpose of this limit, but yeah, I guess that's…
Francesco:I don't know, just an opinion, it's maybe not obvious that that should be the case.
Francesco:And I mean, I guess in general, there's the question of, like, what is the purpose of enforcing this limit for, for,
Francesco:Call data and, like, these other things that are not really execution, but…
Francesco: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.
Maria Silva:Okay, any more comments on this point, or should we move to the next one?
Maria Silva:Okay, so, moving to the next… I'm not sure, is Anders in the call?
Justin Florentine (Besu):Oh, no, go?
Maria Silva:Yes? Sorry.
Justin Florentine (Besu):Before we jump onto another one.
Justin Florentine (Besu):I'll ask a question there. What about the refunds? And Mizanne posted the IP I was talking about. Should there?
Justin Florentine (Besu):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?
Justin Florentine (Besu):Instead, like, kind of integrating both the IPs in a way.
Maria Silva:Right, so that's… that's a good point.
Maria Silva:So, my intuition is that it would make sense to integrate them, but I think we need to…
Maria Silva:To think a bit more on this.
Maria Silva:I think, Francesco, you were going to say something, then you muted again.
Francesco: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…
Ben Adams: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: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…
Francesco: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.
Francesco:So it's, it's really actually completely unmodified.
Francesco: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.
Francesco: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.
Francesco:But again, I just chose not to do it because it felt like, in a way, almost like…
Francesco: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,
Francesco: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.
Francesco: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
Francesco: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…
Maria Silva:Put it as an open question for… for later.
Maria Silva:Does that sound good, Louise?
Maria Silva:I think the Besu team is muted. Not sure if you are answering, but…
Justin Florentine (Besu):Yeah, yeah, I was starting to speak there.
Justin Florentine (Besu):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.
Justin Florentine (Besu):It looked like… it would look like they could fit very well in the steakhouse.
Justin Florentine (Besu):Remix.
Justin Florentine (Besu):But yeah, it's something to think about.
Ben Adams:And remove… remove the refund from execution, so…
Ben Adams:And just have it on state gas, is that correct?
Justin Florentine (Besu):Sorry, Ben, you said repeated.
Ben Adams:Remove the… Remove the refund from the execution side entirely, and just have a…
Justin Florentine (Besu):That's a refund.
Ben Adams:and on… Right, thanks.
Justin Florentine (Besu):Exactly, exactly.
Maria Silva:Okay, any more comments on these, or should we move to the next agenda point?
Maria Silva:Perfect. So do we have endors in the call? He had a comment on an analysis he did.
Maria Silva:I'm not seeing him.
Maria Silva:No. And maybe I can just, link to it and give a quick overview. But essentially, so Anders was analyzing
Maria Silva:This question of, how the new…
Maria Silva:Way that we meter gas impact space fee, and then Resource consumption overall.
Maria Silva:And so he did this nice visual of these two failure modes. So once we have the max function.
Maria Silva:to define, how full a block is. Essentially, you start to have this bottleneck resource. So.
Maria Silva: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.
Maria Silva: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,
Maria Silva: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
Maria Silva: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
Maria Silva:Actually, the state gas is the bottleneck resource.
Maria Silva:And in this case, we end up… Having less, or using less.
Maria Silva: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.
Maria Silva:And so, and this has an impact on which, how much we price state growth.
Maria Silva: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,
Maria Silva:Today, that, actually, link to both analyses, if you want to check.
Maria Silva:But essentially, here, in this analysis, I'm taking into consideration the possibility of different demands.
Maria Silva:For… or different demand values for regular gas and state gas, and how the different possible combinations of these two values would impact throughput
Maria Silva:and state growth under the different aggregation functions. And so at the end of the day, I think,
Maria Silva: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.
Maria Silva:Yeah, so I… I think this is what I wanted to present for these two
Maria Silva:points, and just to clarify that, I think the… the view we take on these will have an impact on the final
Maria Silva:design for AT37, and how much we… so what is the increase, in… in state gas versus the regular gas that we defined there?
Maria Silva:Are there any comments on this point?
Maria Silva:Okay,
Maria Silva: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.
Maria Silva: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.
Maria Silva:And… yep.
Maria Silva: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?
Ben Adams:Yes.
Ben Adams:So, in the ETH…
Ben Adams:Eth transfers a middle log. There is no prices for the log, it's essentially free, and
Ben Adams:That's because… ETH transfers are so massively overpriced.
Ben Adams:And in… 2780, we're bringing it all down and doing it by component parts. But…
Ben Adams:because of that, there's… there is no longer any slack for, you know, just putting the log in, so I'm gonna add
Ben Adams:charging for the ETH transfer logs. It's not a huge amount, but
Ben Adams:in… in principle, how it's derived, the… the prices, or the transactions and so forth. It's… it's based on…
Ben Adams: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.
Ben Adams:But that will be an… unless there's any objections, that will be a… Another component that's included.
Maria Silva:to me.
Maria Silva:Tony, do you want to add anything?
Maria Silva:Or do you have a different point?
Maria Silva: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.
jochem-brouwer:But if you do an EV transfer for, via call, they have to pay 9K, so if you have a non-zero,
jochem-brouwer:transfer, you have to pay 9K or maybe 5K, but at least this is priced in.
jochem-brouwer: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
Ben Adams:the transaction and calls are greatly reduced for an ETH transfer.
Ben Adams:So I'd put the… I'd add the log back onto both of them.
Ben Adams: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.
Ben Adams:But because…
Ben Adams: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…
Ben Adams: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?
Maria Silva: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.
Toni Wahrstätter:So right now, it's a very simple constant increase from…
Toni Wahrstätter:10 per call data token to 15. But there's also this discussion Happening, if we should…
Toni Wahrstätter:harmonize the call data cost at the floor, which means we would change the ERP slightly, such that users
Toni Wahrstätter:Pay the same call data cost as today, at least, not hitting the floor, so 4 and 16.
Toni Wahrstätter:And then, if the call data cost outweighs execution, like in the 7623 model, Then, we charge $64.64.
Toni Wahrstätter:So the same cost per byte, because…
Toni Wahrstätter: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.
Toni Wahrstätter: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.
Toni Wahrstätter: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.
Toni Wahrstätter: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
Toni Wahrstätter:instead of going to, 15 and 60 call data cost going directly to 64.64, I already checked, and it looks like,
Toni Wahrstätter:It's marginally more users that are affected, and more comprehensive analysis to be done, of course.
Toni Wahrstätter: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…
Ben Adams:You know, if you grow up, of course, sorry.
Ben Adams: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
Toni Wahrstätter: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.
Toni Wahrstätter: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.
Toni Wahrstätter: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.
Maria Silva:Anything else people want to discuss?
Maria Silva:Ashuri, wrap up.
Maria Silva:Yeah, sounds good.
Ansgar Dietrichs:Yeah, maybe just a very quick, question.
Ansgar Dietrichs:I think we have…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Josh | OP Labs:I guess still applicable to… to us at OP, which is great.
Josh | OP Labs: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.
Josh | OP Labs:Since those are really the…
Josh | OP Labs:two major differences between what happens at L1 and what happens on OP stack chains.
Josh | OP Labs: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
Josh | OP Labs: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…
Josh | OP Labs:I don't know, maybe we, just align on the best place to share these findings, tooling, and just…
Josh | OP Labs:Generally, deduplicate a lot of the work that's happening.
Josh | OP Labs: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?
Ansgar Dietrichs: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.
jochem-brouwer: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
jochem-brouwer:big state.
Josh | OP Labs:Okay, fantastic. And the EEST benchmark suite, I'm not familiar with the details, can that be run
Josh | OP Labs: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.
Josh | OP Labs: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,
jochem-brouwer:If the fixtures are built on top of state, this is a little bit more difficult.
jochem-brouwer:But I think what we should maybe do is, on ETH R&D, if we could use the EL testing channel, for this.
jochem-brouwer:To align, like, the benchmarking efforts.
jochem-brouwer: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.
Maria Silva:Is there any other points, or…
Maria Silva:Questions?
Maria Silva:Okay, so, if not, thank you all for attending, and, yeah, this will… we'll have, the next call in two weeks.
Maria Silva:Bye bye.
Ansgar Dietrichs:Fantastic.
Toni Wahrstätter:Awesome, thank you. Bye-bye.
Chat Logs
00:02:12
Maria Silva:https://github.com/ethereum/pm/issues/1910
00:02:35
Ansgar Dietrichs:I feel like it’s tradition that whenever there is a group of ppl joining acd together, camera on is a must :-)
00:03:57
Ansgar Dietrichs:great to see some L2 ppl joining today as well btw! maybe if we have time at the end, we could briefly touch on the repricings implications for non-L1 EVM chains?
00:08:30
Maria Silva:https://github.com/ethereum/EIPs/pull/11244
00:11:42
Ben Adams:POINT_EVALUATION determines Blob price floor; so should be knock on to be tested there
00:26:32
Toni Wahrstätter:My feeling is that this might not even need to touch receipts
00:27:39
Ameziane Hamlat:Mgas/s also won’t mean anything if we can’t separate state gas and regular gas
00:29:19
Francesco:Summary of questions I know about:
CREATE regular gas cost? What should it be?
SSTORE insert vs update regular gas cost? Should there be a difference?
Receipts: keep cumulative_gas_used tracking actual user consumption, or change it to gas_used, or have two fields (same question as for other EIP?)
TX_MAX_GAS_LIMIT enforcement: clarify that we want to enforce that max(intrinsic_regular_gas, calldata_floor_gas_cost) < TX_MAX_GAS_LIMIT, and leave TX_MAS_GAS_LIMIT - intrinsic_regular_gas available during execution (other than reservoir)
00:29:56
Ben Adams:Or I guess even in block; but information is lost because is determined at tx level not block level
00:30:23
Luis Pinto | Besu:What about refunds, shouldn’t that be discounted from state gas?
00:31:38
Ameziane Hamlat:Replying to "What about refunds, ..."
You mean from EIP-7778 ?
00:33:43
jochem-brouwer:Does it count against the gas limit or not? We want to incentivize people to clean up their state (refund) but we do not want them to use it to "abuse" the system by granting X% more gas limit to block
00:34:23
Luis Pinto | Besu:Not from the regular gas limit, but subtract it from state gas limit only
00:36:46
Francesco:This is the spec branch I have been working on btw, if you take a look and have comments lmk https://github.com/ethereum/execution-specs/compare/forks/osaka...fradamt:execution-specs:state-growth
00:37:14
jochem-brouwer:Antwoord verzenden naar "Does it count agai..."
Ah right, yes this makes sense
00:37:54
Maria Silva:https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975
00:40:34
Maria Silva:https://ethresear.ch/t/analysis-of-different-aggregation-functions-for-eip-8037-under-different-elasticity-regimes/24033
00:43:37
jochem-brouwer:9k transfer cost per call
00:54:25
Louis:The benchmark documentation for test generation is here: https://github.com/ethereum/execution-specs/blob/forks/amsterdam/docs/writing_tests/benchmarks.md
00:54:51
Louis:We could construct the transaction and send it
Summary
23 highlights
· 3 action itemsExperimental
Summary
23 highlights · 3 action itemsExperimentaltimeline and milestones
- End of February: Preliminary repricing numbers needed for backward compatibility analysis00:03:51
- End of February: All tooling ready including BALL optimizations and Fusaka fork support00:05:22
- End of March: Final repricing numbers and definitive BALL integration complete00:06:02
- April: Testing, security analysis, and community issue resolution phase00:06:18
compute repricing eip7904
- EIP-7904 downscoped to 13 operations performing worse than 60 Mgas/s00:08:40
- Price reductions removed; focus only on underperforming bottleneck operations00:09:14
- Numbers still preliminary: awaiting Fusaka fork runs and BALL optimizations00:10:34
- POINT_EVALUATION increase impacts blob base fee floor calculation00:11:42
state growth eip8037
- CREATE regular gas cost needs definition beyond bundled GasCreate constant00:17:41
- SSTORE update vs insert may need different regular gas costs00:19:05
- Transaction max gas limit should enforce intrinsic regular gas upfront00:21:02
- Receipt fields: cumulative_gas_used semantics unclear with state gas split00:22:02
- Refund mechanism currently unchanged; applies to sum of regular+state gas00:36:52