Overview — Gas, Fees & EIP-1559

The last two parts built the machine and the operators. The EVM part turned Ethereum from a ledger into a shared world computer — a machine anyone on Earth can deploy code to, where every honest node runs that code identically. The consensus part gave us the operators: proof-of-stake validators who take turns proposing blocks and attest to each other’s work, so that untrusting strangers agree on which block comes next.

Both parts left a hole open, and this part fills it. The EVM part answered “what stops a program from running forever?” with a one-word promise — gas — but it never said who pays for that gas, how much a unit of it costs, or why the price you pay this second differs from the price a minute ago. Consensus decided whose block wins but not what goes in it: a block has room for only so much computation, and everyone wants theirs included. This part is about that scarce room — blockspace — and the market that rations it.

The book’s throughline is how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Earlier parts were mostly the first half. This part is the second half, made literal: the actual number, in ether, that a transaction pays.

The one question this part answers

Once anyone can submit arbitrary code to a shared machine, that machine has a resource problem the moment it goes public. Every operation a transaction runs — every add, every storage write, every byte of state it grows — costs real resources on every node on Earth: CPU to execute, disk to store forever, bandwidth to propagate. If those operations were free, the network would be:

• Floodable. Nothing stops an attacker from submitting endless work and grinding every node to a halt — the denial-of-service problem the EVM part first raised.
• Unverifiable. A block with unbounded computation could take unbounded time to check, and a chain you cannot re-execute in reasonable time is a chain you cannot trust.

So the network must do two separate jobs, and keeping them separate is the key that unlocks this whole part:

   a transaction wants to run code on the shared machine
                        │
          ┌─────────────┴──────────────┐
          ▼                            ▼
   METERING                       PRICING
   "how much of the block's       "what does one unit of that
    bounded budget does this       budget cost, right now?"
    transaction consume?"
          │                            │
   measured in GAS                measured in ether-per-gas
   (a fixed, protocol             (a price that MOVES with
    schedule per opcode)           demand for blockspace)

Metering is a fact about a computation: running this exact transaction consumes exactly this many units of gas, set by a fixed protocol schedule, the same on every node forever. Pricing is a fact about a market: at this moment, with this much demand, one unit of gas costs this much ether. Metering is physics; pricing is economics. Conflating them is the single most common source of confusion about Ethereum fees, so we split them from the first page and never re-merge them.

By the end of the part you will be able to do three concrete things: compute a transaction’s total cost from its gas and the prevailing fee, explain exactly where that fee goes (some burned, some tipped), and reason about why the base fee is higher or lower than it was a block ago.

Roadmap for this part

Read these in dependency order. Each page assumes the one before it — we build the gas unit, then how gas is accounted, then two successive pricing mechanisms (the old auction, then EIP-1559), then the controller that steers the price, then the real-world economics a user and a wallet actually face.

#	Page	The idea it teaches	Builds on
2	Gas: Metering Computation and Storage	Gas as the unit that meters work — why an SSTORE costs far more than an ADD, and why costing state growth is the whole point	the EVM
3	Gas Limit, Gas Used, and the Fee Formula	The three numbers on every transaction — gas_limit, gas_used, price — and the formula that turns them into a cost in ether	page 2
4	The Pre-1559 First-Price Auction	How fees worked before 2021: one gasPrice, a blind first-price auction, and why it was so painful to bid in	page 3
5	EIP-1559: Base Fee, Priority Fee, and the Burn	The mechanism live today — a protocol-set base fee that is burned plus an optional priority fee (tip) that pays the proposer	page 4
6	Block Elasticity and How the Base Fee Moves	The target-vs-limit “elastic” block and the feedback controller that raises or lowers the base fee ±12.5% per block	page 5
7	Fee Estimation and the Economics of Blockspace	How wallets estimate a tip, what the burn does to ether’s supply, and blockspace as a scarce commodity market	page 6
900	Revision — Gas, Fees & EIP-1559	The whole part recapped in one breath	all

The spine is deliberate: gas unit → gas accounting → first-price auction → EIP-1559 → base-fee controller → blockspace economics. You cannot price a thing before you can measure it (so metering comes first), and you cannot appreciate why EIP-1559 was designed the way it was until you have felt the pain of the auction it replaced (so the old mechanism comes before the new one).

A first look at the two jobs, in code

We do not need EIP-1559 to see the metering half — it is already sitting inside the book’s companion EVM, ethmini. Every opcode carries a fixed gas cost, and the interpreter charges it before the op runs, so the meter can never go negative:

