其他
crList：PBS 的抗审查替代解决方案
译者注：crList 指的是提议者看到的应该被打包的交易列表，即它们的状态里有正确的随机数和充足余额，以及足够被打包的小费和最高基本费)。这个 crList 只能包含一名 sender (发送人) 的一笔交易。提议者也要对一个 crListSummary 签名和广播，它包含在 crList 上每笔 tx 的 tx.sender 和 tx.gaslimit。Danksharding 这个新的分片方案以 PBS 和 crList 为特点，这篇文章介绍了 crList 如何解决 PBS (提议者/构建者分离方案) 里构建者的审查问题。
资源
Vitalik 的研究现状文章 关于抗审查研究更广泛的文档，包括一些历史背景，各种 crList 的替代方案以及另一种抗审查的提案
高层级的想法
我们希望提议者能够通过对一些交易强制打包来对抗审查，但是我们不想通过带宽密集型的方法来实现 (即经常会导致 Gossip 的冗余通信和/或区块对交易打包的冗余)，这会使具有利他精神的提议者处于劣势，因为这要求他们牺牲 MEV 机会，或者这会给懂技术的提议者一些权力，提取比不熟悉技术的提议者更多的 MEV。当构建者不审查交易，如果协议会基本上如 PBS 提案所写般运行，即提议者只需要选择收益最多和开销最低的区块，这将是最理想的。
做到这一点的关键是了解 1559 之后的审查是什么样的，我们来看看交易池的情况：如果有区块空间可以分配给当前符合条件的交易池交易，但却被空着，例如如果当前交易池是满的，但区块却是不满的，我们就会怀疑构建者在审查交易。显然，通过看交易池的情况来判断会存在一定程度的主观性，但我们可以做的是让提议者提前提出他们视域 (view) (或其中的一部分)，这样我们就可以将审查与只是对交易池的不同视域区分开来。
我们不是让提议者直接强制把他们选中的交易进行打包，而是允许他们强制构建者充分利用可用的区块空间：如果构建者不能这样做，他们必须把未使用的空间用于提议者选择的交易。
审查的成本
关于 PBS 带来的审查成本变化的概述，如果我们不假设贿赂模型 (整个验证者集是可贿赂的)，请参见 Vitalik 研究现状的帖文。
crLists + EIP 1559 对此带来巨大变化
在几个 slot 的时间内，审查成本的增长仍然与你想要审查的 slot 数呈线性关系，但有一个好得多的常量。在没有 crLists 的情况下，一个占主导地位的构建者只需承担在每个 slot 不打包交易的机会成本。在有 crLists 的情况下，他们被强制填满每个区块的 gas 上限，这样的成本就高出很多倍了。 在更长的时间内，审查成本的增长与 slot 数呈指数关系，因为基本费用 (basefee) 会上升，填满区块的成本也会呈指数上升 (而且真正的交易会因为交易费过高而退出，只剩下攻击者填充整个区块)
Vitalik 文章的设计目标
DoS 保护和没有免费的数据可用性：提议者 (或构建者) 不应该打包给没人支付费用的数据，因为这会被攻击者滥用，使得区块链膨胀，或被 rollup 利用来欺骗交易费。例如，这意味着如果一个区块包含一笔因为余额不足或同一个区块里的其他交易而被证明是无效的交易，该协议必须仍然为此收取这个提议者的基本费用。 最低限度的额外带宽消耗：这个机制应该不只是对链上数据有效，还要对 p2p 网络里的数据有效。例如，让数百个来自不同构建者的冗余完整区块主体在网络里漂浮是不现实的。 不重新引入提议者中心化：PBS 的整个要点就是不要求提议者是熟悉技术的。我们不希望创建一个机制是又对熟悉技术的提议者有利的，并由此激励提议者进入进一步的协议外竞价关系或加入池子。 理想情况是使得提议者可以是无状态的：验证者能够变成完全无状态 (一旦 Verkle trees 被部署了) 将会是进一步去中心化和提高可扩展性的一个重大福音。 如果我们依赖利他主义，不要让利他主义变得昂贵：我们一般可以依赖这样一个假设——至少有百分之几的提议者是利他的，且将忽略贿赂出价和接受被审查的交易。但是，如果这样做在协议内是成本高的，这个假设就会变得很不现实。提议者不应该必须牺牲大额收益来帮助确保被审查的交易能被打包。
自然语言规范
这里我们假设是两个 slot 的 PBS，偶数的区块是提议者的区块，奇数的区块是构建者的区块。一个简单的总结是，提议者对他们的信标区块发布一个 crList，该列表与下一个构建者的区块有关，即该区块会被下一个提议者选中。如果 crList 已经被即时发布，那么这个符合要求的区块就会被该区块的证明者强制执行。
处于 slot 2n 的提议者发布一个当前有效的交易列表，即 crList，同时作为它们信标区块的发布。这个列表被发布到 p2p 网络，而不是在信标区块里。 处于 slot 2n+1 的构建者区块以及处于 slot 2n+2的提议者区块，是不会受到处于 slot 2n 的 crList 影响的。规定的证明者行为也不会。 slot 2n+3 (即下一个构建者区块) 的证明者决定 crList 在期限内是否可用，这个期限是在 slot 2n+2 的开端之前的，因此想要对 slot 2n+2/3 出价的构建者会有充分的的时间看 crList 并构建一个符合要求的区块。例如，我们可以在 slot 2n 的末尾设定截止时间，这样构建者就会有差不多整个 slot 的时间来看这个列表和构建符合要求的区块。 slot 2n+2/3 的构建者如果看到了 crList 会构建符合这个 crList 的区块，符合要求的意思是 crList 不能包含任何在该区块后仍然有效的交易 tx，即要满足 block.remaining_gas > tx.gas_limit 如果 slot 2n+3 的证明者及时看到了 crList 且区块不符合该列表，他们将不会投票给该构建者的区块。
分析
共识安全
由于我们对一些证明 (事实上是它们中的一半) 增加了一个额外的条件，这就给证明者之间出现不同视域引入新机会，我们需要确保我们不会削弱共识的稳定性。值得庆幸的是，这个影响是很小的。两个证明者间因为这个额外条件出现不同视域的情况只有一种：crList 必须已经发布，但在他们两个间只有一个及时看到，且下一个构建者必须还没构建一个符合要求的区块。我们可以进一步发现两种情况：
诚实的构建者：构建者必须在他们出价之前没有看到 crList，即使 crList 在期限之前已经被发布了 (因为有证明者看到了)。在良好的网络条件下，这是很不可能的。在网络条件差到足以让构建者 (我们甚至假设构建者的网络连接情况是普遍更好的）在发布期限和发布竞标之间 (如果我们把期限设在提议者 slot 的末尾，这是差不多一个完整 slot 的时间) 看不到这个 crList 的情况，有很多更简单的方式产生不同的视域。 不诚实的构建者：他们可以在发布后故意构建一个不符合 crList 的区块，以产生不同的视域。这能有效分裂对构建者区块的投票证明，这有可能导致构建者的区块不能被打包到权威链。更重要的是，构建者总是可以通过在接近发布期限时发布他们的区块以产生不同视域，因此这个方案不会给他们任何额外的权力。
特性
总的来说，这个方案有以下的理想特性：
构建者不受信任的共识安全：构建者可以通过在接近发布期限时发布他们的区块以产生不同视域。crList 不会使这种情况轻易发生。 提议者不受信任的共识安全：除非有构建者参与，晚发布 crList 不会分裂证明 提议者构建者不受信任的安全性：一个恶意的提议者不能轻易损害构建者的利益： ➤ 如果他们晚于期限发布，构建者只需要依赖他们委员会中的诚实多数，这个委员会是他们无论如何都要依赖的 ➤ 如果他们在期限之前发布，构建者有接近整个 slot 的时间看到 crList。此外，如果他们没有看到 crList 的话是可以不发布的，而且他们有其他理由相信他们正在被攻击。
最低限度的风险，且都落在构建者上：风险全在构建者身上，而且如果他们有理由相信他们的区块主体可能会因为这个额外的证明条件而被认为是错失的，他们完全可以通过降低出价或完全不出价来管理风险。 与 MEV 均匀分配兼容：无论 crList 是否及时发布，所有构建者都能构建符合要求的区块。在第一种情况，他们应该都可以即时看到列表，在第二种情况，没有条件是强制性的。 与单个秘密领袖选举兼容：提议者一起发布 crList 和他们的区块，因此他们不用提前对自己去匿名化。 没有免费的数据可用性：给构建者区块的证明投票不能被用作任何东西可用性的保证，因为区块完全没有引用 crList。 最低限度的额外带宽消耗：唯一需要额外带宽的是广播 crList。这甚至可以通过让提议者发布一个交易哈希列表而不是完整列表来进一步最小化。 如果我们依赖利他主义，不要让利他主义变得昂贵：提议者发布 crList 不会产生任何成本，即时稍微给构建者添加风险或他们有可能会获得溢价也不会有，成本只会在他们接受了出价后才发布 crList 的情况下产生。
点击“阅读原文”获取文章内部链接！原文链接：https://notes.ethereum.org/Dh7NaB59TnuUW5545msDJQ?view