crLists 限制了 Builder 的权益，允许 PBS 从 Proposer 的去中心化属性中获得抗审查能力。

撰文：Jocelyn

TL;DR

• crLists 限制了 Builder 的权益，允许 PBS 从 Proposer 的去中心化属性中获得抗审查能力，而不要求身为 Proposer 的节点性能高低与否。
• crLists 的基本原理是让 Proposer 有权力发布他们认为正在被审查的交易清单。这可以让 Proposer 在不破坏 PBS 的前提下，起到监督中心化的区块 Builder 市场。
• Forward Inclusion List 目前最受市场认可，它能够巧妙的避免 Proposer 和 Builder 有利益冲突。
• Proposer prefixes 和 Proposer suffixes 也是 crList 的实现方式，它们分别在区块前后时间插入 Proposer 自己安排的交易。

当审查 Builder 能够实现利润最大化时，Proposer 将面临以下两种选择：

• 选择经济理性——即使面临审查，也会选择价值最高的区块
• 选择利他主义——避免审查，选择价值稍低的区块

理想的情况是，应当尽可能减少甚至消除利他主义的假设。

然而，在 PBS 之后，Builder 获得了更大的权力。在市场上占主导地位的 Builder 能够行使审查权，并垄断交易排序的能力，这导致了中心化风险的出现。Vitalik 在抗审查中提到了必须有一种机制：「让诚实的 Proposer 可以在不太大幅度地牺牲自身回报的情况下，强制地通过他们怀疑受到审查的交易。」那么，Proposer 可以在确保主网的中立性的前提下，同时实现最大化 MEV 利润。从整个系统的角度来看，crList 限制了 Builder 的权利，通过 Proposer 的去中心化属性获得抗审查能力，而不必关注这些 Proposer 节点的性能水平。

什么是 Censorship Resistance List（crList）？

「crList」，又被人们称为「混合 PBS 」，它能在不破坏 PBS 的情况下，限制 Builder 的权力，从而起到监督中心化的构建者市场的作用。

他的基本原理是让 Proposer 有权力发布他们认为正在被审查的交易清单。假设我们对 Builder 审查某一笔交易有所怀疑，那么 Proposer 可以制定一个交易清单，这个清单包含了符合标准但未被收录的交易。这些清单中的交易必须被 Builder 打包进区块。当 Builder 在拍卖中胜出后，他们需要证明 crList 中的所有交易都已被包含在区块中，只有一种情况下可以不做收录，即当区块已满，无法插入新的交易时，可以不包含列表交易。若 Builder 坚持审查交易，并忽视 Proposer 的 crList ，那么证明者将会判定该区块为无效。在整个过程中，证明者是随机选取的，他们在提议者提出区块后，对规范链的区块头进行投票。如果发现新区块不符合 crList 的要求，那么证明者就不会投票给该区块，因此区块便不会被添加到区块链中。

原始具体方案

原文中 Censorship Resistance List（crList）具体方案如下：

crList 指的是 Proposer 看到的应该被打包的交易列表，即它们的状态里有正确的随机数和充足余额，以及足够被打包的 priority fee 和最高 base fee。这个 crList 只能包含一名 sender ( 发送人 ) 的一笔交易。Proposer 也要对一个 crListSummary 签名和广播，它包含在 crList 上每笔 tx 的 tx.sender 和 tx.gaslimit。

Source: NIC Lin；当 crList 裡有交易，Builder 就被迫要收入交易，除非区块满载或原本就已经满了

举个简单的例子︰

1. Bob 作为 Proposer，他会创建一个 crList 和 crList 摘要，这个列表包含了一些他认为重要的交易。这些交易可能是他自己的，也可能是他认为应该被优先处理的。然后，Bob 将这个 crList 发布到网络中。
2. Alice 作为 Builder，她会看到 Bob 发布的 crList。根据 crList 的内容，Alice 需要在她的新区块中包含 crList 中的所有交易。
3. 如果 Alice 的新区块符合 crList 的要求，那么证明者会投票给 Alice 的区块，Alice 的区块就有可能被添加到区块链中。
4. 如果 Alice 的新区块不符合 crList 的要求，比如没有包含 crList 中的某些交易，那么证明者就不会投票给 Alice 的区块，Alice 的区块就不会被添加到区块链中。

通过这一机制，Proposer 可能会无意间减少其潜在的可捕获利润，因为其提交的 crList 会占据区块的部分空间。这种情况的机会成本则在于，Builder 可能会有机会打包更有利可图的交易。

