FOCIL, the inclusion list that prevents transaction censorship

Strawmap Hegotá (2027) · FOCIL

Each slot, a committee of 16 validators builds an inclusion list from transactions in the public mempool, and attesters do not vote for a block that leaves those transactions out. This mechanism makes sure transactions get into blocks on time without censorship.

Why it is needed

To keep the validator set from centralizing, Ethereum has auctioned the right to build blocks to specialized firms called builders. As a result, a small number of sophisticated builders came to dominate block production, and the network's censorship resistance, its ability to prevent specific transactions from being left out, got worse. Research followed on letting validators place constraints on builders, and the inclusion list, which forces specific transactions into a block, emerged as the answer. However, earlier designs had problems such as bribery and coercion attacks, double signing of lists, account abstraction, and transaction invalidation. FOCIL addresses these problems by having a committee of several validators build the list and by writing into the fork choice rule that attesters do not vote for a block that fails to satisfy the list. As a result, transactions on the list get into blocks on time without censorship. The Strawmap places it as the headliner of the Hegotá fork in 2027, but this is an estimate, not a commitment. On the core developer call, it was agreed to start a Hegotá devnet dedicated to FOCIL alone and merge it once it is stable. heze-devnet-2 will include it for validation together with other consensus layer candidates such as Quick Slots.

How it works

  1. The committee builds the inclusion list Each slot, 16 validators pick transactions from the public mempool, build an inclusion list, and sign it. How to pick, such as randomly, by fee order, or by longest wait, is left to the implementer. The total size of the list cannot exceed 8 KiB.
  2. The execution layer checks the block After executing all transactions in the block, it goes through the list one by one. Transactions that are already in the block, do not fit in the remaining gas, or have a wrong nonce or insufficient balance are skipped. If even one valid transaction that would execute if appended at the end is missing, the block is judged as not satisfying the list.
  3. Attesters do not vote for a non-satisfying block A block that fails to satisfy the list is valid in itself, but the consensus layer does not attest to it. Because this rule is part of the fork choice, if a proposer leaves out a transaction from the list, the block does not receive support from attesters.

Related EIPs

← Roadmap