IL Tx Scoring Function in FOCIL

Background

In a naive implementation where the local EL client sorts transactions by priority fee, an adversarial actor (e.g., the proposer for slot n+1) could flood the mempool with their own transactions, occupying most of the available space in inclusion lists (ILs). When proposing a block, this actor could intentionally invalidate these transactions, incurring minimal cost. As a result, the IL space is wasted, reducing efficiency and affecting overall IL performance.

Costs

• The IL committee sorts transactions received from the EL mempool by priority fee.
  • For example, with a base fee of 10 gwei and a priority fee of 10 gwei, it would cost around 0.005 ETH ($13.11 USD) to crowd out the entire 16 KB inclusion list for non-zero calldata, and about 0.001 ETH ($3.20 USD) for zero bytes calldata.
• A single EIP-7702 transaction could further invalidate multiple transactions by removing balance from EOAs associated with those IL transactions from slot n. This allows the proposer of slot n+1 to bypass the inclusion list at a reasonable cost.
  • The cost for each invalidated transaction scales linearly 9,000 gas, plus the 21,000 gas base transaction cost.

Scoring function

The current approach of the IL committee packing transactions from the local mempool using only priority gas fees is insufficient and can easily be manipulated. To improve this, we propose defining a more robust scoring function for transactions in the mempool. The variables for this scoring function are defined below, but the approach is not limited to these variables. Each client should be able to choose its own variants, which will enhance client diversity. With this variability, the IL transactions become more challenging to exploit, as the IL committee will be composed of different client implementations.

• $T{x}_{PriorityFee}$: The priority fee of the transaction.
• $T{x}_{MemPoolTime}$: The number of slots the transaction has spent in the mempool while being eligible for inclusion but not included.
• $T{x}_{ReorgTime}$: The number of times a transaction has been included in a block but was subsequently reorged out.

Bonuses:

• $T{x}_{HasAddress}$: The transaction receives a bonus for interacting (or not interacting) with a specific address. This could be user-configurable, allowing for flexible prioritization based on address-specific preferences.

Then, for example, a possible scoring function could be:

$S(Tx)=T{x}_{PriorityFee}\times (1+T{x}_{MemPoolTime})\times e^{\beta \cdot T{x}_{ReorgTime}}$

Where

$\beta$ is a positive constant that controls the exponential scaling based on reorgs. A higher

$\beta$ value means the score will increase more sharply with each additional reorg.