Skip to content
Ethereum · First Principles

Ether as Fuel

The previous page, Generalizing the Ledger into a World Computer, took the state machine we started with in A Ledger Is Already a State Machine and let its transitions run arbitrary code. That is a thrilling upgrade and a dangerous one. A ledger that only “moves value” can be checked in a bounded number of steps. A ledger that runs anyone’s program inherits every hazard of running anyone’s program — including the oldest one in computer science: some programs never stop.

This page answers a single question the throughline of the book keeps circling back to: what does it cost to run one? We have not yet built the gas machinery — the gas limit, the gas price, the schedule of per-opcode costs, the “revert-but-still-pay” rule. Those are proven in a later part. Here we do something more foundational: we show why a priced, scarce fuel must exist at all, before we ever look at how it is billed. Ether is that fuel. Understanding why it is needed is what makes every later detail feel inevitable rather than arbitrary.

A free public computer is a broken one

Section titled “A free public computer is a broken one”

Start from the property that makes the world computer valuable: it is shared and ownerless. No single party runs it, no single party can censor it, and — crucially — anyone can submit code to it without asking permission. That openness is the whole point. It is also the whole problem.

Consider what “run any submitted program for free” actually promises. Every full node on Earth would have to execute every submitted program to agree on the result. So the moment execution is free, one line of code is a weapon:

   contract Attack {
       function loop() public {
           while (true) { }        // never returns
       }
   }

If running this costs nothing, a single transaction calling loop() asks every node in the world to spin forever. No block can finish, because no node can finish executing the block. The chain halts — not for the attacker, for everyone. A free public computer converts one cheap infinite loop into a global denial-of-service. It is not a bug you can patch; it is the direct consequence of combining “runs untrusted code” with “runs it for free.”

So the openness we wanted and the safety we need are in tension. We cannot screen the bad programs out, either — and the reason why is deeper than “it’s hard.”

Why you can’t just reject the bad programs

Section titled “Why you can’t just reject the bad programs”

The obvious fix is to inspect each program before running it and refuse the ones that loop forever. This is impossible, and impossible in the strong, mathematical sense.

The question “will this program ever stop?” is the halting problem, and Alan Turing proved in 1936 that no algorithm can decide it for every possible program. You cannot write a checker that looks at arbitrary code and reliably answers “this halts” or “this hangs.” Since the world computer is Turing-complete — that is the power we bought — it can express programs whose termination is genuinely undecidable. Screening is off the table forever, not just for now.

   undecidable:  "does this program halt?"              ← unanswerable, ever (Turing 1936)
   decidable:    "does this program halt within N steps?" ← always answerable: run it, count down

The second line is the entire escape hatch, and it is the reason ether exists.

Metering: charge for every step

Section titled “Metering: charge for every step”

Here is the move. We stop asking the impossible question and start asking a possible one. Instead of proving a program halts, we guarantee it halts, by giving it a finite budget and charging that budget down one step at a time. When the budget hits zero, the machine stops the program — mid-instruction if it must — and throws away everything the halted run tried to do.

This is metering. Attach a price to every step of execution. Give each transaction a fixed budget up front. Deduct the price of each step before the step runs. The rule is trivial and its consequence is profound:

   budget = B units
   loop:
       step = next instruction
       if budget < price(step):  HALT the program, discard its effects
       budget = budget - price(step)
       run step

Every execution now has exactly two endings and no third:

  1. It finishes on its own, having spent some of its budget, or
  2. It runs out of budget and is halted.

There is no “hangs forever.” The infinite loop from the top of the page still cannot be detected, but it can no longer hurt anyone: it runs until its budget drains, then stops. We did not solve the halting problem — nobody can. We sidestepped it, by converting a question of pure logic (“does it halt?”) into a question of economics (“how much are you willing to spend before it must halt?”). The undecidable became the affordable.

The book’s companion computer, ethmini, is built around exactly this rule. Its virtual machine charges before it acts, and its clearest test deploys a deliberate infinite loop and asserts it terminates:

   code:  JUMPDEST ; PUSH 0 ; JUMP     ← jumps back to the start, forever
   budget: 1000 units
   each iteration costs: 1 + 3 + 8 = 12 units
   → after ~83 iterations the budget can't afford the next step → HALT (out of budget)

