Glamsterdam Repricings #2

Transcript

Maria Silva: Hello, everyone. Anything from your.

Butta: Hello, hello.

Maria Silva: Alright. So, I propose he waits. Minutes to see if more people join, and… Yeah, then we'll start. Welcome, welcome to the people joining. Hi, everyone. Just to warn the newcomers, we are waiting one more minute to see if more people join, and then we'll start.

Okay, so I don't see more people coming, so I think we can… we can start. So this is the agenda for today. And we'll start, by discussing, 2780, so reduce intrinsic transaction costs, and, Guru will, give us an update on the status of, the specs and test implementation. Guru, if you want, the floor is yours.

Guruprasad Kamath: Yeah, thanks, Maria. Yeah, so on EIP2780, on the specs and test side, we've got a draft implementation, and some basic tests already written. So, where we are right now is, There are some interactions with… so basically the current implementation is likely to break some of the legacy tests, particularly those around 7702 and 7928, the BALS tests. So, we need to kind of fix those before we kind of can make any test release, but that's kind of a… A lot of tests that we need to fix, so, it would be good to kind of clarify how these interactions… there are some interaction points which I don't think are fully clear from the EIP document. So, ideally, we want to make these test fixes once, not having to go back and forth and, like, keep fixing them again and again.

So I have raised kind of a PR to the EIP's repository to attempt to clarify this, or at least, like, start a discussion on some of these interactions. And once those are clear, we can fix those tests and potentially look at making a release. But the EIP2780 specific tests are already in the draft PR, so on that front, we are pretty good to go. I can also link to the PR if necessary. This is the PR from the EIPs repo.

Maria Silva: Open. Do you have any comments?

Ben Adams: I, it also needs the addition of the log prices from EIP 7708. Because they're currently free. However, the… the assumption there is because the gas prices of an ETH transfer are so ridiculously high. the logs can be free. But since we're bringing down that cost massively. We should add the log prices on. Since, yeah, since essentially the EIP's saying, you know, pay for the… pay for the actual costs, and break it all down. And they should be included.

Maria Silva: Yeah, that's, that's a good point. Do you think you could add a PR to include them, or, Sure.

Ben Adams: I can… I can… I can follow up with.

Maria Silva: Sounds good.

Ben Adams: Do you want me to…

Maria Silva: Yeah, that would be great. Cool. Any more comments for Guru? So, I think he linked the PR, I'll urge everyone to review and see if you find any issues there. Yeah, I linked a few people already to… with some questions, for the Go Guru.

Guruprasad Kamath: Yeah, just a quick point, I think this would be for, Tony, if he's on the call, regarding BALs, I think account access kind of becomes cheaper if you're, attempting to access only EOAs here. So, if he wants to take a look, if there are any, like, implications on that for the… For the BALS… BALS size, in particular.

Toni Wahrstätter: This is interesting, yeah? How much cheaper will it get? So today, it's… 2,400, that's the cheapest you can access an account. How much cheaper will it get?

Guruprasad Kamath: So if you're attempting to access a cold UA, the charge is $500. So you're essentially… 25%.

Toni Wahrstätter: Okay.

Maria Silva: An important, an important point there is this value may also be updated after we have the numbers for the State Access EIP, so AAA38, so it's possible that it will increase a little bit. But still, it should… will likely be a reduction anyways, Due to just, benchmarking out the benchmarking results we've been seeing from ETH transfers benchmarks. But yeah, so it's something we need to think about.

Ben Adams: What's… what's the interaction there? How does it affect Bell?

Toni Wahrstätter: It might affect the worst-case bottle size. So this is one of the things, and yeah. There's also currently some discussion around how to quickly invalidate BALS, which also uses, Currently, the 2,000 gas, because that's the cheapest you can access. Storage key slash account. But this sounds like it will be reduced to 500 then.

Maria Silva: Starting. What are the… what are the next steps there, Guru? Do you want, Tony to just, have a look again and comment, on your PR?

