EIP-7935: Set default gas limit to 60M

Transcript

It's not a change to the mechanism in which we're changing the gas limit. It is more of a rep prioritization of our sort of technical that we're doing at a at a more protocol level and and at a research level as well. >> It's kind of one of these things where now that we've put in the work, it's paying off across other dimensions as well that we didn't necessarily expect when we started. We are able to execute any kind of scenarios on that while having the living network with all of the client pairs just processing the blocks and we are able to attack that and see how the actual network will go through those attacks. If you have too high a gas limit, however, it becomes very hard to run a node. You have more attacks that are possible against the client. It just becomes more difficult

for Ethereum to be sustainable long term. [Music] Welcome to Penip, the one and only EIP series where we explore proposals under consideration for upgrades and those making an impact across the Ethereum ecosystem. [Music] This is episode 155 brought to you by ECH Institute. I'm your host Puja Ranjan joined today by my colleagues Whin and Akash from operations and multimedia

team. Today we are diving into one of the simplest yet most impactful changes with the upcoming Fusaka upgrade. EIP 7935 is anformational EIP and does not contain spec changes. However, this EIP recommends a new gas limit value for Fusaka and upcoming upgrades in the execution layer clients suggesting default config. What exactly is this recommendation and how was this number chosen? We'll discuss all of that in the next few minutes with the author of the proposal and developers involved in implementation. Please welcome Sophia Gold, Parito, Shyanti and we are also

joined by Camil Hot Utala Adaf from Nethermind team. Welcome you all to Peep Anip. >> Hi. >> Hello. Thank you for having us. >> Thank you for joining us here. So Pi has been kind enough to join us again to share more about this new proposal. So he knows the drill but this is the first time we have Sophia and Camil on the show. So before we dive into an EIP, may I invite each of you to share a bit about yourselves and Pari, you may also reintroduce yourself as well. >> Yeah, maybe I can start and um set the tone. Hi, I'm Partosh. I work at the ETH Panda team at the Ethereum Foundation and uh we mostly help with whatever work, testing, roll out, documentation,

whatever needs to happen to make the next fork on Ethereum go smoothly. Been doing this for about 4 years now. started with the beacon chain launch and um yeah, this would be my third or fourth big fork since then. >> Hi, I'm Sophia. I work now on the ZK EVM team at the EF. I've been at the EF for about a year, but I've worked in crypto for nearly a decade previously as a core developer on some other networks. Hi, I'm Camille from Nethermind team mostly doing uh QA stuff leading QA efforts in Nethermind client and and you recently are focusing quite a lot on performance researches on gas limit and all of the other flows which E clients can have mostly focusing for now on E clients.

>> Thank you all for sharing about yourself. I understand gas limit is a topic that everybody loves and this proposal is going to set a default value of it. So I'm so very much interested to learn more about the proposal. So without further ado, let's peep in. >> Okay. So we're going to talk about scaling the gas limit today and how we arrived at at the proposals. To start off with, we're going to talk a bit about how the gas limit was arrived at in the past, how we've scaled it, and what problems we noticed and how we're trying to avoid those problems for the future. To begin with, what are gas limits? So a gas at least in the concept of in the terms of Ethereum is an

abstraction for a unit of computation that happens. So a gas limit tells us the upper limit of the amount of computation you can perform in a block. That unit of computation can be something like a transaction. It can be a call to a smart contract. It's an abstraction layer around all the resources that it uses on the node. So that includes network, CPU, RAM, storage, and so on. In the past, gas limits have always been chosen based on benchmarks and thinking about what attacks happen. We can't actually set the gas limit directly. This is something that is voted on with each block. So every time that there's a block being proposed in the past, if it was the minor, then the block being

mined, you would either vote up or down the gas limit. So if the current gas is 30 million and you're choosing to vote for a gas limit of 36 million then the gas limit of the current block would basically go up by one over some percentage of of the gas. The highle problems are if we have too low a gas limit then it's too expensive to do anything in the EVM. If you imagine that the gas limit is essentially 21,000 gas, something trivially low, that basically means one transaction would take up the entire block. There's nothing else that can happen. If you have too high a gas limit, however, it becomes very hard to run a node. You have more attacks that are possible against the client. It just

