来源 | note.ethereum.org

特别感谢 Francesco 提出解决方案 2 里的核心想法，并感谢 Francesco、Justin Drake、Alex Obadia 和 Phil Daian 的反馈和评论

区块提议者/构建者分离方案是如何运作的？

在现行的交易市场里，区块提议者 (当前是矿工，合并后是验证者) 直接通过看交易池里哪些交易支付最高的小费来选择哪些交易被打包到下一个区块。这使得区块交易者可以使用复杂的策略来选择打包哪些交易，或甚至打包他们自己的交易，以利用像 DEX 套利和清算的机会 (为了简洁，下文只称为 MEV) 来最大化他们的收益。这些策略的复杂性给运行一个有效矿工或验证者节点造成很高的固定成本，并使得代表其参与者使用这些策略的中心化池占据优势。

区块提议者/构建者分离 (PBS) 方案通过把区块构建的角色从区块提议者上分离开来解决这问题。分离出来的一类行动者叫构建者 (buiders)，他们构建执行区块主体 (exec block bodies) (基本上是一个有序的交易列表，这些交易会成为区块里的主要负载) 和提交出价。提议者的工作就只是接收出价最高的执行区块。值得注意的是，提议者 (和其他所有人) 直到他们选择了在竞价中胜出的区块头 (即也选择了区块主体) 后都不知道任何执行区块主体里的内容。这种**确认前的隐私 (pre-confirmation privacy)**对以防止“MEV 窃取”是有需要的，因为懂行的提议者会发现构建者的 MEV 提取策略并复制它们而不分给构建者。

PBS 与现状相比，有哪些抗审查挑战？

首先是现状，假设有一笔 150k gas 的交易，且当前的 gas 上限是 30m (目标是 15m)。经济实力强的行动者试图审查该交易。在当前的交易市场里，如果该笔交易愿意支付基本费和多于 1~2 gas 的小费，区块提议者就会愿意对其打包；平均每个区块有大约 15m 的 gas 松弛空间让他们这样做。要审查一笔发送者为打包愿意支付 x 的交易，攻击者需要把基本费提到高于每 gas X / 150k，并将其保持在那里。如果他们这样做了，其他用户将因费用太高而退出竞价——毕竟，如果基本费高到足以让一笔重要到足以吸引有人试图进行针对性审查的交易退出，攻击者将可能必须自己支付区块中交易费最贵的交易。保守地说，攻击者很可能必须自己支付高达每 slot (X / 150k ) * 10m = X * 66.7(因此大约是每小时 x*20000 )

现在，让我们来探讨一下 PBS 的情况。假设有一个区块构建者一直比其他构建者表现更好，要么因为他们说服不老练的用户运行只给他们发送交易的钱包 ("专有订单流")，要么因为他们有更好的算法和数据访问来发现 MEV 机会。假设有一些特定受害交易是构建者 (“审查构建者”) 试图审查的。设：

• M 为在没有受害交易的情况下非审查构建者的出价
• P = X - basefee \* 150k 为受害交易总交易费的小费部分
• M + P 为受害者交易能够被打包的情况下非审查构建者的出价
• A 为审查构建者获得的优势 (advantage) (等于他们所赚的费用+MEV 与非审查构建者可以赚最多的费用+ MEV 的差值)
• M + A 是审查构建者的出价，无论是否有受害交易 (因为审查构建者不想打包受害交易)

如果 P>A，非审查构建者将能够给出比审查构建者的 0 收益出价 (M + A) 高出 P - A 的出价。为了保持审查，审查构建者将必须把他们的出价提高到 M + P，并每 slot 损失 P - A 以保持出价高于非审查构建者 (还要额外牺牲每个 slot 获利 A 的机会，因此总损失是每 slot P )。这样成本仍然很高。但请注意这比每 slot X * 66.7 要便宜得多。

