智能账户加密内存池

由 Marc Harvey-Hill @ Nethermind 撰写。特别感谢 Ahmad Bitar, Aikaterini-Panagiota Stouka, Stefano De Angelis, Conor McMenamin, Lin Oshitani, 和 Julie Bettens 的反馈。反馈不一定代表认可。

本文探讨了使用智能账户来验证加密 mempool 规则是否得到遵守的概念。这可以增强对 frontrunning 保护和审查抵抗的保证，以应对区块提议者试图违反加密 mempool 规则的情况。

在加密 mempool 中，用户发送加密交易，这些交易以公开约束的形式发布在链上。这是一个对下一个提议者的约束，要求他们以预定义的顺序（例如按优先级 fee 排序）包含这些交易。就在下一个 slot 之前，解密密钥会被揭示，以便提议者可以解密并包含来自公共约束的交易。他们_应该_以预定的顺序在其区块的顶部包含约束中_所有_有效的交易，并且在之前不插入任何可能 frontrun 解密交易的交易。我们关心的是强制提议者遵守这些规则。

智能账户可用于防止恶意提议者的 frontrunning。用户可以加密 ERC-4337 智能账户交易 (UserOp)，而不是加密普通交易，这些交易会检查它们是否已在区块内的正确顺序和正确索引（即顶部）中被包含。如果检查失败，那么 UserOp 的主体（例如，交换）将不会运行，因此它们不可能被 frontrun。

如果提议者不是恶意的，而是离线了，它们也可以提供保护。在这些情况下，解密密钥仍然会被揭示，因此现在每个人都可以看到解密的交易。这意味着下一个提议者可以包含这些已解密的交易，并在之前插入他们自己的 frontrunning 交易。智能账户再次可以提供保护；作为在 UserOp 开始时执行的检查的一部分，我们可以验证 UserOp 是否在其预期的 slot 中执行。如果检查失败，那么 UserOp 的主体将不会运行，因此攻击不再可能。

为了拥有其关键特性，frontrunning 保护和审查抵抗，加密 mempool 应该分别强制执行两个规则：排序和包含。如前所述，智能账户可用于强制执行排序，这意味着交易必须在正确的 slot、正确的顺序以及区块内的正确索引（区块顶部）中执行。我们还将探讨如何通过欺诈证明博弈来强制执行包含，这意味着如果提议者不包含公共约束中的交易，他们将失去奖励，并且可能会被削减罚没。

智能账户加密 mempool 具有以下几个优点：

• 无条件 frontrunning 保护：提议者在任何情况下都不能 frontrun 交易。即使他们处于离线状态并且解密的交易被泄露，未来的提议者也不能包含并 frontrun 它们，因为交易的主体将不会在未来的 slot 中执行。
• Reorg 安全性：即使发生 reorg，仍然不可能 frontrun。
• 激励对齐：如果提议者审查任何加密 mempool 交易，他们将错过所有的 tips。

背景

作为背景，我建议观看我所作的 这个 5 分钟的演讲，其中概述了加密 mempool 的设计空间。

总结：

• 用户加密他们的交易。
• 加密的交易以公共约束的形式发布在链上。下一个 slot 的提议者_应该_在其区块的顶部以预定义的顺序包含_所有_这些交易。
• 就在下一个 slot 开始之前，解密密钥由“keypers”揭示。
• 如果提议者在线，他们会构建他们的区块。智能账户和欺诈证明博弈可用于强制提议者遵守规则，尊重公共约束。

此设计侧重于第 4 点：如何强制执行公共约束中的所有交易都以正确的顺序被包含。我们将探讨一种智能账户方法，该方法通过强制执行排序和包含规则来缓解恶意和离线提议者的问题。

该设计还有其他重要方面，例如加密机制、keypers 的性质、公共约束的确切发布位置；我将不在本文中介绍这些内容。

加密 Mempool 分类

我们可以根据加密 mempool 设计在多大程度上强制提议者遵守排序和包含规则对其进行分类。

阶段 0 - 受信任

