Overview — Advanced & Frontier

Every Part before this one taught a piece of a chain that already runs. You have an account-based world state, transactions that mutate it, a gas-metered EVM that computes the next state, a Merkle-Patricia trie that fingerprints it into a single state root, a Proof-of-Stake consensus that agrees on block order, and rollups plus blobs that scale it out. That machine works today. This Part is about what people are trying to change next — and, just as importantly, why they’d dare.

So the honest framing first. Everything in this Part is forward-looking. Some of it is shipped and live, some is a specification headed for a future hard fork, and some is still research that may never land in the form described. That matters for how you should read it: wherever a page makes a dated or roadmap claim, it is hedged and labelled — live, proposed, or research — and pinned to an absolute date. Ethereum’s roadmap has been redrawn many times; a book that pretends otherwise ages badly. What does not age is the way of thinking, which is the point of the Part.

The frame: each frontier is another turn of the dial

The book’s throughline has been one question the whole way: how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Every Part so far pushed on the second half of that sentence — the cost. Consensus moved the cost from a power bill to a slashable bond. Rollups moved execution off-chain to cut the per-transaction cost. Blobs cut the data cost.

The frontier topics are the same move, again, on new dials:

   THE DIAL                     WHAT IT CONTROLS
   ────────────────────────     ──────────────────────────────────────────────
   what the world computer      Account Abstraction — can an account carry
   can DO for a normal user     logic, not just a keypair?

   what it COSTS to run a        Verkle trees & statelessness — can a node
   full verifying node           verify without storing the whole state?

   who gets to BUILD the         Proposer–Builder Separation — can we keep
   next block, and who profits   block-building open while it centralises?

   how staked capital is         Restaking — can one bond secure more than
   REUSED across services        one system without stacking new risk?

   how any of the above          The EIP process — how does a change to a live,
   actually SHIPS                multi-billion-dollar chain get coordinated?

None of these is a rewrite. Each is a turn of the dial on what the machine can do, what it costs to participate, or who can still verify the result. Read that way, the Part is not a grab-bag of buzzwords — it is five more answers to the same question you have been chasing since Part 1.

The recurring test for this Part

Because these are proposals and not settled facts, you need a discipline for reading them. For every change in this Part, ask three questions — the same three, every time:

1. What does it buy? What does the world computer now do, or cost, that it didn’t before?
2. What does it cost? Nothing is free. New complexity, new trust assumptions, new attack surface, new hardware — name the price.
3. Can a normal user still check the chain? Ethereum’s whole value is that you don’t have to trust the operators — you can verify. If a change quietly makes verification the privilege of a well-funded few, that is a cost measured in the chain’s soul, not just its throughput.

That third question is the one the industry most often waves away, so this Part leans on it hardest. Keep it in hand for every page.

Roadmap for this Part

Read these in order. The order is a dependency order: each page reuses ideas from the earlier Parts named in the last column, so the further down you go, the more of the book you’re standing on.

#	Page	The problem it attacks	Reuses from earlier Parts
2	Account Abstraction — ERC-4337 and Native AA	EOAs are rigid: one keypair, no custom logic, and a lost key is a lost account	Accounts & EOAs, the EVM, ECDSA signatures
3	Verkle Trees and Statelessness	State keeps growing, so running a full node keeps getting heavier	State root & Merkle-Patricia trie, proofs & light clients
4	Proposer–Builder Separation and MEV	Whoever orders transactions can extract value; block-building is centralising	Validators & PoS, transactions, the mempool
5	Restaking and EigenLayer	Staked ETH secures one chain while sitting idle for everything else	Staking & slashing, validators
6	The EIP Process and the Upgrade Roadmap	A live chain with no CEO still has to coordinate and ship changes safely	Everything — this is how The Merge and EIP-4844 reached mainnet
900	Revision — Advanced & Frontier	—	Every idea in the Part, drilled with questions

If you take one map away from this page, take this: pages 2–3 change what the machine does and costs for its participants (the account, then the node); pages 4–5 change the economics of who runs it (who builds blocks, and how their bond is reused); and page 6 is the meta-layer — how a chain governed by no one turns any of these from a document into a rule the network enforces.

Why this order, concretely