如果 P < A，尽管不打包受害交易，审查构建者也能赢得竞拍，虽然他们的确不得不把他们的出价提高到稍稍高于 M + P ，从而牺牲了每个 slot 的 P 收益 (审查构建者的收益变成 A - P 而不是 A)。

请注意，在两种情况里，攻击者都会因为审查而损失每 slot 的 P 收益——对于仅是把一笔交易排除在链外来说，这仍然是一个巨大且持续的成本，但远不像每笔交易在费用市场中的成本那么高。

PBS 的审查经济学和出块时间

上述分析的一个重要结果是，在 PBS 里，审查的成本是按每 slot 算的 (严格来说是每个区块，但为了简单，我们忽略两者的区别，因为实际上以太坊上几乎所有 slot 都有一个区块)。如果出块频率减低 10 倍，审查成本会减少 10 倍。如果出块频率增加 10 倍，审查成本就会增加 10 倍。这是反直觉的，但与上一部分的逻辑是一致的。请特别注意，现在的收费市场有点像 PBS，有 100 多个竞价同时抢一笔交易的打包位置；但是，这是一个有问题的 PBS 市场，因为它缺乏确认前的隐私保护。

因此，很自然要问这样一个问题：我们能否尝试扩展 PBS，以实现快速出块，但使得那些区块是并行出现而不是按顺序的？

抗审查方案有哪些设计目标？

• DOS 保护和没有免费的数据可用性：提议者 (或构建者) 不应该能够打包没人支付的数据，因为这可能会被攻击者利用，使链数据膨胀，或给 rollup 欺骗交易费用的机会。例如，这意味着如果一个区块包含了一笔交易因为余额不足或同一个区块里其他交易而被证明是无效的，协议必须仍然向提议者收取该交易的基本费。

• 最小额外带宽消耗：这个机制不应该只对链上数据有效，对 p2p 网络上的数据也要有效。举个例子，在网络上漂浮着数百个来自不同构建者的冗余完整区块主体是不现实的。

• 不再重新引入提议者中心化：PBS 的全部意义就在于它不需要提议者是老练的。我们不希望创建一个机制会为老练的提议者重新引入好处，从而激励提议者进入进一步的协议外竞拍关系或加入池。

• 理想情况下，允许提议者是无状态的：验证者能够变成完全无状态 (一旦 Verkle trees 被部署到了主网) 将会是进一步去中心化和提高可扩展性的一个重大福音。

• 如果我们依赖利他主义，不要让利他注意变得昂贵：我们一般可以依赖这样一个假设——至少有百分之几的提议者是利他的，且将忽略贿赂出价和接受被审查的交易。但是，如果这样做在协议内是成本高的，这个假设就会变得很不现实。提议者不应该必须牺牲大额收益来帮助确保被审查的交易能被打包。

解决方案 1：我们可以同时运行很多确认前隐私 PBS 竞价吗？

假设在每个 slot 里有一个竞拍是用于主要执行区块 (primary exec block)和有 N-1 个竞拍是用于辅助执行区块 (auxilary exec block) (因此总共有 N 个竞拍)，且它们是并行运行的。这些区块是按顺序被执行的 (顺序为先主后辅)，但它们共识的达成是平行进行的。

假设一个交易发送人愿意支付 P 小费。要把该交易排除在链外，审查者将需要愿意给每个辅助执行区块竞拍的控制员每 slot P+1，因此他们将必须支付每 slot (P+1) * N。

攻击者必须每个 slot 都出价，且不仅当有人试图进行辅助打包时才需要出价，因为如果攻击者只自动出价高于辅助打包，提议者会开始提交虚假的自我出价来迫使攻击者出价高于他们。

但有一个问题：辅助执行区块会如何被构建？构建主要执行区块的构建者 ("主要构建者") 会相对比较简单，因为他们看到他们正在构建的区块所建基的前状态：这是前一个区块的后状态。另一方面，构建辅助执行区块的构建者 (辅助构建者) 则没那么幸运：他们在同一个 slot 里构建的任何区块都需要基于主要执行区块 (和较底部索引的辅助执行区块)。因此，当辅助构建者在选择打包哪些交易是并不知道他们要基于什么状态来构建的。

