ROP-9.4: FOCIL specs and implementation
Difficulty
Tags
Status
Matched
Created time
Apr 29, 2025
Involved
Phase
Project title
FOCIL Interops, Testing and Coordination
Associated ROP
Project summary
This project aims to push FOCIL interops between clients, provide test suites for both CL and EL and help coordinate core devs to be on the same page.
Project details
Project abstract
Ethereum currently operates under a single leader block production model, where block proposers sell their right to determine block content to specialized entities. With a few centralized entities dominating block production and controlling block contents, the status of quo that relies on them leaves the network vulnerable to censorship and threatens chain neutrality. Meanwhile, 90% of validators, who are far more decentralized, are not participating in this censorship. To address this erosion of censorship resistance, FOCIL (Fork-Choice Enforced Inclusion Lists) is proposed as a mechanism that brings agency back to the validators by enabling them to force-include transactions in Ethereum blocks.
FOCIL is the latest in inclusion list proposal, with key design properties:
- Multiple IL proposers
Having multiple IL proposers strengthens censorship resistance as the cost of censorship increases with the number of IL committee. Furthermore, throughout the process of constructing, broadcasting and aggregating inclusion lists, no single entity controls any step of the procedure, reducing the surface for attacks like bribery.
- Conditional inclusion
FOCIL adopts conditional inclusion, which accepts blocks that have sufficient gas left to include transactions from the IL and meet a specified inclusion threshold. This weaker guarantee of inclusion helps limiting the emergence of off-the-protocol markets that could arise from unconditional IL mechanisms.
- Anywhere-in-block
FOCIL is unopinionated about the placement of transactions from the ILs within a block. This lessens incentives for sophisticated actors to use side channels to bypass the mechanism. Combined with conditional inclusion, this flexibility makes it even harder for off-the-protocol markets to emerge.
- P2P objects only
The inclusion list data is not stored onchain but is distributed solely through the peer-to-peer network, preventing free data availability issue.
- Fork-choice enforced
FOCIL bakes the force-inclusion mechanism into the fork-choice rule, an integral part of the consensus process, preventing any actor from bypassing the system. Attesters vote only for blocks that include transactions from the IL aggregate satisfying the specified inclusion threshold. Any block that fails to meet this criterion is deemed invalid.
- There will be no incentive mechanism. We will rely on altruistic validators.
Currently, more than half of client teams are actively participating in FOCIL prototype. As we expect to achieve the interop between them in local devnets, we can now move forward to developing test suites for both CL and EL. This should provide a reliable testing environment for all client teams in future and would make it possible for us to expect each clients will have same behaviors.
Methodology
Phase 1
We aim to push client interops further to have local devnets of all clients that are currently actively participating. Currently we have partially interoping local devnets of Prysm and Lodestar and Lodestar and Teku, respectively. We want extend this to local devents of all three aforementioned clients, and later with Lighthouse.
In the meantime, any requests or needs for Prysm and Geth maintenance should be performed. Until now, Prysm serves as an exemplary implementation of FOCIL prototype and Geth serves as a reliable EL for CL client teams. Nevertheless, Prysm and Geth are not perfect and thus will require further improvements.
Last but not least, we can provide any kind of coordinating engineering effort whenever needed. For example, it could cover questions for clarity or historical context, updating specs, supporting testing environment such as eip7805 fork for ELs, and so on. It’s noteworthy that this coordinating effort will last presumably until we have FOCIL on mainnet.
Phase 2
With the help from STEEL team, we expect to develop test suites for EL using execution spec tests and Hive. EL client teams should be able to run these tests to verify if their implementations follow the spec and requirements correctly. It will start with feedback from Geth and Nethermind, which are the only ELs that currently participating, but it should be applicable to all the other ELs in future. Any feedback from other EL teams should be reflected to the test suites for better reliability and coverage.
Phase 3
On the CL side, we could use Assertoor for CL test suites. While Hive runs local devent for very short period of time usually 1-2 blocks, Assertoor runs a devnet for very long period of time spanning from dozens to thousands blocks. This makes Assertoor suitable for more complicated and life cycle tests. e.g., deploy a validator, wait until the validator onboarded, check validator’s status is active and ensure it proposes a block.
Same with EL test suites, CL test suites will begin with feedback from Prysm, Lodestar, Teku and Lighthouse and aims to be applicable for other CL teams in future. With test suites for both CL and EL, we expect to have more reliable FOCIL prototypes and facilitate more client teams to onboard.
References
- EIP-7805
- FOCIL Consensus Spec
- FOCIL Execution Spec
- FOCIL Prototype in Prysm
- FOCIL Prototype in Lodestar
- FOCIL Prototype in Teku
- FOCIL Prototype in Lighthouse
- FOCIL Prototype in Geth
- FOCIL Prototype in Nethermind
Deliverables
- Help clients interop
- Test suites for EL using spec tests and Hive
- Test suites for CL using Assertoor
- Geth and Prysm maintenance if necessary
- Provide coordinating engineering effort
Project repository link
Use the link to the public ROP page
Project start date
dd.mm.yyyy
Project end date
dd.mm.yyyy