# Unify block gas limit and size limit

**URL:** https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381
**Category:** Research and Development
**Created:** [June 25, 2021, 11:10pm UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381 "2021-06-25T23:10:48Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![murbard](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/murbard/32/67_2.png) [@murbard](https://forum.tezosagora.org/u/murbard)
#### Post date: [June 25, 2021, 11:10pm UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/1 "2021-06-25T23:10:49Z")

</div>

A baker creating a block must currently optimize for two limits, the size limit of the block and the gas limit. While heuristics for the multiple knapsack problem are pretty good, this tends to complicate matters a bit.

For instance, if gas were the only metric, a baker could order transactions by fee/gas and include them in this order, a pretty good heuristic. This is much more complicated with two constraints.

The reason for the size limit of a block is that it takes time to download, and takes up storage space. The first constraint can actually be subsumed into gas, by determining the gas cost incurred to download the block on some baseline Internet connection. It doesn’t fully capture the cost of storing historical blocks, but storage is typically not the limiting factor.

Note that the size limit per operation, which does not affect bakers directly, can be kept in place.

---

<div class="post-metadata">

### Author: ![KevinMehrabi](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/kevinmehrabi/32/2382_2.png) [@KevinMehrabi](https://forum.tezosagora.org/u/KevinMehrabi)
#### Post date: [June 26, 2021, 10:41pm UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/2 "2021-06-26T22:41:25Z")

</div>

Having conducted literally hundreds of 1-1 onboarding sessions in the last last few months, I not only agree but I can add that this has been one of the most frequently expressed points of friction/confusion for newcomers.

---

<div class="post-metadata">

### Author: ![rafoo](https://forum.tezosagora.org/letter_avatar_proxy/v4/letter/r/f08c70/32.png) [@rafoo](https://forum.tezosagora.org/u/rafoo)
#### Post date: [June 27, 2021, 2:20pm UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/3 "2021-06-27T14:20:14Z")

</div>

I think that you already suggested this about a year ago:

> [@Should the block size limit be folded into the gas limit?](https://forum.tezosagora.org/t/should-the-block-size-limit-be-folded-into-the-gas-limit/2143):
>
> There are currently two limits that apply to blocks: a size limit and a gas limit. The role of the gas limit is to ensure that the validation of a block can be completed fast enough for a node to follow the chain and the role of the size limit is to ensure that the blocks do not consume too much bandwidth and disk space. As a result, bakers need to solve an optimization problem based on two constraints when including transactions (a two-dimensional knapsack). Blocks currently less than full, th…

IIUC, you propose to:

- make some reasonable assumption about the speed of the internet connection of Tezos nodes,
- charge some extra gas in each operation, proportionally to the size of the operation, to account for its participation in downloading time,
- raise the gas limit per operation (because the previous gas increase should not invalidate any currently valid operation),
- raise the gas limit per block by the same factor,
- drop the size limit per block,
- keep the operation size limit untouched.

---

<div class="post-metadata">

### Author: ![murbard](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/murbard/32/67_2.png) [@murbard](https://forum.tezosagora.org/u/murbard)
#### Post date: [July 4, 2021, 6:38am UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/4 "2021-07-04T06:38:30Z")

</div>

That’s exactly much it. Technically, I would actually keep the size limit per block but set its value so that gas is the limiting factor. This may be important so the shell knows how big a block should be at most.

---

<div class="post-metadata">

### Author: ![murbard](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/murbard/32/67_2.png) [@murbard](https://forum.tezosagora.org/u/murbard)
#### Post date: [July 4, 2021, 6:39am UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/5 "2021-07-04T06:39:18Z")

</div>

To be clear, I am _not_ talking about storage costs / burn here and I suspect this might be what you have in mind.

---

<div class="post-metadata">

### Author: ![vbot](https://forum.tezosagora.org/letter_avatar_proxy/v4/letter/v/c0e974/32.png) [@vbot](https://forum.tezosagora.org/u/vbot)
#### Post date: [November 12, 2021, 10:58pm UTC](https://forum.tezosagora.org/t/unify-block-gas-limit-and-size-limit/3381/6 "2021-11-12T22:58:41Z")

</div>

This proposal looks reasonable. And, indeed, I also think that maintaining a clear upper-bound is necessary but bumping it shouldn’t have real issues. I’m unclear on the specifics of the gas costs estimation simulation but we might need to go through it to make sure that we don’t miss anything (e.g. (de)serialization, storage on disk, etc.).
