# Gas Limit and Block Execution by MarekM25 | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 22:55
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-L10eJJoTJB4
- YouTube: https://www.youtube.com/watch?v=L10eJJoTJB4

## Description

The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.

Speaker(s): MarekM25
Skill level: Intermediate
Track: Core Protocol
Keywords: Core Protocol, Layer 1, Protocol Design, execution, layer

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] test test okay hi I'm MK ethereum card developer from nether mind team today I'm going to focus on gas limit and block execution there are some voices saying that we've either given up on L1 execution or we need to move ethereum to to Data Centers and eliminate solo stakers to make ethereum successful I disagree with all of these statements I don't want to focus here on suggesting a specific gas limit value instead I want to uh show that there is a significant UNT potential on execution layer and this potential will have to be Unleashed on some point of time at the same time I will point out areas where we need to be careful considering increasing gas limit and I will mention uh challenges and potential Solutions all right let's begin so in 2021 Elon Musk was interested in cryptocurrency and claimed to know how to scale blockchains he mentioned that he discussed with Dogecoin devs to increase block sizes by 10x and uh decrease slot Time by 10x which would supposedly scale Dogecoin by 100x sounds easy right just change one or two variable and we are done so can we do the same for ethereum increase gas limit 10x and reduce slot time 10x yes we can but of course it's not that simple gas limit is powerful variable increasing it leads to uh more transactions um more applications generally greater crypto adoption however it it has to be adjusted carefully because it might impact decentralization and security so there are a few areas when we need to consider when increasing gas limit this cage diss from two things history grow and state grow history grows much faster than State however there's a straightforward path to remove it with EIP for force with the current gas limit State doesn't seem to be significant concern however we need to observe it closely with potential increases um networking so larger blocks are more challenging to propagate and allow for more transaction so potentially it will increase load on mol other things so um increasing gas limit affects sying time RPC uh F uh proof sizes for the future light clients size of archive nodes however today I want to focus on block execution a little bit with isolation from other topics block execution is the main contributor to other Hardware requirements such as CPU or disk speed okay but first of all who control gas limit so validators of course can vote for the desired gas limit however the the block gas limits cannot change uh cannot increase or decrease by more than 1 over 1,24 of its parent block gas limit so whenever you propose a block you can move ethereum in your desired Direction in other words if you think that for 5 million is the correct gas limit uh for ethereum you can set this value in the config and in every block um you will move slightly in this direction however other validators can counteract it bringing it back to 30 million and this fact was used uh in EIP proposed by Julio from Aron team he suggested modifying clients in the way that there is very small increase in every block thanks to that we have a better control what's going on in the network um with increases so the control over gas limit can be divided in two categories local block building and external block building approximately 9% of validators cons uh are local builders in this case execution client teams can set their default gas limit in the config which can be overridden by note operator most of the blocks are externally produced and around 91% and and in this case consensus client teams can set the default gas limit which can be overridden by uh validators however this is not enforced so Builders should follow this but they do not have to so we can say that Builders have the final control over this value so I have seen uh Twitter conversation about um increasing gas limit and that we should increase Hardware requirements or we we should make evm much faster and parallel and scalea one in this way of course we should try to optimize things as much as possible there are many reason there are many reasons to do so uh future potential of L1 l2s rpcs however let's analyze the block execution performance on my uh mini computer Intel knock 11 so as you can see on the charts this de device can execute blocks with the average speed around 330 megag per seconds and blocks are being validated in just 50 milliseconds on average so if we consider higher Hardware requirements let's take a look at much more expensive machine uh four times more expensive used by one of my colleagues and as you can see blocks are being executed all almost three times faster with the average speed uh 950 megag per seconds and uh execution time is around 17 Mega uh milliseconds so at first glance the discussion about Hardware requirements seems relevant mini computers are three times slower than the um high-end consumer machine and there are many machines in between that could be considered however let's pause for a moment ethereum slot time is 12 seconds and we are talking about average execution in just 50 milliseconds so what's the point of using much higher Hardware when we are not utilizing slower machines so this suggest huge potential for main net and um however we know that if everything would be that easy we would already have much higher gas limit earlier I mentioned that I'm think about block execution a little bit if we in isolation from other topics and uh those other things are more concerning like State grow history grow networking aspects however even in Block execution there are challenges first of all if we have 12 seconds slot time it doesn't mean that we have 12 seconds for execution this is uh obvious thing and even if we ignore networking aspect entirely nodes need to be able to catch up with the tip of the chain once's more RPC providers must be able to execute process new blocks while processing heavy if calls and other requests and lastly there is a consensus mechanism so let's take a look at the diagram on the slide ethereum consensus requires strict timing for Block execution the attestation deadline is 4 seconds however El's have much less time to process new blocks uh first of all there is lightweight validation on CL side and um blocks need to be propagated across the network moreover blocks often aren't revealed um at the beginning of the slot due to timing games and the solution to this is to reorganize etherum slots in such a way to allow for more time for execution with two um Solutions under consideration epbs and Shrine proposer Builder separation and APS attester proposer separation while the main goal of those changes is related to blog building and M space there is additional nice benefit on execution side that we will have much more time for execution I will use epbs as a primary example however both solution will reorganize the slot uh in more optimal way so in thepbs attestation deadline is set at third second however a testers will have even up to 11 seconds to execute blocks without uh affecting consensus rules so this is very useful uh in context of worst cases okay other thing that we should consider is of course State grow so with the current gas limit State doesn't grow rapidly in the last three months it has increased 4 gabt in uh nethermind database uh if you want to uh read more about State grow there is an excellent research from The Ref team however the worst cases of most of the operations is essentially function of block so the bigger the block the more operations you can fit in however in case of State we need to be mindful of State database as well so in other words the bigger that tree gets the the slower State access may become so clients spent a lot of time trying to optimizing uh things related to state so uh here is example from nethermind and operations are dominated by load and s store another example from bzu and similar situation uh and ref seems to be um occupied by state root calculation and other thing related to state is that we know that we will eventually need to transition to another tree either vericle or something post Quantum secure if there is sudden breakthrough in research so we know that this transition process will be complex and it will be easier with a smaller tree so we need to be careful to not make this task too difficult with increasing gas limit too aggressively however everything needs to be put in context of data and as Julia from Aron team has shown even if we um double gas limit and ship vericle in four years the transition will take additional 13 days which doesn't sound like very bad solution um long-term solution for verles is of course State expiry and recently vitalic wrote the blog post about it block execution is strictly related to gas pricing gas pricing represents the time it takes to execute the blocks and other resources uh required to do so so we need to take into account State contribution to State grow grow and history grow and recently vitalic proposed that we should increase um gas prices for hasing function as blocks that are heavy with hashing are harder to prove than average blocks so we Benchmark different operations uh and you can see it on the table on the slide we filled the block entirely with one of the operations and as you can see the differences in gas pricing can be substantial for example if we fill the block with rmd precompile it executes with with the speed uh one gagas on very slow machine um if we do the same with simple if transfers the speed is around 700 megag per seconds however other operations can be even slower e recover 80 megag per second Point evaluation precompile 65 megag per second so this is important because the slowest operation should be treated as a bottleneck for increasing frut rather than relying Solly on average execution so let's talk more about worst cases client teams are improving and being better and better on executing uh average transactions however ethereum security must account not just for average case but for worst cases as well and by worst cases I mean situation when optimistic parallel evm encounters as many conflicts as possible when caches are being missed on when attacker found some slow operations in evm and crafted the Block in the way to disrupt the network so let's take one more look at execution times of my Intel knock 11 as you can see the perfect performance on different blocks can vary significantly I marked a few spikes with red rectangles so the average execution is 50 milliseconds but the maximum is 425 milliseconds the known worst case in all execution clients uh that are observed on real networks is are mining contracts so those contracts Works in this way they that they are doing a lot of storage rights and sets values to zero and by setting values to zero they are getting refund and thanks to that they can feed the block with excessive State access so our team member Ben proposed an EAP to prevent such situation EAP 7778 prevent blog gas smuggling so slow blocks can affect consensus um if attest ATT testers won't be able to meet attestation deadline it might impact uh uh they will miss attestation and it will impact chain Health uh what what else it slow blocks can affect block production so the timeout may occur and it might impact liveness of the chain and of course the slower the operation the more probability for dos vulnerabilities and I'm not saying that we have an immediate concern here we need to um analyze our worst cases we need to understand them we need to optimize them uh we need to reprise operation that could be a bottleneck for increasing throughput um the long-term solution for um gas pricing issue could be of vitalic proposal for multi-dimensional gas pricing all these challenges are important but there is other side of gas limit gas limit hasn't been increased for a long time the last increase was done in April 2021 from 12 and half to 15 million uh the increase from 15 to 30 was related to introduction of Bas Fe mechanism so while gas limit is higher the gas Target is still the same in the last three years um Hardware improved so it could be an argument to increase um gas limit however even stronger argument is that ethereum client software improved massively so to summarize taking dis space aside which will be solved with EIP for Force I don't think that the discussion about Hardware requirements is relevant ethereum can be run on mini computers and it will stay in this way even if we increase uh gas limit a little bit I see challenges we cannot forget about State grow about history grow we need to reorganize the slot um we need to migrate to another tree however all of them seem to be solvable and are planned for in ethereum road map we need to ask ourselves what data we need what other problems we need to solve what the correct gas limit should be I don't think that uh we given up on L1 execution and execution is not a bottleneck for scaling L1 of course I agree strongly with vitalik's vision that ethereum mainnet should be a strong base layer and definitely it shouldn't take hyperscaling approach or make any shortcuts all the improvements in the clients and in protocol as well um will benefit l2s allowing them to take hyperscaling approach and use the full potential of evm while ethereum L1 should stay to be a strong secure and decentralized base layer and that's all I want to say thank you everyone pleas okay thank you Merrick for a great summary of the all the factors that can affect gas limit uh increase um so we have extra time uh let's go through the first question please scan the QR code here uh go to the bottom right you'll see the live Q&A button there click there you can add questions you can up vote we'll go by the most up vote first um first question what do you think about ref saying they they are fastest is this relevant that's tough question uh so actually I discussed it with Georgio yesterday and he got the same question on his presentation and he said that actually nether mind is the fastest now and they are kicking our asses so we need to work harder and yeah that is my comment about this I hope it makes sense uh all I I run out mine on my validator um will prow evm ever become relevant for L1 noes I think so but I think it will take time um so if we have multi-dimensional gas pricing that control State grow um we could allow for more execution with parallel evm what's more parallel evm might be important if we cap transaction so we will allow for example only 30 million uh gas transaction and then worst cases um are better basically so yeah I I think maybe on some point of time okay uh the next question is what's your opinion on Pipeline State Roots State Roots being calculated with one block delay huh I think it makes sense but I'm not sure if for L1 for l2s yes but for L1 I'm not sure about consequences for light clients next question is what tooling does nethermind use to measure and Benchmark uh me a gas per second on a Noe if the node is not in sync with the Shain so if the Noe is not in syncing with the chain I'm not sure about the this but but generally nether mind uses the tooling that um monitors um new payloads so we measure the time um it takes to execute new payload in netherite and once we have time and we know how much gas was used in this block we can calculate the speed maybe you can use uh e Shadow for that not sure uh next question would be why gas per second if each operation have different gas use did you think op code per second make more sense huh why I guess per second if each operation no I think I think this there is a problem with gas pricing so ideally gas pricing should represent um the correct resource usage but we have as as I shown in this presentation we have operation that doesn't follow that so yes I think I think we should still use meag gas per second but we should maybe improve um our gas pricing in evm cool uh we have about three more minutes so if you you guys have more questions please feel free to submit um but the last question we have here is what do you think about increasing time spent on on signature aggregation to allow faster finality instead of gas limit increase oh I don't know sorry for not answering this question sign nature aggregation I have no opinion cool um we have two more minutes left uh any