Guruprasad Kamath: Yeah, so, I mean, that's not a blocker, per se. The next blocker would be to kind of agree on how we want to handle, yes, the 7702. gas charge and, like, the points that I've raised in the PR. Once we have clarity on how, the final, clarity on how we want to handle those, I can go back and fix the 7702 and 7928, tests that are currently being broken by these changes. And, that kind of gives us a good test suite, too. To possibly make a release.

Ben Adams: Yeah, I think… I think you're correct on that additional charge, because you have to… Look up the account.

Guruprasad Kamath: Yeah, so ideally, just to summarize, the next step would be to get this PR clarified and merged, and then I can proceed to take that result and update my implementation and fix the breaking tests.

Maria Silva: Sounds good. So I, I would ask, so I already gave, a quick read and added, so I pinged you, Tony, and Ben, so if you could just go there and just, do a thumbs up, or something like this, just to make sure that everything looks good, then I can approve it. And you can leave my shots. Sounds good. Perfect. Anything else we should discuss regarding the transfers EIP? Or should we move to the next point?

Toni Wahrstätter: Yeah, maybe just to add to that, so intuitively, this… tells me that the BALS size will probably increase quite dramatically, right? Because if we… Quarter, basically, the cost of accessing an account. Right now, of course, the storage keys are the main contributor to the file size. But then I would also assume we have to look into, okay, We lower it To a level where the ball size gets bloated, so… We might need to make it more expensive again, because they also contribute to data. We're basically sending one way To as many accounts as possible will probably be the new worst-case bar size.

Maria Silva: Again, I… so I think on there, maybe we can wait to have the preliminary numbers on 1838 to understand what would be the actual costs of Accessing, cold accounts, with code and without code. And then we can do the… the math of recalculating the worst case balls, and if we feel like that's an issue, then it just means that the state's access EIP will have to Add, some sort of additional cost for… for the data part.

Toni Wahrstätter: Yeah, sounds good, let's do that.

Maria Silva: Perfect. Any more topics on, ETH transfers EIP, or should we move to the next, the next stop. Going once, going twice. Okay, I think we'll move to the next topic, so… For the next topic, we'll be talking about state creation, gas cost increase, and here we have two topics. So first I wanted to raise, a question that actually drag on from, from, from RED, first raised, and I think kind of, made me go into a rabbit hole of how to deal with the subcalls and the reservoir mechanisms, so I wanted to present you the options and just open the discussion on that. And let me just,

open it, because I have some slides. Okay, and then after this, we'll have, Spencer will keep an update on what he's been up to for, the specs and the tests for PEIPC. Okay, so I just wanted to, explain, What is happening now in the… how we deal with gas monitoring in subcalls, and what are… what are the open questions? So… just so we are all on the same page, so the current way that the EIP is doing the multidimensional metering, so it is splitting up these two resources, so we have the state creation operations. They spend, state gas, so this is not the state access cost, but the pure cost of creating new states. And then all the other costs are, the regular gas.

And how we are metering this is we have still the gas left, as we have now in the EVM, and this gas left is essentially bound by the transaction gas limits, so the 60 million, gas units. And then, because For state creation, users can use more than These transaction limits, they have this reservoir, so whenever their transaction requires more than the transaction limit. this extract is, sent to this reservoir. And then what happens is that, the gas left, so… The state creation transactions use the reservoir, and then once the reservoir is zero, they start using gas left, while the regular gas is… can only be taken from the gas left, okay? And then, what happens in calls? So.

In calls, the user is still specifying a single gas value to use in the call, and so the question is, we need to define, first, how does the forwarding happen? So how much gas left in the reservoir will the call have access to? And then what happens both in the success case, so how much… how are the unused portions returned, and also what happens in the failure. So in a revert, an exceptional halt, how much gas is returned to the gas left in the residue? And so I try to kind of describe as much as possible all the… all the options. So option one… is, essentially we are… when we are in a call, the gas left is the G that is being sent, of course, with the 6364, cup.

And the reservoir is essentially… is essentially all the reservoir, okay? So when the user says, I'm… the call is using G, that G is passed through the gas lift, and then all the available reservoir He's available for the call. Under success, the stuff that is unused gets returned. And both on… So on the revert, again, gas left, is returned, and the reservoir that is in use is also returned. On an exceptional halt, This is where it's a bit different. So here, all the gas left is consumed, so this is to keep consistent with the current design. But the unused reservoir is also returned. And the rationale for this is that when we have an exceptional halt, then