如果一个辅助构建者打包一笔已经被打包到前一个区块的交易，他们必须支付直到签名和随机数验证前的数据和执行的 gas，但他们不会得到来自该笔交易的手续费。因此，他们会损失钱 (在这种情况下设计一个免除数据+验证 gas 费的协议是不安全的，因为这可能会被 rollup 和其他存储数据到区块链的用例滥用)。

这就提出了一个问题：辅助构建者是否有一个安全策略来打包交易到辅助执行区块？这个策略在正常情况下应该是可获利的 (预期里)，且如果一个会进行审查的主要构建者明显正在试图攻击他们时能提供保护。一个攻击的可能例子是，一个会进行审查的主要构建者可以在直到他们预见有辅助构建者开始打包交易时突然打包那些交易，从而实现审查。如果他们一直这样做，他们可以导致辅助构建者亏钱；一旦辅助构建者亏损太多，他们就会退出市场，让会进行审查的构建者可以自由审查交易。

最低限度可行的辅助构建者策略

请记住，在“好的情况”下，辅助区块会是空的，因为任何想被打包的交易都会被打包到主要区块。因此，这个策略只需要在审查真的发生的时候才激活。

• N = 每个 slot 上发生的竞拍总数 (包括主要的和辅助的)
• P = 交易小费
• B = 当前的基本费

首先，为了简单起见，假设 N = 2 (因此，每个 slot 只有一个辅助执行区块)。也假设 P = B (审查的受害者总是支付两倍的费用，以吸引辅助构建者和避免审查)。下面是一个建议的辅助构建者策略：

如果一个辅助构建者看见一笔交易在 k 个 slot 前第一次被接收，但还未被打包，并且从那时起就一直有效，那么构建者应该在他们的提议区块里打包这笔交易的概率是Pinclude(k)=0.00000001⋅2max(k,1)P_{include}(k)=0.00000001\cdot 2^{max(k,1)}Pinclude​(k)=0.00000001⋅2max(k,1)。

假设会进行审查的主要构建者在 k 个 slot 后接受了受害者交易。要么 k = 0，在这种情况里他们只有 0.00000001 的机会能“陷害”辅助构建者 (意思是，审查构建者和辅助构建者在同一个 slot 里发布，导致他们会亏损钱)，要么 k > 0，在这种情况下攻击者陷害辅助构建者的概率与辅助构建者先于攻击者打包受害交易的概率相等 (即Pinclude(k)=∑i=1k−1Pinclude(i)P_{include}(k)=\sum_{i=1}^{k-1}P_{include}(i)Pinclude​(k)=∑i=1k−1​Pinclude​(i)，因为 k≥1 )。

在后一种情况下，辅助构建者平均来说是不赚不赔。这是因为在攻击者陷害他们时，他们亏损 B，而在他们打包了一笔交易时，他们获利 P，而我们在上文假设 P = B。将指数基数降低到 2 以下，使数学运算更简单，并确保辅助构建者是可获利的。我们可以通过把基数设为1+PP+B1+\frac{P}{P+B}1+P+BP​延展到任意小费。

而 N > 2 的情况比较棘手，因为有可能出现干扰：如果一笔交易同时被打包到两个辅助执行区块呢？但是，如果我们假设辅助构建者使用独立的随机策略，发生冲突的机会是可控的 (一个模拟脚本表明，如果基数是 2，无论有多少名构建者， P 都接近于 1/4)。

在实践中，上述的数字几乎肯定是太悲观的。被审查的交易可能在几个 slot 后就被辅助构建者打包了，而辅助构建者将对攻击作出动态反应。此外，交易失败时的成本比成功时低，所以在实践中， P 仅需要大量交易的几个百分点的 B。相反，上述内容更多的是作为一个存在证明，即辅助构建者可以使用固定的特定策略，甚至在攻击下也能获利。