The loop is genuinely non-terminating. The meter makes it terminate anyway. That single guarantee is what lets an ownerless machine safely run code it has never seen. The detailed mechanics of that meter — the exact per-step prices, the budget field on a transaction, the fact that a halted run still pays — are the subject of a later part; the point here is only that some meter is not optional.

Ether is the fuel the meter spends

Section titled “Ether is the fuel the meter spends”

A meter needs units. What should the budget be denominated in? It cannot be an unpriced counter the sender mints for free — then the loop is free again and we are back where we started. The units have to be scarce, so that spending them is a real cost, and they have to be owned by no one in particular, so that no single party can hand themselves unlimited compute on the shared machine.

That unit is ether. Ether is the native, scarce asset of the world computer, and it is the thing you must spend to make the shared machine do work. Running a step of a program burns fuel, and the fuel is paid for in ether. This is the sense in which the page title is literal, not a metaphor: a program is an engine, computation is motion, and ether is what you pour in to make it move. When the tank is empty, the engine stops.

Naming the fuel gives the ownerless resource a price. Compute on a shared computer is a real, finite thing — every node has a finite CPU and finite time per block — but nobody owns it, so left to itself it has no price and gets consumed carelessly (the classic tragedy of the commons). Pricing each step in a scarce asset repairs that: now the person who imposes a heavy computation on every node pays in proportion to the burden they impose. A cheap arithmetic step, which touches a register and vanishes, costs little. A step that writes a value every full node must store forever costs far more. The price is not a tax on using the machine; it is the machine charging you for the lasting cost you push onto everyone else.

Rationing: whose transaction runs next?

Section titled “Rationing: whose transaction runs next?”

Metering answers “how do we stop one program running forever?” But there is a second scarcity, and it is just as fundamental. Even with every program bounded, the machine can still only do so much per block. There is a hard ceiling on total work per block, so that every node can finish processing it in bounded time no matter what code it contains. Blockspace is finite and shared among strangers who will never meet and do not trust each other.

So a question arises the moment demand exceeds supply: when more transactions want in than a block can hold, whose runs next? An ownerless machine cannot appeal to an owner to decide. It needs a rule that strangers can accept as fair without trusting one another — and the natural such rule is a market.

Because every transaction attaches ether as fuel and can offer to pay more per unit, senders who value getting in sooner bid more; the block includes the highest bidders first. This is a fee market, and it does two jobs at once:

  • It rations scarce blockspace to whoever values it most, without any central allocator.
  • It prices congestion: when the machine is busy the fuel price rises, which both compensates the network for the load and dampens frivolous demand.
                 pending transactions (strangers, no trust)
                 ┌──────────────────────────────────────────┐
                 │  tx  offering 3   ●                        │
                 │  tx  offering 9   ●●●●●●●●●                 │
                 │  tx  offering 5   ●●●●●                     │
                 │  tx  offering 1   ●                         │
                 └──────────────────────────────────────────┘
                                │  order by price/unit
                                ▼
                 ┌── next block (bounded total work) ─────────┐
                 │  offering 9  ✓                              │
                 │  offering 5  ✓                              │
                 │  offering 3  ✓   ← fits under the ceiling   │
                 │  offering 1  ✗   ← waits for a later block  │
                 └────────────────────────────────────────────┘

The same ether that bounds a program (metering) also allocates the shared machine among strangers (rationing). One scarce resource, two problems solved. The precise fee-market mechanism — a base fee that moves with demand, priority tips, and what happens to a transaction that pays but reverts — is proven in a later part. Here the takeaway is why a fee market is needed: finite blockspace shared among untrusting strangers requires some fair, ownerless way to decide who goes next, and pricing it in fuel is that way.

Under the hood — one asset, three jobs

Section titled “Under the hood — one asset, three jobs”

