Increased Resilience and Stability Through Gas Limit Cap

Transcript

There are some sophisticated users that might go to 1 million guests or even 2 million, 5 million gas. But it is a very very rare edge case. If we would only ship the parallelization but not the cap, then the worst case block would just be a block consuming the full 135 million gas ending up in being executed on one core. The proposal was mainly looking at okay why are certain worst cases as worse as they are as bad as they are and how can we somehow [music] mitigate it. This is one of the projects that will be affected where we know it will be affected because [music]

Welcome back to the Fusaka file, unlimited episode podcast exploring Fusaka EIPs [music] that make Ethereum faster, smarter, and easier to use. I am Puja Ranjan from EC Institute >> and I'm Paul Brody, the chairman of the Enterprise Ethereum Alliance. >> We believe the truth is out. So today we are diving into EIP7825 [music] transaction gas limit cap, a proposal that introduces an upper bound on [music] gas per transaction. It's already live on Ethereum test net and is set to activate [music] on mainet with Fusaka upgrade. To help us understand why this change was introduced and what enterprise benefits or use cases it might bring we are joined by Tony was from the Ethereum Foundation. Welcome

Tony. >> Hi nice to be here. >> Nice to have you. >> Thanks for joining us Tony today. One of the things that we want to do with this podcast is really talk about the business use cases and reasons for some of these improvements. They have lots of good technology behind them, but our goal here today is to really not focus on the technology, but more on the like why is this good for uses and we've got a few questions lined up for you. >> Sounds good. >> Of course. Yes. And we would like to maybe kick off this session with your brief introduction. So could you briefly introduce yourself and let us know what you are currently engaged in?

>> Yeah, happy to do so. As already mentioned, my name is Tony. I'm with the AF now for 3 years. I'm currently leading the protocol prototyping team at the AF, mainly focused on getting research ideas into production, helping with specking and prototyping. >> That's pretty awesome. Before we get into like the enterprise use cases and technical details of it, maybe we want to like uh kick off things by just stating the story behind this proposal. What inspired the inclusion of EIP7825? Can you please give us a big picture of what this proposal is all about?

>> Okay. Yeah, that's an interesting question because it's um 7825 is not like a new feature as everyone who um has seen the EAP quickly realizes. It's not like something new, something awesome that a user can suddenly do. It's really just a mitigation against things that can go wrong potentially. And in the past, we have seen multiple such cases where worst case scenarios were triggered and one of the common denominators there was always that the fact that a max size transaction was used, right? Every time when you want to attack the network, you would of course go all in. And what you would do is you bundle as many let's call them evil

operations in one transaction. And this has always been a problem. Of course, capping the transaction gas limit doesn't help necessarily here, but the proposal was mainly looking at okay, why are certain worst cases as worse as they are, as bad as they are, and how can we somehow mitigate it? And this was the original motivation behind the proposal. Later on, I would say another aspect became very important which was parallelization. So how can we make Ethereum as efficient as possible for users? And on that regard, I think the EIP 7825 is even more effective than the changes we have on the road map. So it's

a quite simple change, but in my opinion, quite impactful. So talk about gas fees in terms of like dollars and cents. Like what does this actually do? What am I paying for a transaction today? What is this actually what is this likely to do to the price in dollars, not gas of transactions? Cuz I think when people say, you know, it's going to use 200 mega gas, I don't even know what that means. And I've been in this business for 10 years. I always have to say, and what is that in dollars? So, so spell it out for me in dollars. >> Yeah, gas is an abstract unit that is a little bit difficult to understand at the beginning. So what users usually care about is exactly what you say. It's like how much do I pay in dollar terms?

And in order to get to that amount, you usually take the gas you spend for that transaction times the gas price. And what we are talking about in the EIP here is the gas you spend on it. So how much gas do you spend for computational resources? And this is completely deducted from how much does each individual unit of gas costs, which is the gas price. So for users, let's say you send ether to a friend, then you pay 21,000 gas. If you do a token transfer, then it's a little more 25,000 to 30,000. You do an approval, you do defa interactions, all of those events, all of them cost you some amount of gas,

which is then multiplied by the gas price, which gives you the the final amount you pay in dollars. What the usual user interaction, right, we're talking about 21,000 gas to maybe 100,000 gas. There are some sophisticated users that might go to 1 million gas or even 2 million, 5 million gas, but it is a very very rare edge case that a user consumes all of the gas available in a block. It is possible. So today I can just buy a block for myself. Basically, I will put a lot of um heavy computations in there. They cost me a lot of gas and in the end the block consists of my own transaction and nothing else because nothing else fits in there.

>> This is actually what happened to us at EY back in 2018. We wanted to show the prototype of our privacy technology and we needed not one, we needed two consecutive blocks, the entire block to complete the transaction because it was so computationally intensive. Now we've squeezed it down enormously since then, but give me a sense like you know 25,000 gas I think today is like under 25 cents US dollars in terms of like a cost for sending a simple transaction, right? >> Yeah, very like clearly around that.

