Right but you can’t stop executing because you haven’t started executing because this scenario is prevented from happening by checks that occur when the block is validated, which happens before the block is executed.
You can’t have the tx gas used go over the block gas limit because:
the tx gas reserved can’t go over the remaining block gas limit
The tx gas used can’t go over the tx gas reserved.
If either of those conditions did happen (although I don’t believe it does in the example we were looking it), it would invalidate the block… but the second condition is impossible to reach because it requires execution, which would never happen because the first condition would get caught in the validation (before execution) and the block would be invalid anyway and so there’d be nothing to execute.
Edit: or are you saying the block builder could intentionally overpack the block and this would overflow the execution gas used, which would lead to a skip? In which case that would mean you’re removing check 1. (Prior paragraph) from the block validity requirements?
There is no sum([tx.gas for tx in transactions]) check in the pre-execution validation. Where do you see what you describe in the specs?
Initially, we only check that the transactions stay within the block gas limit using the inclusion gas, not the max possible (tx.gas)
Then, when it comes to execution, we deduct the inclusion gas from the gas available:
And here, during execution, we make sure every additional transaction, specified by its max gas, still fits into the block. If not, it is skipped (and pays for inclusion):
I see! Thank you for taking the time to walk me through that - my mental model was off.
That is so interesting that you kept the tx.gas < gas_available check but have it in the execution phase rather than the prevalidation phase.
Is the rationale for doing it during execution (rather than earlier at prevalidation) that doing the check in execution lets you waste less space as the average |gas - gas_used| for txs in the block increases?
I am thinking maybe we can run tx validation logic (the logic that invalidate the whole block) in the current slot, and keep the rest of the full execution in the slot after. this way we remove the requirement for coinbase to front the base tx cost (21K) and the calldata fee.
Could you elaborate on that?
The validation logic under delayed exec is performed before attesting. If we want to accept transctions without executing, we can’t tell if the transations are actually executable. Therefore, we must charge someone beforehand, in case a transaction becomes “skipped”. In such cases, the coinbase could have prevented the skip by reording or not including that transaction, thus, it’s not the sender’s fault.
We have this feature in our production blockchain—it definitely helps improve performance.
As mentioned above, all you need during the block proposal phase is to ensure that charges are applied to protect against DoS attacks. Everything else is not strictly necessary. The state root can be calculated after the fact, rather than beforehand.