The Ethereum Virtual Machine & Gas

Smart Contracts, DeFi & Web3 Security
Course 2 · Chapter 2 · The Ethereum Virtual Machine & Gas

Chapter 1 said the EVM executes compiled bytecode, and that gas pays for it, without going any deeper. This chapter does: what the EVM actually is under the hood, what a transaction is really paying for, and precisely what happens when a transaction runs out of gas mid-execution.

The EVM: A Real, Stack-Based Virtual Machine

The Ethereum Virtual Machine (EVM) is a stack-based virtual machine — it executes by pushing and popping values on and off a stack, with a real, specified maximum depth of 1024 items, where each item is a 256-bit word (a deliberate size choice for compatibility with the cryptographic operations Course 1 Chapter 2 covered).

Crucially, the EVM is formally a deterministic state transition function: given the same starting state and the same transaction, it always produces exactly the same resulting state, on any machine, anywhere. This determinism is what lets every node on the network independently execute the exact same contract code and reach identical conclusions about the result — without that guarantee, Chapter 6 of Course 1's own account-balance consensus would be impossible to maintain.

Bytecode and Opcodes

Solidity source code (Chapter 1) compiles down to real EVM bytecode — a sequence of low-level instructions called opcodes. Some are ordinary computational operations (ADD, AND, XOR); others are blockchain-specific, reading real context about the transaction or the chain itself (ADDRESS, BALANCE). A tiny illustrative trace of how the stack changes while evaluating 2 + 3:

PUSH 2stack: [2]
PUSH 3stack: [2, 3]
ADDstack: [5] — pops both, pushes the sum

Why Gas Exists: A Real Solution to a Real Problem

Every opcode has an assigned gas cost. This solves two real, distinct problems at once:

  • It fairly charges users for the real computational effort their transaction actually demands from every node on the network, which has to independently perform that same work to verify it.
  • It gives the EVM a genuine, mechanical way around the halting problem — the real, classic computer-science result that there's no general way to determine in advance whether an arbitrary program will ever finish running. Since a smart contract could, in principle, contain an infinite loop, Ethereum needs some way to guarantee execution always eventually stops. Requiring gas for every single operation, with execution forcibly halting the instant available gas runs out, sidesteps the halting problem entirely — not by solving it, but by making it irrelevant: execution is guaranteed to stop within a bounded number of steps no matter what the code does, because it will always run out of purchased gas eventually if it hasn't finished by then.

Gas Price, Gas Limit, and Gas Used

Three real, distinct terms, easy to conflate:

  • Gas limit — the maximum amount of gas the sender is willing to let this transaction consume. A standard, simple ETH transfer has a real, fixed cost of exactly 21,000 gas — a useful, concrete reference point.
  • Gas used — how much gas the transaction actually consumed once executed. This can be less than the gas limit (any unused gas is refunded), but never more.
  • Gas price — how much the sender is willing to pay per unit of gas, typically quoted in gwei (one billionth of an ETH).
Running Out of Gas: A Real, Important Detail If a transaction runs out of gas partway through execution, the EVM reverts every state change the transaction attempted to make — but the gas already consumed doing that work up to the point of failure is not refunded. This is a deliberate, real design choice: it still costs the network real, genuine computational effort to have attempted (and then unwound) that partial execution, and refunding it would let an attacker probe the network for free by repeatedly triggering failed transactions.

EIP-1559: A Real, Documented Change to How Fees Work

Ethereum's fee mechanism changed in a real, significant way on 5 August 2021, as part of the London hard fork, which activated a proposal called EIP-1559. Rather than a single gas price bid, every transaction now pays two real, separate components:

Base fee set automatically by the protocol itself, and permanently burned (destroyed) rather than paid to anyone
Priority fee (tip) a real, optional amount the sender adds, paid to whoever validates the block, as an incentive for prompt inclusion

The real, resulting formula for a transaction's total cost:

total fee = gas used × (base fee + priority fee)

A worked, real example: a simple 1 ETH transfer at 21,000 gas, with a base fee of 10 gwei and a priority fee of 2 gwei, costs 21,000 × (10 + 2) = 252,000 gwei, or exactly 0.000252 ETH in fees — on top of the 1 ETH actually being sent.

Tying This Directly to Chapter 1's Own Counter Contract Chapter 1's increment() function writes to a state variable — a genuinely real, gas-costing operation, since permanently updating on-chain storage is one of the more expensive categories of work an EVM opcode can do. Chapter 1's getCount() function, marked view, doesn't modify anything and can typically be executed locally by a node without ever being broadcast as a real transaction — which is exactly why it doesn't cost any gas at all in ordinary use, even though it's still, technically, running real EVM bytecode to compute its answer.

Hands-On Exercises

Three exercises reinforcing gas mechanics and the EIP-1559 fee model before Chapter 3 covers real, reusable smart contract design patterns.

Exercise 1
A transaction has a gas limit of 100,000, but genuinely needs 130,000 gas to fully complete. Using this chapter's own explanation of out-of-gas behavior, describe exactly what happens to (a) the transaction's intended state changes, and (b) the gas the sender paid for.
Exercise 2
Calculate the real total fee for a transaction using 45,000 gas, with a base fee of 15 gwei and a priority fee of 3 gwei, using this chapter's own formula. Then explain, in your own words, why the base fee portion doesn't go to the validator who included the transaction.
Exercise 3
Explain, using this chapter's own halting-problem reasoning, why Ethereum couldn't simply say "every contract function must finish within 10 seconds" as an alternative to gas — what real problem would that alternative rule fail to solve?

Quick Reference

  • EVM — a deterministic, stack-based virtual machine (1024-item stack, 256-bit words) that every node runs identically.
  • Bytecode / opcodes — Solidity compiles to low-level EVM instructions, each with its own real gas cost.
  • Why gas exists — charges for real computation, and sidesteps the halting problem by guaranteeing execution always eventually stops.
  • Gas limit / gas used / gas price — the cap you'll allow, what was actually consumed, and the per-unit price (in gwei) you're paying.
  • Out of gas — state changes revert, but gas already consumed is not refunded.
  • EIP-1559 (5 August 2021, the London hard fork) — total fee = gas used × (base fee, burned, + priority fee, paid to the validator).