becomes more difficult for Ethereum to be sustainable long term. So, it's always a bit of a gamble. We have to try and figure out what are the needs of Ethereum today but also what it can sustain and then we propose or set a gas limit accordingly. So you can see over here there's a chart of the gas limit over time. We started off in 2015 16 with something I think 2 million gas something around these numbers and you'll see a plateau around 2021 where it goes to 30 million and in the last half a year to a year you'll see these bigger changes that are happening more consistently. Just clicking a bit deeper into cost of when we got the gas limit wrong. For example, in 2016 there was a

series of uh denial of service attacks that happened. There was an underpriced op code that led to massive state load affecting mainly the GU client. Back then in Ethereum, we had two major clients. We had GU and Par. And the par client did not have this bug. So the parity client was the one that was able to continue to mine blocks and keep Ethereum going while G was fixing and patching the issues. This also shows you a bit as to why client diversity has always been important for Ethereum. Had we just have one client back then, then Ethereum would have been effectively down. But thankfully we didn't. We had multiple clients and the chain was able to progress without any issues. The gas limit was then reduced drastically. So you can see this big drop to mitigate

the severity of the attack. There was some repricings that went on and then once the repricings were done and the attack was considered to be taken care of, then the gas limit went back up again. So this showcases why we're also very careful about setting the gas limit. It's also hard to coordinate on it because you have to always vote. You have to have the validators in today's Ethereum kind of accept the new limit. So if we have to even increase or reduce, then we always have to take them into account. The next topic is why did we go from 30 to 36 million gas around early Feb this year? It feels like a relatively marginal increase, right?

This is because once so there was a the social layer of Ethereum was uh aiming for 60 million gas around that time and they were pushing there was a lot of websites as well as Twitter push to increase the gas limit to 60 million. There's a researcher the EF Tony uh you might know him from some of the other EIP talks that he's given at peep and e where he wanted to test a specific type of call data style attack that he thought would be interesting. It was a very fun incident because we didn't necessarily know that it would be an attack. We wanted to test something else. But once we tested something else, we broke the sea chain. And when we broke the sepoleia chain, we realized that this could be a real attack. You could essentially create these large call data transactions that wouldn't fit

through the engine API. And because they wouldn't fit through the engine API, you would have these stalled nodes. Pectra as a fork increases the call data cost to prevent this attack. So it isn't a problem anymore. But this essentially gave us a ceiling of about 42 million I think back then and we decided that okay maybe even going to 42 million is a bit risky. Let's do 36 million and give us some more margin of error. You can see the whole incident timeline described in the blog post over there. The second section is we've had a shift over the last year. So in the past it's been very reactive scaling. So you'd see the community complain about high gas prices. Obviously the community sort of already starts signaling for higher gas

and then we figure out what type of attacks could exist then we figure out what types of problems could happen and then we mitigate those problems and then increase the gas limit. However, now we're shifting to a more proactive style. So we're trying to before people even ask for a gas limit increase already do the test already have the benchmarks and already scale up Ethereum so that it's cheaper for everyone to use and we're doing it in a safe way. In order to do this earlier this year, we came up with a couple of large topics we wanted to look at. The first one was benchmarking op codes across all the clients and diversity is super important. So we want to make sure that all the clients can support the gas limit also at the recommended hardware specifications for Ethereum. So this

shouldn't require you to have like a data center node but nodes that home stakers can run. The second one is if you have a very high gas limit, you also have higher state growth and the higher the state growth, the harder it becomes to process blocks on Ethereum. So you want to also try and capture all of these state related benchmarks, state related attacks and kind of get the information about when this will start to be a problem. So we that's a major component for any gas limit increase. And the third one is any type of security attack related things that we can open ourselves up to that we might not be vulnerable to right now. So we had to figure out like a proactive rollout plan. How do we test each of these things? Who's responsible for

them? Where's the data going to be? How do we then convert this into a gas limit that we can propose to the community to vote on. You'll find a bigger description about everything in the link over there. We met in person in Berlin earlier this year and we spent a entire week working on a lot of topics related to the gas limit. Maybe Camille wants to take this section. >> Yes, sure. So, one of the major things and major tools which we use in Berlin as mentioned by Pari was the gas benchmarks repository. So basically in mind about a year ago we crafted a tool which allowed us to fill the block to the maximum with one specific op code or one specific pre-ompile with certain

