Revision — Advanced & Frontier

The overview opened this Part with a warning and a discipline. The warning: everything here is forward-looking, so read every claim as live, proposed, or research. The discipline: for each change, ask what it buys, what it costs, and whether a normal user can still check the chain. This page walks back over the five frontiers with that discipline in hand, so the buzzwords resolve into the same single question the whole book has chased — how do untrusting strangers agree on the state of a shared world computer, and what does it cost to run one?

Nothing below is new. It is the Part compressed, with the certainty labels kept attached, so you can see the shape of the frontier without mistaking a proposal for a promise.

The account: from keypair to program

The chain you already understand splits accounts in two: an externally owned account (EOA), which is a bare ECDSA keypair that can only authorize a transaction with one fixed rule — “does this signature match this key?” — and a contract account, which holds code but cannot start a transaction on its own. That split is rigid. One lost key is a lost account forever. There is no way to say “require two of three signers,” “let someone else pay my gas,” or “rate-limit withdrawals,” because an EOA’s validity rule is burned into the protocol.

Account abstraction dissolves that rigidity by letting an account decide for itself what makes a transaction valid. ERC-4337 ships this today (live, since 2023) entirely off-protocol: it never changed the base chain. Instead it invents a parallel pipeline — users sign UserOperation objects, a separate mempool carries them, bundlers package them into ordinary transactions, and a single on-chain EntryPoint contract calls each smart-contract account’s own validateUserOp to check them. The validity rule becomes code you wrote, so an account can now do the things an EOA never could:

   EOA (today, protocol-level)        Smart account (ERC-4337, contract-level)
   ─────────────────────────────      ────────────────────────────────────────
   validity = ECDSA(sig, key)         validity = your validateUserOp() code
   one key, one rule                  multisig, passkeys, session keys, ...
   caller always pays gas             a paymaster can sponsor the gas
   lost key = lost account            social recovery / guardians possible

That unlocks three concrete wins the Part kept returning to: programmable validity (any signature scheme or policy you can express in code), gas sponsorship (a paymaster pays so a new user can transact with zero ETH, or pay fees in a token), and recovery (guardians can rotate the signing key without moving the account). The proposed successor, native account abstraction (research/proposed, via EIPs such as EIP-7702 and the longer-running EIP-3074 lineage), aims to fold this into the protocol so an EOA can temporarily act like a smart account — removing the separate mempool and its extra trust in bundlers. Read the split honestly: ERC-4337 is real and running; native AA is a moving target, and which EIP wins is not settled.

The cost side stays on the table. A second mempool is a second thing to run, watch, and possibly censor, and “trust the bundler to include my op” is a new dependency an EOA never had. The bargain — usability for added machinery — is a good one for most users, but it is a bargain, not a gift.

The node: keeping verification cheap as state grows

The book’s deepest value is that you don’t trust operators, you verify. That property has a quiet enemy: state growth. Every new account and storage slot makes the world state bigger, and a node that must store the whole Merkle-Patricia trie to check the chain gets heavier every year. Left alone, that trend prices ordinary people out of running a full node — and if only the well-funded can verify, “trustless” is slowly hollowed out.

Verkle trees and statelessness are the proposed answer (research/proposed as of 2024–2025; not live). The move is in two steps. First, replace the Merkle-Patricia trie with a Verkle tree, whose vector-commitment cryptography produces much smaller proofs — the branch of a Merkle proof lists every sibling hash at every level, while a Verkle proof collapses that to a compact constant-ish witness. Second, use those tiny proofs to enable statelessness: a block ships with a witness — the exact slice of state it touches, plus a proof that the slice is correct against the state root. A verifier can then re-execute the block and check it without storing the whole state at all.

   TODAY: verifier must hold the entire state to check a block
   ┌───────────────────────────┐
   │  full state (tens of GB) │──► re-execute block ──► compare state root
   └───────────────────────────┘

   STATELESS (proposed): block carries its own proof of the state it touches
   witness = { touched slots + Verkle proof } ──► verify against root
   (no full-state storage required)

Say plainly what this protects: who gets to check the chain. Cheaper verification keeps the door open to hobbyist verifiers, phone-class hardware, and light clients, which is the difference between a chain guarded by everyone and one guarded by a data-center few. The cost is honest too — Verkle leans on cryptography (polynomial/vector commitments) that most users cannot audit by hand the way they can eyeball a hash tree, and the migration of a live multi-terabyte-history chain to a new tree is a genuinely hard, unshipped engineering problem. Buys cheap verification; costs auditability and a painful transition.

Who builds the block: PBS and MEV

Whoever orders transactions in a block can extract value from that ordering — front-running a trade, sandwiching a swap, capturing an arbitrage. This is MEV (maximal extractable value), and it is not a bug you can delete; it is a consequence of a public mempool plus a single party choosing order. The danger is centralizing: if maximizing MEV requires sophisticated, capital-heavy optimization, then validators who do it well out-earn those who don’t, and staking drifts toward a professional elite — corroding the “anyone can validate” premise from Proof of Stake.

