EIP-7547: Inclusion lists

Discussion thread for Inclusion List EIP by michaelneuder · Pull Request #7943 · ethereum/EIPs · GitHub

Abstract

Censorship resistance is a core value proposition of blockchains. Inclusion lists aim to provide a mechanism to improve the censorship resistance of Ethereum by allowing proposers to specify a set of transactions that must be promptly included for subsequent blocks to be considered valid.

Motivation

Since the merge, validators have started outsourcing almost all block production to a specialized set of builders who compete to extract the most MEV (this is commonly referred to as Proposer-Builder Separation). As of October 2023, nearly 95% of blocks are built by builders rather than the proposer. While it is great that all proposers have access to competitive blocks through the mev-boost ecosystem, a major downside of externally built blocks is the fact that the builders ultimately decide what transactions to include or exclude. Without any forced transaction inclusion mechanism, the proposer is faced with a difficult choice: they either have no say on the transactions that get included, or they build the block locally (thus have the final say on transactions) and sacrifice some MEV rewards.

Inclusion lists aim to allow proposers to retain some authority by providing a mechanism by which transactions can be forcibly included. The simplest design is for the slot N proposer to specify a list of transactions that must be included in the block that is produced for their slot. However, this is not incentive-compatible because builders may choose to abstain from building blocks if the proposer sets some constraints on their behavior. This leads to the idea of “forward” inclusion lists, where the transactions specified by the slot N proposer are enforced in the slot N+1 block. The naïve implementation of the forward inclusion lists presents a different issue of potentially exposing free data availability, which could be exploited to bloat the size of the chain without paying the requisite gas costs. The free data availability problem is solved with observations about nonce reuse and allowing multiple inclusion lists to be specified for each slot. With the incentive compatibility and free data availability problems addressed, we can more safely proceed with the implementation of inclusion lists.

Related workinclusion-lists-related-work.md · GitHub

2 Likes

It provides a mechanism for proposers to retain some control over transaction inclusions, offering them authority in the block production process. :+1:

Ideally the proposer also has plausible deniability.

Super cool idea. Let me see if I get it straight though: We have two groups: validators and builders. Builders are censoring at a rate of X and Validators at a lower rate of Y. The idea here is to make it so that Validators can remove the ability of builders to censor their transactions, thus moving the whole system to min(X,Y) vs the current situation of max(X,Y)?

I think it is a win, but the big issue I have is that the reason validators weren’t/ aren’t censoring is that the legal culpability falls on the builders if they just “take the built block”. By adding in the ability to select the transactions, you could change the dynamic to where validators are now responsible for the transactions, thus making them more likely to censor (like the builders) and more of a regulatory target.

2 Likes

What do you think is a better split - 50/50? 33/67? 80/20?

Should it be closer to 50/50 or does this aim to give validators more than 50% authority in blocks built?

Thanks for all the writeups on inclusion lists, after reading through the material, I have a few questions / concerns and have not found a lot of discussion around this so far.

  1. Should the protocol be opinionated about transactions, especially since there does not seem to be a objective criteria to proof (onchain) that a transaction is being censored. I really dislike the fact that another proposer can force me to include transactions, e.g. what if the transaction I am forced to include will have legal consequences. Imagine a proposer in the US having to include OFAC txs, they either have to go to jail or miss the block?
  2. Currently, the only reason transactions are censored is due to legal reasons as far as I know. Let’s assume the US sanctions more smart contracts, wouldn’t this make builders in the US less competitive due to a reduced pool of transactions to choose from? If that assumption is true, then the problem would likely resolve itself as builders would have to relocate. I don’t see a economic reason for censoring transactions, it might even be the opposite as those transactions could pay higher fees due to delayed inclusion as not all builders process them.
  3. How much value would ILs provide if we assume that the vast majority of transactions will be on L2 in the future?
  4. I know this was quickly discussed in the CL meeting this week but it would be good to better understand why shouldOverrideBuilder is considered to be insufficient and something like IL is required, assuming there is a majority of honest / non-censoring proposers that care about the health of the network.
1 Like

for sure, but at some point, we need someone to push the txn in. the question becomes, who do we depend on for CR? builders or proposers?

thanks for your response! i don’t think the MIN/MAX thing is quite the right way of thinking about it though. the distinction comes from the fact that with inclusion lists, there are now multiple “versions” of a censoring proposer. A censoring proposer could (1) not use the IL, but still accept blocks from non-censoring builders, or (2) not use the IL AND not accept blocks from non-censoring builders.

While I agree that there will certainly be a lot of proposers in (1), I don’t think the addition of ILs will make any proposer change the set of builders they connect to (hope that makes sense). If that is the case, then ILs can only increase the CR of the protocol. Because some validators will opt in to using them, while some will leave them empty and maintain their setup of today.

It is worth mentioning that the honest specification will be to build the IL, so any proposer who wants to change this will need to modify their client directly and act “dishonestly” from the PoV of the protocol.

thanks for the reply!

one really cool thing about 1559 is it does provide an objective truth about what txns are being censored. namely, if the txn is in the mempool, pays the base fee, has a non-zero tip, and there is gas remaining in the block, it is being censored. regarding your second point, yes! that is the entire point of ILs. if as a validator, i have no choice but to include a transaction, then i have deniability from the protocol perspective. if you choose to miss blocks because you dont want to include transactions, then that is just the price of censoring, which should be high!

one thing to get straight here. we don’t know how builders will respond to ILs. For example, the builders have deniability in that they have to include a set of transactions in order for their block to be valid, so “censoring builders” of today may well build blocks that conform to ILs. we just don’t know. as to your second point, yes! running a censoring builder should be a competitive disadvantage! this is a great feature for improving the CR of the protocol.

potentially immense value considering L2 batch transactions could be censored in the future! the core protocol is the place to have CR, not the L2s IMO. i expect L2s to start censoring ofac transactions very soon. if the core protocol cannot provide CR properties, then no one can and i don’t think there is much value in the chain in that case.

fair! will write about this asap, thanks for bringing it up!

1 Like

Thanks for your response too! Any reason why the IL needs to be from the proposer? Why not give each of the a beacon commitees a txn in the IL and make it something the winning aggregator gets to choose? Especially with the MEV auction idea (or just in general) that proposers will become more sophisticated and centralized over time, this would mean that the inclusion list could remain sort of blue collar if that makes sense

  1. What incentive do validators have to submit an IL other than goodwill?
  2. Was there any analysis done on potential game-theoretic attack vectors? Validators backrunning next block, forcing loss-making txs, etc?
1 Like