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, there is no optimization being performed now, but the optimization needs to happen if and when they fill up. This isnâ€™t too big of a problem as there are excellent greedy heuristics for this problem but it is, nonetheless, a small complication. More relevant is the fact that users submitting transactions and wishing to evaluate fees must maintain a model of how typical fees depend on both the gas consumption and the size of transactions.

One avenue for simplifying this would be to adopt a fixed conversion between size and gas. The bandwidth constraint is, after all, rather expressible as a time constraint, and that time constraint may dominate considerations related to block storage.

The downside of this approach compared to the multiple constraint approach is that it is more sensitive to mistakes. A transaction that is underpriced in terms of gas can become size bound, one underpriced in terms of size can become gas bound. There is a belt and supsender effect at play in the current model that would go away.

As an intermediate, it possible to create a block size limit that is lower than the one implied purely from gas consideration but high enough that â€śnormalâ€ť blocks never hit the size limit first and therefore are all purely gas bound.