Proposer–builder separation splits the job so the validator can stay simple. A builder does the hard, specialized work of assembling the most valuable ordered block; the proposer (the chosen validator) merely picks the highest-bidding block by its header, commits to it, and only then sees its contents. The proposer never needs to be an MEV expert — it just runs an auction.

   builders  ─► compete to build the most valuable block ─► submit bids
                                                              │
                                          (proposer sees only headers + bid)
                                                              ▼
   proposer  ─► picks highest bid, signs the header ─► block is revealed & attested

Hold the certainty labels firmly here. MEV-Boost is the live version (widely used since The Merge, 2022): an out-of-protocol marketplace where relays sit between builders and proposers. Enshrined PBS (ePBS) is proposed/research — building the separation into the protocol itself so it no longer depends on trusting relays. The unresolved tension the page insisted on: PBS keeps proposers decentralized and simple, but it can concentrate power in a small set of builders, and a handful of dominant builders is its own censorship and centralization risk. It moves the centralization pressure; it does not abolish it.

Reusing the bond: restaking and its central risk

Staked ETH secures one chain. Restaking — pioneered by EigenLayer (restaking contracts live on mainnet since 2023, with the AVS/operator layer following in 2024) — asks the natural follow-up: could that same bond also secure other systems? A restaker opts in to have their stake become slashable by additional services (oracles, bridges, data-availability layers, alternative consensus systems, called AVSs), earning extra reward in exchange for accepting extra slashing conditions. Like ERC-4337, it began not as a hard fork but as application-layer contracts using rules the protocol already allowed — a reminder that the frontier can live in the space above the base chain.

The Part named one risk above all the others: restaking stretches a single security budget across many services. The same ETH now backs the base chain and a stack of AVSs, so a bug or coordinated failure in one service can trigger slashing that cascades into correlated losses — the exact kind of shared-fate risk that turns many small, “independent” failures into one large, systemic one. The bargain: reused security and higher yield, bought with layered, correlated slashing risk that is hard to price and, as of 2024–2025, not yet stress-tested at scale.

   Without restaking            With restaking (one bond, many claims)
   ─────────────────            ───────────────────────────────────────
   32 ETH  ─► secures L1         32 ETH ─► L1
                                       └─► AVS #1  ┐
                                       └─► AVS #2  ├─ all slashable against
                                       └─► AVS #3  ┘  the SAME bond

How any of it ships: the process, not a decree

None of the above becomes real by fiat. A live, multi-billion-dollar chain governed by no CEO still has to coordinate change, and the EIP process and roadmap is that machinery: an idea becomes an EIP, is debated in the open, is implemented across independent client teams, is tested on public testnets, and only then activates in a coordinated hard fork. This is exactly how The Merge and EIP-4844 blobs reached mainnet — and it is the reason the honest labels in this Part matter: an EIP can sit in “draft” for years, get rescoped, or be dropped entirely. The process is why the roadmap keeps being redrawn, and why reading claims as live/proposed/research is not caution for its own sake but an accurate model of how the chain evolves.

Reading the frontier: live, proposed, research

Set the whole Part side by side and keep the labels attached, because the single most common mistake with frontier material is mistaking a specification for a shipped feature:

   TOPIC                     STATUS (as of 2024–2025)      LIVES
   ───────────────────────   ──────────────────────────    ─────────────
   ERC-4337 account abstr.   live                          contracts (off-protocol)
   Native AA (7702/3074)     proposed / research           future hard fork
   Verkle + statelessness    proposed / research           future hard fork
   MEV-Boost                 live                          out-of-protocol market
   Enshrined PBS             proposed / research           future hard fork
   Restaking (EigenLayer)    live                          contracts (off-protocol)

Two patterns are worth naming. First, the frontier does not always mean a hard fork: account abstraction and restaking both began as ordinary contracts in the space the existing rules already permit — sometimes progress is what people build on top of the chain, not a change to it. Second, every single row is a bargain, and each bargain is judged by the same three questions the overview handed you.

The thread

How do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Every frontier in this Part is that question asked again on a new dial, and the answer is never a free lunch:

• Programmable accounts buy usability and recovery, and cost a new mempool and trust in bundlers.
• Statelessness buys cheap nodes and open verification, and costs heavier, less-auditable cryptography and a hard migration.
• PBS buys simple, censorship-resistant proposers, and costs concentration in a few powerful builders.
• Restaking buys reused security and yield, and costs correlated, hard-to-price slashing risk.
• The EIP process is the machinery that decides which of these bargains ever becomes a rule the network enforces.

The connective tissue is that third overview question — can a normal user still check the chain? Account abstraction is neutral to it, statelessness exists to protect it, and PBS and restaking each put it under pressure by concentrating power or risk. Judge each proposal by whether it keeps the door to verification open, and the frontier stops being a slogan and becomes what it actually is: 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 verify it for themselves.

Where to go next: nothing here is finished. Re-read each sibling page — account abstraction, statelessness, PBS, restaking, and the EIP process — but this time reading each claim aloud with its label attached. The habit of asking live, proposed, or research? is the most durable thing this Part can leave you with, because it is the only thing about the frontier guaranteed not to age.