智能账户加密内存池

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

这篇文章探讨了使用智能账户来验证是否遵守加密内存池规则的概念。这可以加强抢先交易保护和审查阻力的保障，以防区块提议者试图违反加密内存池规则。

在加密的内存池中，用户发送加密交易，这些交易在公共约束中发布在链上。这是对下一个提议者的限制，要求他们按预定义的顺序（例如按优先费用排序）包含这些交易。在下一个时隙之前，解密密钥会被显示出来，以便提议者可以Decrypt并包含来自公共约束的交易。他们应该按照预定的顺序将约束中的所有有效交易包含在他们的区块顶部，不要事先插入任何可能抢先解密交易的交易。我们关心的是强制提议者遵守这些规则。

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

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

为了实现其关键属性，即防止抢先交易和抵制审查，加密内存池应分别执行两个规则：排序和包含。如前所述，智能账户可用于强制执行排序，这意味着交易必须在正确的位置、以正确的顺序、在The Block内的正确索引（块顶部）执行。我们还将探讨如何通过防欺诈游戏来强制执行包含，这意味着如果提议者不包含公共约束中的交易，他们将失去奖励，并可能被削减。

智能账户加密内存池有几个好处：

• 无条件的抢先交易保护：提议者在任何情况下都不能抢先交易。即使他们离线并且解密的交易被泄露，未来的提议者也不能将其包括在内并抢先交易，因为交易主体不会在未来的时隙中执行。
• 重组安全性：如果发生重组，仍然不可能进行抢先交易。
• 激励一致性：如果提议者审查任何加密的内存池交易，他们就会错过所有提示。

背景

作为背景介绍，我推荐我作的这个 5 分钟演讲，其中概述了加密内存池的设计空间。

总结一下：

• 用户对他们的交易进行加密。
• 加密交易在公开约束下发布在链上。下一个时隙的提议者应将所有这些交易按预定义的顺序包含在其区块的顶部。
• 在下一个时段开始之前，“密钥员”会透露解密密钥。
• 如果提议者在线，他们就会构建自己的区块。智能账户和防欺诈游戏可用于强制提议者遵守规则，尊重公共约束。

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

设计中还有其他重要方面，例如加密机制、密钥人的性质、公共约束的具体发布位置等；我不会在这篇文章中介绍这些内容。

加密内存池分类

我们可以根据加密内存池设计对提议者执行排序和包含规则的强度对其进行分类。

第 0 阶段 - 受信任

• 完全信任的提议者。
• 排序和包含不强制执行，因此能够抢先和审查而不承担任何后果。

第一阶段-质押

• 提议者拥有可以被削减的权益。他们可以发布提议者承诺。
• 如果提议者重新排序或审查，他们的股份可能会被削减。要求提交提议者违反规则的证据。
• 订单仅可追溯执行，因此仍有可能抢先交易。如果收益超过赌注，则可能发生这种情况。
• 除了削减质押金额外，还可以使用质押来补偿用户。
• 问题：必须削减允许解密交易泄露的离线提议者，即使他们没有及时收到密钥。
• 本白皮书探讨了第一阶段的内存池。它使用了削减和提议者承诺。

第 2 阶段 - 智能账户

• 由智能账户强制执行的排序。
• 提议者在执行之前证明链上排序正确。
• 无法抢先执行，如果顺序不正确，UserOp 主体将不会执行。
• 如果未满足纳入条件，提议者将失去所有加密的内存池奖励。也可能像第一阶段一样被削减。

第 3 阶段 — 供奉

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

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

最终，第三阶段将在长期内提供最强大的安全保障，但实际上需要很长时间才能就适合纳入协议的设计达成共识。从短期到中期来看，第二阶段应该可以提供足够的保护。

下表总结了加密内存池不同阶段的各种执行机制：

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

设计

我将介绍一种使用智能账户和防欺诈游戏对提议者强制执行排序和包含规则的设计。在探索细节之前，我们将首先从高层概述其工作原理开始：

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

该流程如下图所示：

概述3366×1560 267 KB

现在我们将通过一个示例逐步了解该设计在实践中的运作情况，然后更详细地探讨该过程的不同部分。

例子

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

约束690×960 23.5 KB

加密的 UserOps 包含在链上以 blob 或 calldata 形式发布的公共约束中。除了密文之外，还会显示底层 UserOps 的哈希值，以及这些哈希值属于明文 UserOps 的证明。

在下一个时段开始之前，密钥生成者会透露 UserOps 的解密密钥；提议者现在必须构建一个排序声明。

声明780×957 26 KB

