How Focil and ePBS Are Rewriting Ethereum’s Block Production Pipeline

3-Point Summary

• The MEV structure is increasingly concentrating power in a small number of Builders and Relays, causing Ethereum’s block production pipeline to solidify into a centralized architecture.
• Issues such as weakened censorship resistance, Payload verification bottlenecks, and insufficient Proposer authority reduce transparency and fairness across the network.
• Ethereum aims to fundamentally resolve centralization, censorship, and bottleneck problems by redesigning its pipeline through Focil and ePBS.

Exploring how Focil and ePBS fundamentally reshape Ethereum’s block production pipeline toward a faster, safer, and more decentralized future.

50-Second Shorts Video

Watch the 50-second video to understand why Ethereum is redesigning its block production pipeline before diving into the full analysis below.

1. Why Ethereum Is Redesigning Its Block Production Pipeline

MEV (Maximal Extractable Value) refers to the economic profit that block producers can obtain by reordering, including, or excluding transactions within a block.

The problem is that MEV revenue is increasingly concentrated among a small number of Builders, while the Relays that mediate block delivery and validation are also operated by only a few entities. As a result, Ethereum’s block production pipeline has effectively solidified into a centralized structure. In the current architecture, Builders hold excessive economic power, and Relays hold excessive informational and delivery power.

Validators cannot directly inspect the contents of a block and must rely on the Payload provided by the Relay. This reduces transparency and increases the risk that certain transactions may be intentionally excluded, weakening censorship resistance.

Ethereum’s motivation for redesigning its pipeline is to fundamentally address the centralization, censorship, and bottleneck issues that arise from the current MEV extraction process.

• MEV structure accelerates Builder centralization
• Execution Payload verification creates bottlenecks
• Proposers lack sufficient control over block contents
• Potential weakening of censorship resistance
• Structural limitations that hinder slot-time reduction

To understand how these issues manifest in practice, it is helpful to examine the full lifecycle of an Ethereum transaction. Let’s walk through each stage of the pipeline.

2. Ethereum Transaction Lifecycle

Ethereum transactions are processed through cooperation between the Execution Layer (EVM) and the Consensus Layer (Beacon Chain). The following sections describe what happens at each stage and how Focil and ePBS address specific problems.

① Transaction Submission — Basic Execution Client Validation

A transaction is sent from a wallet to a node, where the Execution Client performs basic validity checks such as signature, nonce, and gas limit.

Valid transactions are stored in the mempool, sorted by fee, and propagated across the network. Focil and ePBS do not intervene at this stage.

② Pre-Execution Validation — EVM Transaction Eligibility

The EVM performs deeper validation, including fee calculations and state simulation, to determine whether a transaction can be included in a block.

However, under the current structure, Builders can selectively include or exclude transactions, creating censorship risks. In other words, Builder discretion can distort the fairness of the network.

Focil Intervention

• Uses an Inclusion List (IL) to specify transactions that must be included
• Prevents Builders from arbitrarily excluding transactions

ePBS Intervention

• Separates Proposer and Builder roles to remove Proposer incentives for MEV extraction
• Reduces structural incentives to exclude transactions

Problems Addressed

• Strengthened censorship resistance
• Reduced MEV-driven selection distortion

Once a transaction is deemed valid, the next step is selecting the validator who will propose the block.

③ Proposer Selection — Consensus Layer

In each slot, a validator is chosen to propose a block. In the previous architecture, Builders monopolized both block construction and submission.

ePBS separates these powers: Builders construct Payloads, and Proposers choose one Payload from multiple Builders.

Problems Addressed

• Mitigation of Builder centralization
• Improved censorship resistance

Once the Proposer is selected, the next question is: which transactions will be included in the Payload?

④ Execution Payload Construction — Builder Transaction Selection

Builders select transactions from the mempool to construct the Execution Payload. This is the stage where MEV, censorship, and centralization issues are most severe.

Focil Intervention

• Enforces Inclusion Lists
• Shifts Payload construction authority from a single Builder to a multi-party structure

ePBS Intervention

• Limits Builder authority
• Gives Proposers final selection power

Problems Addressed

• Decentralization of block contents
• Strengthened censorship resistance
• Reduction of Builder centralization

The constructed Payload is then ready to be included in a Beacon Block. This is where the difference between the old architecture and ePBS becomes most apparent.

⑤ Beacon Block Creation and Inclusion — Consensus Layer

A. Previous Architecture — Builder Determines Block Contents

The Consensus Layer simply included the Payload created by the Builder. The Proposer’s role was largely ceremonial, with no real decision-making power.

As a result, Builders effectively controlled block contents, reinforcing centralization.

B. ePBS Architecture — Proposer Exercises Final Choice

Proposers receive multiple Payloads from Builders and choose one to include in the block. Builders only “propose” Payloads; they do not control final inclusion.

Focil Intervention

• Reduces Payload verification overhead
• Simplifies node operation by clarifying Execution vs. Consensus roles

ePBS Intervention

• Structurally limits Builder influence
• Reduces centralization risks

Once a block is proposed, the network must verify its legitimacy.

⑥ Attestation — Validator Voting

Validators form randomly selected committees to vote on block validity. If two-thirds of the committee votes for the same block, it is accepted as valid.

Focil Intervention

• Reduces validation overhead
• Decreases attestation delays

ePBS Intervention

• None (pure Consensus Layer function)

Problems Addressed

• Foundation for slot-time reduction
• Reduced node operational complexity

Finally, the block reaches Finality and becomes irreversible.

⑦ Finality — Irreversible Confirmation

Blocks achieve finality at the epoch level. Once finalized, a block cannot be reverted.

Focil Intervention

• Maintains Inclusion Lists even at finality
• Ensures censorship resistance and decentralization

ePBS Intervention

• None

Problems Addressed

• Reduced node complexity
• Preserved decentralization of block contents

3. Summary: Mapping Each Stage to Its Goals

Transaction Stage	Goals Addressed
Transaction Submission	—
Pre-Execution Validation	Stronger censorship resistance
Proposer Selection	Reduced Builder centralization, stronger censorship resistance
Payload Construction	Decentralization, censorship resistance, reduced centralization
Beacon Block Inclusion	Slot-time reduction foundation, reduced node complexity
Attestation	Slot-time reduction foundation, reduced node complexity
Finality	Reduced node complexity, preserved decentralization

4. Conclusion: Ethereum Is Moving Toward a Faster and More Decentralized Future

Focil and ePBS are not mere performance upgrades—they represent a fundamental redesign of Ethereum’s block production pipeline.

Together, they achieve five major goals: reducing Builder centralization, decentralizing block contents, strengthening censorship resistance, enabling shorter slot times, and simplifying node operations.

Ethereum is evolving into a faster, safer, and more decentralized network—and Focil and ePBS are key components of that transformation.

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.

Read This Article in Korean →