Can EIP-7732 (ePBS) and EIP-7805 (FOCIL) work together without conflict?

Yes, and here’s a breakdown of how:

What's the core idea?

Both ePBS and FOCIL make major changes to Ethereum’s slot structure:

• ePBS enables slot pipelining, giving more time for execution and blob propagation.

• FOCIL enhances censorship resistance by enforcing inclusion of specific transactions in each block.

The Key Assumption.

FOCIL doesn’t require inclusion lists (ILs) to be built on the latest canonical head. That’s what makes compatibility possible.

Even outdated ILs must be considered by builders, so ordering between duties isn’t critical.

Slot Flow with ePBS + FOCIL.

And this is how a post-ePBS world looks like:

• Slot N–1:Includers broadcast and bulid ILs:
→ Attesters freeze views.
→ Proposer freezes ILs, builds payload satisfying ILs.

• Slot N:Proposer runs fork-choice rule.
→ Picks builder payload.
→ Attesters check IL compliance before voting.

Split Enforcement Design.

Two options for verifying inclusion lists:

A. Attesters (Slot N).
They check if all known ILs were respected in the builder’s bitlist.
• Leverages full committee.
• Can lead to block reorgs if bitlist is incomplete.

B. PTC (Payload Timeliness Committee).
PTC checks bitlist inclusivity.
• Avoids beacon reorgs.
• Smaller validator set.

Both are viable in this case.

What Happens if Payloads Are Missing?

In earlier Inclusion list designs (EIP-7547), missed payloads cause to accumulate endlessly.

With FOCIL + ePBS, only the most recent missing-payload block’s IL must be satisfied.
→ Simpler.
→ More liveness-friendly.

A major synergy of FOCIL and ePBS is separating the beacon block from the execution payload.

So, this means that:

• The beacon chain can remain stable and canonical.

• A non-compliant payload can be rejected without reorgs.

Source: https://ethereum-magicians.org/t/epbs-focil-compatibility/24777

This post was written by Everstake, a responsible staking provider trusted by 735K+ users across 70+ blockchain networks.