Thanks to Jihoon Song, Caspar Schwarz-Schilling ,Terence Tsao, Jacob Kaufmann and Francesco D’Amato for feedback and comments on this note.
This document follows a template designed by @timbeiko to propose a headliner for a fork inclusion.
Summary (ELI5):
Fork-Choice Inclusion Lists (FOCIL, EIP-7805) improve Ethereum’s censorship resistance by enabling multiple validators to ensure that any transaction valid under protocol rules is included in blocks.
Why it matters:
Censorship resistance, permissionlessness, and credible neutrality are core Ethereum values. Today, >80% of all blocks are produced by two builders who can unilaterally decide whether to include or exclude transactions (clearly illustrated by data from censorship.pics, where the level of builder censorship fluctuates significantly over time). FOCIL fixes this by empowering the decentralized set of validators to enforce inclusion constraints on builders’ blocks, restoring fairness and ensuring Ethereum remains decentralized and neutral.
Who directly benefits:
This directly benefits all users by ensuring their transactions are included on-chain in a timely manner as long as the network is not congested, without having to rely on two centralized entities to not censor them.
Why now?
A solution to mitigate the censorship risks arising from the centralization of the builder market is long overdue. The builder market is inherently prone to centralization due to MEV and private order flow, and we have observed increasing vertical integration across builders, relays, and searchers over time. Ethereum must enforce protocol-level guarantees to users that their transactions will land on-chain, as long as they are valid according to protocol rules, not subject to external preferences. FOCIL should be implemented now, before more significant censorship behavior emerges and makes protocol-level changes that improve censorship resistance more difficult to coordinate and adopt.
Detailed Justification:
Primary benefits:
- Improving censorship resistance of Ethereum: Ethereum’s current block production is heavily centralized, with two builders constructing more than >80% of all blocks. FOCIL significantly reduces this centralization risk by empowering multiple decentralized validators to enforce transaction inclusion, preventing any single entity from arbitrarily censoring transactions.
- Scaling Ethereum without imposing constraints on local block builders: By allowing validators to independently enforce transaction inclusion, FOCIL represents the first step toward scaling Ethereum throughput without depending on local block builders to preserve censorship resistance at the cost of performance or incentives (Decoupling throughput from local building - Economics - Ethereum Research).
- Improved user experience by reducing transaction inclusion time: With today’s centralized block-building process, if the two dominant builders choose to exclude specific transactions, users would experience delays averaging around 7 blocks (approximately 84 seconds). FOCIL ensures prompt and reliable transaction inclusion unless the block is full, significantly enhancing overall user experience.
Technical Readiness:
FOCIL demonstrates a high level of technical maturity. It has already been implemented by six client teams and successfully runs on a local devnet with Prysm, Lodestar, Teku, and Geth interoperability. It is currently undergoing spec testing, with additional local devnet testing using Assertoor scheduled to begin in the next few weeks. The consensus-layer specification has undergone preliminary review by CL client teams, and the execution-layer specification is now under review by EL client teams.
- Consensus Specification: EIP-7805 -- The Beacon Chain - Ethereum Consensus Specs
- Execution Specification: feat: add initial EIP-7805 by jacobkaufmann · Pull Request #1214 · ethereum/execution-specs · GitHub
- Execution APIs: Add initial FOCIL spec by jihoonsong · Pull Request #609 · ethereum/execution-apis · GitHub
- Consensus Layer
- Execution Layer
Security & Open Questions:
FOCIL (EIP-7805) includes clear mitigation strategies for key security risks such as consensus liveness, IL equivocation, and fork-choice related changes, all detailed in the EIP. The design is also compatible with EIP-7702 and other proposals like Delayed Execution (EIP-7886), BALs (EIP-7928), or ePBS (EIP-7732).
Resources:
Implementation progress, research posts, and talks about FOCIL can all be found at https://meetfocil.eth.limo/