configurations and based on that we started to seek for the the worst scenarios and actually the modx repricing which we have in Fusaka is an outcome of this testing. So we figured out that modex is kind of underpriced and we should consider repricing it to reduce any potential risks of attacks on on on the network. Right? So yeah that was the very early state of the the audit tool and this year we started looking at it in more people. Uh we started thinking how we can use it more and give more insights into the and any potential gas limit increases moving forward. Right. And yeah we spent a lot of time we added a lot of scenarios. It was actually one of the major tools

which we used on Berlin interrupt where we were testing a lot and trying to figure out the fixes for all of the clients not only on the worst cases but also on some more average cases but to to mitigate the risk for the future and also we figured out that in the meantime while we were doing that tool and we were having our set of tests other teams were doing something similar right so ZKVM team was doing some kind of benchmarks which were actually on the fundamental was doing exactly the same thing but was started in different way and also as I know flashbot team was trying to do something similar as we do.

So we sat together actually in Berlin and started thinking how to standardize that effort and merge all of the test cases and have much bigger subset of scenarios to to work on. And yeah right now we are on a status that we have the standard set for benchmarking of op codes. it is uh merged into the EST framework which which is used commonly for all of the testing across the Ethereum right now. And yeah uh this is like merged effort right now between EF, Neetmind and all of the client teams to work on scenarios to start looking at some graphana charts which we have which are visualizing the the results and telling us what is the safe limit we can probably choose right now. But this is

only attacking one side of the problem which is op codes and pre-ompiles and as parto mentioned we have also the state growths which also needs to be taken into consideration but we'll come to that a little bit later on also as you can see there are new type of dev nets for now back in past we were using devets for testing the the new features which are going to be enabled by the most recent fork but we never had any devet which was like purely focused on testing the performance on reproducing some scenarios which can be potentially problematic on mainet etc. Right? So that's how we first experimented with some small networks with super high

parameters for gas limit for blobs etc and seeing when things will start to crash but then it evolved so we have a mainet shadow for which is having the current specification of mainet so but with increased gut limit and we are able to execute any kind of scenarios on that while having the living network with all of the client pairs just processing the blocks and we are able to attack that and see how the actual network will go through those attacks. And this is perfet one which is focusing mostly on the computational scenarios. So some heavy op codes or few compiles attacks per devet 2 which is actually something crafted specifically for state bloat we call it bloatnet. So this network for at

least few months we focused only on figuring out how to increase the state size of the mainet as fast as possible and be able to simulate what will happen if mainet in a matter of year or two will increase its state size to x of what it is at current state and yeah we achieved that we have a network right now on which we have mainet shadow fork but the state is basically duplicated it's twice as big as actual mainet And because of that we are able to test scenarios on mainet shadow fork and 2x mainet shadow fork and compare what are the performance differences and if we have anything which will be like growing linearly but maybe in some logarithmic way it will be getting four times slower

while having two times bigger state. So we have a lot of different tools, different opportunities right now to benchmark our scenarios and our EAP proposals which will be able to be having some kind of preconditions to be met to be able to be included in next fork. Yeah. And as on the slide you can see right now we also focus on some syncing test because the 2x state will affect for sure the processing part of the blocks but also we need to take a look how the syncing part will perform during that state and if we'll be able actually to sync at all or what will be happening if we'll be syncing to such chain which will be under heavy attack with some high gas limit and very stateheavy scenarios. if we'll be able

to to sync at all, if the healing part of the node will be processed properly, etc. So you have a link right here where you can actually see how the EL client implementations are doing on this perfet 2. And yeah, right now we are focusing on testing some the most of the heaviest scenarios from mainet we know like for example contract executions on the on this 2x inside mainet network to see if it will be an actual problem moving along or we should keep an eye on that and maybe make some additional improvements to the E client implementations.

>> Yeah, thanks. Um yeah, so we also have about two to three different types of databases in Ethereum. So we have the flat style database. We have yeah hashbased databases and we have to also make sure that all of these styles can keep up so that we're not vulnerable to any one type of attack. Yeah. So there's a lot of information that you can find on the syncor tool for syncreated information and for bloatet.info there's the status team at the EF that is doing a ton of work. What metrics are important? What types of attacks can exist? How do we quantify these attacks?

How do we get a two times mainet state size? Can we print information about the tree or the internal tree representation of a client via some sort of logging mechanism? So, they're trying to get all of these metrics visible to us so that we can start identifying where things are going to be a problem. The next large topic is security and attacks. So, gas limit increases actually also have a huge effect on consensus layer blocks. So we need sort of a holistic view of how one affects the other. A simple example is if you have a very massive execution layer block that still needs to be gossiped on the consensus layer peer-to-peer layer. The consensus layer peer-to-peer layer also has size limits.

