Description

This censorship resistant website tracks topics of interest and lists blockers related to EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL).

Properties

  • Committee-based: FOCIL relies on a committee of multiple validators, rather than a single proposer, to construct and broadcast ILs. This approach significantly reduces the surface for bribery and extortion attacks and strengthens censorship resistance.
  • Fork-choice enforced: FOCIL incorporates the force-inclusion mechanism into the fork-choice rule, an integral component of the consensus process, thereby preventing any actor from bypassing the system. Attesters vote only for blocks that include transactions from a set of ILs provided by the IL committee and that satisfy the IL constraints. Any block failing to meet these criteria will not be voted on by the attesters, and therefore cannot be canonical.
  • Same-slot: With FOCIL running in parallel with the block building process for slot N+1 during slot N, the constraints imposed on block B for slot N+1 can include transactions submitted during slot N. This represents a strict improvement over forward IL designs like EIP-7547, where the forward property introduced a 1-slot delay.
  • Conditional inclusion: FOCIL adopts conditional inclusion, accepting blocks that may lack some transactions from ILs if they cannot append the transactions to the end of the block or if they are full.
  • Anywhere-in-block: FOCIL is unopinionated about the placement of transactions from ILs within a block. This reduces incentives for sophisticated actors to use side channels to bypass the mechanism. Combined with conditional inclusion, this flexibility makes the emergence of off-protocol markets less attractive.
  • No incentive mechanism: FOCIL does not provide explicit rewards for IL committee members participating in the mechanism. We believe that the added complexity of implementing a transaction fee system for FOCIL is not justified. Instead, we rely on altruistic behavior, as FOCIL requires only a 1-out-of-N honesty assumption from IL committee members for the mechanism to work as intended.

Resources

This gallery contains notes with problem statements of various subproblems related to FOCIL.

IL flooding in FOCIL

IL flooding in FOCIL

This post explores potential mempool flooding attacks on FOCIL and discusses mitigation strategies.

FOCIL, but with transaction hashes

FOCIL, but with transaction hashes

In this note, we explore the pros and cons of propagating only transaction hashes instead of full transactions on the consensus layer peer-to-peer network.

Transaction Invalidation

Transaction Invalidation

Other transactions in the execution payload could invalidate transactions in inclusion lists. Invalid transactions should not be written on-chain because it would expose free data availability (DA). How is free DA prevented in FOCIL? How does FOCIL prevent an adversary stuffing the IL with invalid transactions?

Open Problems