Censorship resistance lists (crlists) are designed to prevent builders from censoring users in PBS. The design was originally put together with in-protocol PBS in mind. Can we adapt this solution to improve mev-boost?

• The original design: https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ#Hybrid-PBS-can-we-use-proposers-only-for-inclusion-of-last-resort
• A critique/analysis: https://notes.ethereum.org/@fradamt/H1TsYRfJc

Why censorship resistance is important with MEV-Boost

We anticipate the builder market to be smaller than the total validator set, becoming more centralised over time. This higher degree of centralisation makes censorship much easier and much likelier, severely affecting the neutrality of the network. Additionally, it is unclear how the builder market will evolve (e.g. presence of EOF, fair-ordering builders etc.). This opacity makes it hard to reason about censorship resistance with MEV-boost as it is.
Consequently, validators may find themselves in a position where they suspect the builder market of censoring users (e.g. because of a government sanction where most builders are located) and have to choose between the additional profit of PBS and the ideologically sound move which is building blocks locally. Building in a censorship resistance mechanism means that proposers can continue to run MEV-boost with assurance that the neutrality of mainnet isn’t being compromised. From the perspective of the system as a whole: crlists allow us to derive censorship resistance from the decentralisation of proposers rather than builders without requiring proposers to be sophisticated.
Additionally, including crlists in mev-boost could provide useful insight into challenges and market dynamics in a low risk environment (discussed below) which would prove useful for designing in-protocol PBS.

What are crlists?

The basic idea is to allow a proposer to publish a list of transactions which it suspects are being censored. (e.g. a valid txn with sufficient basefee that hasn’t been included for several slots). Builders supplying blocks to this proposer must either supply completely full blocks or include as many of these transactions as possible until the block is full or they are all included.

The flow in mev-boost would look something like the following:

1. The proposer announces its crlist at some point before receiving block headers
   1. one option is to send this list with the “getHeader” request, but this may be a bit late since builders may already have started building blocks, meaning that builders might have to restart building, leading to a loss of profit for proposers.
   2. another option is to leave the timing of the announcement up to the proposer (any time after they are assigned a slot and before the getHeader request). The longer they wait the more likely they are to reduce their bids but also the more fine-grained their crlist selection will be.
   3. We allow proposers not to participate by submitting an empty crlist or not submitting a crlist at all (depending on implementation).
2. Relayer conveys crlist to partnered builders
3. Upon receipt of blocks, relay checks that crlist conditions are satisfied before forwarding headers to the proposer. We have the option of adding some metadata (some json or binary map? not sure how these kinds of things work in practice) indicating which transactions are from the crlist for speed of checking conditions. The conditions would be:
   1. block is full (~30m gas)
   2. OR all valid (basefee and nonce) crlist transactions are in the block
4. Header is signed and relayer/builder sends full block to the proposer
5. Proposer conducts same check as in (3). If conditions are violated, relayer reputation is adjusted/proposer no longer accepts headers from relay

The original in-protocol design ideas attempt to make this a trustless process where builders would send proofs that the crlist conditions are satisfied along with their headers. Since mev-boost is still a trust-based system, proposers could simply outsource the checking of crlist conditions to relayers. If a relayer sends a block that does not satisfy the conditions, this should affect the relayer’s reputation score. This is the same mechanism which we use to address the problem of signed headers with a missing block body.

As for builders censoring users while fulfilling the crlist requirements (i.e. filling blocks), this becomes exponentially more expensive as time passes, since full blocks move up the basefee via EIP1559 and the censoring builder must continue to fill entire blocks.

Importantly, since crlists are optional in this design and there are no encoded slashing conditions or punishments for deviation, if unwanted effects arise from the implementation, proposers simply stopping submission of crlists could be a quick fix in many cases.

Risks, Obstacles and Problems

As far as I can tell, the biggest issues identified with crlists are related to their in-protocol enforcement and DAS. Neither of these topics relate to the trust-based PBS which mev-boost is implementing so crlists seem like a good fit.

Proposer protection

• One concern is that proposers publishing crlists will be intentionally or inadvertently (e.g. because of regulation preventing builders from satisfying crlist requirements) punished by receiving lower, fewer or no bids.
  • This also constitutes opportunity cost for builders and, assuming a competitive market, is unlikely to have a large impact
  • Even if this does happen, proposers are still able to build local blocks, which is the censorship-resistant choice under the current model
• Is the sending of the crlist burdensome in terms of network requirements? I would imagine not but would like confirmation.

Relay burden

• One could argue that this design places additional load on the relay which now has more checks and must manage builders more closely. I don’t see this being much more intensive or qualitatively different than what relays are already expected to do in terms of insuring validity and availability of blocks. However as Jolene pointed out, this could restrict relay design space as it would require either:

1. relayers having a way of pushing lists to builders (i.e. a list of IP addresses)
2. builders regularly pinging the relay to check if a new crlist has been released (here there may also be latency advantages if crlists are released late).

Objects of user intent

Account abstraction, EIP712 and similar designs may mean that users could express their intent in formats that are not currently recognised by the mempool. Hence, crlists in the design above do not capture censorship of these expressions of intent.

• In the worst case, users can submit transactions satisfying their “intent” directly to the mempool

Formation of lists

As Jolene pointed out, implementing crlists may require changes to EL/CL clients. The problem, as I understand it, is that mev-boost doesn't have access to the mempool so either must be given access to the mempool via a communication channel with the EL or must have the crlist passed into mev-boost via some other means like changes to the Builder API.