So if it's bigger than the size limit then it's not going to be gossiped which will become a problem. So in order to enumerate all the different dependencies we have this one interactive website that we've built. It's on the eastband hops repo if you want to look at the codebase where you can specify different types of attacks. So like Tony's call data attack you can specify what repricing has happened. So you can say Fusaka repricing has already happened and then you can play around with what the gas limit is and see what the different limits are and see if any limit is being hit. So this allows us to sort of get a multivaried view of everything that's happening from this specific type of attack. There's another

one that we found at bull interrupt which was a receipt size limit on the peer-to-peer layer. This is also fixed with E70 but we still need to deploy E70 on mainet. It doesn't affect us at the current gas limit but it is a bottleneck that we know for a future gas limit. A lot of time in bulop was actually spent writing new attacks and tests for east. A couple of them were the ones that Camille mentioned that required us to repric mod x again. So had we not gone through this effort, we might have shipped Fusaka with a ModX pricing that would have bottlenecked us down the line. So this effort is sort of speeding up finding bottlenecks. So we proactively can do it and we don't have to wait for changes later on. We are rewriting a lot of attacks to make sure

that they take into account refunds as well, which is something that wasn't always done in the past. And yeah, we still have a lot that's in the pipeline that we just can't reveal today. And I think once we're patching them and we go beyond these restrictions, you'll also see a lot of our writeups and blog posts on what these different attacks are. And maybe a bit on what the path forward looks like. So we do want to safely increase the gas limit. So mainet has been at 45 million for over a month now. If you were to compare this to some point last year, I think we're talking about almost a 50% increase. The bottlenecks of 60 million have mostly been solved at least as of AC/DT that happened on Monday. So we're bringing up the topic on ACD if not this week the next week to figure out a rollout plan

that takes into account Fusaka. So we also want to make sure that we're not increasing the gas limit one week before Fusaka and if something goes wrong then we can't put our attention into Fusaka, right? So we also have plans for 70 80 100 million and systematically we'll address each topic each bottleneck and then as soon as that's done we'll have E releases CL releases updating the default gas limit. We'll have posts and information showcasing what the new safe gas limits are and validators can set them on their client software or just update their releases and then the blocks will slowly vote their way up to a higher gas limit. A couple of things we do want to mention is the gas limit scaling efforts will always take into account blob scaling efforts as well. So

any analysis on blob counts is assuming that the gas limit is already higher than it is today. So we're not kneecapping ourselves on anyone's side. And it's also only going to be recommended once it's clear that the average home stake can also support it. So we're not increasing the gas limit to such a drastic degree that you can't run a node at home anymore. And yeah, there's a lot of work that Sophia and everyone in her team is doing with ZK that will be leading the path beyond like 120 million. And yeah, I think they can also talk a lot about it as and when it's ready. Yeah, thank you. I know Sophia, if you wanted to expand on what's happening in the ZK world and how that fits in, then I think this is also the perfect time for that.

>> Yeah, I take a step back, right? I think this is like a kind of odd ea at least to schedule as part of a hard fork rate and the primary motivation for doing that is that it's to understand that it's quite a lot of work for EL client devs and and and everyone doing testing like eth panda ops right so and especially with there not being a very large execution layer feature scheduled for fagano you know we thought this would be one of the biggest things that would occupy their time and you know wanted to make that understood so This is largely the stage in scaling that we think of as sort of like just good oldfashioned engineering work. Though that said, I think that the EL clients already have been quite performant for

some time and it could individually handle much higher gas limits and as you know Perry and Camille have been talking about this is largely about identifying DOS factors and mitigating those either through client implementations or some features that will also go into FAKA and also the peer-to-peer release that will come along with it with the E70. And I think that's like important to point out because Ethereum is largely unique in really caring about the worst cases and uh um that's quite important I think you know for uh for livess the chain and you know for the the user experience right you know the an example of that I suppose is the large execution layer EIP that's scheduled for glamsterdam the fork after

fusaka which you I'm sure you'll do an episode on uh block access lists you know one obvious way that you would increase the amount of compute you can do in a given amount of time. Execution throughput is through by parallelizing execution of transactions, right? Um, and I think that some Ethereum execution layer nodes already do that. Many other chains already do that, right? But if you think about they're doing that optimistically, right? So the worst case is they all touch the same state like you have say all transactions that are swapping to the same DEX pool or something and you have to execute them all in parallel. So for what we care about and Ethereum that doesn't matter as much and block access lists essentially what they give you is best case becomes the worst case right

