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.

8 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.

PEEPanEIP 141: EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) with @soispoke and @Julian

1 Like

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).

Stakers Union Backs EIP-7805 (FOCIL) for Glamsterdam

Stakers Union has formally voted to support EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) for inclusion in the next Ethereum network upgrade, Glamsterdam. We believe FOCIL measurably improves censorship resistance, reduces builder centralization risk, and strengthens solo-validator sovereignty without adding undue operational burden to home stakers.

You can read more on our website (linked in profile).

2 Likes

Is there any subtlety to how FOCIL interacts with EIP-1559? I’m assuming FOCIL transactions still need to pay the base_fee to be considered valid for inclusion in a block – that’s implicit as part of this check, right?

Validate T against S by checking the nonce and balance of T.origin.
- If T is invalid, then continue to the next transaction.
- If T is valid, terminate process and return an INCLUSION_LIST_UNSATISFIED status.

I’m concerned that IL transactions could be used to bypass regular fees (priority fees?), which would incentivise users to bribe IL committee members to include their transaction in an IL rather than going via the normal route. However, I think this doesn’t work, as the block builder can choose not to include the IL transactions if the block is otherwise full of more profitable transactions. In other words, users gain no benefit from using IL transactions other than censorship resistance. There is no fee-benefit to using an IL transaction, right?

1 Like

that’s exactly right, FOCIL transactions definitely still need to pay the base_fee, so they need to have sufficient balance and a correct nonce.

And with the conditional inclusion property, builders can exclude IL transactions from their block if it’s full. So yeah, there’s definitely no fee benefit from using an IL transaction.

1 Like

Does FOCIL take OFAC into consideration?

I would consider myself to be a supporter of FOCIL, but I think I would prefer a stronger version. Let me explain what that means via specific examples, and feel free to correct me. I will put also a few other comments:

  1. After reading the pseudocode For each transaction T in ILs, perform the following..., do I understand correctly that the block builder (read: titan/buildernet) can freely choose to fill the entire block with transaction that are not part of any IL, and that is allowed as long as the block is full? What is the point of this EIP if it can straight up be ignored like this. I had hoped that at least one tx from every IL HAS to be included (so if I am part of the committee I can decide to only put a single tx in my IL and therefore have guarantee that this tx will happen now). A malicious builder can always craft a tx that wastes so much gas that there is an excuse to ignore all IL entirely.

  2. Right now there is no equivalent to sth like a mild inactivity penalty or a harsh slashing penalty for equivocation, maybe that should be looked into. To me this seems like malicious behavior, and yes it would complicate the EIP further but maybe that is worth it.

  3. The EIP code example shows: transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD]. What exactly is MAX_TRANSACTIONS_PER_PAYLOAD doing here? It is the only time this is used in the EIP.

  4. Very-late-equivocation: A malicious IL committee member can equivocate near or after the view freeze deadline. Nodes that observe the second conflicting IL before attesting may mark that validator as an equivocator and ignore its IL entirely, while nodes that do not observe the equivocation in time may continue enforcing the first IL they stored before freeze. This does not create new post-freeze inclusion obligations, but can it create an attestation split because some nodes relax obligations while others still enforce them?

  5. FOCILIS was already mentioned (and seems relevant to me) in regards to committee member privacy. In the current design I worry that u would prefer including your own tx so effectively u would dox urself/wallets linked to u or ur activity over time. The other issue is that if u publicly uncensor a controversial tx that would be the linked to ur identity (e.g. u were the reason a NK money laundering tx was added to the block)

All in all I am not sure how i feel about the ‘no incentive’ design: yes it keeps the EIP simple but it also makes it economically rational to sell your right to not censor to someone who wants to censor. Ironically the ‘Motivation’ part describes how currently auctioning-off your rights is commonly done and then presents an EIP in which it is economically rational to also auction-off your rights to put up an IL. (But maybe no one would buy this right because of 0.).

Feel free to address my concerns or correct any inaccuracies!

Interesting, very interesting.

Can we consider assigning validators as includers proportional to their stake, as is already done for proposers? The reason is that income from inclusion duties may discourage validator consolidation. To the extent that keeping stake split across smaller validators offers more of this income, it seems rational for an operator to do so. This could undermine consolidation, which is useful for fast finality.


To see why the inclusion role may carry income at all, first consider what a spot in an IL is worth to a transaction. The marginal value attributed to having a transaction in an IL can be loosely defined as the reduction in priority fees that still allows inclusion. In a non-full block, the sender of an IL transaction will not need to pay any priority fee. As long as the block producer is better off accepting an IL transaction than it would be by filling the block with dummy transactions in order to censor it, the transaction will get included. The marginal value to a transaction of the IL is thus affected by any frictions that transaction inclusion may incur, for example by making the block slower to propagate or introducing legal questions. Of course, the biggest frictions are incurred by transactions that would otherwise be censored for more indirect reasons, for example to force a liquidation and extract MEV, or even more “external” reasons, such as sanctions. But my point here is to highlight the sliding scale of “censorship” that may not involve outright refusal of inclusion, but rather hinge on the size of the priority fee.

