EIP-7805: Committee-based, Fork-choice enforced Inclusion Lists (FOCIL)

Discussion thread for Committee-based, Fork-choice enforced Inclusion Lists (FOCIL) EIP by soispoke · Pull Request #9010· ethereum/EIPs · GitHub

Abstract

Implement a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion.

FOCIL (Fork-choice enforced Inclusion Lists) is built in a few simple steps:

  • In each slot, a set of validators is selected as inclusion list (IL) committee members. Each member gossips one IL according to their subjective view of the mempool.

  • The proposer and all attesters of the next slot monitor, store and forward available ILs.

  • The proposer (or the builder if the block is not built locally by the proposer) includes transactions from all collected ILs in its block. The proposer broadcasts the block including IL transactions to the rest of the network.

  • Attesters only vote for the proposer’s block if it includes transactions from all stored ILs.

Motivation

In an effort to shield the Ethereum validator set from centralizing forces, the right to build blocks has been auctioned off to specialized entities known as builders. This has led to a few sophisticated builders dominating block production, leading to a deterioration of the network’s censorship resistance properties. To address this issue, research has focused on improving Ethereum’s transaction inclusion guarantees by enabling validators to impose constraints on builders. This is achieved by force-including transactions in blocks via ILs.

6 Likes

FOCIL is nice in that it essentially creates a parallel building process of 16 independent actors. Only one of them needs to be honest about seeing a transaction for it to be included.

However, ILs point back to specific IL members. This information is kept on chain allowing specific transactions to be mapped to specific validators. So an IL member must always be willing to go on record that they did not censor specific transactions. This may deter some IL members. Can we do better?

We may be able to extend FOCIL so that no specific validator is attributable. Only that one of the 16 committee members was honest about the mempool state.

FOCILIS: FOCIL with indistinguishable submissions

This is an outline of an extension which involves to additions to FOCIL.

  1. Instead of signing an IL, a member creates a zero knowledge proof that they are a member of the committee.
  2. To identify equivocation, IL members generate IDs in advance. These serve as nullifiers. The IDs are broadcast in the preceding slot and included in the fork choice rule using the same mechanism used for the ILs. Attesters vote for blocks that have ID lists that match the local view.

Another framing is that this is a semaphore-like construction to enable private voting by the committee members on mempool contents.

I go into more detail in the repository below.

1 Like

FOCIL can be deployed in a near-future fork and in a later fork be upgraded to FOCILIS if desired. I think this is probably the wisest approach as FOCIL is specced, simple and ready. I’ve added some notes to this effect (basically around SNARK selection considerations being dependent on other potential consensus upgrades).

Thanks for your nice feedback and suggestions!

I think the general direction of unlinking IL committee members from specific lists of transactions is a very promising one.

This is also what we had in mind with anonymous inclusion lists (anon-ILs), my general intuition is that more research is needed to settle on a design we want to implement, but it’s great to see efforts in this direction.