all the state that would be created is actually not created. And so, if we were to spend the reservoir, this would be too punishing for users. And so these means that, Actually, we should, return the reservoir. So this is option… option one. Option two is very similar, so the forwarding, is… is the same. Success is the same, revert is the same. But then, on the exceptional halt, we are saying that both the gas lab and the reservoir are zeroed out. Again, this is what is more in line with the current behavior of the exceptional halt. But again, it's… I think it's too punishing for, for cases where we… we have an exceptional halt, because we would be spending all the reservoir, which was made available, right, and we would be zeroing it out, so it seems a bit too…

to punish you. Then option 3, the change is how much… is… the change is more on the forwarding part. So for the forwarding, we are saying we are not making all the reservoir available. But instead, we are making the same proportion that was available in the gas left, we are making the same proportion for reservoir. So, if the call is with G saying, I want to send 20% of my gas left. To the fall, then we also send 20% off of the reservoir. And then the success, revert, and exception, halt behaved as the same as in option 1, which is less punishing than option two. And then, we have, option 4. So this one, the only change is, again, how much of the reservoir is being forward.

And here, the idea is, like, you don't forward the same ratio, but you forward the exact same volume, right? So if you say, I'm making 20… K available of gas left, then you also make 20K of reservoir available, if it's available. Like, if you only have 10K, then you send all the available reservoir. But it's not a ratio, it's the exact volume. And I think this one is a bit more in line with The current way that multidimensional metering works, where you say there's a block limit of 10K, let's say, or there's a block limit of 60 million gas units, and you can use up to 60 million gas units of both resources. So this is actually a bit more similar to how multidimensional metering does it at block level.

And then success revert an exception is the same as option one. So, what are the trade-offs? So, it seems like… In option 1 and 2, you do have, forwarding is a bit simpler. You have access to the full reservoir, but also, this has the problem that G… doesn't give you a bound on how much the call can spend. So this could lead to weird behaviors where you are just saying, I just want to send G to my call. And then you end up spending a lot from the reservoir, and so this is a bit, It's, a bit worse for entrusted, calls. And, and option two here is even worse, because it's like, if you end up in a… in an out-of-gas condition, then you even get your entire reservoir wiped out. So, I think, clearly, between option one and option two, I would,

prefer much more option one. Then option 3 and option 4, they give you a bit more control over how much you are spending via the G. But it means that you… you may have to send bigger gas if you want to use more… if you want to create states during your calls, which also can… comes with, with, with its own, issues. Then you, you have, like. the option between 3 and 4 is more like what would be more, intuitive for users when they are setting up G, and what would be, easier, which I don't have, like, a strong intuition there. And so… I wanted to just open the… the discussion, if there are any comments in the call, great. If not, I can… I will also share this, async, so we can start the discussion, but I think there's here the question of

how should we define these… these semantics? I mean, in my opinion, option one seems better, sorry, the other… yeah, option one seems better than option two. But we should maybe… think a bit more and see, like, is this really true? And then, are there any additional problems with any of those options that we haven't thought about? So yeah, happy to, to hear your, your comments, on these. And if there are any questions, also happy to… Happy education to go into it. Ben, do you have your hand raised? Do you want to talk?

Ben Adams: Yeah, it's a little bit tangential to this, but, does… Estimate GAF need to change to, provide people with, like, Who we estimate and hire. Based on the fact they could be charged more. Because we need to estimate above refunds, if that makes sense. Because otherwise it will go, can you pay the potential gas that you might spend?

Maria Silva: I'm… I'm not sure I understand what you are asking, sorry, can you… can you explain that again?

Ben Adams: With, with this EIP, is there a potential that you're charged more upfront, which is then refunded. So I'm wondering if, a note should be made that estimate gas should be estimating, like, the higher bound, if you see what I mean. You could… What you could be spending. Which might be higher, because you're… You're spending more on, storage, creating accounts.

Maria Silva: But, sorry, do you mean, like, in the case of a Halton Reverse, where your reservoir ends up being… Wiped out, or not?

