As computational "work" is required for programs to perform an action or set of actions, there is a cost associated with executing smart contract code and transacting on the Ethereum blockchain. This cost is related to the type and number of computational steps that are being executed. In contrast to Bitcoin transaction fees which only take into account the size of a transaction (kB), Ethereum transaction fees must account for an arbitrary number of computational steps that can be performed by smart contract code. The higher the number of operations a program performs, the higher the cost to run it to completion. Gas is Ethereum’s unit for measuring how much computational "work" a program takes to perform an action or set of actions. Every operation performed by a transaction or contract costs a certain number of gas.
To each operation, a fixed amount of gas is assigned. Some examples from the Ethereum yellow paper:
-
Adding two numbers costs 3 gas
-
Calculating a Keccak256 hash costs 30 gas + 6 more gas for every 256 bits of data being hashed
-
Sending a transaction costs 21000 gas
Gas is a crucial component of Ethereum’s defense against denial-of-service attacks. In order to prevent accidental or malicious infinite loops or other computational wastage in the network, the initiator of each transaction is required to set a limit to the amount they are willing to spend on gas. The gas system therefore decentivizes attackers from sending spam transactions, as they must pay proportionately for the computational, bandwidth, and storage resource that they consume.
The idea of transaction fees and accounting seem practical, though you might wonder why Ethereum requires gas in the first place. Gas is pivotal, as it not only attends to the halting problem, but is also critical for safety and liveness. What is the halting problem, safety, and liveness, and why should you care?
While gas has a price, it cannot be "owned" nor "spent". Gas exists only inside the Ethereum Virtual Machine (EVM) as a count of how much computational work is being performed. The sender is charged a transaction fee in ether, which is then converted to gas and then back to ether as block rewards for the miners. These conversion steps are in place to separate the price for the computation (tied to amount of "work") from the price of ether (tied to market fluctuations).
If the transaction is being sent from an Externally Owned Account (EOA), the gas fee would be withdrawn from the EOA’s balance. In other words, the initiator of the transaction is paying for the gas. The initiator funds the total gas consumed by the transaction as well as any sub-executions that follow. This means that if the initiator X attaches 1000 gas to call contract A, which spends 500 gas on computation and then sends another message to contract B, the gas used by A to send the message to B is also deducted from X’s gas limit specified at the start.
An EOA account X initiates a transaction and calls functions on contract account A, attaching 1000 gas
Contract A spends 500 gas on computation and sends a message costing 100 gas to Contract B
Contract B spends 300 gas on computation and completes the transaction.
100 gas gets refunded to XAn intermediary contract (e.g. contract A in our example) that executes a portion of the operations in a transaction can therefore theoretically run out of gas if the initiator of that transaction did not attach a high enough gas fee at the start. In cases where contracts run out of gas mid-execution, all state changes are reverted except the gas fee payments. The fee is added to the miner’s account.
While the gas cost is a measure of operational steps performed in the EVM, the gas itself also has a gas price measured in ether. When performing a transaction, the sender specifies the gas price they are willing to pay (in ether) for each unit of gas, allowing the market to decide the relationship between the price of ether and the cost of computing operations (as measured in gas).
total gas used * gas price paid = transaction fee in ether
This amount is deducted from the sender’s account at the start of the transaction execution. Instead of "total gas used", the sender is to set a gas limit that should be sufficient to cover the amount of gas required to perform the transaction.
Before sending a transaction, senders must specify a gas limit - the maximum amount of gas they are willing to buy. They must also specify the gas price - the price in ether they are willing to pay for each unit of gas.
gas limit * gas price in ether is deducted from the sender’s account at the start of transaction execution as a deposit. This is to prevent the sender from going "bankrupt" mid-execution and being unable to pay for gas costs. Users are also unable to set a gas limit that exceeds their account balance for this reason.
If the gas used goes over the specified gas limit, i.e. if the transaction "runs of out gas" during execution, the operation is terminated. Although the transaction was unsuccessful, the sender would not get their transaction fee back as miners have already performed the computational work up to that point, and will be compensated for doing so.
If the sender specifies a gas limit that is higher than the gas used however, they will get the excess amount refunded back to them, as miners are only compensated for the work they actually perform.
In which case:
(gas limit - excess gas) * gas price ether goes to the miner as a block reward
excess gas * gasprice ether is refunded to the sender
Gas price is the amount in ether that the transaction sender is willing to pay for each unit of gas used. The miner who mines the next block gets to decide which transactions to include. Since gas price is factored into the transaction fee they will receive as a reward, they are more likely to include transactions with highest gas prices first. If the sender sets the gas price too low, they may have to wait a long time before their transaction makes it into a block.
Miners can also decide the order in which transactions are included in a block. Since multiple miners are competing to append their block to the blockchain, the order of transactions within a block is arbitrarily decided by the "winning" miner and then the other miners verify with that order. While transactions from different accounts can be ordered arbitrarily, transactions from an individual accounts are executed in order of an auto-incrementing nonce.
-
x What is Gas
-
x What is gas cost
-
x What is the gas limit
-
x How is gas counted
-
x Who pays gas
-
x What happens if there’s not enough gas
-
x Is gas paid if there’s not enough?
-
x Who pays for contract calls if intiated by EOA
-
x Who pays if the contract initiates the message?
-
How are contracts funded
-
x Can you set the gas limit above the balance you have?
-
x When is gas actually charged
-
x Can you double spend gas? Why not?
-
x how are transactions sequenced when sent concurrently (same block), in terms of gas and balance?
-
x How can a contract run out of gas?