# Outsider's View: Increasing the Gas Limit

*Digestible Core Developer Content*

By [Order and Flow](https://paragraph.com/@oflow) · 2024-02-09

ethereum, ethereumdevelopment

---

![](https://storage.googleapis.com/papyrus_images/b24595345f820442503a7ac939c7eded.png)

Ethereum development for the average crypto twitter user.

For many users, L1 development may seem like a black box, especially for Ethereum. While the ETH Foundation puts in a lot of effort to keep development progressive and decentralized, for an outsider it's a lot like reading scientific/technical papers. While most of their resources to understand Ethereum are out in public, Ethereum has nearly a 10-year trail worth of discussion for protocol development. Although most resources to understand Ethhereum are publicly available, they are written for those who are already familiar with the fundamentals. These posts will attempt to showcase what is in the Ethereum core developer/mechanism design mindshare.

[Subscribe](https://paragraph.xyz/@oflow/memberships)

▼**Terminology**

*   Block size: Maximum amount of computational work that can be done in a single block. This is not fixed at a size like BTC, but rather variable with gas.
    
*   Calldata: Input data sent with a transaction that tells a smart contract how to execute.
    
*   EIPs: Ethereum improvement proposals, suggestions for improvements to the Ethereum network, and can be proposed by anyone.
    

### **Increasing the block gas limit**

Ethereum's gas limit is what decides how much can be done in a single block, the higher the gas limit the more transactions can be executed per block. The block gas limit has not changed since [EIP-1559](https://help.coinbase.com/en/coinbase/getting-started/crypto-education/eip-1559) (released 3 years ago). The capability to increase or decrease this limit is in the hands of the stakers. Block size, however, has only grown, especially over the past year where block size doubled.

![](https://storage.googleapis.com/papyrus_images/75c0db579a0def818ded50588cedfcdd.png)

Source: [My Dune.](https://dune.com/jevil/ethereum-aggregate-dashboard)

**There are risks for gas limit increases as well.**

Missed Block Rate: This metric represents the total number of slots where a validator failed to produce a block. This happens if validators are offline or opt out of proposing in their allocated slot. Increasing the block gas limit may increased missed block rate for nodes that are under-provisioned.

State Size: Increasing the gas would also accelerate the biggest problem for scalability, state size. It is not necessarily the size that is the problem, rather there is a problem with accessing/modifying this data. Larger state sizes mean that operations onchain would become slower due to increased timer equired to read from and write to the state.

History Size: This is the historical data of everything recorded since the chain's inception, every transaction, block, and smart contract execution. Transaction count has more than doubled within the past three years, leading to increases in full node size. Increasing the gas limit would make history size increase faster and thus contribute to increases in full node size.

There's been a lot of discussion about increasing the block gas limit, perhaps in response to the criticism about Ethereum being slow compared to Solana. On Twitter, Vitalik made a comment saying that the block gas limit can be increased by a validator vote at any point. Then over an Ethereum Core Developer AMA on Reddit, there was further discussion. General consensus among core developers is that they are willing to increase the gas limit as long as there are incentives in place to keep data and other transactions on other layers (i.e., certain transactions/data should move to rollups)

[![User Avatar](https://pbs.twimg.com/profile_images/1115816977061351424/HdvT_PLp_normal.png)](https://twitter.com/dankrad)

[Dankrad Feist](https://twitter.com/dankrad)

[@dankrad](https://twitter.com/dankrad)

[![Twitter Logo](https://paragraph.xyz/editor/twitter/logo.png)](https://twitter.com/dankrad/status/1745406611202437356)

I am for increasing the gas limit, but we need to be more careful.  
  
I think after 4844, the best way to do this would actually be:  
\- Increase the execution capacity by increasing the gas limit BUT ALSO increasing CALLDATA cost (ETH L1 is for execution, not data)  
\- Increase the…

[![User Avatar](https://pbs.twimg.com/profile_images/1575685906786402304/P5UbjDt6_normal.jpg)](https://twitter.com/adietrichs)

[ansgar.eth 🦇🔊 .oO](https://twitter.com/adietrichs)

[@adietrichs](https://twitter.com/adietrichs)

[![Twitter Logo](https://paragraph.xyz/editor/twitter/logo.png)](https://twitter.com/adietrichs/status/1745183445628699129)

That’s a framing of the upcoming Dencun update that I haven’t seen yet - given that the blob data will be in addition to the existing block limits, it is equivalent to a raise of the gas limit by ~11M, just with that gas reserved for L2 data.

 [![Like Icon](https://paragraph.xyz/editor/twitter/heart.png) 305](https://twitter.com/dankrad/status/1745406611202437356)[

6:25 AM • Jan 11, 2024

](https://twitter.com/dankrad/status/1745406611202437356)

This discussion transitioned to [ethresearch](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567?u=nerolation) later with notes and design considerations for a possible increase. A few different ideas for solutions have came up.

### Proposed Solutions

1.  **Increasing calldata costs.** Raising these costs allows room to be made for a change in the block gas limit. Rather than straight up raising the block gas limit, thus increasing block size, and then we encounter all the risks aforementioned, calldata can be disincentivized for the L1. **Raising calldata price allows more room to be made for the block gas limit without increasing the block size. However, there could be downstream effects for STARKs.**
    
2.  **Increase calldata and decrease other costs.** Same as above, except ETH R&D specifies a few specific cost drivers for gas usage. This approach is the alleviate ZK L2s like Starknet. The goal is to lower costs just enough so that proof verification from Starknet is not overshadowed by the increased calldata gas price.
    
3.  **Simple 2D calldata pricing. This is** [**EIP-4488**](https://eips.ethereum.org/EIPS/eip-4488) **(stagnant development). Could cap the calldata per block, turning it into a strictly scarce resource.** This keeps block size relatively bigger compared to the two solutions prior.
    
4.  **Full 2D calldata pricing.** This is creating an EIP-1559 for calldata specifically, this would look like blob transactions in the sense that blobs are a separate resource from gas, in this type of market, the resource while separate from gas is priced in variable gas which adjusts so that the number for that resource hits a target (in the long run).
    
5.  **The Loyalty Bonus.** This would compensate protocols that need to spend on increased calldata costs. This proposal aims to balance the needs of applications requiring a lot of calldata (ZK applications). In this proposal, applications that require large amounts of calldata but do not accomplish much onchain computation could face higher gas costs, encouraging optimized data usage.
    
6.  [**EIP-4444**](https://eips.ethereum.org/EIPS/eip-4444)**.** This EIP is history expiry, and it essentially allows Ethereum clients the capability to prune their historical data (headers, bodies, and transaction receipts) older than a year. This means that historical data older than a year is no longer passed around between nodes. **This is an indirect impact to a possible increase in the gas limit, as it makes one of the risks a lesser problem than before.**
    

If you do like reading all the mumbo jumbo, here are some pretty good aggregate resources to check out.

[Subscribe](https://paragraph.xyz/@oflow/memberships)

▼Sources

[On Increasing the Block Gas Limit](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567)

[On Block Sizes, Gas Limits and Scalability](https://ethresear.ch/t/on-block-sizes-gas-limits-and-scalability/18444)

[Testing path for a gas limit increase](https://ethresear.ch/t/testing-path-for-a-gas-limit-increase/18399)

---

*Originally published on [Order and Flow](https://paragraph.com/@oflow/outsiders-view-increasing-the-gas-limit)*