在主要执行区块内容已知后，为什么不让辅助构建者通过一个位字段选择要排除哪些交易到链外

一个位字段仍然携带足够多的信息，攻击者可将指令编码到智能合约，以了解如何利用 MEV 机会。此外，如果有多个辅助构建者，他们将必须按顺序提供他们的位字段。因此，这将简单地将辅助竞拍转换为一系列主要竞拍。

解决方案 2：我们是否仍然可以使用提议者 (“混合式 PBS")，但仅用作”打包的最后手段“

防止审查的另一个自然想到的方法是把当前的交易费用市场和 PBS 融合起来。这种方法将依靠提议者来抗审查。只有少数提议者需要实际上使用这个方案；即使 95% 的提议者不知怎么地就成功被贿赂了，都假装没有看到交易并只接受 PBS 机制下产生的区块，剩下的 5% 意味着，平均来说，任何受害交易仍会在 20 个 slot 后被打包。

这个方案的工作原理如下。在每个 slot ：

1. 提议者广播 crList，这是提议者看到的应该被打包的交易列表 (即它们的状态里有正确的随机数和被打包的充足余额、小费和最高基本费)。这个 crList 只能包含一名 sender (发送人) 的一笔交易。提议者也要对一个 crListSummary 签名和广播，它包含在 crList 上每笔 tx 的 tx.sender 和 tx.gaslimit。
2. 构建者创建一个提议主体，它必须包含在 crListSummary 里
3. 提议者接受胜出的区块头
4. 构建者发布主体。主体的验证需要检查在 crListSummary 上的每个 (sender, gaslimit)，要么是否 block.gasused + gaslimit > block.gaslimit，要么 sender 是否区块里某笔交易里的发送人。

为了进一步节省空间，还有一个更复杂的替代方法，就是要求 crList 按照 tx.gaslimit 的降序排序，然后要求主体只包括 (i) 在 crList 上不能被打包的第一笔交易的 Merkle 证明，和 (ii) 区块中那些在 crList 上的交易的位字段。任何人都可以通过重建 Merkle 证明之前树的那部分并检查它是否与 Merkle 证明相符来验证。

请注意，无论哪种解决方案，如果提议者错误地构建了 crList，构建者可能无法安全地提议一个执行区块主体。在这种情况下，构建者应该就直接不提议任何东西，就像提议者根本没有广播过 crList 一样。

融合 PBS 和无状态

PBS 的一个重要的次要目标是允许验证者是完全无状态的 (一旦 Verkle trees 被部署了)。PBS 会实现这点是因为只有构建者需要真正地构建主体；构建者还负责附上见证数据 (witness) 到他们的区块，使得验证者可以在无状态下验证区块。

而要把这个属性扩展到这个方案，每笔交易都需要伴有一个简单的见证数据，证明交易发送人的余额和随机数。如果用户是无状态的，这个见证数据可以由中间节点 (例如，构建者可以自愿做这件事) 来添加。

混合式 PBS 会如何与二层账户抽象交互 (例如 ERC 4337)

ERC 4337 从根本上改变了抗审查的博弈情况，因为它将以太坊层面上交易的概念与用户意图对象的经济概念解耦了。归根结底，我们试图确保用户意图对象是抗审查的。当两者相同时 (就像今天一样)，这可以被说成是交易的抗审查。但是，在 ERC 4337，交易变成了一个包含许多用户意图对象 (在 ERC 4337 里这被称为 user operations) 的封装器。

在”常规的“ PBS 中，这个区分并不重要，因为协议只直接与执行区块交互。构建者可以创建一个包含很多笔 ("常规") 交易的执行区块，或他们可以创建一个包含一笔封装了多项 user operations 的交易的执行区块，或是两者的混合。两种情况的机制是完全相同的；封装器与封装器的封装器之间区别不大。

如果辅助执行区块被用作抗审查，那么机制仍然是一样的。如果使用混合式 PBS，那么对现状交易和 ERC 4337 user operations 的处理就会出现差异：对现状交易的抗审查性是直接得到保证的，但对 ERC 4337 user operations 的抗审查性只是间接提供的。

无论是 ERC 4337 还是混合式 PBS 都需要稍作修改，以确保其在混合式 PBS 的世界中集成抗审查性。要了解原因，首先看看一个为什么 ERC 4337 将保有抗审查性的第一个有问题的论点：

携带 ERC 4337 user operations 的”交易“直接映射到上述”辅助区块“的概念。如果一个给定的 ERC 4337 user operations 不被会进行审查的主要构建者打包，那么任何人 (我们把他们称为”中继者”) 都可以创建一笔打包了 user operations 的交易 (一个假的辅助执行区块)，并期望从中获利。当然，审查者可以在那个确切的时间打包 user operations ，并夺走中继者的收入，但并不总是如此，因此平均而言，中继者将是可获利的，原因与上述辅助构建者策略部分的解释一样。

这个论点的关键缺陷是，“不总是”是错的。这是因为在辅助执行区块的情况和 ERC 4337 交易情况之间存在根本的区别。在辅助执行区块的情况里，主要和辅助执行区块的主体是同时被提交的。因此，两边都不能看到另外一边在做什么，也做不了抢跑。但在 ERC 4337 交易的情况里，胜出的构建者能看到交易，因此他们能做抢跑。

解决方案 1：修改 ERC 4337

我们可以对 ERC 4337 做如下修改： **user operations 将需要有能力指定允许打包它们的一个单一中继者。**这可以保护 user operations不被“窃取” (不过要注意的是，与用户合谋的审查构建者可能仍然可以汲极辅助构建者的收益，因为会进行审查的构建者可以对有相同随机数但不同用户操作的中继者进行抢跑)。

解决方案 2：修改混合式 PBS

需要在 crList 上的交易在所有其他交易前被执行。这就防止构建者抢跑。但是，实际上使用这个功能对提议者来说可能成本更大，因为它可能会减少他们从 MEV 竞拍中获得的收益，因为在 crList 上的交易本身可能就在提取 MEV。因此，用这个方法可能会激励提议者在 crList 的构建上用更复杂的方法，这又把中心化激励带回来了。

PBS 是一个活跃发展的研究领域。减轻 MEV 带来的验证者中心化风险对任何寻求保持其去中心化性质的区块链来说都非常重要。但是，防止构建者中心化变成另一种类型的审查漏洞也同样重要。

在这个时间点上，我在短期更倾向于混合式的 PBS。混合式 PBS 在当前和“纯” PBS 模型之间得到两全其美的效果：

• 即使是一个利他主义的提议者也可以提报任何其他提议者和交易捆打包者正在审查的交易，因此我们保有了现有的抗审查性。
• MEV 提取所需的优先位置被竞拍给另一群专门的行为者，因此验证者不需要碰 MEV，这样我们就减轻了 MEV 驱动验证者中心化的风险。
• 提议者不需要亲自执行区块，因此验证者可以式是全无状态的。这意味着大幅提高一层的区块容量会变得更安全。

在更长期的未来，混合式 PBS 的问题以及希望有更多的抽象性这两点都会是探索辅助执行区块这样概念的原因，它们会与主要执行区块被并行构建。

此外，这篇文章中的论点提出了一些有趣的理由，可能最终会考虑在协议层承认 ERC 4337 的user operations。在短期内，ERC 4337 应该保持作为一个额外协议 ERC，因为在那里它的创新速度会快得多。但是，长期来看，很明显把它写入协议层，并在协议层明确承认用户意图对象能为确保它们免受审查提供更多的选择。

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[email protected]进行授权。