PBS to ePBS: Exclusive, Effortless Censorship Resistance.

Ethereum’s fee market now runs through professional builders. That shift unlocked massive MEV revenue, but it also created new choke points. When a handful of relays and builders decide what gets into blocks, censorship risks move from theory to practice. Proposer-builder separation (PBS), its enshrined variant (ePBS), and inclusion lists are the core ideas meant to keep block production open, fair, and credibly neutral.

From MEV-Boost to PBS: how we got here

After The Merge, most validators adopted MEV-Boost. Proposers outsource block construction to external builders via relays, taking the highest-paying bid. The market found more MEV, user tips rose, and node hardware requirements stayed modest. Good outcomes—on paper.

The catch: relays became gatekeepers. During periods of OFAC pressure, “OFAC-compliant” relays filtered transactions touching sanctioned addresses, even if those transfers were legal in other jurisdictions. Imagine a user sending a swap with a 30 gwei tip that touches a tainted address; a majority of blockspace routed through compliant relays may ignore it for minutes. That delay can be financially ruinous.

PBS is the design pattern behind this separation. Today it’s out-of-protocol (MEV-Boost). ePBS brings it into the protocol, removing relays and formalizing the split between proposers and builders while tightening guarantees for liveness and inclusion.

What “censorship-resistance” must mean in practice

It’s not a slogan. It’s a measurable property: a well-formed transaction broadcast to the network must be included in a timely manner by an honest majority of proposers, despite external pressure on builders. Two concrete targets often discussed are “soft” guarantees like inclusion within N slots and “hard” paths that bypass censoring builders altogether.

This is where inclusion lists and protocol-level commitments matter. They give proposers a tool to force consideration of certain transactions, without collapsing the MEV auction.

Inclusion lists: the proposer’s nudge with teeth

An inclusion list is a set of transaction hashes the proposer attaches to a block header. Builders must either include those transactions or prove they can’t (e.g., nonce gap or insufficient balance). If a builder can’t include a listed transaction for a valid reason, they include a witness; if they simply refuse, their bid loses.

Used correctly, inclusion lists turn “please include this” into “include this or forfeit the block,” which deters soft censorship while leaving builders free to optimize the rest of the block.

Slot-level choreography: who does what, when

The flow is time-sensitive. A typical slot under PBS with inclusion lists involves a few crisp steps.

1. The proposer gathers mempool data and compiles an inclusion list (e.g., top X fee-paying transactions not seen in recent blocks, plus any delayed txs).
2. Builders receive the inclusion list and craft candidate blocks that include all feasible listed transactions, then maximize MEV around them.
3. Builders submit sealed bids; the proposer picks the highest.
4. If a listed transaction is truly invalid or temporarily unfillable, the builder supplies a witness; the protocol verifies and accepts the exception.
5. The block is published; the chain records whether the inclusion list was satisfied.

This structure keeps incentives aligned. Builders chase profit, proposers ensure baseline inclusion, and users get reasonable liveness even if some builders attempt to censor.

What ePBS changes—and why it matters

ePBS moves the negotiation and commitments on-chain. Instead of trusting relays to forward bids intact, the protocol verifies builder commitments, handles payments, and enforces deadlines. That reduces trust in off-chain infrastructure, closes griefing vectors, and gives the protocol native hooks for inclusion enforcement.

Two immediate benefits stand out: verifiable builder commitments and simpler fallback paths when builders fail to deliver. With ePBS, the protocol can enforce that a builder who wins must deliver the exact payload committed, including the listed transactions or valid witnesses. No relay discretion. Less room for subtle filtering.

Threat models and real failure modes

Not all censorship looks the same. Designing for one threat and ignoring others is a common pitfall.

• Soft filtering by majority builders: a large share avoids “risky” flows (mixers, sanctioned hops). Transactions eventually land, but with long delays.
• Coercion or collusion: a small cartel blocks a competitor’s arbitrage or a political target’s transfers, degrading price discovery and fairness.
• Transaction censorship via data withholding: a builder pretends a listed transaction can’t be included while hiding state that would allow it.
• Spam-saturation: adversaries flood mempools to crowd out inclusion lists or exhaust proposer bandwidth.

Inclusion lists and ePBS tackle the first two directly by hardening incentives and verification. The latter two require careful protocol design: witnesses, gas-accounting limits, and sane quotas on list size to keep DoS risk in check.

Parameter choices: how big, how often, how strict

Inclusion lists are only as good as their parameters. Make them too small and censorship slips through. Make them too large and builders lose room to optimize, shrinking MEV rebates to stakers and harming user fees.

A practical recipe is conservative: small fixed gas share for listed transactions, predictable selection (e.g., oldest-first among high-fee txs), lightweight witnesses (nonce/balance proofs), and penalties calibrated to outweigh any censor’s economic benefit.

Micro-scenarios: what it looks like on-chain

Suppose a transfer from a mixer pays a 60 gwei tip. A censoring builder would skip it, but the proposer lists it in a 200k-gas inclusion quota. Honest builders include it to win the bid, pocket the tip, and move on. The user sees inclusion within a slot or two, not an hour.

Or a spammer tries to game the list by broadcasting thousands of tiny high-fee transactions. The protocol caps the total list gas, and the proposer’s selection rule favors age plus fee density. Result: spam gets sliced; genuine delayed transactions rise to the top.

Open questions the ecosystem still needs to settle

There’s no shortage of design nuance. Several items remain active research and engineering work.

• How to measure “timely inclusion” across chains with varying latency and reorg risk.
• Whether to allow partial block auctions versus full blocks to improve flexibility.
• Best way to encode witnesses so they’re cheap to verify yet hard to fake.
• Protections against proposer misbehavior, like listing self-dealing txs to crowd out others.

These details matter because attackers will probe edges. The right defaults should make the common path cheap and honest, and the malicious path costly and visible.

Practical guidance for builders, validators, and users

Until ePBS arrives, operational choices still move the needle. Small disciplines help curb censorship and reduce reliance on any single actor.

1. Validators: diversify relays and monitor relay-level filtering; prefer configurations that forward all valid transactions.
2. Builders: publish inclusion compliance metrics and document witness handling; transparency invites order flow.
3. Wallets: surface inclusion delays and suggest fee bumps or alternative routes if a transaction is being filtered.
4. Searchers: design strategies that tolerate inclusion lists, e.g., bundle variants that respect listed txs.

These practices are incremental, but they stack. The market rewards participants who make inclusion predictable and censorship costly.

Why inclusion lists fit the builder era

Builders aren’t going away; they make blocks better and cheaper to use. The job now is to bind their power to rules that keep Ethereum credibly neutral. Inclusion lists provide the minimal constraint that preserves competition while protecting users from arbitrary exclusion. ePBS provides the scaffolding to enforce those constraints without trusted intermediaries.

Put simply: keep the auction, cut the gatekeeping. Make censorship expensive, verifiable, and rare—so ordinary transactions land with the reliability users expect.