# Inclusion Lists for ePBS & mev-boost `Jai Siyaram` ## Background ![image](https://hackmd.io/_uploads/H1LJujyE0.png) *source : https://explorer.rated.network/builders* The current methods of MEV extraction require validators to outsource block building by out of protocol systems like flashbots (open source) [mev-boost](https://github.com/flashbots/mev-boost). According to a source ~94% of the blocks in ethereum are being built by just 3 builders!😶‍🌫️ While Flashbots is open source and works well, it's not exactly in line with Ethereum's core values of decentralization, trustlessness, and censorship resistance. Relying too much on a few key players, isn't good. There is a need for in-protocol or enshrined proposer-builder-seperation to mitigate non-user-value-additive MEV capture, basically protect the innocent users from falling victim to MEV strategies such as sandwich trades or front-running. Current discussions on ePBS designs: [Two-slot PBS](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980), [PTC](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054/1). Whether we go with ePBS or mev-boost, block proposers seem to have no say in their own blocks. The censorship risks, pretty evident from the figure below...😶 ![image](https://hackmd.io/_uploads/S1tDzz0XC.png) *source : https://censorship.pics/* This is where Inclusion Lists (ILs) come into picture. They allow proposers to retain some authority by providing a mechanism by which txns can be forcibly included. ## Design The naive design of ILs to be made for the same block is incentive-incompatible and will not be accepted by builders coz they need money & not restrictions so proposers will be forced to create empty ILs. Hence the idea of forward ILs (creating ILs for the next block) along with some considerations was proposed in [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547) by mike, Vitalik, Francesco, Terence, potuz & Manav. The design of IL comprises of a summary and a list of txns. summary = (sender address, gasLimit) of the txns to be included in the blockchain and the corresponding txns in the txn list. The summary needs to be satisfied necessarily and not the Txns list, so if any other txn that is not in the list and satisfies an entry of the summary (has same sender and gasLimit), then the txn from the Txns list need not be included. The is simplified design, the exact specs of ILs are [here](https://ethresear.ch/t/specing-out-forward-inclusion-list-w-dedicated-gas-limits/17115). ![image](https://hackmd.io/_uploads/BkQV3-y4A.png) ## How it works Slot n proposer creates an IL (summary+Txns), signs the summary on the EL (execution layer). This is sent to CL (concensus layer) and then gossiped to the network along with the block n. The txns that accompany the summary should be valid based on slot-n-pre-state. The slot n+1 proposer will receive the block n and one or more ILs. It then checks if the ILs are valid and hence fork-choice rule is applicable i.e. it can build on the block n. It then sends the block+ILs to mev-builder. The builder can thus select among the most profitable ILs to build upon. The summary of the IL can be satisfied by txns in block n or n+1. If it isnt satisfied then the block n+1 will be considered invalid. The block n+1 needs to contain the IL summary and signature that it satisfies, so that the IL fulfillment and signature can be validated by the rest of the network(validators). The Crux! ![image](https://hackmd.io/_uploads/HyW2EBgEA.png) Few Validation Points to consider: • The txns of IL should be valid in N-pre-state. • The maxFeePerGas should be at least 112.5% of the block n base fee. • The accompanying Txns should fulfill entries of summary. • The signature over the summary should be valid. ## Q&A on apparent issues * ***Why only one IL txn per-address-per-slot is allowed?*** To protect from situations for example: a user creates tx1(nonce 10, gasLimit 15), tx2(nonce 11, gasLimit 16) which are valid in n-pre-state and these both get into the IL. Then to exploit the system he creates another txn1b(nonce 10, gasLimit 15) which drains eth from the account and hence txn2 becomes invalid and the IL can't be satisfied. * ***What if the slot n+1 proposer doesnt like the IL restrictions & denies having received any ILs?*** For the fork-choice rule to be applicable on the block, there needs to be atleast one valid IL for that block. So the n+1 proposer needs to consider the IL, in order to proceed forwards. The block n is considered for fork-choice rule only if validators see a valid IL by the block proposer. So for that proposer-n should broadcast block+IL, or his stake will be slashed for producing invalid block. Similarly if n+1 proposer denies recieving the IL, basically proposes a block not satisfying the IL, then as the IL is in the view of the validators, his block becomes invalid. * ***Can block N proposer DoS N+1 proposer (by multiple txns with same nonce)? Multiple txns with same nonce can lead to bloating and free data availability issues. How is it ensured that this doesn't happen?*** This doesnt happen because we are commiting on the summary and not on any specific txn which might get invalid in n-post-state. As for the free data availability issue... this can only happen when there are multiple txns satisfying the same entry in the summary or the case of multiple txns with same nonce. In the first case out of all those txns, the one that matters is the one that makes it to the chain and others could be discarded and need not be stored. In the case of nonce reuse, only one txn can be claimed as valid, and obviously it will be the one that will satisfy the IL summary and others being discarded. * ***What if the proposers of n, n+1 slot collude?*** In this simplified design of the IL application, there is no measure to prevent this. But thinking it in a broader sense, why do we use ILs in the first place? to grant some authority to the proposers over the txns in their blocks, and to prevent censorship that comes with builders. If a validator doesn't want this and colludes to create empty ILs, there isnt much incentive other than the bribe from MEV. This would happen if there are MEV txns of very high value at some particular time and only by a small percentage of validators, but in the overall picture as there are validators woking honestly the ILs will strengthen the censorship-resistance(CR) of ethereum. That being said, this issue still needs more research. ## Issues One of the biggest problem seems the compatibility of IL design with account abstraction in the functioning of ILs. As AA allows for more complex interactions between transactions from different accounts, which can lead to cross-invalidation i.e. a transaction from one account can invalidate a transaction from another account, creating a potential vector for DoS attacks. This could be exploited to disrupt the validity of subsequent blocks, causing the next proposer to miss their slot. I'm not very sure about the integration of these two. This needs thought. A lot of issues are solved just bcz sender is listed rather than the txns. Know more, [here](https://github.com/ethereum/EIPs/pull/7943). # References :::success [No free lunch – a new inclusion list design](https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389)\ [MEV- Eth docs](https://ethereum.org/en/developers/docs/mev/)\ [ePBS design constraints](https://ethresear.ch/t/epbs-design-constraints/18728)\ [Payload-timeliness committee (PTC) – an ePBS design](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054/1)\ [EIP 7547](https://eips.ethereum.org/EIPS/eip-7547)\ [EIP 7547 Eth Magicians](https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474)\ [EIP 7547 PR & Discussion](https://github.com/ethereum/EIPs/pull/7943)\ https://www.youtube.com/watch?v=oRjG0RMnK5U [Why enshrine Proposer-Builder Separation? A viable path to ePBS](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710) :::