• 完全受信任的提议者。
• 不强制执行排序和包含，因此能够 frontrun 和审查而不会受到任何惩罚。

阶段 1 - 质押

• 提议者拥有可以被削减罚没的 stake。他们可以发布提议者承诺。
• 如果提议者重新排序或审查，他们的 stake 可能会被削减罚没。需要发布提议者违反规则的证明。
• 仅追溯强制执行排序，因此仍然可能 frontrun。如果收益超过 stake，则可能会发生这种情况。
• 可以使用 stake 来补偿用户，而不是削减罚没。
• 问题：必须削减罚没允许泄露解密交易的离线提议者，即使他们没有及时收到密钥。
• 本白皮书 探讨了第 1 阶段的 mempool。它使用削减罚没和提议者承诺。

阶段 2 - 智能账户

• 通过智能账户强制执行排序。
• 提议者在执行之前在链上证明正确的排序。
• 不可能 frontrun，如果排序不正确，UserOp 主体将不会执行。
• 如果不满足包含，提议者将失去所有加密 mempool 奖励。也可能像在第 1 阶段中一样被削减罚没。

阶段 3 - 纳入协议

• 通过区块有效性条件强制执行。
• 如果不满足排序和包含，提议者无法构建有效的区块；这意味着他们将错过区块奖励。
• 必须通过硬分叉将其纳入协议中。
• 需要更长的时间来协调适合纳入协议的设计。

与第 1 阶段相比，第 2 阶段具有无条件 frontrunning 保护的优势。在第 1 阶段中，frontrunning 仍然是可能的，因为它只是在事后才受到惩罚；如果获得的价值超过削减罚没造成的损失，则可能会发生这种情况。如果提议者只是离线并且其 slot 中的解密交易被泄露，也可能会发生这种情况。对于第 1 阶段，提议者可能会因此而被削减罚没（如果他们没有及时收到解密密钥，这可能是不公平的），而在第 2 阶段中，这不是问题，因为泄露的交易无法在其预期 slot 之外执行。

从长远来看，第 3 阶段最终将提供最强的安全保证，但实际上需要很长时间才能就适合纳入协议的设计达成共识。对于中短期而言，第 2 阶段应该提供足够的保护。

下表总结了不同阶段的加密 mempool 的各种强制执行机制：

请注意，加密 mempool 的阶段不是其安全性的唯一因素，这还取决于其他方面，例如 keyper 机制。

设计

我将提出一种设计，该设计使用智能账户和欺诈证明博弈来强制提议者遵守排序和包含规则。在更详细地探讨细节之前，我们将从该设计如何工作的高级概述开始：

• 用户创建并加密 UserOp。这些 UserOp 指定它们应该在哪个 slot 中执行（即下一个 slot）。
• 加密的 UserOp 作为公共约束包含在链上。
• 在下一个 slot 开始时，解密密钥被广播，提议者解密其 slot 的 UserOp。他们开始构建自己的区块（他们可以使用 MEV-boost，这将在 PBS 部分 中讨论）。
• 提议者创建一个“排序声明”。此声明是提议者声明哪些交易在公共约束中，以及它们应如何根据 mempool 的规则进行排序。他们还可以声明某些解密的 UserOp 无效，并且不包含它们。
• 提议者将所有（有效的）解密 UserOp 捆绑到一个 ERC-4337 交易中。排序声明应作为 calldata 传递到此交易中。
• 提议者_应该_在其区块的顶部包含此捆绑交易。
• 验证检查作为此捆绑交易的一部分在链上进行。可以验证排序声明是否满足公共约束，然后可以验证每个 UserOp 是否遵循排序声明。
• 如果检查通过，UserOp 主体将被执行，否则它们将在检查执行后停止，并且主体将不会被执行。
• 提议者可能错误地声称某些有效交易无效；这就是使用欺诈证明博弈的地方。交易 tips 被锁定一段时间，在此期间，任何人都可以提供证据证明提议者谎报了某个交易无效。然后，提议者将无法收取其奖励并且可能会被削减罚没。

流程如下图所⽰：