Furthermore, the transaction may for that matter simply not reach the self-building solo staker in time through ordinary transaction gossip, such that the IL path is the only viable option for inclusion in that slot, thus giving that path value. And of course, a centralized builder set would do best to use any pricing power it has to not include transactions outside of the IL that pay too little in priority fees, even when there is room for them.

At the same time, we must suspect that priority fees will compress already with FOCIL. The compression is nevertheless likely to remain partial, if the ILs, each capped at 8 KiB, cannot hold every transaction that would benefit from them, especially once overlaps between them are taken into account. Thus, while the marginal value of a spot in the IL may be highest for transactions that would otherwise be censored for external reasons, more transactions may ultimately derive value from being in an IL.

It stands to reason that some of this value may accrue to includers, in the form of out-of-band payments, which includers base their inclusion decisions on. Competition from includers willing to list transactions for free may limit such payments, but senders excluded from, or uncertain of, those free options could still pay for reliable inclusion. The price of a spot may then reflect the scarcity of IL space and the value senders place on certainty. Competition among includers need not drive this price to zero if they cannot jointly accommodate every transaction that derives some value from a spot. Some of the value that would otherwise accrue to builders, and through their bids to proposers, may thus accrue to includers instead, shifting income from a role assigned in proportion to stake to one assigned per validator. To extract the most value, includers may need to expand their services to also negotiate the final payment to the block producer on behalf of senders in the case that the block is (potentially close to being) full, a payment which may also be made out-of-band.

Now, we must assess the importance of consolidating the validator set against the potential benefit of giving smaller validators a higher chance per unit of stake of becoming includers, thus potentially increasing censorship resistance. Uniform selection favours smaller validator balances, however, not necessarily smaller operators: a large staking service provider (SSP) can retain the same advantage by keeping its stake split across validators. Indeed, the more others consolidate, the more includer seats fall to those who do not. If 70% of the stake were consolidated into validators of 2048 ETH, the remaining 30% held in validators of 32 ETH would occupy about 96.5% of all includer seats in expectation. Were that 30% controlled by a party intent on censorship, it would hold all 16 seats in more than half of all slots, something that would practically never happen under stake-weighted selection. Uniform selection may thus weaken the very censorship resistance it appears to strengthen, for such a party has every reason to keep its stake split. This is not to deny that solo stakers holding 32 ETH would also gain seats, and thereby strengthen censorship resistance. The difficulty is that the protocol cannot tell their validators apart from those of a party that chooses not to consolidate in order to gain pricing and censorship power.

Under the assumptions outlined above, the inclusion role can thus give an SSP a reason not to consolidate, to be weighed against the modest operational savings that consolidation offers. Since the main benefits of consolidation accrue to the network as a whole rather than to the operator, even a modest income from inclusion duties could tip this balance. The income for includers may indeed be very small, because priority fees for openly propagated transactions may very well compress without accruing to includers. Some SSPs are already consolidating: perhaps due to a belief that it will be difficult to extract much value from the inclusion role, for operational simplicity, due to social pressure, or a wish that Ethereum prospers.

The social pressure to consolidate may be enough. What I am asking for is a closer discussion of our assumptions. The social pressure to make unprofitable choices is never as strong as the social pressure that can be achieved when the choice is neutral. A competing SSP may keep its validator set unconsolidated to attain a high probability of having at least one includer in any given slot, offering senders a reliability that no includer drawn at random can match, and taking payments out-of-band. Or such services may emerge in a more general fashion (analogous to MEV-Boost). This would make an SSP with a consolidated validator set less competitive.

We must finally also consider that the includer role is rather versatile and may come to be expanded in the future, giving even better opportunities for includers to extract value. If we pursue an encrypted mempool, the ILs can come to facilitate inclusion also for transactions that currently rely on private submission. If we pursue an expansive multidimensional fee market, UPIL may be adopted to preserve censorship resistance, allowing the ILs (together with the ranking fee) to force inclusion also in full blocks. We may also in the future allow includers to get paid directly by senders in-protocol, solidifying IL income also for validators that do not wish to rely on out-of-band payments. Admittedly, the balancing act here must also account for the actual value we assign to a consolidated validator set, in terms of reducing consensus overhead and making faster finality easier to achieve, and thus needs broader input from the ecosystem.

1 Like

Thanks for your comment!

I’m broadly against assigning includers in proportion to stake. It may discourage some consolidation (I’m not sure to what extent), but it would also weaken censorship resistance. With the current selection, every validator has the same chance of becoming an includer. When large operators consolidate, their seats go to smaller validators, including solo stakers, and that’s a feature I would want to keep.

I agree an operator could stay unconsolidated to keep more seats. But there are other, more targeted ways to incentivize consolidations (e.g., capping) and as you said includers don’t earn any rewards in the current version. i agree that if they do in a future upgrade/fork we can revisit but I wouldn’t give up this property now.