Preamble

The inspiration for this post came after spending too much time reading the bird app, capped off by this post here.

There are many opinions about what the Ethereum community should do to combat transaction censorship from block builders and relays. From what I’ve gathered, social consensus amongst community members appears to favor enshrining crLists ASAP.

“Can we do better?”

One of the best decisions Ethereum developers made was pivoting away from execution sharding to a rollup centric roadmap. To quote Hasu, “Ethereum has effectively deregulated its execution market.” This deregulation has fostered permissionless innovation allowing rollups to move faster and make tradeoffs that Ethereum cannot make (upgrade keys, exit games, proof generation, single sequencer, et al.). More examples of permissionless innovation likely to be implemented in protocol include;

• MEV-Boost-> PBS

• Zk Rollups -> zkEVM

• Eigen DA -> danksharding

• Lido -> in protocol LSD

Furthermore, I propose an alternative to enshrined crLists that retains credible neutrality while requiring no (minimal?) changes to consensus or execution clients. Instead I’m proposing an update to Mev-Boost.

crLists

How do we solve the problem of getting transactions included in a block that some builder/relay entities will not include like transactions from OFAC sanctioned addresses and contracts for example?

At the moment, it appears unlikely that a crList EIP will to be appended to the current CFI (considered for inclusion) list in time for the Shanghai Hard fork. However, we do not need to rush an in protocol upgrade for the sake of saying we satisfied our current censorship problem.

litList (crList) Builder

A simple but elegant solution could be to add a patch to Mev-Boost that allows the consensus client to connect to a new type of Builder API that runs in parallel with the existing Builder API and would allow each client to connect to a crList builder/relay.

The crList builder would receive a transaction inclusion list from the last proposer to be included in the next slot. If the block is not full and the pending tx fees >= the base fee then the crList builder would aggregate the crList txs and relay the txs to the proposer. If the builder’s block is full, 2x the target, then the crList builder would not relay the aggregated txs to the proposer. Otherwise the crList builder would always send txs up to the max gas limit of the total block. Indeed, The crList builder is only constructing a small fraction of the block.

At this point the decision to censor would be entirely up to the Proposer who could choose not to connect to the crList builder/relay.

As an alternative, the crList builder could produce the Inclusion list instead of the proposer. This would likely require some type of opt in slashing conditions to keep to crList builder honest.

Both designs would require altruism by honest actor(s) with the requisite resources to run crList builders and relays.

For better ideas, see Vitalik’s latest proposal.

Enshrined crList?

The current equilibrium between the Ethereum protocol, users/developers, regulators and apps/middlewear suggests that rushing to enshrine crLists could shift the balance and draw further regulatory hostility provoking n+1 countermeasures.

Instead, we should consider implementing crLists (in protocol) during the early phase of the next economic cycle, acting from a position of strength.

Finally, as MEV-Boost allows us to collect empirical data and build deeper intuitions about PBS, an intermediate crList builder update to MEV-Boost will help us make better informed decisions about crLists.

Ultrasound Memes

As a community let’s stop using the term crLists. Transaction Inclusion list is okay, but again, we can do better.

crlList → litList (Last included transactions)

Not only is this a better meme than crList, It’s lit. The power of memes should not be overlooked. Though I do like Inclusion List as well.

Conclusion

• Testing crLists with MEV-Boost could be more beneficial than playing the reactionary meta-game with unknown outcomes

• litList (crList) builder can send a prefix or suffix to proposer to be added to the execution block , but requires at least 1 altruistic actor(s) to run a Builder/relay combination (roles can be split, multiple altruists)

• In protocol crList should ship only when ready

• litList is a better meme, (FitList for prefix) but Inclusion List is strong as well