Unify block gas limit and size limit

[murbard]

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.

[KevinMehrabi]

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.

[rafoo]

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

Should the block size limit be folded into the gas limit?

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.

[murbard]

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.

[murbard]

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

[vbot]

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