// from rust/ethmini/src/vm.rs — the per-opcode gas schedule
pub fn gas_cost(&self) -> u64 {
    match self {
        Op::Stop | Op::Return => 0,
        Op::JumpDest => 1,
        Op::Push(_) | Op::Pop | Op::Add | Op::Sub => 3,
        Op::Mul => 5,
        Op::Jump => 8,
        Op::JumpI => 10,
        Op::SLoad => 100,   // reading state is dear
        Op::SStore => 200,  // *growing* state is dearest — every node keeps it forever
    }
}

That ordering — arithmetic cheap, a storage read dearer, a storage write dearest — is not arbitrary. It is the metering job doing exactly what it exists to do: charge in proportion to the burden an operation puts on the network. The exact numbers are simplified from real Ethereum, but the shape of the incentive is the same, and page 2 makes that shape the whole lesson.

Notice what this snippet says nothing about: it never mentions ether, or a price, or the market. gas_cost returns pure gas — a count, not a cost. Turning that count into a bill in ether is the pricing job, and that is where the auction (page 4) and EIP-1559 (pages 5–6) come in.

By the numbers — the two halves of one bill

A plain ETH transfer meters at a fixed 21,000 gas on real Ethereum — that number is protocol law and does not change with demand. What changes is the price per gas. Suppose the base fee is 20 gwei and you add a 2 gwei tip (1 gwei = 10⁻⁹ ether):

metering (fixed):     gas_used      = 21,000
pricing  (moves):     base_fee      = 20 gwei/gas   (burned)
                      priority_fee  =  2 gwei/gas   (to the proposer)
                      effective     = 22 gwei/gas

cost = gas_used × effective
     = 21,000 × 22 gwei
     = 462,000 gwei
     = 0.000462 ETH

  of which:  burned = 21,000 × 20 gwei = 0.000420 ETH  (leaves circulation)
             tipped = 21,000 ×  2 gwei = 0.000042 ETH  (paid to the proposer)

Same 21,000 gas; the bill rose or fell only because the price per gas did. Gas figures are protocol constants; gwei prices are illustrative and move block to block — as of 2024 the base fee has ranged from under 10 gwei in quiet hours to hundreds of gwei during demand spikes.

The thread

This part is the point where the book’s two words finally meet in a single number. Metering is the child of determinism: because every node runs the same schedule (page 2), every node agrees on gas_used down to the unit — the same reason the EVM must be deterministic at all. Pricing is the child of scarcity: because a block holds only so much gas, and consensus lets exactly one proposer fill it, blockspace is a rivalrous good and needs a market to allocate it.

Watch, across the next six pages, how a design keeps splitting these two jobs cleanly — and how the one time Ethereum blurred them (the pre-1559 auction, where users had to guess the market price themselves) produced the worst user experience of all, which EIP-1559 was built to fix. Keep asking of every mechanism: is this metering, or is this pricing? Almost every fee question dissolves the moment you know which one you are looking at.

Check your understanding

1. This part says the network must do two separate jobs on every transaction. Name them, and give the unit each is measured in.
2. A plain ETH transfer always meters at 21,000 gas, yet the cost of sending it swings wildly hour to hour. Which of the two jobs explains the fixed 21,000, and which explains the swing?
3. Why must the metering schedule be identical on every node — what earlier property of the EVM does that requirement come from?
4. The roadmap places the pre-1559 first-price auction (page 4) before EIP-1559 (page 5), even though the auction is obsolete. Why teach the dead mechanism first?
5. Restate the book’s throughline in your own words, and say which half of it this part is mainly about.

Show answers

1. Metering — measuring how much of the block’s bounded budget a transaction consumes, in units of gas. Pricing — deciding what one unit of that budget costs right now, in ether per gas (e.g. gwei/gas). Metering is a fixed protocol fact; pricing moves with demand.
2. The fixed 21,000 is metering: a transfer runs the same operations every time, so it consumes the same gas by the protocol’s fixed schedule. The swinging cost is pricing: the price per gas rises and falls with demand for scarce blockspace, and cost = gas × price.
3. Because the EVM must be deterministic — given the same code, inputs, and state, every honest node must reach the same result, or the network forks. If nodes disagreed on what an op costs, they would disagree on gas_used, on whether a transaction ran out of gas, and therefore on the resulting state.
4. Because you cannot appreciate why EIP-1559 was designed the way it is until you have felt the pain it removed. The first-price auction forced every user to blindly guess the clearing price and routinely overpay or get stuck; EIP-1559’s protocol-set base fee is a direct answer to that pain, and the “why” only lands once you have seen the problem.
5. Something like: how do mutually distrusting parties come to agree on the state of one shared programmable machine, and what does it cost to keep that machine running? This part is mainly about the second half — the cost — turning the “gas” promise from the EVM part into an actual price, and thereby an actual bill in ether.