MEV or Maximum Extractable Value has been one of the biggest concerns to Ethereum’s ethos of economic fairness, credible neutrality and censorship resistance. At its core, MEV is originated by the ability of proposers to include and order transactions within a slot, enabling different MEV techniques such as Sandwich attacks, Just-In-Time Attacks, Oracle Extractable Value (OEV) or Multi Block MEV. These tactics impact users not only economically but even degrade the user experience on the network. Is it possible to reevaluate how block proposing works?
Today, most of the validators have opted to outsource the block production to a set of entities who will 1) search the most profitable transactions in the mempool and 2) build the most profitable block. This has led the current block building landscape to be controlled by two builders who at some points represent over ~95% of the blocks built in Ethereum. These two builders can even have incentives to propose blocks as late as possible to extract even more MEV.
How do we solve MEV?
The truth is: we don’t know.
There are two different categories of thinking around MEV. On one hand, some people think MEV is intrinsic to Ethereum's decentralized nature, as information asymmetry will always exist. On the other hand, another group believes MEV is a consequence of the blockchain design and can be solved. Both perspectives are in some way correct and have led a wave of research into mechanisms like ePBS, Execution Tickets, Attester-Proposer Separation, MEV Burn, Braid, and Inclusion Lists. All of them focus on bringing clarity to the Dark Forest.
A recurring issue across these solutions is centralization: the rights to propose and include transactions often rest with a single entity so the logical step to break this monopoly is to introduce multi proposer rights to the playfield. One way to achieve this is through Inclusion Lists (ILs) which offer a compelling approach by decentralizing transaction inputs for block construction.
Inclusion Lists and FOCIL
Inclusion Lists is a design philosophy that enables a broader and more decentralized set of Ethereum participants to provide inputs about which transactions must be included in a block. In the traditional IL model, a validator in Slot n creates a list of valid transactions, which the proposer of Slot n+1 must include into its block. This design ensures that valid transactions will enter into the supply chain reducing the potential of censorship.
While different approaches have been analyzed the latest developments and conversations have been around the EIP-7805 or Fork-Choice enforced Inclusion Lists (FOCIL) which introduces a committee of validators, rather than a single proposer, to construct these lists.
The core goal behind FOCIL is to increase the Credible Neutrality of the network by allowing any valid transactions to be included into the protocol. FOCIL pretends to be a lightweight mechanism that could be improved in the future by being integrated with other mechanisms while keeping their robustness respecting their main goal.
Current parameters for the FOCIL design:
-
Committee selection: Each slot, 16 validators will be chosen to create local ILs that will be aggregated into one aggregate IL.
-
Each of these ILs will contain an average of ~20 transactions giving a total of ~360 ILs across 16 committee members.
-
The aggregated IL doesn’t condition the proposer to respect a specific order on the block.
-
Due a block containing around 100-200 transactions a block proposer should include transactions from the aggregated IL until the payload is full.
-
The aggregated IL only will be valid in the current slot and not enforce the next proposer to include any of the transactions remaining in the next slot.
This IL design is “enforced” thanks to Attesters, when a block satisfies the condition above (no more txs in the ILs or until the block is full) the Attesters vote for the block as valid.
Tradeoffs and challenges
As we can see, FOCIL is a design running in parallel with the block building process that introduces a committee of 16 proposers that will decide what transactions should be included in the block and a group of attesters validating that the block satisfies the IL conditions. Some of the unique advantages that FOCIL introduces are the preservation of Credible Neutrality by requiring only one honest committee member to ensure the inclusion of valid transactions, the boost on Solo Staker representation with a ~63% chance of at least one in any committee and the simplification of the model by avoiding economics incentives.
But not everything is so good. Today there are some concerns about the potential increase of resource demand like bandwidth or computational need that could lead to less nodes being able to participate efficiently. Also, the time to verify the ILs by the proposers could be insufficient specially if other upgrades like reducing slot times to 8 or 4s are implemented without mention the compatibility with other developments like ePBS, peerDAS, or even Account Abstraction also remains uncertain.
Are Economic Incentives Necessary?
The current design of FOCIL doesn’t provide any rewards for IL committee members participating in the mechanism. This decision has been taken to reduce the complexity around implementing this EIP. My thoughts are that it will be interesting to explore different scenarios and mechanism designs around incentives and penalties.
On the incentives side, ILs proposers could receive a percentage of the priorities fees of the next valid block as a retroactive reward once their ILs have been verified. Or a separate fee for inclusion in the IL could be considered taking as base the study from Fox, Pai, and Resnick in which they realize that including an auction mechanism reduces the probability of a bad actor winning the auction.
On the penalties side, bad behavior such as a committee member sending two or more ILs or failing to deliver the IL on time should be penalized to maintain the system’s integrity.
When FOCIL or ILs?
FOCIL is still in its early stage. Different ideas are still discussed and the team behind this EIP needs to evaluate all scenarios to ensure this proposal will effectively improve the censorship resistance properties of Ethereum. Probably we’ll see the final design of ILs in the next fork after Pectra.
In the meantime, if you’re interested in contributing to the discussion or learning more, here are some resources to explore: