Censorship resistance is a key value of the Ethereum community and the rise of mev-boost shows block production in the hands of a few mev-boost builders who censor some transactions following the regulatory regime of their jurisdictional domicile. While there is a broader, ongoing conversation around “base layer neturality” at the legal layer of the protocol stack, a promising technical direction to improve censorship resistance of the protocol lies in inclusion lists.

An inclusion list (e.g. built by a given proposer) would specify a set of transactions that must be included in their block for the block to be valid. A candidate solution is given here: https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389, with some corresponding analysis here: https://ethresear.ch/t/fun-and-games-with-inclusion-lists/16557.

An interesting RFP would continue to explore the design or analysis of the inclusion list construct generally. The linked posts also consider inclusion lists in the base layer protocol, but there are designs to implement the inclusion lists “off-chain”, e.g. at the relay.

Inclusion list generally open the door to the idea of “partial block building” where the builder and proposer work together to assemble a single block. RFPs exploring more general designs on this front are also welcome. A key challenge of partial block building is sharing state either from builder to proposer (depending on who makes the suffix and who makes the prefix) that would prevent MEV stealing and how this interplays with stateless designs the Ethereum protocol eventually hopes to adopt.