Fundamentos de blockchain
Gas limits and execution cost
Gas meters computational and storage work.
Los artículos de investigación y las referencias se publican en inglés. La navegación está disponible en siete idiomas.
En este artículo
Gas measures work; the fee pays for it
Ethereum uses gas to account for computation and other resources consumed by a transaction. The gas limit is the maximum amount of that work the transaction is allowed to consume. The price per unit of gas is a separate quantity. Confusing the two leads to bad advice such as “increase gas” without explaining whether the transaction needs more execution capacity or a more competitive fee.
A transaction that runs out of gas cannot simply finish the remaining instructions for free. Its execution fails, although the work already performed still costs gas. A contract can also revert for a reason unrelated to the limit, such as an expired deadline or an unmet access condition. Raising the limit does not repair those conditions. Ethereum: gas and fees.
A worked fee example
For a typical EIP-1559 transaction, the sender specifies a maximum total price per gas and a maximum priority fee. The effective price depends on the block’s base fee and the priority fee that fits under the sender’s cap. The base-fee portion is burned. Setting a high cap does not mean the entire cap is automatically charged. EIP-1559 fee rules.
| Input | Assumed value |
|---|---|
| Gas limit | 100,000 units |
| Gas actually used | 70,000 units |
| Block base fee | 20 gwei per unit |
| Maximum priority fee | 2 gwei per unit |
| Maximum total fee | 40 gwei per unit |
| Effective gas price | 22 gwei per unit |
| Execution fee | 70,000 × 22 gwei = 0.00154 ETH |
The 100,000-unit limit is not the amount used in the last row. The 40-gwei cap is not the price charged in that row either. Those are ceilings; the example’s charge uses actual consumption and effective price. Its maximum execution-fee budget would be 0.004 ETH, excluding any value transferred. A wallet may therefore require a balance larger than the eventually charged fee.
Why a successful payment can still be a bad transaction
A fee estimate answers an execution-cost question. It does not establish whether the recipient is legitimate, whether an approval is excessive or whether the user will receive what the website promises. A malicious transaction can execute perfectly and consume little gas. Conversely, a legitimate operation can fail when its state-dependent conditions no longer hold.
Consider a website calling a payment a “wallet synchronisation fee”. Inspect the destination and value, rather than accepting the label. A transfer to an operator’s wallet is a transfer to that operator even if the interface draws it inside a box labelled gas. The question is who receives each part of the payment and what the signed transaction actually does. A screenshot of the quoted fee cannot resolve that question.
Diagnose the failure before changing the settings
Record the chain, transaction hash, receipt status, gas limit, gas used and any available revert information. Compare the actual call with what the user intended. A failed swap caused by a minimum-output condition should lead to a review of price and execution, not an automatic recommendation to remove the protection. If the call is an unfamiliar approval, repeated attempts to make it succeed can increase the user’s exposure.
This example covers an ordinary execution fee. A rollup may charge additional data-publication costs, and blob transactions have a separate fee mechanism. Do not present the table as a universal bill for every chain or transaction type. For practical reading, continue with slippage and checking signing intent.