because you're you're provided with the state validators are provided with the state and the state access patterns for each transaction by the builder right so that's that like segus into we sort of think of scaling as sort of three things one being this sort of work which is just a lot of grinding by engineers and and and and and DevOps people on testing, right? Then we also think of protocol changes uh that can enable more scaling through traditional execution like block access lists like forms of what's called pipelining like APBS.

We're also we have scheduled on that the consensus layer for Glamsterdam. But that also gives you more throughput on the execution layer by essentially giving you more time to execute. Right? right now you've uh very little time relative to the uh entire slot to actually execute the transactions and then we think about and we've typically put this as like very short-term medium-term and long-term scaling I think in reality these three streams will all kind of go together certainly in terms of the work being done and maybe actually in in production as well but the the third phase of it like Perry mentioned and was on the last slide is with ZK right this is with the validators who are testing blocks or

cryptographically signing them to say that they're valid. Instead of actually executing them again, they will verify a cryptographic proof of their of the block's validity, right? And so what that will do is it fully decouples the throughput from the amount of work that a a tester or anyone running full node say as a wallet backend is doing. So I think something important here is that we are scaling without raising hardware requirements for validators right or validators or full nodes anyone who wants to to follow the chain and this is like an age-old question in blockchains it goes this is what the Bitcoin block size wars were about do you want more throughput at the expense for less you know more centralization in terms of who

can follow the chain higher hardware requirements we have also anformational EIP that I believe Kev who is in the audience here as the author on I I don't know if you did a episode on this but that defined reference hardware for validators as part of all this work we won't be changing that right this is all achieving more throughput with the same hardware through you know engineering improvements or protocol level improvements with ZK that effectively completely decouples that hardware the hardware requirements from the amount of throughput that you can get because it's more about the the amount of transactions that you can amount of gas that you can prove in a given amount of time so that actually would allow ow us to even lower those hardware requirements to the meme that Justin

Drake has been saying is a smartwatch or Raspberry Pi effectively like absolutely minimal because proof verification is constant time they're constant size relative to the the amount of compute being done and that they're quite fast to verify something on the order of like 100 milliseconds per proof. Thank you so much Sophia for adding more context to it and all the work about ZKVM team and you all are doing around these proposals. Definitely it helped making other proposals. You mentioned about model EXP and I would agree to your statement that Ethereum is unique in its own way. We are considering so many things that perhaps are missed by some of the other blockchains or the lady blockchains but that's what make

Ethereum one of the best blockchain. Thank you par for this great presentation. Camille for adding all the relevant information from the client development side about the perf nets and other dubnets. Those are there in place to make these testing. So you guys have already like kind of tied all loose ends. Not making room for questions. A lot of questions here. But we are great audiences and we do have a bunch of questions for you. Yes, Kev has done that episode on the hardware requirement. It is episode number 145.

So people if you have missed it, it's a very good episode to learn about what is the present hardware requirement to run a node and learn where we stand. From the question side, I believe Kev has some questions. Kev, if you would like to maybe share it with guest. >> Yep, sure. Yeah, my first question was is scaling the gas limit blocked more by the RPC like use cases or the block validation use cases right now? >> I can take on that. So yeah, for now we are focusing mostly on the blog validation side, but nice that you mentioned the RPC because we are in progress like currently building a tool for testing the performance of RPC because we don't want only to increase

the gas limit and only take care of the block validation part of this problem but we know that it affects plenty of other things which and RPC and tracing of the blocks etc is one of the things which we need to take much closer look than we are doing right Yeah. So yeah, for for now we are focusing mostly on the block validation and we are setting some thresholds which we want to to follow. So it's none of the client implementations is processing the block for longer than three maximum or for of 4 seconds for now and RPC is something we will be focusing alongside right now.

>> Yeah, one of the critical things is also that especially with attacks, it's a bit easier to come up with attacks that would trigger the validation pipeline. There aren't necessarily that many attacks for the RPC pipeline because that's very specific to use case. So benchmarks at least for now have been mostly focused on block validation also because on Ethereum you have about 4 seconds for a validator to attest. And while of course we're also thinking about full nodes and not just validators but validators are a critical piece of the puzzle. The gas limit is kind of a function of how much gas you can process per seconds times a upper limit of 4 seconds. So if you're able to do minimal