Ben Adams: I don't mean with these changes you're highlighting at the moment, I just mean the overall EIP. In that… If we tell the user how much gas they the transaction costs… Then their transaction will get rejected because… You originally get charged how much you could potentially pay, and then you get, And then you get refunded back. If you spend less, if you sort of. I'm just wondering if we need to put a caveat in for estimate gas to… to make sure it's… estimating… the maximum. That you could be spending.

Maria Silva: So I'm… I may be wrong, but my understanding is, like, the… The way that refunds work are not changing. It's true that gas costs will change, but this is true for all the other EIPs, right? Like, for the… it transfers EIP, it's the same thing, like, gas costs will change, so we'll have to update the… the estimate costs, Well, I don't see how these EIP is different from all the others on that respect. But I'm… I may be missing something, so please, let me know if so.

Ben Adams: On… on this, I do think we do need to… I'm not sure what's the right approach, but I do think we need to limit it. cap the amount… if… if the, toll is capped. Then the amount of, reservoir paths should be kept in some way else.

Maria Silva: Right. Yeah, I think this is, yeah, so I think this was a good… a good raise from… from Drogan, like, I… I hadn't… hadn't thought on that. But I think it's, yeah, it's not obvious, the right approach there. Well, Daniel, do you have any comments?

Daniel Lehrner: Yeah, so, I mean, the idea of the reservoir Or the problem it tries to fix is mainly to deploy… smart contracts up to the new maximum, no? Because without it, it would not be possible. With 8047. So… Right. I mean, we don't want to encourage people to create a lot of state. And, you know, when you create a contract, I would say it's either directly in the transaction, or maybe you do one… Subcore when you use a factory. But… I'm not sure if you really have to worry about the issue that people have. you know, very nested cores, and then create the contract. So maybe even option 2 is fine, because either the contract is created successfully, or it isn't.

And… I'm not sure if it really makes sense to allow people to have this very nested course to use the reservoir, even though maybe there is a revert or whatever. Because, I don't know, maybe they can abuse it again in some form. So… As I said, I would say, you know, we should think what we want to do with the reservoir, and as far as I know, the only use case is to create new smart contracts. And that's it. We don't want to encourage people to… Use up a lot of state, or to create a new state in any other way than that. Turns out, for me… draining all the state cars on the road, actually, I think would be fine.

But, there might be some patterns for smart contract deployment that I'm not aware of that would… be… that would not be a work anymore. It did work today.

Maria Silva: Right, I think here the issue is mostly on the factories, which is what you pointed out, too. I think these are the ones that need more state gas within nested calls. But yeah, Dragan, do you have a comment there?

Dragan Rakita: Okay. Maybe I would even split this this in, like, two problems. One is how to limit reservoir to subcalls. Second one, not problem, but, like, discussions. The second one's, is, how about to revert and halt? In general, limit… for the first discussion. Maybe makes sense to limit it somehow? I like idea to limit it proportionally, depending on what gas regular gas is set, but I don't have strong opinions on any of that. Second discussion, I think it makes sense to revert, basically, to refill the reservoir if, basically, the gas that is That should be used for creation is basically not used. I do think that previously we didn't have this option, because we had just one gas, and it was…

different state. But we couldn't, like, make the difference between the… the CPU work that was done, or maybe state work that was done. But because we are making this split inside the VM, I think it's a good idea to… Not charged for something that was not done. Yep.

Maria Silva: Yeah, I tend to… I tend to agree as well. Yeah, it's just a matter of if someone can think of a problem with that approach. Yeah, I think it's one of those that we need to kind of stew on it and see if more… More things come up. Any more comments on these? Gold Leash?

Luis Pinto: Yeah, sorry, Maria. Just rolling a bit back even on the problem itself. So, since the state created is kind of rollback if there is a halt or a revert. In the… inside the call. Do we really need to be… to care about, Limiting the amount of state gas costs. That is passed. Since, I mean, we do care about the state that is carried across blocks, but do we carry that much about the state that's temporarily created? In the case of, of a halt or a revert. Inside the call. Yeah, I think…

