✈️crList

Due to the separation of proposal and packing tasks in PBS, packers (Builders) actually have greater ability to censor transactions. They can intentionally ignore certain transactions, arbitrarily sort, and insert their desired transactions to gain MEV. However, the Anti-Censorship List (crList) addresses these issues.

The mechanism of the Anti-Censorship List (crList) is as follows:

- Before the packer (Builder) packs block transactions, the proposer (Proposer) first publishes an Anti-Censorship List (crList), which includes all transactions in the mempool.

- The packer (Builder) can only choose to pack and sort transactions in the crList. This means that the packer cannot insert private transactions to gain MEV, nor can they intentionally reject a transaction (unless the Gas limit is full).

- After the packer (Builder) completes the packing, they broadcast the hashed final version of the transaction list to the proposer (Proposer). The proposer then selects one transaction list to generate a block header and broadcasts it.

- When nodes synchronize data, they obtain the block header from the proposer (Proposer) and then get the block body from the packer (Builder) to ensure that the block body is the final selected version.

The Anti-Censorship List (crList) resolves issues related to MEV, such as the "sandwich attack," as nodes can no longer insert private transactions to gain similar MEV benefits.