The dependency order is not arbitrary. Here’s the chain of reuse, so you can see the book holding itself up:

   Account Abstraction   ─► needs: accounts, contract code, the EVM, signatures
        │                        (a smart-contract account is just a contract that
        │                         validates its own transactions)
        ▼
   Verkle / statelessness ─► needs: the state root and the trie whose PROOFS
        │                         it shrinks — you cannot appreciate a smaller
        │                         proof until you've felt a big one
        ▼
   Proposer–Builder Sep.  ─► needs: PoS validators (the proposers) and the
        │                         mempool of pending transactions they order
        ▼
   Restaking             ─► needs: staking, the 32-ETH bond, and SLASHING —
        │                         restaking is literally "point your slashable
        │                         bond at a second system too"
        ▼
   The EIP process       ─► needs: all of the above, because it's the machinery
                                that decides which of them ever becomes real

Notice that two of these — account abstraction and restaking — are not new protocol features at all. ERC-4337 runs entirely in smart contracts on top of the chain you already have, and restaking (as of 2024) began as a set of contracts too. That is itself a lesson the last Part will sharpen: sometimes the frontier is not a hard fork, it’s what people build in the space the existing rules already allow.

The thread

How do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Everything you’ve learned answers that for the chain as it stands today. This Part asks it about the chain of tomorrow, and the answer is never a free lunch. Making accounts programmable buys usability but adds a new mempool and new trust in “bundlers.” Statelessness buys cheap nodes but leans on heavier cryptography most users can’t audit by hand. Proposer–builder separation buys censorship-resistance for proposers but concentrates power in a handful of builders. Restaking buys reused security but stacks correlated slashing risk. Each is a bargain, not a gift — and whether it is a good bargain is exactly the “what it buys / what it costs / can a normal user still verify” test you’ll run on every page. Hold that test steady, and the buzzwords resolve into what they actually are: five more attempts to move a dial on the world computer without breaking the one property that made it worth building — that strangers who trust nobody can still check it for themselves.

Check your understanding

1. This Part is described as “forward-looking.” What discipline does that impose on how every dated or roadmap claim is written, and why does it matter for a chain whose roadmap has been redrawn many times?
2. The overview gives a recurring three-question test to apply to every proposed change. State all three, and explain why the third is treated as the most important.
3. The roadmap is deliberately in dependency order. Pick any page from 3 onward and name at least one earlier-Part idea it reuses, and why it couldn’t be understood without it.
4. Two of the five frontier topics are said to be “not new protocol features at all.” Which two, and what does that fact reveal about where the frontier can live besides a hard fork?
5. Restate the whole Part in one sentence using the book’s throughline — framing each frontier as “another turn of the dial.”

Show answers

1. It requires every dated or roadmap claim to be hedged and explicitly labelled — live, proposed, or research — and pinned to an absolute date rather than a word like “recently.” It matters because Ethereum’s roadmap has been reordered and rescoped repeatedly; a page that states a future plan as settled fact would be wrong the moment the plan changes, whereas a labelled, dated claim stays honest and the underlying way of thinking still holds.
2. (1) What does it buy? — what new capability or lower cost the change adds. (2) What does it cost? — the new complexity, trust assumptions, attack surface, or hardware it demands, since nothing is free. (3) Can a normal user still check the chain? — whether verification stays open to ordinary participants. The third is most important because Ethereum’s core value is that you verify rather than trust operators; a change that quietly makes verification a privilege of the well-funded erodes the one property that justified the whole system, a cost that pure throughput numbers hide.
3. Examples (any one): Verkle trees & statelessness reuses the state root and Merkle-Patricia trie — it is fundamentally about shrinking the proofs that trie produces, so you can’t grasp the gain without first feeling the cost of a big proof. Proposer–Builder Separation reuses PoS validators (the proposers) and the mempool of pending transactions they order. Restaking reuses staking and slashing — it is literally pointing one slashable bond at a second system. Each depends on the earlier idea because the frontier change is defined relative to it.
4. Account abstraction (ERC-4337) and restaking (as of 2024). ERC-4337 runs entirely in smart contracts on top of the existing chain, and restaking began as a set of contracts too. This shows the frontier can live in application-layer code that uses the rules the protocol already allows — you don’t always need a hard fork to change what the world computer effectively does for its users.
5. Each frontier topic is another turn of the dial on the world computer — programmable accounts turn the “what can a user do” dial, statelessness turns the “what does a node cost” dial, proposer–builder separation and restaking turn the “who runs it and how their bond is used” dials, and the EIP process is the machinery that decides which turns actually ship — every one a bargain judged by what it buys, what it costs, and whether untrusting strangers can still verify the result for themselves.