Maria Silva: Yeah, that's… that's a good question, and I think this is where, like, the separation that Dragon did help. So I think one question is, like, on halt and revert what we do. The other one is, like, even in the success case, how much reservoir should be available for the call? Right? And I think… The second question is more about, like, if I'm a user, and I want to, like. the reason why I'm limiting the gas that is being available in the call is usually a protection, right? Like, if you are interacting with contracts that you are not too sure about, you want to have that control over how much gas is being charged. And so… these…

this, concept of letting all the reservoir be available changes this, right? Like, now a user says, I just want to use 10K for this, call, but actually I could end up using 20K if I have 10K in the reservoir in my contract somehow, like. creates a lot of states. And my intuition is, like, this is a bit, like. It's a bit weird, not giving the option for the user to, To kind of being able to limit also the reservoir. And under the two options, essentially, you'd still be limited by G. It wouldn't be exactly G, so for it's an option for it to… And, in option 2… I'm sorry, in option 3, G plus the fraction of state gas that is induced by the fraction between. So it's a bit more complicated, but it still gives you some sort of, like.

way to limit this. So I think… This is the… The question is, like, is this even something that, like, Users to have. The possibility of doing? Because the simplest approach would be just to do option one. Like, you let all the reservoir available, but then this comes with, sort of, some Like, some protection from the user side.

Luis Pinto: In a way, Yes, are you, Ruben?

Ben Adams: If you did option one, it would potentially mean that you call a contract with a limited amount of gas, but they can burn all of your State storage.

Luis Pinto: But the compute part is, like, the S-load is… or S-store is… there's also a compute side of that as well, so… There's a… Excited and the compute part, and that is capped still with the current limits.

Maria Silva: Right, I think the issue that, like, the way that you could do it more clearly would be with, like, deploying contracts within the call.

Ben Adams: Where there, you can, yeah. There you can scan.

Maria Silva: Spend much more state gas without execution costs. Sorry, Benacle.

Ben Adams: Yeah, because there's the pattern where you do, you know, try-catch. You can do, like, a try-catch, and… you might expect it to… out of gas as the worst thing that can happen. But… If it can destroy your reservoir, then that might limit what you… What you'd expect to be able to do afterwards. After calling someone.

Luis Pinto: Yeah, I think the committee is a good point.

Daniel Lehrner: Yeah, what if we limit the reservoir only to create, and create 2, and not the other? Another store, for example. So, this means when I call a contract, they cannot write at least their own state?

Maria Silva: I'm sorry, Danielle, I think I lost the first speech, can you finish it?

Daniel Lehrner: Yeah, sorry, I'm just thinking out loud, but what if we bind the reservoir, or only to create and create two, and not to S-store? So we really say the reservoir is only meant for creating new contracts? So this means when I call another contract, it could only use my state capacity to create other contracts, but it could not use it to write something to its own state. And it would need to use the… The, the, the normal gas for… for that.

Maria Silva: How… how would that help with this… with this?

Daniel Lehrner: I mean, this would help, because the contract that I called could only create new contracts. I learned that, yeah. It can still burn all your state costs, I mean, that is true. To this, this, Yeah. Yeah. No, maybe it makes no sense, really. I was just… I was just thinking out loud.

Maria Silva: Yeah, but I think good, I think it's good to think out loud and throw ideas.

Daniel Lehrner: Cheer.

Maria Silva: Any more comments on these? Rose Spencer.

Spencer Taylor-Brown: I guess I'd ask, just for the sake of, speeding things up, should we settle on one of the options now, and then we can change, like. M… In the future, so maybe for DevNet Free, we pick an option, and then… And DevNet4, we actually… Settle with either the same one, or update it to a different one?

Maria Silva: Yeah, I think that's… that's a good question. I think, in my opinion, it's like. Clearly, option 1 is better than option 2. And then the question of option one versus the other two, I think, is a bit more nuanced. So I would say, Yeah, I guess, like, my intuition could be maybe we could start with option 1, which is the simplest one, and then we can think a bit more about it, and then we can switch it to option 3 or 4. What, what do people think?

Jochem Brouwer: Yeah, I think we should do this, and what we then do is we figure out what breaks, what can be abused, and if we then figure out that this is something what we don't want, then we have to change it.