Yeah. >> Let's say I have something very complex like it's a zero knowledge onchain computation. Is there an upper limit on price that's going to be like $10, $20? what should I think about in terms of the likely upper limits and and is this really just an edge case situation where we're fixing edge cases or is this something that's going to drive cost down for most people most of the time? >> Yeah, this is a good question. So there are definitely operations that are also userfacing like you said the zero knowledge example for example if you look at tornado cache or railway I think those transactions they consume around 5 million gas so a deposit and a withdrawal so of course you still want to be able to make sure that those

transactions are still um possible. So on the one hand the EIP is a little bit restricting on that regard but on the other hand we need to kind of find the right balance where to put this cap to make sure that all we want is still possible while still on the other hand squeezing out as much efficiency as possible. And the efficiency here is especially important when we think of parallelization because today if you naive example you have two cores and you have a block with only one transaction in there even if you could parallelize them right because they are independent.

Let's say there are two transactions in them. They are both fully independent, right? Today you don't know they are independent, right? So today you would just use one core to execute the first transaction and after executing the first you would realize nice transaction two is independent of the first. I could have executed them in parallel. But this is not possible anymore. And of course, a block that is filled with only one single transaction can never be parallelized because you cannot split a transaction into more chunks and execute them in parallel. So the transaction gas limit is also important when we think of parallelization that will be introduced to Ethereum around next year where transactions can be validated in

parallel. This is EIP 7928. Having 7825 together with the parallelization EIP is then even more powerful because suddenly you cannot end up in a situation where you have 100 million gas available and it's all consumed by one transaction and this one transaction eventually must be executed on one single core. Instead, you have at least like five to six transactions and they can be nicely distributed over your course.

>> So, it sounds like this is more about laying the foundation for a much higher volume of transactions than it's really about making the price of transactions sort of low and consistently reliable. Is that a fair statement? >> I would say both because as soon as you scale the chain, it becomes um cheaper for everyone. >> Yes, I would agree with you. But practically speaking for business users, there's not going to be a meaningful change for most simple transactions like making payments, transfers, even DeFi protocols are not going to see big sub substantial changes as a result of this.

Uh but it's laying some of the foundation for much more substantial scalability in terms of transaction volume and capacity. >> Exactly. This is a good explanation. So the EIP itself won't affect them at all. But in the end, the impact the EIP has the the effects on other parts of the protocol making them more robust and allowing the rest of the protocol to then scale up which eventually then makes everything cheaper and more efficient. >> Excellent. Thank you. I think I understand. Now >> I would like to maybe pick your brain on uh one of the important u motivation point that is mentioned in the proposal.

It's called the validation overhead. You briefly mentioned here like we would be having a better way in upcoming uh upgrade with I believe uh the BS proposal that is there. So what is the kind of validation overhead we are trying to deal here? What is there for validators? >> So validation overhead is essentially any transaction right every every any computation is some validation overhead. And for example, currently the most expensive operation compared to how much it costs is the schemodex pre-ompile which is repriced in the upcoming Fusaka fork. And of course if you bound transaction if you kept them at a smaller gas limit you can fit less of

those operations in one transaction. So for example what was possible that an absolute number of modx operations which is this operation that is possible through a pre-ompile. So the number of operations that was possible pre the EIP will reduce after the EIP and this is also one of the goals here to yeah you have to split those transactions up. You can still almost do the same because the gas overhead you incur by splitting transactions into parts is not that high but you definitely cap it at some point.

>> That is good to know. So from developers point of view if we are trying to figure it out because now we are going to have this cap in place. What is the basic change that I should expect when this proposal goes live? So for for the everyday developer that is building decentralized applications on Ethereum using Ethereum tooling and so on, they wouldn't see any changes. Things like best practices in coding, for example, that you don't implement um loop that you can't control. For example, you deploy a contract with a loop where users can add something into an array and suddenly the loop grows bigger and bigger and at some point you can't execute it anymore. Those are very bad coding practices that have never really

been existing, right? So of course those things will break and some of them have broken already, right? We see contracts on Ethereum where functions cannot be called anymore because they grew they grew too expensive. So this is one of the things that devs are doing a great job already in making sure that their code survives assuming Ethereum doesn't change. Of course, now this is a change for Ethereum and what it means for some of the developers is that big operations that they would do in one transactions need to be batched into two transactions. For example, if you want to post half a megabyte on chain, you will not be able to do that anymore. In

one transactions, you might need two transactions for that. So, it's still possible. Those batching operations are generally not a problem because it's cheap to split them up into two pieces and do them sequentially. Of course, it's not possible if you have like big math going on that would really consume that much gas, which is not really the case today. >> That is great because that sometimes lead to DOSs attack kind of planning like if Malaysia's parties are thinking of adding all of those in one transaction, it could lead there and that's one of the motivation points here. So on a high level from an author's point of view, what do you think is the biggest impact of EIP7825 when it goes on um mainet uh I know there is a list of motivations but in