\ overview3366×1560 267 KB

现在，我们将逐步执行一个示例，以了解此设计在实践中如何工作，然后再更详细地探讨过程的不同部分。

示例

三个用户有他们想要通过加密 mempool 执行的 UserOp。这些 UserOp 具有哈希值 0xa、0xb、0xc。用户加密他们的 UserOp 并将其发送到加密 mempool。

\ Constraint690×960 23.5 KB

加密的 UserOp 包含在发布在链上 blob 或 calldata 中的公共约束中。除了密文之外，还揭示了底层 UserOp 的哈希值，以及这些哈希值是明文 UserOp 的证明。

在下一个 slot 开始之前，keypers 揭示 UserOp 的解密密钥；提议者现在必须构建一个排序声明。

\ Declaration780×957 26 KB

在此示例中，加密 mempool 按优先级 fee 排序。提议者为每个 UserOp 提供优先级 fee 的证明，并相应地对其进行排序。提议者还声明哈希值为 0xa 的 UserOp 相对于前置状态无效。提议者现在必须构建他们的区块。

\ Block966×1407 26.1 KB

提议者已将有效的 UserOp 捆绑到一个交易中，并将该交易包含在区块的顶部。在此交易中，首先验证排序声明。接下来，按照正确的顺序执行有效的 UserOp 0xb 和 0xc。对于每个 UserOp，在执行主体之前首先执行验证检查。

由于提议者声明哈希值为 0xa 的 UserOp 无效，因此他们没有包含它。但是，现在任何人都可以提交证据证明 0xa 实际上是有效的，并获得该 slot 提议者的 tips。

排序声明

一旦 UserOp 被解密，提议者必须首先在 calldata 中发布“排序声明”。这是提议者声明为正确排序的 UserOp 哈希列表。一旦证明此列表对于公共约束是正确的，则每个 UserOp 都可以使用它来检查是否已按正确的顺序包含它。

排序声明应：

(1) 遵守 mempool 的排序规则，例如按优先级 fee 或 FCFS 排序。

(2) 不包含任何不在原始约束中的 UserOp。

(3) 声明约束中哪些 UserOp 相对于前置状态无效。

我们可以立即验证 (2)，方法是将声明与发布在 blob 或 calldata 中的公共约束进行比较；提议者可以针对 blob KZG 承诺证明约束的内容。公共约束应公开 UserOp 的哈希值（用户可以在提交时证明哈希值）；然后可以将这些哈希值与排序声明进行比较，以确保不存在未包含在原始约束中的哈希值。

我们还可以通过将排序声明与公共约束中的哈希列表进行比较来立即验证 (1)。在 FCFS 的情况下，列表应该是相同的。对于优先级 fee 排序，提议者必须为每个 UserOp 提供优先级 fee 的额外证明。

声明 (3) 允许提议者声明某些 UserOp 无效，因此不需要包含它们。预先证明这一点将非常昂贵，因此可以在欺诈证明博弈中改为在事后验证。我们将在 包含部分 中进一步详细介绍这一点。

一旦在链上证明了 (1) 和 (2)，现在就可以在 UserOp 排序检查中使用排序声明。

排序

在执行 UserOp 的主体之前，必须进行检查以验证：

• UserOp 正在正确的位置执行，与排序声明匹配。
• 当前 slot 与 UserOp 中包含的 slot 匹配。可以使用 SLOT 预编译来检查这一点。
• 捆绑交易在区块顶部执行。可以使用 TXINDEX 预编译来检查这一点。
• 之前没有 UserOp 未通过验证检查。

只有在验证了这些内容之后，才会执行 UserOp 的主体。如果任何检查失败，则 UserOp 的主体以及后续 UserOp 的主体都无法执行；提议者将无法获得任何奖励，并且可能会被削减罚没。

包含