Maria Silva: Sounds good. So yeah, let's go with option one. I will comment on, on, on the PR, Spencer, and then, we can… March, I think.

Dragan Rakita: There is one edge case related to the option one. It is… you have parent call and subcall, child call. And what if the parent call sends, like, 20 million guests? And then the charcoal… basically… It has, like, 60 million for the regular gas and 4 million for the reservoir. Or… doesn't matter, it doesn't send ventilators, just send, like. Sorry, example is not that great. Imagine sending, like, 1 million, and reservoir, it's, like, 3 million. But what if the child code is basically spedding the… 3.5 million gas, state gas, on itself. What happens if that reverts? Basically, they did spend all the reservoir, and…

For the state gas, he additionally spent half a million from the regular gas. Should we, my idea that I had is, basically, we should… we could refill Basically, parent call, then gets additional half a million. on a reservoir. In that sense, we are refilling. full amount of state gas that was consumed by the charcoal. Because the charcoal consumed 3.5 million, but it had only 3 million of reservoir. I'm not sure if I explained it okay.

Maria Silva: Right, no, no, no, I think that's a good con… so… just to summarize, so the case is you had some reservoir, but you were in a coal, and you used more state gas than you had in the reservoir, so you have to spend also gas left, and then there's a revert. Then what happens in the, like, the reservoir will be fully reinstated. But the gas left wouldn't, so that would go… that would be spent fully. So I…

Dragan Rakita: would be spent.

Maria Silva: It should be specified. So I… so I think it's, like, in a reverse, it doesn't matter… what happens within the call, right? Like, you still do the same as the gas left you sent with the call all gets used, and then the reservoir gets reinstated. So you… in your case, the 500 gas that you used for state gas, that's was spent from the gas left would also be reinstated, so you wouldn't… It wouldn't be spent.

Dragan Rakita: Should the idea is we shouldn't add it back to the… You know, gas left. But we should add it to the reservoir. Then, at the end, the parent call, after the child call reverts halts. It would have, it had 3 million reservoir, but afterward, it would have 3.5.

Maria Silva: I don't understand why. Why should it have to be in the hub?

Dragan Rakita: If we bant to… Not spend all the… all of the state gas. We should add it somewhere, somewhere. So, we could add it back to the regular gas, but this seems… bad in the sense that we are, like, splitting. The gas that was spent on the state is now added to regular gas. So, better option is to add it back, or add it to the reservoir. Or there's option just to ignore it, and just say, if the… The gas that is basically the state gas, if this consumed… if this consuming regular gas, then this part of the gas is going to be deleted. Not reverted, or…

Maria Silva: I… I mean, maybe we should just do this async and write down in the space PR, but my intuition should be that, yes, those 500 would go away, because you were sending a certain amount of gas to the… To the call, and on a revert, that amount that you sent should all go away. Independently, if you use it for state creation or not. But, yeah, let's, let's, let's, let's discuss this async. Sounds good. Okay, so maybe I will, after, I will, link, the PR here for people who want to see, and, and for the next point, Spencer, do you want to give a quick update on, what you've been up to for, week 37?

Spencer Taylor-Brown: Yeah, I can be fast, so, Still have the same, specs PR as last week, I believe I've got option 2 implemented, from the previous discussion, but, Right now, I'm trying to fill all the… existing tests that we have in deals, with the spec implementation, and I have ran into quite a lot of issues, mostly surrounding, the gas limit for transactions, so I think we… we hard-coded the gas limit in a lot of the transactions in the tests. And with the new, state gas dimension. This gas limit, is very low in a lot of the tests, so there's, A lot of the tests need that increase, but some of the tests also have Some other interactions with,

So I guess, also with the tests, we need to make sure they're refillable for every fork, right? And with, 7825, we have the transaction gas limit cap. So it's also trying to make some of the tests fork-aware, so that we're not breaking any previous, fillings. Of the test. So, I've been working quite heavily on that. So far, I think I've fixed from Frontier to Shanghai, and then it'll be… yeah, Prague, Cancun, Osaka, and the Amsterdam tests. I have not yet tested the… legacy tests as well, and I think those will need to change, so I think it might be a bit of extra work from our side. We do have the internal Steam call after this call, and I think I will ask for some extra help.