your mind what is that? So I think in my mind this going to this relatively low gas limit right it's still conservative we could go to 8 million gas cap and we would still affect only like 0 something% of the users because as said the vast really vast majority of transactions is is way below 1 million and so it's still conservative but 16.67 67. So 24 gas is a quite nice gas limit if you think about the future or when we have a gas limit that is like eight times that number. Why eight times?

Because usually our nodes have eight cores and if you're at 135 million gas something like this then you can basically guarantee that each transaction has a dedicated core. So if someone builds a worst case block which would be a block with all filled with max size transactions which would be eight transactions of 16.67 million gas then you still guarantee perfect parallelization because you can distribute those transactions over your eight cores and the execution time becomes the execution time of one of those transactions because they are running in parallel. Compared to today, if we would only ship the parallelization but not the cap, then

the worst case block would just be a block consuming the full 135 million gas ending up in being executed on one core. So I think that the really big impact will be seen in the future and we will then think back and we'll be like okay wow this was actually a really important change here. >> So I got one final question for you. Are there any routine transactions that are going to be affected by this? And can you tell me like a specific company or DeFi protocol or something that's actually affected by this? And do all those participants know how to be able to split them up?

>> Yes. So, for example, one of the projects that is affected by by this chain is the project. It's X en it's an interesting token concept that I'm not fully into how it works or we don't need to rehash how it works here but in summary it uses max size transactions. So for Zen to work the best case is to use the maximum amount of gas that is available to it. It will still work if we would go if we would cap the gas limit at 1 million. The project would just work a little bit differently. So this is one of the projects that will be affected where we know it will be affected because in empirical studies we did we found that it was the main party

affected and apart from that there are other users that are affected. For example there are those ENS farmers right I guess no one likes them but they exist and they farm ENS names and they renew them in batches. So if you have 10k names, it's of course nice if you [clears throat] can renew as many of them in one transactions instead of using many transactions, but it will become more expensive for them too. So apart from this very specific use case, everything that is done in batches. So for example, contracts deploying very big contract ecosystems, they will also have to split it up into more transactions. It's quite nicely doable.

So you will still be able to deploy like five max size contracts within the limit. So it's not like you would be constrained by what you can create on chain but for example earlier it was possible to deploy like 10 contracts for example now you will only deploy like like five contracts per transactions which means if you want to get like 15 transactions what took you or let's do 20 um contracts. If you have 20 contracts that you need to deploy all of the maximum size, then it will take you like um two transactions now or four transactions will took you two transactions and some things will become more expensive. But this is almost negligible especially for those contract

deployment use cases because splitting up uh a contract deployment is is like really cheap compared to the deployment itself. There is always a trade-off and we should focus on the gain that we are going to get with this proposal getting in. I see uh the proposal has already defined a very good high limit 2 to the power of 24. It's really on a higher side knowing the history of Ethereum people always come up with new ideas. So I'm curious to know do we see any change in future? >> Yeah, of course we could see changes there. I don't think this change would happen soon. I think we we got to this number because we just wanted to see some immediate gains through that for example if we would have stick to 30 million and this would have meant we are

really constraining ourself more when we think of like what's happening in like 2 or 3 years because we would still have to deal with very big transactions and I also remember Vitalik on one of the old call bringing up the argument that doing the change today is like less expensive than doing the change tomorrow. So if we decide suddenly that we we actually need it and most people um agreed that we need such a change but if we only do it next year then it will be even harder right and the gas limit is currently increasing. So what would be the best amount? probably 45 million we could have set it to 45 then the change would be quite tess and at 30 million would have also been an acceptable number but

cordups and the community in general wanted to yeah be more aggressive while still as you said being very conservative with I think only 0.038% so 0.04% 04% of all transactions are affected. Most of those transactions are coming from the same entities. So there are a few entities having a lot of those transactions like Vixen project and the rest of the users will not even realize that this change happen but they will in a few years when we can actually scale even further because we have the safety that one transactions cannot occupy too much block space. Thank you for explaining that uh Tony that was really great and I really hope that we would

include uh Modi XP in this series as well to provide a better perspective to our audiences and I believe that is the perfect time where we can perhaps wrap up today's episode. >> Very good. Well Tony, thank you so much for your time today. We really appreciate it. We're going to edit this out into what we hope is a very compelling but short podcast on this EIP. >> Awesome. Thank you very much. >> And dear listener, thank you for tuning in. Check out show notes for links and resources and follow ECH Institute and Enterprise Ethereum Alliance on YouTube and Spotify for next episode. There is a very good blog post out. We are hoping to add the link right over here. But yes, there's going to be a lot about Fusaka [music] EIPs in upcoming episode.

So stay tuned. Cheers everyone.