Yes, though a simpler solution could be to have a variable block size limit. Block builders are capable of adding complexity to their algorithms.
The problem with block constraints is that it results in discrimination, one of the problems this change is trying to address. Gas and gas price (now priority fee) are supposed to be fair ways to evaluate whether a transaction can or should go into the block. Discrimination here means that a transaction might pay a fair priority fee but not be accepted due to outsized calldata. This isnât fair because the transaction is being treated as if it uses more gas than it does, diluting its priority fee. If blocksizeGas is a constrained resource, there should be a market for it, similar to blobgas.
A question that I have here is how much gas is made available for the actual execution of the opcodes.
Currently, that amount is pre_7623 = tx.gas - 21000 - data_cost - create_cost - access_list_cost. If data_floor_cost is the new floor cost of call data (as per this EIP), do we now make post_7623 = tx.gas - 21000 - data_floor_cost - create_cost - access_list_cost available for execution?
If yes, would we be under-funding some transaction executions?
I imagine a scenario where we passed post_7623 gas for opcode execution but during the course of execution, the execution gas used built up enough to cross the threshold. This means that we should really have passed pre_7623 gas for opcode execution. Since post_7623 < pre_7623 we have essentially underfunded the execution in a way. This could be the difference between success vs OutOfGas in some cases.
The computation uses gas_used which is only known after execution. So this EIP can cause out-of-gas after execution would have otherwise succeeded, by retroactively increasing the calldata cost. While the available gas could be computed ahead of time, the spec does not currently do this.
The internal gas of the transaction is computed by taking the higher gas cost, such that 99% of transactions (those donât reach the floor) get more refund.
We must make sure that we donât run out of gas after execution, otherwise clear DoS.
So thereâs a possibility that a transaction that ran out of gas, gets a gas refund. And that it wouldnât have run out, if the refunded gas was available for execution.