And they're from the team. But yeah, that's, that's the update for myself.

Maria Silva: Thank you. Thank you, Spencer. Are there any questions for Spencer, or should we move to the next point? Okay, I guess there are no more questions. So the next topic is, on 7976, so the increased call data floor costs. Tony, do you want to give a quick update on that one?

Toni Wahrstätter: Yes, I'm happy to do so. I just posted in the agenda the EthResearch post I recently had. I already brought this new pricing up in the last ACDE and ACDT, so it's nothing new, but recently we changed the pricing from $15.60 So 15 for 0 bytes, 60 for non-zero bytes, to 64.64, which means, at the floor cost. Users would pay the same Gas per byte, no matter if it's a zero byte or a non-zero byte. I already updated the analyzers that is linked in the EIP, And instead of affecting 1.5% of transactions, this would affect slightly above 2% of the transactions. So, most transactions are still, like, unaffected, and the rational behind this change was that in the worst-case scenario, so for worst-case blocks, it doesn't actually matter that much if it's a zero or non-zero byte, because

you can… you can otherwise use 0 bytes. You would maximize the number of 0 bytes, because they are cheaper to get, like, the max size block. And just making sure that they cost the same, 64… Gas per byte ensures that, This doesn't matter in the worst case. So, I'm curious if people have any opinions on that. In the EthResearch post, you can see, if you scroll down, I created this chart. That projects, like, what the worst-case block size will be with that change. And… Yeah, so this gives us some room for scaling, ensuring that the worst-case block size won't be a problem that soon again. Of course, until at some point, we have to do something more sophisticated with the call data pricing anyway.

But this is, like, diffusing the situation, I would say. And the worst case block size, so with the… Pricing that we had earlier with the… 1560, the worst case block size, would have been at 3.5MB compressed size. And with the 6464 pricing, we will get down to slightly above 2MB in the worst case compressed block size. I've already started, like, reaching out to the affected parties. There are not many. Like, most users can use blobs anyway for posting data. It's only those that can't move to blobs that still need their call data to get inside DBM. And it's only a few parties, that are affected. Right? So… If there is any objection or anything, I'm curious to hear it.

Ben Adams: On the 64 value, I don't have an opinion, I'll defer to you. On the zero byte being the same, I think it makes sense, because… If you're doing useful work, then… Most of your bytes won't be zero. So… It's only… The people most affected by it will be the ones filling… Essentially filling the blocks with nothing.

Toni Wahrstätter: Right, exactly.

Ben Adams: Not doing… not doing useful work.

Toni Wahrstätter: Exactly, yeah. So this is… maybe… maybe I should have, added that previously. The call data price for everyone who will not hit the floor will stay at 416. So it's… it's very well backwards compatible, so users… most users won't feel any difference. It's only those that hit the floor. That would actually pay the $64.64.

Maria Silva: Yeah, thank you, Tony. I can't think of any issues, I think it makes things change, but yeah, if anyone, has some time to take a look at it and has any issues with comments, please, For them to…

Butta: Tonya, I'm just wondering which entities are affected. Are they, like, are these, like, protocols? Like, bigger ones, or…

Toni Wahrstätter: Yeah, good question. So, it's the same entities that were already affected by 7623 that introduced that mechanism. For example, among those entities, there is Polygon, and there is Starknet. And for them, it's because they have very large proofs that can't… and they can't just post their data in blobs. So for them, they need the call data to actually, yeah, do some math with the data.

Butta: Okay, maybe I'll…

Toni Wahrstätter: Those are the main users. There are some… there are some smaller users that is, like, negligible. It's, like, me sending you a transaction and saying, hi Butter. So this is, like, the largest amount of users that are affected, users that are just, like. Saying a few words in their call data. But when it comes to, like, what is the economic impact, it's those protocols that can't use blobs that are still using call data.

Butta: But, yeah, maybe… Go ahead, yeah, please. Maybe, afterwards you can connect with those, and I can force them to fill out our survey.