gas for the worst case test that we can write of let's say 20 million gas per second that means you can realistically do a 60 to 80 million gas limit. Anything more than that basically becomes impossible. >> Thank you. I guess these numbers that you mentioned 70 million to 120 uh this is all assuming 12 second blocks. >> Yeah, exactly. So this is uh definitely still assuming 12 seconds blocks. It's still not assuming block level accessless parallelization benefits or EPBS pipelining benefits or any of these things that Sophia just mentioned. This is just purely things that we can get away with up until Fusaka or shortly after Fusaka before Glammad. Glammadam's

also bringing with it a lot of repricings whole effort that Maria from the EF is largely leading where we're kind of looking at gas with a fully holistic picture and making sure that we're not pricing anything wrong. So all of these bits and pieces are going to fit together so that we're better utilizing block space and block space per time in the future. But yeah, that's a high level of what we're thinking of. >> Yeah, just to add to it, very important thing is that we focus right now on current specification of mainet. But we also have some efforts to test the Fusaka. I didn't mention that before, but we have a way of testing for example modex free pricing and how it will look like after the fork. And moving forward

it it will be important to know to have like two two separate numbers what will happen on current fork and what will happen on the upcoming fork. We kind of have that right now. But as say tools are very quickly evolving this changes but this is like a really important requirement for the tooling. >> And one of the kind of other side effects of working on gas limit increases has become that now that we have someone explicitly looking at repricing. They look at repricing having an exhaustive list of benchmarks. So you can tweak prices based on whatever theory, model, whatever you have. And then you can run it through the benchmarks and make sure that you're not introducing a new attack vector somewhere else. So it's kind of one of these things where now that we've put in

the work, it's paying off across other dimensions as well that we didn't necessarily expect when we started the work. I also should say that if or I'd rather say when we uh lower the slot time, we will likely at the same time adjust the gas limit to say if we're having it to 6 seconds, maybe have the gas limit. Uh because as Perry said, it's really a function of gas per second, understanding that that's not just about the slot time, but also what is going on within slot and which can also be changed. >> That makes sense. And are you guys seeing a trend towards the client implementations becoming less diverse just because they need to choose the fastest way to do things?

>> I think as of now at least talking about 60 million I don't think we've seen this. It's actually been very impressive looking at how clients are approaching the problem. There was again a concrete case of um with modex. There was a bottleneck on uh get and switching to the same library that Aragon uses might have been the fastest way forward but the get team instead spent time forking a library that will in the future they try to get upstreamed the changes and they've managed to get speed up that they hoped for and I think it's going through the hardening process and will eventually get released as well. The bezo team is doing something similar. I think they had a bottleneck in big library so they've decided to write

their own and I feel like this is a good example of Ethereum also not just always not choosing the easy path we're kind of choosing the path that we think will be resilient and set us up for success in the future rather than just yeah flipping a switch and then increasing a number >> right yeah that makes sense I think it'll be interesting to see how where client implementations stay diverse as we go towards 120 million And I guess also do you guys have a way to measure the bandwidth uh limits or bandwidth impact on increasing the block or is it just bundled with the blob increases?

>> So we don't explicitly measure block versus blob amounts of bandwidth we can. However, most blocks aren't really that big on Ethereum. You get big blobs by stuffing it with call data. except we've made call data relatively expensive because we've moved all of that stuff that uses the call data into blobs. And if you were to just do for example zeros in call data then that's very compressible and it doesn't show up as massive on the peer-to-peer layer. So you can create really big blocks. The blocks will take a different propagation path than blobs do. But that being said it's not a massive bottleneck at least right now. It is something we can measure but for now we measure

holistically. So it's always blobs and blocks together. >> That makes sense. Yeah. I guess my last question is related to the number of bugs that sort of pop up with the client implementations changing so fast in order to accommodate for increasing gas limit. Is this a trend that you're seeing or is it or maybe not recording it? The actually if I can if I can chime in on that we don't see like actual increase of bugs in client implementations because of the multiple tools which we have right now for testing the result of that we have a early reporting of any kind of issues.

So for example we have gas benchmarks when where you can verify if the actual improvement works and uh for the testing of the improvements we are suggesting all of the E clients to use very separate branches. So we kind of introduced a a standard where every EL client have a performance branch and they are they can go crazy on those branches and test whatever they want but they don't want to move it very fast to to their main branches right so they are testing on those branches whenever they feel confident that this is actually giving the performance improvements and they can merge that but on top of that we have the perf devets which are running also on those performance branches so we have like performance