在此示例中，加密的内存池按优先级费用进行排序。提议者为每个 UserOp 提供优先级费用证明并对其进行相应排序。提议者还声明哈希值为 0xa 的 UserOp 对预设状态无效。提议者现在必须构建其区块。

块966×1407 26.1 KB

提议者将有效的 UserOps 捆绑到单个交易中，并将其包含在The Block顶部。在此交易中，首先验证排序声明。接下来，以正确的顺序执行有效的 UserOps 0xb 和 0xc。对于每个用户，在执行主体之前，首先进行验证检查。

由于提议者声明哈希值为 0xa 的 UserOp 无效，因此他们没有将其包括在内。但是，现在任何人都可以提交证明 0xa 确实有效并索取提议者对此时隙的小费。

订购声明

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

订货声明应当：

（1）尊重内存池的排序规则，例如按优先费用或FCFS排序。
（2）不包含原始约束中不存在的任何 UserOps。
（3）声明约束中的哪些 UserOps 对预状态无效。

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

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

声明 (3) 允许提议者声称某些 UserOps 无效，因此不需要包含在内。提前证明这一点的成本非常高，因此可以在防欺诈游戏中事后验证。我们将在包含部分进一步阐述这一点。

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

订购

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

• UserOp 正在正确的位置执行，与排序声明相匹配。
• 当前插槽与 UserOp 中包含的插槽匹配。可以使用 SLOT 预编译来检查。
• 捆绑交易在区块顶部执行。可以使用 TXINDEX 预编译进行检查。
• 先前的 UserOp 均未通过验证检查。

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

包容性

欺诈证明游戏用于验证提议者未审查任何有效的公共约束交易。提议者小费累积在智能合约中，并保留一段时间。在此期间，任何人都可以提交 zk 证明，证明提议者声明无效的 UserOp 确实对预设状态有效。提交此证明的任何人都可以从该位置索取提议者小费，提议者也可能被削减。可以烧掉一定比例的奖励，以阻止提议者自己提交欺诈证明（如果没有削减）。如果在挑战期内未提交任何挑战，则提议者可以索取所有小费。

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

注意事项

依赖项

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

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

ERC-6900模块化智能账户可能比标准 ERC-4337 账户更可取。这些账户支持预执行钩子的实现，可用于在执行主要 UserOp 主体之前运行检查。

重组安全

为了重组安全，解密的 UserOps 必须在发布公共约束的时隙之后立即执行。要理解这一点，请考虑如果我们在时隙 x 中在链上发布约束，并在时隙 x+2 中包含解密的 UserOps，会发生什么情况。攻击者可以等到 UserOps 在时隙 x+2 中解密，然后重组链以在时隙 x+1 中包含包含抢先交易的区块。

一旦实现单槽最终性，这一要求就会被取消。

泄露意图

假设用户正在通过加密的内存池将代币 X 大额兑换为代币 Y。该时隙的提议者处于离线状态，因此解密的 UserOp 会向所有人公开。正如所讨论的那样，该兑换不能包含在未来的时隙中，因为 UserOp 的主体不会在未来的时隙中执行，因此无法进行抢先交易。但是，用户进行兑换的意图已被泄露，因此其他人可能会在用户重新提交兑换之前买下代币 Y，从而有效地抢先交易用户。

目前尚不清楚这种攻击是否可靠。例如，交易可能是故意泄露的，目的是操纵市场并提高代币 Y 的价格。

在某些情况下，这可能是一个更大的问题，例如，如果使用加密的内存池提交交易以注册ENS名称。尽管从技术上讲，交易不能被抢先执行，但泄露注册名称的意图可能是一个不可接受的风险。

哈希或承诺

为简单起见，我建议公共约束应显示纯文本 UserOps 的哈希值，以便可以在链上将它们与排序声明进行比较。这种方法会破坏加密机制的安全性，因为哈希值是确定性的，这会使加密方案不安全，无法抵御选择纯文本攻击。

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

EOA 支持

利用EIP-7702，可以通过将ERC-6900代码部署到 EOA 地址来为 EOA 带来相同的功能。

提议者建造者分离

到目前为止，我们假设提议者将在本地构建The Block，但设计仍然可以与MEV-boost或ePBS配合使用。提议者可以照常构建捆绑交易，并通过约束 API请求构建者将其包含在The Block顶部。

结论

我已经概述了一种加密内存池最大程度免信任执行机制的设计，该机制需要的共识级别更改最少。这为防止抢先交易和审查提供了强有力的保障。未来的文章将更详细地探讨设计的其他部分，例如公共约束。