Thanks to Sarisht Wadhwa, Aikaterini-Panagiota Stouka, and Anders Elowsson for feedback on the post. Thanks to Thomas Thiery, Barnabé Monnot, and Caspar Schwarz-Schilling for discussions on the idea.

FOCIL is an inclusion list design proposed to be included in Ethereum via EIP-7805. The EIP does not include a reward mechanism for inclusion list committee members, or includers, since the additional complexity is currently not warranted. However, such a reward mechanism would contribute to the robustness of FOCIL in the long-term. Designing a reward mechanism is complicated. The objective may be to incentivize includers to include transactions that the block producer may otherwise exclude. The objective may also be to improve the long-term composition of the includer set to encourage includers to contribute to the long-term goals of FOCIL. These goals may overlap but may not be entirely equal.

Not only should the mechanism fulfill the objective, but the mechanism should also not be too invasive to implement, it should not uproot the EIP-1559 transaction fee mechanism (unless there are very strong arguments for it), and it should ideally make the cost of censorship, the minimum cost an adversary needs to pay to prevent a transaction from being included, higher than the cost of inclusion, the minimum cost a user needs to pay to get its transaction included on-chain.

Implementing a reward mechanism may not be without trade-offs. Thomas Thiery is leading a strand of research that aims to improve the privacy of includers. The goal is to prevent inclusion lists from being directly linked to a specific includer (see anon-ILs and zk-FOCIL). Proposals improving includer privacy are hard to reconcile with targeted reward mechanisms since their design makes it impossible to link performance to a specific includer.

On the other hand, significant efforts are being made to design the incentive mechanism. Notably, there is promising ongoing work by Aikaterini-Panagiota Stouka from Nethermind and AUCIL, a strong and innovative proposal led by Sarisht Wadhwa, Kartik Nayak, and Fan Zhang.

In this post, I propose an alternative incentive mechanism for FOCIL called IncluderSelect. This proposal has the following properties:

• The cost of censorship is higher than the cost of inclusion in the “usual” case.

• Compatible with privacy-enhancing variants of FOCIL.

• Relatively low cost of implementation.

The key intuition behind this proposal is that the users who want their potentially censored transaction included have an extrinsic motivation to create good inclusion lists such that an in-protocol fee split amongst committee members may not be necessary to ensure high-quality inclusion lists. This proposal aims to ensure inclusion lists include those transactions that most benefit from being included in an inclusion list.

IncluderSelect

In the following, the mechanisms of the proposal are discussed. Assume an inclusion list is created for slot n via the FOCIL mechanism.

Step 1: Includer Auction.

Users can submit bids of the form (bid, bytes) for the right to construct an inclusion list of size bytes* in slot n. Users should submit a bid that corresponds to the size of at least their transaction. Bids are included in the beacon block of slot n-1. Let the vector of all bids be denoted as b. Let the set of bidders be denoted as N.

To prevent censorship from bids by the beacon proposer of slot n-1, the system could either:

• Allow bids in earlier beacon slots, for example, during the interval n - k to n-1, for k greater than or equal to 1.

• Enforce that all bids seen at some predetermined time before the honest beacon block release time are included in the beacon block. This can be done via the class of consensus bids mechanisms, of which MEV-Burn is an instantiation.

Although the time difference between the deadline after which bids are no longer enforced via MEV-Burn and the honest beacon block release time leads to problems when applied to the block auction, it is not expected to do so in this mechanism. That is because FOCIL is specifically designed for transactions that carry little MEV, and their value is unlikely to change (drastically) over time, unlike the value of a block in Proposer-Builder Separation.

Step 2: Auction Settlement.

The auction winners are selected deterministically. In almost all cases, all bidders should receive the allocation they bid for since the maximum number of bytes available, M, corresponds to an amount of gas larger than the block gas limit. Since by the EIP-1559 transaction fee mechanism, the block should not usually be full, only in exceptional cases will M bytes be demanded. Moreover, usually few transactions per slot require the additional censorship resistance properties of inclusion lists, so only in very exceptional cases will all M bytes be demanded.

If at most M bytes are demanded, all bidders are allocated their demanded amount of bytes; their payments are processed via the payment rule p(M, b). The payment rule could, for example, be that of a first-price auction. The leftover number of bytes (M minus the sum of bytes demanded in all bids) are allocated to randomly selected includers like in the standard FOCIL mechanism.

If more than M bytes are demanded, the beacon proposer of slot n-1 runs a deterministic allocation rule, x(M,b) that specifies how M is split amongst the bidders. The allocation rule could be a knapsack rule in which the highest bids are prioritized until the number of bytes demanded exceeds M. Either the beacon proposer must attach a proof that it correctly allocated bytes to bidders, or attesters must enforce correctness.

Although there should almost never be enough natural demand for this allocation rule to be necessary, it is vital when there is a censoring adversary. A censoring adversary must buy M units of gas, regardless of the number of bytes, say c, the censored user demands. Since the allocation rule must be run correctly, the cost of censorship is higher than the cost of inclusion. Assuming that the bids that pay the highest price per byte are prioritized, the cost of censorship (without congestion) is about M/c times as large as the cost of inclusion, M/c is greater than or equal to 1. If the censored party only demands a few bytes, the cost of censorship can be far higher than the cost of inclusion.

Step 3: FOCIL.

The includers appointed in the second step become the inclusion list committee members of slot n. They propose inclusion lists according to the size of their bids in the same way as in the standard FOCIL mechanism.

IncluderSelect Properties

This mechanism ensures censored transactions are included within inclusion lists, thereby backstopping the effectiveness of the FOCIL mechanism, even though it does not explicitly foster a specialized set of includers long-term. The key intuition behind this proposal is that the users who want their transactions included are naturally incentivized to create “good” inclusion lists.

Bids are semantically similar to the priority fee (h/t Sarisht) that regular transactions pay; technically they differ because the bid is not tied to a transaction. This is important because it increases the cost of censorship. In FOCIL, a block producer could send fee-paying transactions into the mempool, but insert one transaction in the block that drains the balance of the sender address of those transactions, rendering them invalid. This leads to a low cost of censorship as it just requires the base fee of one transaction. This attack is not possible with IncluderSelect as bids are paid before the transaction that drains the balance of the sender address can be included in a block (h/t Aikaterini for bringing this up).

The implementation complexity of this proposal seems relatively approachable. At the minimum, bids must be recorded on the beacon chain for a few blocks, and an allocation rule must be determined. It would be preferable to have a consensus bids system, as described in Step 1, to prevent censorship of bids within one beacon slot. Like in EIP-7805 (FOCIL), no inclusion lists must be recorded on-chain to split rewards, and no separate fees are necessary for users.

Moreover, once the includers are selected (after step 2), it is possible to implement privacy-preserving techniques like anon-ILs or zk-FOCIL to prevent inclusion lists from being linked to any specific includer. Other incentive mechanisms that rely on rewarding includers for specific contributions are harder to merge with privacy-preserving techniques.

* Note that inclusion lists in the FOCIL context are measured in terms of bytes, not in gas units. This is because inclusion lists almost solely consume bandwidth