Toni Wahrstätter: Yeah, happy to do so. We are already in discussions with those anyway, but I'm happy to forward them the survey. I guess that's the proper way to do so. Yeah, let's do that.

Butta: Yeah, I would, like, yeah, I mean, I think it's gonna be my time anyway, right, Maria? In the agenda, maybe? I'll take over then.

Maria Silva: Yeah, we can… maybe we can… we can move to your… to your section.

Butta: Right, so for those that weren't here, last Friday, we introduced a new website, which is called GasRepricing.com. And on this page, you will be able to find everything related to gas repricing. It also links to the progress, so if you're curious what the status of each individual task is, you can find it here. You can find a simulator. This is more specifically designed for those that are affected, but more importantly, there is also a survey that would be nice if you or someone you know that might be affected could fill out, because If you're not affected, you probably will just ignore it, so it's kind of hard to get data to, just confirm the design of the current EIPs.

But still having real data would be nice. For those that forget about the website, we also linked it at the top of Forecast, so it also is promoted here. And I think yesterday, we also posted it on Twitter, so if you can retweet it, it would be great. I think so far, we got, like, 2 or 3, official survey, candidates. But I also manually reached out to Coinbase, Kraken, and one other exchange, because I think those are, like, most obvious stakeholders that will be affected, because they have payouts, like, withdrawals, deposits to exchanges. Or they have other products. So while they might not be represented in the survey itself, yeah, they gave me, like, off-chain information.

Yeah. I will link it in the chat, so, yeah, maybe you can retweet it. I saw Tony already retweeted it this morning, so thank you for that. Yeah, that's… that's my part.

Maria Silva: Thank you, Bhuta. Yeah, I think this community outreach will be very, very important going forward to make sure that Users are not surprised by… By, by the changes, and also that we take into consideration their, their feedback, in time to… While we are implementing these changes? So yeah, I'll just, reiterate, like, if you can share these, and, if you know anybody that would be impacted, please, share it with them. Are there any questions or comments for Bhuta?

Butta: So… just for your knowledge, next thing, we'll be posting it on Reddit, like, eFinance, maybe we can get, like, individual people, to fill it out. I will also try to get in touch with Aave, because I think if they are fine, it's also gonna be fine for other, DeFi projects, and then maybe Tony can connect me with Polygon and the other folks that he was talking to. But yeah, as I said, like, if people are fine, they tend to be quiet.

Maria Silva: Thank you, Bhuta, and, we are almost at the end of the call, there are no more topics, but I think if there are any questions or general comments or topics people want to bring up, we still have some time for that, so I'll just open the floor for random topics.

Toni Wahrstätter: I had a question in the chat. Basically, is it… is it true that… the cheapest way to access… for example, if I call balance on an ac… going very much… going back to 2780, If I call balance on an account that has no code, will this effectively only cost me 200 gas? Can someone clarify that?

Maria Silva: You always, you always charge at least the transaction-based cost, which currently is 4,005 benefits. So, and that covers… let me just open it up so I… say it incorrectly, but it covers ECU cover costs, as data plate costs, and the call account costs, no codes. So those three components are always charged.

Toni Wahrstätter: Right. Yeah, Maria, you did an amazing analysis by the time, if I remember correctly, about the worst-case bar size, so I guess we should just, connect async to see, what changes, but my first intuition would be that the new worst-case bar size will be a transaction. a max test transaction that then calls, for example, the balance opcode. at as many… empty accounts that have no code as possible. And for each of those calls, you would only pay $200, But you would get… you would not only call the account, you would also do an S-load, I guess. And then you would end up with, 20 bytes from the address, 32 bytes from the storage slot. And you would only pay 2,600 plus the 200 gas.

So I think the worst case file size would change a bit, but yeah, let's connect async and clarify that.

Maria Silva: Sounds good. Yeah, happy, happy to do it. Are there any more comments, or… Topics, or should we wrap up? Okay, so it seems there are no more topics. Thank you all for attending. Notes, recordings, and all that will be made available in ForkOST. Yeah, thank you for… thank you for joining.

Toni Wahrstätter: Thank you. Bye-bye.

Ameziane Hamlat: Bye, see you all in two weeks.

Jochem Brouwer: Right.

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