A transaction gas limit caps the execution resources that its sender authorizes. A block gas limit constrains aggregate execution in a block. These are related controls at different scales, not two names for the same setting. If execution exhausts its available gas, state changes from the failed execution are reverted while gas already consumed remains chargeable. Some invalid transactions are rejected before inclusion instead, which is a different failure from running out of gas inside a block.

Imagine a contract call that uses 70,000 gas under the state in which it executes. A 90,000 gas limit provides headroom; it does not mean that all 90,000 units will necessarily be spent. Lowering the limit to 50,000 does not make the same computation cheaper. It can make the computation fail before completion. Raising the price per unit likewise does not increase the number of permitted execution steps: the price and the limit are separate transaction parameters.

A simulation observes a particular network state and proposed transaction. Another transaction can alter a contract before yours is included, changing the path it takes. Applications should therefore explain estimation failures and avoid presenting an arbitrarily large limit as a universal remedy. The sender must also satisfy the network's balance and fee-cap requirements. A large authorized budget deserves attention because a different execution path may spend more than the happy-path estimate suggested.