performance branch which is used for benchmarking and then the very same branch with the very same changes is used on the computational branch which is mainet shadow fork and on a blo net which is mainet shadow fork with twox state. So we have like two living networks which are testing those branches with those performance improvements and we are also doing some different tests on on those. So we are covering much more scenarios than we we will do in normal path with just improving some some of the performance loss on clients and just pushing them to the main branches. So it's like quite well covered. There is a lot of issues which are popping out in in this way.

But this is like supposed to happen. But as long as it happens on on this site also on performance branches and is being fixed before it's being included on main, it's completely fine because this is like the purpose to experiment and improve the performance of clients. Sorry, I have one more question. Uh on bottlenecks, uh where do you see the majority of the bottlenecks? Is it in state root computation? Is it in the EVM pre-ompiles or Yeah, >> say I'm not sure if we should talk a lot on where the bottlenecks are right now, especially those not not yet publicly spoken about, but uh it is very specific to each client implementations like each of the client is using like the different languages except GF and argon, right? So there are some language

dependencies which which are making clients a little bit slower on some paths or clients are needing to rewrite some libraries like we heard about uh bezu rewriting begin uh never mind also have a it's its own implementation for in 256 right so yeah this is quite often the language limitations where we need to overcome that in some different ways >> I'd say so far we haven't found any like one bottleneck across clients at least for the short-term scaling road map. I do think for the long-term scaling road map these exist and stuff like pipelining block level access lists are meant to address them but like Sophia

mentioned we had a lot of headroom that was available here and there and we're basically just doing the engineering work of getting us to utilize that headroom. I think stuff like a holistic bottleneck similar to state root computation we haven't hit that yet. >> Thank you. All right. So these were all technical questions very well answered as well. I have one basic question. In the presentation you shared about the past gas changes. What were the blockers and how team arrived at this number for this EIP? But in the past gas limit changes were handled informally before or after upgrade. So as authors, why was it important to document this change as an EIP as well as how do you see this

formal coordination help among all EL clients? >> Well, I think this comes back to what I mentioned about the primary reason is because of the amount of work that it would take from the execution layer client devs, right, as part of this hard fork cycle. One secondary reason is to just coordinate that all the default configurations in the clients would be updated at the same time even you know that level of coordination over this many clients hasn't always been easy in the past but I think it's important to note that the mechanism for changing the gas limit uh remains the same right so we really talking in terms of the actual concrete change to the number here just a change to the default configurations that come with client releases it is

still up to block producer validators in the role of as block producers whether the gas limit goes up. So that is to say that yeah it's not a change to the mechanism in which we're changing the gas limit. It is more of a rep prioritization of our sort of technical things that we're doing on a at a more protocol level and at a research level as well. Yeah, it's kind of like saying once this is an EIP that has been set, if there were bottlenecks, then clients have to prioritize fixing those bottlenecks as well. And it allows everyone to allocate resources a bit more carefully. Since this has been included, since this is a information EIP that will go into the fork, if a client team needs to allocate some resources to rewrite a library, then

this gives them more credibility to do that as opposed to in the past where I don't know the community is just mad that why can't we ship a gas limit increase and then it's too informal to justify putting in the resources or efforts from an organizational perspective even though it might have still happened. Uh this is just us being a bit more explicit because yeah, we have this approach right now. We want to scale the L1, scale the L2, fix UX and this is kind of helping us scale the L1. >> That is very good to know. I mean like definitely it has been done in the past.

There were different processes but this seems to be way more organized. Raising gas limit generally sounds simple but has always been controversial in the past and as you mentioned it also carries risk like too low, too expensive, too high, hard to run nodes and things like that. So what are the biggest technical risks that you guys are watching like as a team for testing and how are client teams mitigating them? >> So there's a couple right. So the first one is u monitoring if we're opening us ourselves up to attacks. So if there are blocks that are being produced that take significantly longer than expected to validate then we will look into them and figure out why they took significantly

longer to validate. So it's mostly spending a lot of time monitoring and making sure that that isn't happening but besides that I would say the approach is is quite straightforward. Yeah, I I don't think so. If I have more like monitoring and reacting on anything which we don't know but thankfully now with benchmarking we are catching the issues before they actually appear on on mainet. So we are proactively trying to fix them. But other than that we have this monitoring which if pandops is having set up so we can know very easily that there was some block which was taking significant amount of time for some specific clients or for all of the clients.