在 crList 中，Proposer 通过发布他们认为正在被审查的交易清单，从而限制了 Builder 的中心化。一旦 Builder 忽视了 Proposer 的 crList 并坚持审查交易，那么证明者将会判定该区块为无效。然而，这种做法也增加了 Proposer 的负担，因为他们需要花费时间和资源来创建和发布 crList。尽管如此，这种机制仍然是必要的，因为它可以防止 Builder 滥用他们的权力，从而保护了区块链系统的公正性和透明性。

那么，回到上文我们提到的 Proposer 将面临 2 种选择：

• 假设有 Proposer 是善意的，他们宁愿减少收益也不会理会 Builder 的威胁，这自然是件好事。
• 但如果假设 Proposer 都是理性的，他们可能会基于获利情况与否同 Builder 合作。在这种情况下，提议者提交 crList 的意愿可能会降低，从而影响审查的过程。

对此，很多理性的 Proposer 将会提交一个空白的 crList 从而获取利润最大化。

Source：Uncommons censorship-resistance workstream如果我们希望在所有提议者都是理性的情况下仍能实现抗审查，那必须要对 crList 机制做一点调整，而不是依赖利他主义假设。

Forward Inclusion List，避免 Proposer 和 Builder 之间的利益冲突

Forward Inclusion List 是目前最受认可的 crList 模型，该模型能够巧妙地避免 Proposer 和 Builder 之间的利益冲突。在 Forward Inclusion List 中，由 slot n-1 的 Proposer 来决定 slot n 区块的 crList。这是因为 slot n-1 的 Proposer 收取的是 slot n-1 而不是 slot n 的竞标收益，因此不存在利益冲突。这种设计巧妙地避免了 Proposer 和 Builder 之间的潜在利益冲突，使得系统能够在保持高效运行的同时，有效地抵抗审查。

Source：NIC Lin；Proposer 不必担心 crList 会影响到来竞标的 Builder，影响的是下一个 Slot 的 Builder。

另外，之前我们在 Block Auction 和 Slot Auction 中提到过让 Proposer 在区块中直接插入交易：Proposer prefixes 和 Proposer suffixes，在区块前后时间插入 Proposer 自己安排的交易也是 crList 的实现方式。

Proposer prefixes，预先安插交易

Proposer prefixes 能够确保某些特定的交易能够优先被处理。Proposer 在 commit 时会先插入他自己安排的交易，然后再告诉 Builder 剩下多少 gas 可以用以及这些交易执行完的状态，让 Builder 能够调整区块内容。

Proposer prefixes 在确保 Proposer 的交易能够被优先处理基础上，也可以防止 Builder 滥用权力，因为 Builder 不能随意更改 Proposer 插入的交易。然而，这种策略可能会增加 Proposer 的负担，因为他们需要花费时间和资源来选择和插入交易。

Source：NIC Lin；Proposer 先插入他安排的 tx，然后 Builder 在构建区块的时候必须将这笔 tx 打包进去

Proposer suffixes，空余位置安插交易

Proposer suffixes 充分利用区块的空间。Proposer commit 时会顺便 commit 一个他想插入的交易清单并交给 Builder，Builder 发布区块内容后 Proposer 再按照清单里的顺序，一一安插交易到 Builder 的区块内容之后，直到区块空间不够或没有剩余交易。

Proposer suffixes 可以充分利用区块的空间，提高区块链系统的效率。然而，这也可能导致 Proposer 的交易被延迟处理，因为他们必须等待 Builder 填充完区块后才能插入自己的交易。

Source：NIC Lin；Proposer 先 commit 他想插入的交易，最后如果有空间再一一插入

Source：Uncommons censorship-resistance workstream

小结

crList 给 Proposer 更多的权利以实现抗审查，也同时给 Builder 带上了枷锁。如果 Proposer 反过来威胁 Builder 必须将交易包含其中，或者当他们与 Builder 私下勾结，并告诉 Builder 不要包含交易呢？

Reference

https://www.ethereum.cn/Eth2/crlist

https://www.ethereum.cn/Eth2/pbs_censorship_resistance

https://notes.ethereum.org/@fradamt/H1TsYRfJc#High-level-idea

https://www.reddit.com/r/ethereum/comments/rwojtk/comment/hrnf9k2/?utm_source=embedv2&utm_medium=comment_embed&utm_content=whitespace&onetap_auto=true&one_tap=true

https://hackmd.io/@potuz/ry9NirU2p

https://cn.cointelegraph.com/news/a-beginners-guide-to-ethereum-censorship

https://barnabe.substack.com/p/pbs

https://medium.com/taipei-ethereum-meetup/mev-proposer-builder-separation-968d519a4898