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.
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.
Instead of signing an IL, a member creates a zero knowledge proof that they are a member of the committee.
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.
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).
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.
I have some thoughts on the IL building rules. Currently the spec leaves the IL building rules fully unspecified, allowing clients to decide. While this aims to promote a diversity of IL building rules which can strengthen censorship resistance, I believe there is a risk that many clients could implement similar deterministic rules.
For example many clients could implement a simple order-by-priority fee strategy. If all IL committee members are using the same deterministic ordering strategy then (assuming they have a similar set of transactions in the client txpools) all members would build the same IL. When we take the union we will get an 8KiB IL rather than the theoretical maximum of 128KiB. This undermines censorship resistance, as now a single 8KiB transaction with a high priority fee can censor all other transactions from the mempool. Reducing the amount of overlap between ILs would increase the size of the IL when they are combined, meaning there is more throughput to force-include transactions.
Even if different clients use different ordering rules, it is still possible that we end up with an IL committee all running the same EL client. If these rules are deterministic then we would have the same situation of completely overlapping ILs.
I propose to recommend that implementers should aim for a more disjoint and nondeterministic set of ILs while leaving the exact algorithm unspecified. This can be done by introducing randomness, and using bias to pick some transactions more often than others. This would work by giving each committee member an id from 0 to f; the member with id a would then be more likely to pick transactions with hashes that start with a. Adding bias could further reduce the amount of overlap between ILs while crucially not eliminating it entirely.
This would be desirable. An author of this EIP (Francesco) previously outlined such ideas with further details in the following write-up (refer to the second half of the post).
