Censorship Resistance In PBS (Heterogeneity, BFT)

Before PBS, Ethereum derived CR from a large, heterogenous validator set which meant that it was unlikely that the desire to censor would be present for many blocks in a row (e.g. due to validators located in non-US territories). However, sourcing blocks form a smaller set of builders disrupts these guarantees.

Several similar solutions have been proposed for addressing this issue. Most notable among these are variations of inclusion lists (proposer stipulating transactions which must be included) and proposer suffixes (proposer is permitted to append transactions to the end of blocks or host a secondary auction to do so). See:

However, several concerns have also been raised about these solutions:

  • Requiring proposers to see transaction for them to be included necessitates transactions being propagated publicly, rendering users vulnerable to undesired behaviour such as sandwiching.
  • One of the original goals of PBS was to ensure equal yield for all stakers, irrespective of “sophistication”. Providing degrees of freedom for proposers (e.g. through suffixes) means that proposers have an avenue to leverage relationships with searchers to capture MEV. As these relationships will be trust-based, this is unlikely to be accessible to all proposers.
  • Declaring an inclusion list before block production might see proposers being griefed by builders who want to discourage such behaviour.


  • What is the best mechanism for providing censorship resistance properties at least as good as a locally building network? What are the tradeoffs? Are there any impossibilities?
  • For domains other Ethereum, what are the best CR mechanisms that give this property? How does PBS interact with forced inclusion to L1 contracts or other “escape hatches”?