混合加密内存池：密码学

作者：Benedikt, Julian

我们感谢 Anders Elowsson、Terence Tsao、Luis Bezzenberger 和 Jannik Luhn 的反馈和评论。

引言

根据 Hildobby 的 dashboard 的数据，平均每约 30 秒就有一位 Ethereum 用户被 sandwich 一次，该 dashboard 显示，大约三分之一的区块至少包含一次 sandwich attack。被 sandwich 的交易者在交易结束时收到的 token 更少，用户体验也很差，因为那些发现自己被 sandwich 的人可能会觉得自己被窃取了价值。

有了 encrypted mempool，交易可以在其内容尚未知晓之前就被包含进区块并完成排序。由于能从加密交易中提取的 MEV 更少，用户可以享受更低的交易成本。此外，还可以使用 encrypted mempool 构建新的应用，而这些应用在今天的 Ethereum 上无法 trustlessly 存在。最后，本文所提出的 encrypted mempool 方案还可以创建不可偏置的 randomness beacon，通过移除 multi-slot MEV，解锁诸如 Attester-Proposer Separation 之类的新 protocol 功能，见下文。

Builders 目前提供 private transaction submission channels，使用户无需公开暴露交易就能将其送达 Ethereum，效果类似 encrypted mempool。值得注意的有 MEV Protect 和 MEV Blocker。这些 private channels 已经保护了数千亿美元的交易量，并提供一些特殊服务，例如向创造 backrun 机会的用户返利。此外，像 BuilderNet 这样的新 private channels 运行在 Trusted Execution Environments 中，从而创建 trustless 的 private transaction submission。

不过，我们仍然认为，Ethereum 上一个 enshrined 的 encrypted mempool 值得考虑，原因如下：

1. 抗审查性。 Ethereum mempool 提供了其他任何 private submission channel 都无法提供的 抗审查性。Encrypted mempools 以及像 FOCIL 这样的其他抗审查工具会彼此 互补，从而创造出 应用和机构所需要 的抗审查水平。即使其他 private submission channels 并不打算审查，mempool 也可能由于其他力量而向它们集中，正如 email 所发生的那样。
2. 用户仍然会被 sandwich！ 我们不能忽视证据。平均而言，大约每 30 秒就会有人被 sandwich 一次。自你在页面顶部 读到 那个事实以来，这大约又相当于 2-4 位用户。滚动查看这里的 Eigenphi dashboard，以查看最新攻击。显然，协议外的 private submission channels 并不足以保护所有用户。

在这篇文章中，我们提出一种 encrypted mempool 设计，允许 builder 将 encrypted transactions 与 plaintext transactions 一起排序并打包进区块。解密发生在 slot 期间，交易按排序执行。解密密钥包含在下一个区块中。解密通常由 threshold committee 完成，但也可以由用户发起。如下所述，这种 hybrid decryption 设计既能防止 MEV trick，又能保证 liveness。

此外，我们还明确指出，一个 threshold encryption scheme 应该具备哪些属性才适用于这种设计。

可选解密问题

Anders 最近提出了一种名为 Sealed Transactions 的 encrypted mempool 机制。我们在这里用一种非常简化的形式概述其工作方式：

• 用户将加密交易发送到 encrypted mempool。
• 加密交易会在下一个区块中被引用，但不会执行（因为它们是加密的）。
• 用户观察区块并释放一个解密密钥。
• 解密后的交易会排在下一个区块的顶部。

依赖用户负责解密的设计，其根本问题在于，用户可能只会在对自己有利时才这样做。考虑下面这个例子：Ethereum 上有一个交易 USDC/ETH 的去中心化交易所。AMM 上的当前价格是 4500 USDC/ETH。下一个区块中的第一笔交易可能捕捉到一个套利机会。用户可能提交 加密的 交易，如果市场价格变为 4490 USDC/ETH、4480 USDC/ETH、……、4400 USDC/ETH 以及 4510 USDC/ETH、4520 USDC/ETH、……、4590 USDC/ETH，它们将是最优套利交易。就在必须释放解密密钥之前，用户只会为有利可图的交易释放解密密钥。

问题在于，可选披露会诱发 spam 交易，从而挤占 Ethereum blockspace 中创造福利的使用。鉴于 encrypted transactions 的空间有限，是否会包含除上述这些 options 之外的其他交易并不明确。此外，这种 optionality 会对 builder market structure 造成巨大冲击。

Threshold Cryptography 及其问题

上面的讨论表明，对于 encrypted mempools 来说，一个核心问题是：

谁可以解密 encrypted transactions？又在什么时候解密？