>> I think that the reason in in an Ethereum context that's been the case has largely been due to state growth rate which is one of the things that that we mentioned that we're we're now monitoring and have a devet for. I think that it is still to be determined how we will handle state growth and there are many possible ways. One could be just making it more expensive to add new state items. One answer is that we do expect in a matter of years full nodes and validators won't need to store the state but it is still a consideration for sure >> right and in the same line like I understand that it may have some effect for running validators nodes. So what are the practical changes uh that will be brought into consideration? Would that be related to throughout fees or

hardware requirement that an individual or DAB builders may have to consider? >> We are hoping not to affect for sure the hardware requirements like the main thing which we are like focusing on while doing any kind of benchmarks is to use the hardware which is actually below the recommendations which we want to set. So we don't want to came up with the performance improvements or some repricings which will cause that the average homestaker will not be able to run a validator. So this is like a number one priority when we set up any tests right now. So from this standpoint this is like a ve very clear that we don't want to to make it any any more difficult or required the node runners to to to switch the the hardware.

>> Yeah. Just a follow-up question. So the hardware requirement EIP will still stand well for all the node runners. Yes. >> Okay. Perfect. Sophia, >> I was just going to say from the standpoint of adapt developer, I think the probably the most significant thing that will change not so much in Fusaka a little bit, but especially following this uh for scaling is that we're changing the price of many op codes. So that will, you know, change how smart contracts are optimized to some degree. Ideally they shouldn't be you know depending on gas prices but but that will you know affect them on an engineering level and then you know of course there is a level where same with scaling blobs we expect um you know to some degree new type of of applications

and new levels of applications to be enabled by having more throughput on on mainet >> that is interesting it's always good to have collect all these information because that's what community wants to learn about very well my uh next question is with respect to the predictability of transaction cost and performance. Do we think that with this change in gas limit a high volume users may see any changes with respect to predictability of transaction cost and performance? Yeah, I think it with more block space it essentially means that if there are more things happening on Ethereum that each unit of thing will just be cheaper to do. So that it should be easier for us to handle bigger DAPs

coming online or for the average transaction cost to stay cheap. The other kind of side effect that hasn't been mentioned but is also very applicable that when we started looking at benchmarking we also realized that this is something that other L2s have been looking into. They had their own benchmark suite and we're working with them to try and sort of coales benchmarking suites into one format one approach so that bottlenecks we're finding and identifying on mainet can also be removed on layer 2. We also will get better insights into state growth.

This is something that is worse on L2s and they solve differently. But us thinking about it about thinking about scaling doesn't just apply to cheaper costs for the average user on the L1 but it also applies on the L2. >> This is really good news. My last question for today is how can enterprises give feedback or participate in testing before the Fusaka upgrade or before this EIP moves to the final status? One of the things would be that the benchmark tests themselves are all open source. The guest benchmarking tool Nethermind uses is also open source. The fixes or changes that the clients are making also open source. The performance branch is very straightforward. You can do a diff between performance and master

and figure out what the changes each client has. So if you're an enterprise user, enterprise person who is very technically knowledgeable, then please look into the changes. make sure that we aren't missing any attacks, make sure that we're not noticing overseeing something like validate our approaches would be phenomenal. >> So are they invited to participate in testing in any way >> directly? >> That would be great. Yeah. Uh please submit ideas. One of the nice things about this whole approach is it's all just using the execution specs test format. So east which means if you're able to write a benchmarking test you can actually also write a test for any EIP for anything that we're going to deploy on Ethereum which is in itself a

great skill to have. >> Awesome. So Ethereum is moving forward with collaborative effort. We are inviting everyone to join participate and help make these EIPs run on the Ethereum mainet and that do successfully. Well that wraps up today's episode of Penip. A big thank you to Sophia, Partosh, and Camille for joining us and sharing your insight on EIP7935 and the upcoming Fusaka upgrade. Dear listeners, if you have found this discussion helpful, don't forget to like and subscribe. You can catch all previous episodes in the playlist of PEP. Follow us on Twitter at EC Institute to stay updated on new proposals and future episodes. Thanks for listening and until next time, keep

learning, keep building, and keep peeping into EIPs with us. This is Puja and then signing