It is worth seeing that ether is doing three distinct jobs, and that they reinforce each other:

  • Bounding. Every program is guaranteed to halt, because it halts the instant it can no longer afford its next step. This is the halting-problem escape hatch.
  • Pricing. The ownerless, unpriced resource of “compute on a shared computer” gets a price, so its cost falls on whoever consumes it rather than on everyone equally.
  • Rationing. Finite blockspace is allocated by a fee market, so strangers can agree on transaction order without a trusted allocator.

Remove the fuel and all three collapse together: unbounded programs return, compute becomes free and therefore abused, and there is no non-arbitrary way to decide whose transaction runs. The fuel is not a convenience bolted onto a world computer. It is the thing that makes an open world computer possible at all.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Because a shared, ownerless computer that runs untrusted code for free is a standing global denial-of-service: one infinite loop asks every node to spin forever. Ether exists to put a price on every step so that no program can consume the shared machine for nothing.
  • What problem does it solve? Three at once — it bounds otherwise-unbounded programs (sidestepping the undecidable halting problem by making termination a budget), it prices an ownerless resource so cost falls on whoever consumes it, and it rations finite blockspace among strangers through a fee market.
  • What are the trade-offs? Using the world computer is never free, and during congestion it can be expensive — that is the cost of expressiveness. A system with a non-Turing-complete language (like Bitcoin’s) needs no fuel because it can’t express infinite loops, but it also can’t express arbitrary contracts. Ether buys back safety for the expressiveness we chose to keep.
  • When should I avoid it? When your computation does not need a shared, untrusting, ownerless machine at all. If a single trusted party can run the code, an ordinary server is cheaper and faster; paying priced fuel only makes sense when the point is that no one owns the computer.
  • What breaks if I remove it? Everything the fuel was holding up: programs are no longer guaranteed to halt, compute becomes free and therefore abused, and there is no fair, ownerless way to decide whose transaction runs next. Removing the fuel does not make the machine free — it makes the machine unusable.

Check your understanding

Section titled “Check your understanding”
  1. Why can’t a public, ownerless computer safely run untrusted code for free? Walk through what one infinite loop does to every node if execution costs nothing.
  2. State the halting problem and Turing’s 1936 result. Explain precisely how metering sidesteps the problem rather than solving it.
  3. Metering needs a unit to count down. Why must that unit be scarce and ownerless, and what goes wrong if a sender can mint the units for free?
  4. Ether does a bounding job (metering) and an allocation job (rationing). Explain how the same scarce asset ends up solving both “stop one runaway program” and “decide whose transaction runs next.”
  5. This page deliberately does not explain the gas limit, gas price, or the per-opcode schedule. What is the one thing it does establish, and why is that the right thing to settle first?
Show answers
  1. Every full node must execute every submitted program to agree on the result, so a free infinite loop asks every node on Earth to spin forever. No node can finish executing the block, so no block finishes — the chain halts for everyone, not just the attacker. “Runs untrusted code” plus “runs it for free” is a built-in global denial-of-service, not a patchable bug.
  2. The halting problem asks whether an arbitrary program will ever stop; Turing proved in 1936 that no algorithm can decide this for all programs. Metering doesn’t answer “does it halt?” (still undecidable) — it guarantees the program halts within a finite budget by charging each step down to zero. It converts the undecidable logic question into a decidable economic one: “does it halt within N units?”
  3. The unit must be scarce so spending it is a real cost — otherwise running a step is free and the infinite loop is free again. It must be ownerless so no single party can hand themselves unlimited compute on the shared machine. If a sender could mint units for free, the whole meter is decorative: there is no budget to run out of.
  4. Bounding: each program is given a finite ether budget and charged per step, so it must halt when the budget drains. Rationing: because blockspace per block is finite and every transaction attaches ether and can bid more per unit, a fee market orders transactions by price and includes the highest bidders first. One scarce, priced asset both stops a runaway program and lets untrusting strangers agree on who goes next.
  5. It establishes why a priced, scarce fuel must exist at all — that an open world computer is impossible without one, for bounding, pricing, and rationing. Settling why first makes every later mechanic (the gas limit, the price, the schedule, revert-but-still-pay) feel like the natural way to deliver a fuel we’ve already proven is mandatory, rather than an arbitrary set of rules.