换句话说，我们在问用户应当把交易加密给哪个公钥。回到 sealed transactions，在那里是用户自己解密（或者更准确地说 打开）交易，这为新的 MEV 向量打开了大门，如我们所见。另一个常见建议的方法是 threshold cryptography。简而言之，设置如下：

• 存在一个由 n 个参与方组成的 committee，并拥有一个相关联的 encryption key（它可以是 n 个独立的 key，也可以是一个联合 key，见下文）。
• 这个 committee 的每个成员持有 decryption key 的一个 share。
• 只有当足够多（例如至少 t 个，其中 t 是某个 threshold）的 committee 成员聚集起来时，他们才能解密 ciphertexts。

这样一来，用户现在会把交易加密给该 committee 的 encryption key，而 committee 会在之后解密交易。注意，这引入了一个 新的对 committee 的诚实性假设，即 committee 中 <t 个成员被腐化。并且，为了 liveness，我们需要假设至少 t 个诚实成员 在线。如果这不成立，那么 committee 就无法解密。这是使用 threshold encryption 时的主要挑战，即使我们拥有一个理想的 threshold encryption scheme（见下文）也是如此。

概览与思路

在解释我们方案的详细架构之前，我们先给出一个概览并概述主要思路。

参与方与威胁模型

我们考虑这样一种设置：一个 用户 希望向 blockchain 提交一笔交易。该用户可能是诚实的，也可能是不诚实的。

此外，我们假设存在一个由 n 个参与方组成的 committee。该 committee 的选取方式不在本文讨论范围内。若 < t 个参与方表现为不诚实，我们定义该 committee 为诚实。重要的是，诚实参与方可能会暂时离线。如果在任何给定时刻，在线的参与方少于 t 个，因此诚实参与方无法解密，我们就认为该 committee 处于离线状态。

总结如下：

• 用户：不诚实或诚实
• 委员会：诚实（且在线）或离线

思路 1：Hybrid Mode

我们的第一个观察是，Sealed Transactions 和 threshold encryption 彼此互补，并且可以有效结合。

我们假设，在正常情况下用户会加密给 committee，但：

• 用户打开 ciphertext（如 sealed transactions 中那样），并且
• committee 解密 ciphertext。

这种组合解决了前面讨论的两个主要问题：Sealed Transactions 中的 selective opening，以及 threshold encryption 的 liveness 问题。为说明这一点，考虑以下四种情况：

• 情况 1：诚实用户，委员会在线： 用户发送一个单一 ciphertext，委员会成功解密它。
• 情况 2：不诚实用户，委员会在线： 用户不能再像普通 sealed transactions 那样对其 ciphertexts 做 selective open。因为委员会会解密 所有 ciphertexts。
• 情况 3：诚实用户，委员会离线： 用户会打开其交易。
• 情况 4：不诚实用户，委员会离线： 这是坏情况，此时 selective opening 是可能的。为了解决这个问题，我们希望在创建 ciphertexts 时，用户不知道自己处于情况 2 还是情况 4，也就是说，不知道 committee 是在线还是离线。

总结如下：

为了让用户难以猜测 committee 是在线还是离线，定期（例如每几个 slot）轮换 committee 是有意义的（可以是确定性的，甚至是随机的）。注意，使用 silent threshold encryption（见下文）时，这样做的成本可以很小。

虽然情况 4 不理想，但在 committee 大多数时间都在线的前提下，它应该很少发生。此外，如果我们让情况 2 的成本对用户足够高，这会抑制不诚实行为。因此，系统在大多数时间实际上会运行在情况 1 或情况 2。

简而言之：Threshold encryption 主要用于抑制用户在 Sealed Transactions 中制造 MEV 向量的动机。

思路 2：Hybrid Encryption

如果我们想实现这种 hybrid approach，就需要把 threshold encryption scheme 的 ciphertexts 写到链上。根据不同 scheme，这可能会很昂贵，因为 ciphertexts 很大。此外，从 threshold encryption 的定义来看，用户是否已经对一个（可能格式错误的）ciphertext 所对应的交易 承诺 也并不完全清楚。为了解决这两个问题，可以采用 hybrid encryption：

1. 用户在链上放入 ct = \mathsf{AES.Enc}(k,tx) 和 h = \mathsf{Hash}(k)，其中 k 是一个对称加密 key。
2. 用户将 k 的 threshold encryption 发送给 committee。这可以在链下进行，但有一些限制（见思路 3）。
3. 为了打开交易，用户或 committee 在链上发布 k。

