Censorship Resistance in Consensus Protocols
Liveness guarantees in consensus protocols do not imply short-term censorship resistance. Standard BFT protocols ensure transactions are eventually included if an honest leader gets a slot — but a Byzantine adversary can censor specific transactions for many consecutive rounds without creating a detectable liveness failure. This gap is particularly dangerous for on-chain auctions and MEV-sensitive applications. (→ NoConsensus.wtf 2025 — Overview)
Liveness vs. Censorship Resistance (Odysseas Sofikitis / Common Prefix)
The auction attack: an adversary bribes validators to exclude high-value bids. From outside, the chain appears to be making progress. But honest bids never land. The adversary wins with a sub-optimal bid by making the optimal bid invisible.
Short-term censorship resistance (STCR): a transaction submitted to an honest validator must be included in the very next block (or at most within a small bounded number of rounds), not just eventually. Standard liveness fails this test.
Why STCR matters beyond auctions: any time-sensitive application — liquidations, oracle updates, governance votes with deadlines — is vulnerable to strategic censorship that exploits the gap between “eventually” and “immediately.”
Analysis of Existing Protocols (Common Prefix Research, ~2024)
| Protocol | Censorship Behavior |
|---|---|
| Tendermint | Must wait through all malicious leader slots (f rounds). Honest inclusion requires an honest leader to appear. |
| HotStuff (pipelined) | Responsive, but still requires an honest leader for guaranteed inclusion. |
| DAG-based (Bullshark, Shoal, etc.) | Leaderless — no single validator can block inclusion. But: much higher latency penalty. |
Gadgets to patch non-DAG protocols:
- Inclusion lists (EIP-7547 / EIP-7810 style): proposers must include a list of pending transactions or justify exclusion. Partially effective but gameable at edges.
- DA layer: dispersal proofs showing transactions were available to validators. Adds overhead.
- Reliable broadcast: client sends transaction to all validators with signed receipts. Provides accountability but not prevention.
These can achieve near-zero censorship but at significant cost; they’re patches on top of a protocol that wasn’t designed for STCR.
A Leaderless Primitive for STCR (Odysseas Sofikitis)
A simpler alternative: bypass consensus entirely for transaction attestation:
- Client sends transaction to all validators.
- Each honest validator signs the transaction + a timestamp and returns an attestation.
- Client collects a quorum of attestations (2f+1).
- Quorum proves the transaction was seen by enough validators at a specific time.
- Auctioneer reads transactions streamingly from validators with timestamped proofs, constructs bid set from all transactions within the auction window.
Properties:
- No leader: no single validator can prevent attestation.
- Speed: as fast as network delay (single round-trip vs. multiple consensus rounds).
- Provable completeness: the auctioneer has cryptographic proof that all submitted transactions in the window were considered.
- No consensus needed: safety and finality come from the application layer (the quorum), not from total ordering.
This primitive was the conceptual basis for the POD protocol (Common Prefix), designed for censorship-resistant on-chain auctions.
Phil Daian’s Stronger Claim
Inclusion lists and consensus-layer STCR gadgets are insufficient against state-level adversaries who can:
- Observe all network traffic and identify validator IPs.
- Throttle or block specific packet flows at the ISP/infrastructure level.
- Coerce validators through legal means when their identities are known (see Validator Deanonymization on Ethereum’s P2P Network).
The required response: the entire stack must be private. Anonymous broadcast (see Anonymous Broadcast) hides transaction sources from the network. Validator identity protection hides who is attesting. Together they create a system where censoring a specific transaction requires compromising the cryptographic protocol, not just bribing a known infrastructure operator.
“Ethereum go dark” — Phil Daian’s framing: the P2P layer, mempool, and validator communication should all be made private before state-actor censorship becomes a serious threat.
Connections
- Anonymous Broadcast — Full-stack censorship resistance requires P2P privacy, not just consensus gadgets
- Distributed Block Building — BuilderNET faces network-layer censorship even inside TEEs
- Validator Deanonymization on Ethereum’s P2P Network — Known validator identities make coercion-based censorship practical
- Ethereum Scaling Roadmap — Inclusion lists are on the Ethereum roadmap; this analysis provides context for their limitations
- NoConsensus.wtf 2025 — Overview — Conference context
Open Questions
- Can POD-style leaderless attestation be integrated with Ethereum’s consensus without a hard fork?
- Are DAG-based protocols (Narwhal/Bullshark, Autobahn) the right answer for STCR, or is the latency penalty unacceptable for L1?
- Does “Ethereum go dark” require full DCNet-based anonymous broadcast, or do weaker privacy guarantees suffice for practical censorship resistance?
- How do you prevent the leaderless attestation quorum from being gamed (e.g., equivocation attacks on the timestamp proofs)?