Ethereum’s Block Reborn: Why FOCIL and ePBS Completely Redesign the Slot Structure
3-Point Summary
- Ethereum is redesigning its entire block‑building pipeline to overcome builder centralization and slot‑time rigidity.
- FOCIL introduces mandatory Inclusion Lists to strengthen censorship resistance and decentralize block content.
- ePBS formalizes proposer–builder separation with cryptographic accountability, enabling faster and safer slot times.
50-Second Shorts Video
Watch the 50-second video for a quick overview of how FOCIL and ePBS reshape Ethereum’s 12‑step block production pipeline.
Why Ethereum Is Rebuilding Its Block-Building Pipeline
— How FOCIL and ePBS Reshape the 12‑Step Block Production Process
Ethereum is entering a pivotal moment. Simply “making blocks faster” is no longer enough. The network must increase speed without sacrificing decentralization, censorship resistance, or validator diversity. To achieve this, Ethereum is undergoing a full redesign of its block‑building pipeline.
For years, Ethereum relied on a simple structure:
One proposer
One builder
A public mempool
A single block assembled by a single actor
This model worked, but it created two structural limitations:
Builder centralization due to MEV economies of scale
Slot‑time rigidity, because too much responsibility rested on one builder and one proposer
Vitalik’s roadmap introduces two major upgrades designed to break these bottlenecks:
FOCIL (Forced Inclusion Lists)
ePBS (Enshrined Proposer‑Builder Separation)
Together, they distribute responsibility across more participants and enforce cryptographic accountability—unlocking the possibility of shorter slot times.
FOCIL: Strengthening Censorship Resistance Through Inclusion Lists
FOCIL introduces a randomly selected validator committee that generates an Inclusion List (IL) at the start of each slot. This IL contains transactions that must be included in the block.
FOCIL ensures:
Censorship resistance — builders cannot exclude IL transactions
Decentralized block content — no single builder controls the block body
Predictable minimum inclusion — the network always knows which transactions must appear
FOCIL marks the shift from single‑actor block building to a multi‑participant model.
ePBS: Formalizing the Proposer‑Builder Separation
ePBS elevates PBS to the protocol level and introduces a commit–reveal mechanism that prevents last‑second manipulation.
The process works as follows:
Builders submit bids and payload candidates
The proposer selects the highest bid
The builder submits a cryptographic commitment to the payload
The proposer gossips a header containing the commitment and the IL
The builder later reveals the full payload
Validators verify that the payload matches the commitment
This structure guarantees:
Builders cannot alter the block after seeing the proposer’s choice
Proposers cannot reconstruct the payload to steal MEV
The builder market becomes permissionless, safe, and accountable
ePBS is the foundation for a more secure and transparent block‑building ecosystem.
FOCIL + ePBS Across the Full 0–12 Step Block Pipeline
Below is the complete 12‑step block production and verification pipeline.
0. IL Committee Forms → Generates IL → Gossips IL (FOCIL)
A randomly selected IL Committee creates the Inclusion List and broadcasts it across the network. This IL defines the minimum set of transactions that must appear in the block.
1. Builders Submit Payload + Bid to the Proposer (ePBS)
Builders compete by submitting payload candidates and bids in the open builder market.
2. Proposer Selects the Winning Builder (ePBS)
The proposer chooses the builder offering the highest bid. IL compliance will be checked later.
3. Builder Sends Payload Commitment (Commit Phase, ePBS Core)
The builder submits only a cryptographic commitment—not the payload itself—locking in the block body.
4. Proposer Gossips Block Header with IL + Commitment (FOCIL + ePBS)
The proposer publishes a header containing both the IL and the builder’s commitment. The network now knows:
Which IL must be included
Which builder was selected
What commitment the builder must honor
5. Builder Reveals the Payload (Reveal Phase, ePBS Core)
The builder reveals the full payload. The network prepares to verify commitment–payload consistency.
6. Validators Receive the Header (FOCIL + ePBS)
A selected validator subset (256–1024) receives the header and begins verification.
7. Validators Verify IL Compliance (FOCIL Core)
Validators check whether the block includes all IL transactions. Failure means the block is effectively invalid.
8. Validators Verify Commitment–Payload Match (ePBS Core)
Validators confirm that the revealed payload matches the earlier commitment. Any mismatch invalidates the block.
9. Validators Receive the Block Body (ePBS)
Validators download the payload to complete verification.
10. Validators Submit Attestations (FOCIL + ePBS)
Attestations are submitted only if:
IL compliance is correct
Commitment–payload consistency is correct
11. Attestations Are Aggregated (FOCIL + ePBS)
Blocks violating IL or commit–reveal rules receive fewer attestations and lose fork‑choice weight.
12. Fast Confirmation Rules → Fork‑Choice Update (Final Integration)
The chain head is updated based on:
IL compliance
Commitment correctness
Attestation weight
This is where FOCIL and ePBS jointly determine the canonical block.
Toward a Faster, Safer, and More Decentralized Ethereum
FOCIL and ePBS are not isolated upgrades—they represent a coordinated architectural redesign of Ethereum’s block‑building pipeline. By distributing responsibility and enforcing honest behavior, Ethereum can safely move toward:
8‑second slots
6‑second slots
4‑second slots
and eventually even faster
Ethereum becomes faster because it becomes more decentralized—not despite it.
Younchan Jung
Researcher exploring structural shifts in AI, blockchain, and the on‑chain economy.
If you would like to read this article in Korean, please click the button below.

댓글
댓글 쓰기