这样一来，链上只会留下一个小的对称 ciphertext 和一个 hash。此外，潜在恶意用户通过 h 对 k 进行了承诺，因此也就对唯一交易 tx = \mathsf{AES.Dec}(k,ct) 进行了承诺。

思路 3：采样 Ciphertexts

上文中的对称加密 key k 的 threshold encryption ciphertext 可能很大。由于区块大小有限，大 ciphertext 意味着每个 slot 能包含的数量很少。

在我们的思路 2 中，我们提出将这个大 ciphertext 链下发送，而链上只放一个简短的交易对称 ciphertext。

然而，这里有一个重要问题：加密 k 的 ciphertext 必须对 threshold committee 可用，否则只有用户自己能够解密，并保留“只有在有利可图时才解密”的 optionality。因此，我们提出对 data availability 进行采样。

如果 ciphertext 不可用，或者它已被解密但 ciphertext 与对称加密 key 不对应，那么对应交易不应被执行，以防止给予用户披露的 optionality。

builder 在区块中包含特殊的 blobs，这些 blobs 引用了那些其 blob 中包含 encryption keys 的交易。Attesters 对这些 blobs 的可用性进行采样。

最后，如果 threshold committee 找到的 decryption key 与用户提交用来打开交易的 decryption key 不同，那么该交易可能不会被执行。因此，decryption keys 必须与链上放置的对称加密 key 的 hash 对应。

Threshold encryption 的要求

对于我们的方案，所使用的 threshold encryption scheme 应满足以下要求：

• 小 Public Keys 的 Silent Setup： 该 scheme 应避免使用 distributed key generation (DKG) protocol 来创建共享 public key。DKG protocols 复杂、交互性强，并且需要大量实现工作。此外，每当 committee 变化或轮换时，都必须重新运行它们。相反，我们要求采用 silent setup：每个 committee 成员独立生成自己的 public key。加密时依据所有 committee 成员 public keys 的列表进行。这些 public keys 的大小应为常数，不依赖于 committee 规模——例如，只由几个 group elements 组成。
• 非交互式解密： 为了尽量降低延迟和复杂性，解密过程应是非交互式的。具体而言，每个 committee 成员都应能够使用自己的 secret key 和 ciphertext 计算一个 decryption share。一旦收集到足够多的 decryption shares，任何参与方都应能够公开地组合它们，以恢复原始消息。
• 小 Ciphertext Size： Ciphertexts 必须保持在实际可接受的大小范围内，因为它们将存储在 blobs 中。为了最大化效率，我们希望每个 blob 能存储多个 ciphertexts。
• CCA2 Security： 该 scheme 必须提供 CCA2 安全性（即在 chosen ciphertext attacks 下的安全性）。这一点至关重要，因为在我们的场景中，任何人都可以提交 encrypted transactions，而委员会成员随后会为这些交易计算并公开 decryption shares。

另一个（可选但非常有用的）特性可能是能够以较小通信量 batch decrypt 多个 ciphertexts，也就是能够为一组多个 ciphertexts 生成简洁的 decryption shares（见 这里 和 这里）。

让我们引用几个候选 scheme，并说明它们在哪些方面未能满足我们的要求：

• 经典的 CCA2 安全 threshold encryption schemes，例如 Shoup and Gennaro 的方案，或 Boneh, Boyen, and Halevi 的方案，以及为 encrypted mempools 提出的现代 schemes（例如 这里 和 这里）都依赖 DKG。
• Garg et al. 的 scheme 具有 silent setup，但对规模为 n 的 committee 使用线性大小的 public keys（即每个 public key 包含 n 个 group elements）。尽管他们把导致这种开销的元素称为 “hints”，但这些元素实际上属于 public key，必须与真正的 public key 一起存储在链上。
• 一个较新的 scheme 具有 silent setup 和小 key。缺点是，它的 ciphertext（对于小 plaintexts）略大，并且只具备 CCA1 安全性。考虑到 ciphertext 的大部分会存储在 blobs 中，这种 ciphertext size 可能是可以接受的。

架构

本节更详细地描述 Hybrid Encrypted Mempools 机制。我们参考下方 Figure 1 以了解整体概览。

