# Gas Limit and Block Execution

- Speakers: [MarekM25](https://streameth.org/speakers/marekm25)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-15
- Duration: 23:06
- Watch: https://streameth.org/watch/6736c52f9dbb7a90e1893847

## 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.

## About the speakers

### MarekM25

Team lead @nethermindeth, working on @ethereum


## Transcript

Marek. Test, test. Okay. Hi, I'm Marek, Ethereum Curve developer from the Nevermind 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 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 show that there is a significant untapped 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 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 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 a powerful variable. Increasing it leads to more transactions, more applications, generally greater crypto adoption. However, it has to be adjusted carefully because it might impact decentralization and security. 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 usage, this stems from two things, history grow and state grow. History grows much faster than state. However there is 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. Networking, so larger blocks are more challenging to propagate and allow for more transactions. So potentially it will increase load on mempool. Other things, so increasing gas limit effects, syncing time, RPC, proof sizes for the future light clients, size of archive notes. 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 controls gas limit? So validators of course can vote for the desired gas limit. However the block gas limit cannot change, cannot increase or decrease by more than 1 over 1,024 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 35 million is the correct gas limit for Ethereum, you can set this value in the config and in every block you will move slightly in this direction. However, other validators can counteract it, bringing it back to 30 million. And this fact was used in EIP proposed by Giulio from Eregon 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 with increases. So the control over gas limit can be divided into categories, local block building and external block building. Approximately nine percent of validators are local builders. In this case, execution client teams can set the default gas limit in the config, which can be overridden by node operator. Most of the blocks are externally produced, around 91%, and in this case, consensus client teams can set the default gas limit, which can be overridden by 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 Twitter conversation about increasing gas limit and that we should increase hardware requirements or we should make EVM much faster and parallel and scale L1 in this way. Of course, we should try to optimize things as much as possible there are many reasons there are many reasons to do so future potential of l1 l2s rpcs however let's analyze the block execution performance on my mini computer intel nac 11. so as you can see on the charts this device can execute blocks with the average speed around 330 megagas 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 a much more expensive machine, four times more expensive, used by one of my colleagues. four times more expensive used by one of my colleagues. And as you can see, blocks are being executed almost three times faster with the average speed 950 megagas per second, and execution time is around 17 milliseconds. So at first glance, the discussion about hardware requirements seems relevant. Many computers are three times slower than the 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 suggests huge potential for mainnet, and however, we know that if everything would be that easy, we would already have much higher gas limit. Earlier, I mentioned that I'm talking about block execution a little bit in isolation from other topics. And 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-second slot time, it doesn't mean that we have 12 seconds for execution. This is an obvious thing. And even if we ignore networking aspect entirely, nodes need to be able to catch up with the tip of the chain. What'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 four seconds, however, ELs have much less time to process new blocks. First of all, there is lightweight validation on CL side and blocks need to be propagated across the network. Moreover, blocks often aren't revealed at the beginning of the slot due to timing games. And the solution to this is to reorganize Ethereum slots in such a way to allow for more time for execution. We have two solutions under consideration, EPBS, enshrined proposer builder separation, and APS, att Proposer Separation. While the main goal of those changes is related to block building and MEV space, there is additional nice benefit on the execution side that we will have much more time for execution. I will use EPBS as a primary example. However, both solutions will reorganize the slot in a more optimal way. So, in EPBS, attestation deadline is set at third second. However, attesters will have even up to 11 seconds to execute blocks without affecting consensus rules. So this is very useful in context of worst cases. Okay, other thing that we should consider is, of course, state growth. So with the current gas limit limit state doesn't grow rapidly. In the last three months it has increased four gigabytes in a Nethermite database. If you want to read more about state grow there is an excellent research from the Rev team. However the worst cases of most of the operations is essentially function of block size. 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 the tree gets, the slower state access may become. So clients spend a lot of time trying to optimize things related to state. So here is an example from Nethermind, and operations are dominated by Sload and SSStore. Another example from Bezu bezel and similar situation and ref seems to be 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 vertical or something post-quantum secure if there is a 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 Erigon team has shown, even if we double gas limit and ship Verkul in four years, the transition will take additional 13 days, which doesn't sound like a very bad solution. Long-term solution for Verkulz is of course state expiry and recently Vitalik 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 required to do so. So we need to take into account contribution to state grow and history grow. And recently Vitalik proposed that we should increase gas prices for hashing functions as blocks that are heavy with hashing are harder to prove than average blocks. with hashing are harder to prove than average blocks. So we benchmark different operations 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 repmd precompile, it executes with the speed 1 giga gas on a very slow machine. If we do the same with simple if transfers, the speed is around 700 mega gas per second. However, other operations can be even slower. EC recover, 80 Mbps. Point evaluation precompile, 65 Mbps. So this is important because the slowest operation should be treated as a bottleneck for increasing throughput rather than relying solely on average execution. So let's talk more about worst cases. Client teams are improving and being better and better on executing 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, 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 NAC11. As you can see, the 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 that are observed on real networks are mining contracts. So those contracts work in this way that they are doing a lot of storage writes 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 ban proposed an EAP to prevent such situation EAP-7778, prevent block gas smuggling. So, slow blocks can affect consensus. If attesters won't be able to meet attestation deadline, it might impact, they will miss attestation and it will impact chain health. What else? Slow blocks can affect block production, so the timeout may occur and it might impact aliveness of the chain. And of course, the slower the operation, the more probability for DDoS vulnerabilities. And I'm not saying that we have an immediate concern here. We need to analyse our worst cases, we need to understand them, we need to optimise them, we need to reprice operation that could be a bottleneck for increasing throughput. The long-term solution for gas pricing issue could be a vital 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.5 to 15 million. The increase from 15 to 30 was related to introduction of base fee mechanism, so while gas limit is higher, the gas target is still the same. In the last three years, hardware improved, so it could be an argument to increase gas limit. However, even stronger argument is that Ethereum client software improved massively. So, to summarize, taking disk 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 gas limit a little bit. I see challenges. We cannot forget about state grow, about history grow. We need to reorganize the slot. We need to migrate to another tree. However, all of them seem to be solvable and are planned for in Ethereum roadmap. We need to ask ourselves what data we need, what other problems we need to solve, what the correct gas limit should be. what other problems we need to solve, what the correct gas limit should be. I don't think that we've 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 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. Okay, thank you, Marek, for a great summary of all the factors that can affect gas limit increase. So we have extra time. Let's go through the first question. Please scan the QR code here. Go to the bottom right. You'll see the live Q&A button there. Click there. You can add questions. You can upvote. We'll go by the most upvote race. First question, what do you think about Reth saying they are fastest? Is this relevant? That's a tough question. So, actually, I discussed it with Georgios yesterday, and he got the same question on his presentation, and he said that actually, Nettermind 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. I run Nettermind on my validator. Will parallel EVM ever become relevant for L1 nodes? I think so, but I think it will take time. So if we have multidimensional gas pricing that controls state grow, we could allow for more execution with parallel EVM. What's more, parallel EVM might be important if we kept the transaction, so we will allow, for example, only 30 million gas transaction, and then worst cases are better, basically. So, yeah, I think maybe on some point of time. Okay, the next question is, what's your opinion on pipeline state routes, state routes being calculated with one block delay? I think it makes sense, but I'm not sure if for L1, for L2, 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 mega-gas per second on a node if the node is not in sync with the chain? So, if the node is not in syncing with the chain, I'm not sure about this, but generally NetherMite uses the tooling that monitors new payloads, so we measure the time it takes to execute new payload in NetherMite. 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 for that. Not sure. Next question would be, why gas per second if each operation have different gas use? Did you think opcode per second makes more sense? Why gas per second if each operation... No. I think there is a problem with gas pricing. So ideally, gas pricing should represent the correct resource usage, but we have, as I showed in this presentation, we have operation that doesn't follow that. So, yes. I think we should still use megagas per second, but we should maybe improve our gas pricing in EVM. Cool. We have about three more minutes, so if you guys have more questions, please feel free to submit. But the last question we have here is, what do you think about increasing time spent on signature aggregation to allow faster finality instead of gas limit increase? Oh. I don't know. Sorry for not answering this question. Signature aggregation. I have no opinion. Cool. We have two more minutes left.