欺诈证明博弈用于验证提议者是否审查了公共约束中任何有效的交易。提议者的 tips 累积在智能合约中，并保留一段时间用于挑战。在此期间，任何人都可以提交一个 zk proof，证明提议者声明为无效的 UserOp 确实相对于前置状态有效，并且有足够的 gas 可以包含它。任何提交此证明的人都可以获得该 slot 提议者的 tips，并且提议者也可能会被削减罚没。奖励的某个百分比可能会被销毁，以阻止提议者自己提交欺诈证明（如果没有削减罚没）。如果在挑战期内未提交任何挑战，则提议者可以获得所有 tips。

另一种设计可以强制提议者预先提供无效交易的证明。由于生成这些证明的成本很高，因此可能会导致针对提议者的恶意攻击，因此我建议使用欺诈证明博弈。

考虑事项

依赖项

此提案依赖于 EIP-7793，即 TXINDEX 预编译；不需要其他共识级别的更改。必须具有交易索引才能检查捆绑交易是否在区块顶部执行。

EIP-7843，即 SLOT 预编译，是一个软依赖项。通过此预编译，我们可以验证当前 slot 是否与 UserOp 中指定的 slot 匹配。它不是一个严格的依赖项，因为 UserOp 可以改为包含一个时间戳，该时间戳与 TIMESTAMP opcode 进行比较。这种方法有效，但不太具有前瞻性，因为它需要在 slot 长度发生变化时进行更新。

ERC-6900 模块化智能账户可能比标准 ERC-4337 账户更可取。这些模块化智能账户支持预执行 hook 的实现，可用于在执行主要的 UserOp 正文之抢跑检查。

Reorg 安全性

为了 reorg 安全性，解密的 UserOp 必须在发布公共约束的 slot 之后立即执行。为了理解这一点，请考虑如果我们在 slot x 中发布一个链上约束，并在 slot x+2 中包含解密的 UserOp 会发生什么。攻击者可以等到 UserOp 在 slot x+2 中被解密，然后 reorg 链以在 slot x+1 中包含包含 frontrunning 交易的区块。

一旦实现单 slot 最终性，就可以删除此要求。

泄露意图

想象一下，一个用户正在通过加密 mempool 进行从代币 X 到 Y 的大型交换。该 slot 的提议者处于离线状态，因此已解密的 UserOp 已向所有人显示。如前所述，不能在未来的 slot 中包含该交换，因为它可能会被 frontrun，因为 UserOp 的主体将不会在未来的 slot 中执行。但是，用户进行交换的意图已被泄露，因此其他人可能会购买代币 Y 以预期用户重新提交其交换，从而有效地 frontrun 该用户。

尚不清楚是否可以可靠地执行此攻击。例如，可能是故意泄露交易以试图操纵市场并提高代币 Y 的价格。

在某些情况下，这可能是一个更大的问题，例如，如果加密 mempool 用于提交交易以注册 ENS 名称。尽管从技术上讲无法 frontrun 该交易，但泄露注册名称的意图可能不是可以接受的风险。

哈希或承诺

为了简单起见，我建议公共约束应公开明文 UserOp 的哈希值，以便可以在链上将其与排序声明进行比较。这种方法会破坏加密机制的安全性，因为哈希值是确定性的，这将使加密方案对于选择明文攻击不安全。

我们可以使用不会泄露有关明文信息的承诺，而不是使用哈希。可以使用来自 Lee et al., 2019 和 Campanelli et al., 2019 的技术，这些技术将加密方案与承诺相结合。

EOA 支持

通过 EIP-7702，可以通过将 ERC-6900 代码部署到其地址，将相同的功能引入 EOA。

提议者构建者分离

到目前为止，我们假设提议者将在本地构建区块，但是该设计仍然可以使用 MEV-boost 或 ePBS。提议者可以像往常一样构建捆绑交易，并请求构建者通过 constraints API 将其包含在区块的顶部。

结论

我概述了一种用于加密 mempool 的最大程度地无需信任的强制执行机制的设计，该设计需要最少的共识级别更改。这提供了针对 frontrunning 和审查的强大保证。未来的文章将更详细地探讨设计的其他部分，例如公共约束。

• 密封交易

• 原文链接： ethresear.ch/t/smart-acc...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～