• Block n 之前 (Before T{1})：用户通过向 threshold committee 加密，将 encrypted transactions 提交到 encrypted mempool。交易会明文指定 gasLimit 和 from address。用户会被预先收取 gasLimit \* gasPrice。用户可以提交比严格必要值更高的 gasLimit 以获得额外混淆，正如 Anders 在 Sealed Transactions 中所建议的那样。
• Block n (T_{1})：builder 像今天一样传播区块。区块中有一个有序交易列表，encrypted 和 decrypted transactions 可以交错出现。每个 encrypted transaction 的对称加密内容会放入区块，同时还会放入对称加密 key 的 hash。交易的对称加密大小大致与明文交易一样大。此外，加密 key 的 ciphertext 会放入一个 blob 中，以确保其可用。
• Attestation Deadline Block n (T_{2})：Attesters 验证区块中每个 encrypted transaction 所对应的对称加密 key 的 ciphertext blobs 是否可用。如果发现任何 blob 不可用，他们就不会对该区块投票。
• Non-interactive Threshold Decryption (Before T_{3}, After T_2)：threshold committee 成员一旦看到区块，就开始非交互式解密。这意味着每个 committee 成员都会输出并传播一个 decryption share。
• Decryption Deadline (T_{3})：用户必须在此截止时间之前提交其 decryption keys k。此外，committee 也必须在此截止时间之前提交 k。更准确地说，我们假设至少有一方会在足够多的 decryption shares 可用时创建 k，并在此截止时间之前传播它。Attesters 会冻结对已可用 decryption keys 的视图，无论这些 key 是来自单个用户还是 threshold committee。
• Block n+1 (T_{4})：区块必须包含在截止时间之前释放的所有 decryption keys。builder 可以自由包含在更晚时才释放的 decryption keys。
• Attestation Deadline Block n+1 (T_{5})：Attesters 使用 block n+1 中包含的 decryption keys 来执行 block n。如果某个 attester 在 Decryption Deadline 之前看到了一个 decryption key，但它没有被包含在 block n+1 中，那么该 attester 就不会对 block n+1 投票。这类似于 FOCIL 中也使用的 fork-choice rule 的 view-merge 变更。

Figure 1：Hybrid encrypted mempool 设计的示意概览。用户在 T_{1} 之前，将其交易的 hash 和对称加密内容放入一个黑色密封信封中发送给 builder。此外，它还在 T_{1} 之前将其对称加密 key 的 threshold encryption ciphertext 作为 ‘ct’ 发送到网络。相关信息被包含在区块及其 blobs 中，并由 attesters 在 T_{2} 之前进行采样。Threshold committee 观察该 ciphertext 并执行非交互式解密，在截止时间 T_{3} 之前输出一个 decryption key，用户也可以释放一个 decryption key。Attesters 强制要求在 T_{3} 之前释放的任何 decryption key 都要包含在区块中。Decryption keys 会在 T_{4} 之前被包含到下一个区块中。在 T_{5} 时，attesters 执行 block 1。

作为一个缺点，我们注意到，如果 threshold committee 在 attesters 对区块投票之前就完成解密，那么一个晚些时候才揭示的区块，无论其是否恶意，都会导致 threshold committee 解密该交易，即使它最终不会成为 canonical。用户可以让其交易仅在特定 block height 执行，从而阻止已解密交易被包含到更晚的区块中。不过，即使如此，已解密交易仍会泄露用户意图，从而伤害用户。

Threshold committee 也可以在 attesters 完成 attest 之后再解密，以减少 reorg 的可能性；然而，这样一来区块仍然不会 finalized，仍可能发生 reorg，而且会增加 slot 持续时间，用户体验更差。

这个设计的另一个大缺点是，block n 的执行结果只能在 block n+1 之后才能确定无疑。这是因为 builder 总是可以包含比公开观察到的更多 decryption keys。假设 committee 离线，而 builder 包含了一个 attesters 之前没有见过的 decryption key，那么执行结果就会与 attesters 预期的不同。这会导致更差的用户体验，因为执行时间会延迟一个 slot。如果 committee 在线，用户可以在委员会释放 decryption key 后立即执行一个区块。

安全直觉

让我们对我们的设计给出一些安全直觉。

可选解密问题被消除。 我们首先论证，在 sealed transaction 设计中存在的可选解密问题，在我们的构造中得到了缓解。为此，先观察到用户没有动机假设 committee 离线，因为：

• committee 会频繁轮换。
• 每个 encrypted transaction 都需要预先支付，因此对离线 committee 的投机成本很高。

当 committee 在线时，有两种可能情况：

• 情况 1：threshold encryption ciphertext 可用且格式正确，因此会被解密。
• 情况 2：threshold encryption ciphertext 不可用或格式错误。

重要的是，在 T_1 时，用户已经对自己处于情况 1 还是情况 2 做出承诺（这使用了对 blob 的 commitment 的 binding property）。这意味着用户必须 预先 决定 ciphertext 是否会被解密——这与 sealed transaction 设计不同，在后者中，这个决定可以被推迟。

该构造的隐私性。 接下来，我们声称我们的构造会隐藏交易内容，直到它们被包含进区块。直观地说，这是因为：

