The Case for ILECTRA

# The Case for ILECTRA <img src=https://storage.googleapis.com/ethereum-hackmd/upload_66702f46f66fe344a9cc46fe6f068b34.png width=92%> **^*ILECTRA is a portmanteau of "Inclusion Lists" (abbr. IL) and "Electra" (the next Ethereum hard fork). lol.*** $\cdot$ *by [mike](https://twitter.com/mikeneuder) – friday, march 15, 2024. ([18-month anniversary](https://www.reddit.com/r/relationship_advice/comments/ng54jq/is_an_18_month_anniversary_a_thing/) of [The Merge](https://ethereum.org/en/roadmap/merge/)!!)* $\cdot$ *Many thanks to [Justin](https://twitter.com/drakefjustin), [Lion](https://twitter.com/dapplion), [Julian](https://twitter.com/_julianma), [Thomas](https://twitter.com/soispoke), [Toni](https://twitter.com/nero_eth), and [Tim](https://twitter.com/timbeiko/) for comments on the draft of this document.* > **Note:** *The following is the author's opinion alone. Reviews are not necessarily endorsements (though Justin said he explicitly gives his endorsement :).* $\cdot$ **Contents** 1. [Context](#1-Context) 2. [Reasons to ship inclusion lists](#2-Reasons-to-ship-inclusion-lists) 3. [Reasons to ship inclusion list *in Electra*](#3-Reasons-to-ship-inclusion-lists-in-Electra) 4. [Reason *not to* ship inclusion lists in Electra](#4-Reason-not-to-ship-inclusion-lists-in-Electra) 5. [FAQ](#5-FAQ) --- ### 1. Context [Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547) allow validators to express their preferences over included transactions while outsourcing their block production to the builder market. This concept has seen significant research over the [past three years](https://github.com/michaelneuder/mev-bibliography?tab=readme-ov-file#censorship-resistance) leading to [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547) and the [related work](https://gist.github.com/michaelneuder/ba32e608c75d48719a7ecba29ec3d64b). Inclusion lists are a step towards preserving censorship resistance of the base chain under the reality of block-building centralization, which Vitalik explicitly characterizes in [*"Endgame,"*](https://vitalik.eth.limo/general/2021/12/06/endgame.html) > *"So what's the result? Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented."* Currently, validators must choose between building a block locally or fully outsourcing their block production to the `mev-boost` market. Inclusion lists reduce the "cost of altruism," allowing validators to both contribute to the censorship resistance of the chain (by constructing an inclusion list) *and* to benefit financially from the MEV markets (by using a PBS system like `mev-boost`). *PBS is inevitable; minimizing the resulting negative externalities is critical.* With the overwhelming success of the [Cancun/Deneb](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) fork on March 13, 2024, debates on the contents of the [Prague/Electra](https://ethereum-magicians.org/t/prague-electra-network-upgrade-meta-thread/16809) fork (which is targetting end-of-year 2024) are in a critical phase; the candidacy of inclusion lists (EIP-7547) remains tenuous [but alive](https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-128/). Stepping away from the technical specifics of the EIP, as discussed in [other venues](https://gist.github.com/michaelneuder/ba32e608c75d48719a7ecba29ec3d64b), this short article presents the high-level case for inclusion lists in Electra (a.k.a. ILECTRA). By succinctly documenting both the reasons *to* & *not to* ship inclusion lists in this hard fork, we hope to ground the discussion in the broader evolution of Ethereum. ### 2. Reasons to ship inclusion lists We begin with the high-level reasons to ship inclusion lists without focusing on the specific timing. 1. Censorship resistance is the essence of Ethereum. - Blockchains are designed to be permissionless and censorship-resistant. While we acknowledge that block building will likely always be highly centralized and dominated by a few sophisticated entities, we should not settle for those entities having unilateral discretion over the set of transactions in each block. If a small cabal controls the contents of the chain, we lose. Inclusion lists empower the validators to express more diverse preferences without sacrificing significant MEV rewards. 3. Ethereum has the most decentralized validator set. - A core design philosophy of Ethereum is to allow solo operators to participate in the consensus mechanism. Allowing permissionless participation in the validator set allows Ethereum to express high [preference entropy](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#staking-economics-in-the-rainbow-world-6). **Inclusion lists enable the protocol to depend on the decentralized validator set for censorship resistance rather than the centralized actors in the MEV ecosystem, improving the economic position of non-censoring validators compared to the status quo.** 5. Inclusion lists are compatible with the Ethereum roadmap. - The [endgame](https://vitalik.eth.limo/general/2021/12/06/endgame.html) emphasizes how crucial censorship resistance is under the reality of centralized block production. Further, the [roadmap](https://twitter.com/VitalikButerin/status/1741190491578810445/) includes making the protocol MEV-aware. Whether this is through [Execution Tickets](https://ethresear.ch/t/execution-tickets/17944), [ePBS](https://notes.ethereum.org/@mikeneuder/infinite-buffet), [PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879), or some other mechanism, inclusion lists are a fundamental building block in allowing the decentralized validator set to preserve the censorship resistance of the chain. ### 3. Reasons to ship inclusion lists *in Electra* We now argue for inclusion lists in the Electra hard fork, the end-of-year 2024 upgrade. 1. The MEV landscape has changed and will continue to change. - In the 1.5 years since the merge, the MEV landscape has evolved dramatically. [Builder censorship](https://censorship.pics/) today is more than 60% and trending upwards, and the situation remains highly precarious with a single, non-censoring builder. **Without committing to inclusion lists in Electra, we allow the progression of MEV to continue out-of-protocol until (at the earliest) the end of 2025.** This is another 1.5+ years of uncertainty and potential path dependence that we cannot rewind. EIP-7547 represents a clear step towards hardening the protocol and embarking on Ethereum's long-term MEV solutions. 2. The scope of the change is well-contained. - The [IL PoC Spec](https://notes.ethereum.org/@mikeneuder/il-poc-spec) aims to highlight the minimal-viable change to enable inclusion lists. A relatively simple and intuitive specification modification increases confidence in the feasibility of a rapid implementation. 3. Out-of-protocol mechanisms differ significantly from in-protocol solutions. - Several proposals for out-of-protocol inclusion lists exist. See [*"Resistance is not futile"*](https://ethresear.ch/t/resistance-is-not-futile-cr-in-mev-boost/16762) for a taste of these ideas. While valuable and parallelizable with EIP-7547, two significant issues plague these mechanisms. **Out-of-protocol censorship resistance mechanisms differ significantly from the in-protocol design and also increase dependence on `mev-boost` and the existing builder and relay market.** While there may be value in shipping an out-of-protocol solution, I don't believe that should factor into the decision to delay EIP-7547. - *Different mechanisms.* All out-of-protocol solutions are necessarily "same slot" (the proposer constructs the IL for their slot) rather than "next slot" (the proposer constructs the IL for the subsequent slot). By nature of being out-of-protocol, there is no possible enforcement of an inclusion list constructed by someone else (the `slot N+1` proposer ignores the `slot N` inclusion list). This distinction is critical because it makes inclusion list construction much less desirable; why would the proposer limit the builders during their slot? As a result, we are not in a position to leverage the pattern of "collecting data from an out-of-protocol solution and using it to inform the in-protocol design" because the mechanisms are different. From my perspective, this severely reduces the value of investing time and energy into out-of-protocol censorship resistance. - *`mev-boost` scope creep.* Out-of-protocol mechanisms further increase the dependence on and feature set of `mev-boost` infrastructure, which continues to be a pain point in the Ethereum ecosystem. Further entrenching the trusted relays and builders feels like an anti-pattern, especially when attempting to preserve the core values of Ethereum. Lastly, the software to implement inclusion lists in `mev-boost` outside the consensus and execution clients must be developed and maintained. ### 4. Reason *not to* ship inclusion lists in Electra In my opinion, the above reasons to ship inclusion lists far outweigh the following reason not to. That being said, for completeness, I highlight the only reason that justifies (in my view) not shipping them. 1. Electra fork minimization. - Referencing Tim's [nifty diagram](https://ethereum-magicians.org/t/prague-electra-network-upgrade-meta-thread/16809/57), [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) (EL-triggered withdrawals), [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) (on-chain deposits), and [EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) (committee index out of attestation) are already committed to by the core-dev community. If Electra solidifies into a "tech-debt only" fork with only these three EIPs from the consensus layer, then inclusion lists would be excluded. ### 5. FAQ 1. Why are there so many different designs? - I didn't communicate well about the EIP-7547 design iterations. **All variations discussed recently differ only in minor details and are not new designs.** The [four key considerations](https://notes.ethereum.org/@mikeneuder/il-spec-overview#Key-design-considerations) in the spec overview doc highlight the main necessary choices. The [PoC Spec](https://notes.ethereum.org/@mikeneuder/il-poc-spec#Core-PoC-Elements) shows a template based on the highlighted decisions. Another source of potential confusion is ongoing research into more complex censorship resistance gadgets (e.g., [Committee-enforced ILs](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), [PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879)). *Single proposer ILs (as specified in EIP-7547) are an initial, well-understood, fully future-compatible step toward hardening the censorship resistance properties of the protocol.* 3. What do inclusion lists have to do with ePBS? - ILs are only useful in the PBS world. If the proposer is self-building their block, they would include those transactions directly rather than using the IL. As a result, ePBS (or execution tickets) discussions bundle ILs as a prerequisite. **As mentioned in "Reason to ship #3", ILs are a building block (pun intended) for any in-protocol MEV solution.** 5. Will there be a market for inclusion list construction? - The guarantees granted to inclusion list transactions are intentionally weak. The protocol commitment states: "The chain will include a transaction from this address in one of the next two blocks." Notice that there is no assertion over transaction ordering, meaning the transaction is fully front-runnable by the block builder that includes it. Since inclusion lists extend the block gas limit during high congestion periods, there may be occasional contention for getting a transaction into an inclusion list. There are two reasons this doesn't feel like a deal-breaker. - The ordering of inclusion list transactions is not enforced, so the capturable MEV by being in the list is limited (a builder can arbitrarily front-run the transaction). A self-built inclusion list based on a greedy algorithm over the priority fees represents a highly effective default. - High-congestion periods are relatively rare ($\approx 2\%$ of blocks have $>29$ million gas), meaning the market for outsourced inclusion list construction would be infrequently valuable. 7. What is the endgame for censorship resistance? - While no one can answer this with certainty today, I think there is tremendous value in embarking on the path of enshrinement of this core primitive. While more research continues on [concurrent block proposers](https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777), [committee-enforced inclusion](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), inclusion list maximization (an active research direction similar to [MEV-burn](https://ethresear.ch/t/mev-burn-a-simple-design/15590)), and other anti-censorship gadgets, **it is invaluable to start building a defense-in-depth solution today to protect Ethereum from censorship.** Again, EIP-7547 is fully compatible for integration into proposed future gadgets. 8. Should we ship inclusion lists if we don't know what will happen? - One of the most common responses to inclusion lists is, "We don't know who will use them or how they will evolve." While this is true, we also don't know what will happen if we don't protocolize anything. **Inaction is a choice. Allowing external pressures to continue shaping Ethereum's block space unabated for the next two years appears far riskier than taking action now.** We also reiterate that inclusion lists aim to *increase the flexibility* of the protocol, allowing validators to express many different preferences in an incentive-aligned way.