1. committee 只有在时间 T_2 之后才开始解密。
2. 只要 committee 不解密，threshold encryption ciphertext 就不会泄露关于 k 的任何信息（依据 threshold encryption scheme 的安全性）。
3. 在 random oracle model 下，并假设 k 具有足够高的 entropy，hash h = \mathsf{Hash}(k) 不会泄露关于 k 的任何信息。
4. 因此，对称 ciphertext ct = \mathsf{AES.Enc}(k, tx) 不会泄露关于交易 tx 的任何信息。

Split-View 攻击。 最后，截止时间 T_3 的选择是为了确保 proposer 有足够时间观察已解密或已打开的 key k。如果在截止时间之前，attesters 看到的所有 decryption keys 都被包含在区块中，那么他们就会对该区块投票。如果没有这样的截止时间，就可能出现 attesters 看到某个 key，而 proposer 没有看到的情况——这会导致他们拒绝为 proposer 的区块投票，因为该区块看起来是不完整的。

来自 Encrypted Mempools 的随机性

Ethereum 当前的 randomness 来源是 RANDAO，这是一个 accumulator，每个 proposer 都会在已有的 RANDAO 值上添加随机贡献。更多信息可参见 Ben Edgington 的 Ethereum book。RANDAO 的一个问题是它是 可偏置的：proposers 可以选择是否揭示他们的区块，从而使 RANDAO 的输出产生偏置。如果这样做对他们有利，proposers 就可能这么做，例如 Kaya Alpturer 和 Matt Weinberg 在 这篇论文 中探讨的那样，这可能让他们在下一个 epoch 更频繁地被选为 proposer。此外，RANDAO 的可预测性是迈向 Attester-Proposer Separation (APS) 的关键阻碍，如 这场 talk 中所探讨的。

Encrypted mempools 会创建一种新的、更好的 randomness 来源。例如，我们可以把一个区块的 post-state root 的 hash 作为 randomness 来源。如果区块中存在 encrypted transactions，那么 post-state root 就是不可预测的。如果通过 FOCIL 强制包含，builder 可能无法排除这些 encrypted transactions。也许 threshold committee 释放的 decryption key 的 hash 也可以作为 randomness 来源。即使 threshold committee 离线，这种 randomness 也很难预测，因为很难预测 threshold committee 是否离线，而且 committee 会频繁轮换，甚至可能每几个 slot 就轮换一次。不过，这种 randomness 来源并非万无一失，因为如果区块中没有或只有少量 encrypted transactions，那么 post-state root 可能是可预测的。

未解问题、问题、替代方案

在本文中，我们提出了一种 encrypted mempool 设计，它使用 threshold committee 来移除用户的 reveal optionality，同时允许用户 reveal 以降低 threshold committee 的 liveness 风险。本文的主要贡献是：

1. 探索了设计空间中的一个新部分，我们称之为使用 threshold committee 并依赖用户解密的 hybrid encrypted mempools。
2. 澄清了 Ethereum 语境下 threshold committee 的 cryptographic 要求。

在最后一节中，我们强调这个提案仍然存在的开放问题和难题。

首先，为了确保用户不知道 threshold committee 是否在线，必须频繁轮换 threshold committee。频繁轮换也会降低对 threshold committee 的 liveness 担忧。如果只存在一个 threshold committee，而不是 hybrid design，协议设计会更简单。其他缓解 liveness 风险的设计也可能可行。例如，在满足某个条件（比如错过了几个 slot）后，可以关闭 threshold committee。总而言之，也许 hybrid design 带来的额外协议复杂性并不值得。

其次，用户会把交易加密给一个特定的 threshold committee。如果 committee 轮换而交易尚未被包含，就需要重新提交交易。这会恶化用户体验。

此外，还需要协调将来自不同用户的多个 ciphertexts 放入一个 blob 中。通常 blob 是由 blob submitter 创建的。builder 可以承担协调者的角色，但这样的话，ciphertexts 需要以某种方式通过 gossip 传播给 builder。或者，可以创建一种新的 data structure，它像 blob 一样被采样，但恰好容纳一个 ciphertext。

最后，应更认真地考虑应用是否可以在协议外构建类似设计。交易 hashes 当然可以被包含在区块中，而应用可以考虑通过例如 EigenLayer 来设置 threshold committee 和 data availability。这种方法可以降低协议内复杂性，同时支持依赖 encrypted transactions 的用例，例如防止 sandwich。

• 一种简单的 PBS 形式：MEV Lock
• LUCID：具有分布式 payload 传播的 encrypted mempool

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