对LUCID及加密方案不可知的加密内存池设计的批评
本文档的目的与免责声明
EIP-8184 (LUCID) 是一项关于加密内存池设计的最新提案。加密内存池旨在保护用户免受不良 MEV 形式（如抢先交易和三明治攻击）的侵害，并解决一个非常真实、面向用户的问题。不幸的是，设计一个安全的加密内存池是一个难题，其“理想版本”需要密码学工具，即某种足够好的门限加密，而我们现在（还？）没有这样的工具。
LUCID 的编写目标很明确：在缺乏足够好的门限密码学的情况下提供最佳方案——但这带来了严重的缺点和局限性。
在这篇文章中，我们收集并记录了这些缺点和局限性，包括 LUCID 用于缓解它们所采取的对抗措施中存在的陷阱。目标是形成一份参考文档，将 LUCID 的负面问题集中在一处，便于访问和理解。目标受众包括：
希望进一步研究加密内存池并寻求缓解此处所述缺点的人。
最终需要决定是否将 LUCID 纳入 EIP 流程的核心开发者。
想了解 LUCID “细则”的潜在用户。
我们想强调，下面描述的 LUCID 最重要的局限性最终源于缺乏足够好的密码学，并且 LUCID EIP 本身也承认了这一点。特别是，最大的弱点是交易发送者的披露可选性。我们认为，只要我们缺乏足够好的密码学工具，任何加密内存池设计都会存在这个问题。
免责声明
作者并未声称此处收集的批评点是新提出的；如上所述，EIP 本身甚至承认了若干问题。
此外，尽管此处提出的批评（有意地）听起来非常负面，但作者对于是否将 LUCID EIP（在经过一些简单的错误修复/澄清后）纳入并没有强烈的支持或反对意见：鉴于目前密码学方面的技术水平，LUCID 风格的设计可能确实是目前我们能做的最好方案，而加密内存池的使用场景非常有力。然而，我们认为，在充分了解其缺点的情况下做出这样一个艰难的决定——现实地说，目前（某种变体的）LUCID 是唯一的选择——是非常重要的。
什么是 LUCID？
LUCID 是一项关于加密内存池设计的 EIP。它旨在让用户向公共内存池提交一笔交易 tx（例如，ETH → USDC 交换），并确保在交易被包含之前，任何其他方都无法看到交易的内容。这消除了某些形式的有害 MEV，例如抢先交换。
让我们简要、高层级地（并且有些简化——特别是，我们很大程度上省略了交易包）概述 LUCID 的工作原理。更多细节请参考 EIP。请注意，由于我们关注点不同，此处的解释与 EIP 中的解释有很大不同。
在 LUCID 中，用户首先仅向内存池提交对 tx 的承诺，并购买一个被包含在插槽 n 中的交易票证。购买交易票证本质上意味着，只要用户遵守协议规则，就能获得其承诺的交易将在确定的时间点被包含的保证。在插槽 n 的区块负载确定并包含交易票证后，用户打开承诺并披露 tx。所有此类已披露的 LUCID 交易随后在插槽 n 和插槽 n+1 之间按照预定义的顺序执行。形式上，LUCID 强制下一个插槽 n+1 的构建者将所有正确披露的交易包含在区块顶部。但对于我们的讨论来说，将已披露的 LUCID 交易视为在插槽之间执行更有帮助。
这里的加密在哪里？
细心的读者可能已经注意到，上面的描述中没有提及加密，只有承诺。这是因为 LUCID 实际上并不是一个加密内存池，至少不是文献中通常理解的那种；相反，它试图通过一种承诺-披露方案来实现这些目标。LUCID 仅以以下方式使用加密：
而不是承诺 tx 并在之后披露，LUCID 发布 tx 的加密结果，并承诺（之后披露）一个解密它的短密钥。这样做的巨大优势是将大部分通信提前到更早的时间点，只留下小消息用于延迟关键的披露，代价是稍早泄露一些消息长度元数据。然而，这种优化不会影响本文的论点，因此我们考虑更简单的版本。
协议实际上并不关心披露消息来自何处，LUCID 添加了对委托披露的基本支持，即用户可以指定一个外部方来负责披露并由此获得报酬。用户如何使这个外部方能够实际做到这一点是协议外的；它可能涉及某种双向的信任关系，和/或很可能涉及实际的加密——例如，用户可以向一个委员会进行门限加密。
交易发送者的披露可选性
承诺-披露方案固有的一个大问题（正如我们上面所论证的，很可能也是任何缺乏我们尚未拥有的密码学工具的解决方案所固有的）是发送者可以简单地选择不披露。更糟的是，他们可以在看到其他方的披露之后，再决定是否披露。具体来说，几个攻击场景示例说明了这个问题。
概率性抢先交易
一个攻击者如果对诚实用户承诺的交易 tx 有可靠的猜测（例如，在 DEX 上常见交易对之间的交易）——但不确定——可能会在 tx 之前插入一笔抢先交易 tx_attack，其中 tx 和 tx_attack 都使用 LUCID。在 tx 被披露后，如果攻击者的猜测正确，他们就披露 tx_attack；否则就不披露。注意，攻击者也可以插入 k 笔前面的交易，对应 2^k 种可能的披露/不披露组合。
延迟敏感型交易
由于 LUCID 实际上在插槽 n 和插槽 n+1 之间创建了一个新的阶段来执行交易，因此延迟敏感型用例有很强的动机使用 LUCID 并利用其可选性。考虑 DEX-CEX 套利：一个套利者可能在时间 t_1 承诺一笔执行 DEX-CEX 套利的 LUCID 交易，然后在时间 t_2 决定是否披露它，这取决于 t_1 到 t_2 之间的价格波动。这里 t_1 是在插槽 n-1 中可以为插槽 n 提交交易的最晚时间，t_2 是可能披露的最晚时间（以便交易在插槽 n 和插槽 n+1 之间执行）。实际上，LUCID 在 t_2 处添加了另一个时间戳，可以在此时清除 CEX-DEX 价格差异（在 LUCID 之前，下一个时间戳将是插槽 n+1 窗口关闭时）。套利者在经济上有动机使用这个时间戳，并利用可选性来应对价格波动的多种潜在版本。请注意，从经济角度看，这种可选性实际上并不坏：它允许更快的价格信号进入链上，而未披露所消耗的费用会烧掉 MEV。问题仅仅在于，存在一种激励，让人们以不遵守预期规则（通过不披露）的方式使用 LUCID，并且这种方式与其他用例竞争，推高了价格。
对抗措施
LUCID 提供了几种对抗措施，但这些并不能完全防止可选性相关的问题；它们只会使利用可选性变得更加昂贵。值得注意的是，LUCID 对未披露行为施加了惩罚，并允许每笔交易（或交易包）限制前面 LUCID 交易（或交易包）的数量。问题在于，这些对抗措施并不能阻止攻击，它们只是让攻击更难，而这可能是不够的。在概率性抢先交易的情况下，一个问题是合法发送者必须支付足够高的顶部区块费用（并且本质上在短时间内托管其 128 倍的费用）来威慑攻击者，而发送者可能不愿意这样做。此外，必要的威慑取决于攻击者视角下被攻击交易明文的确定性程度，这对合法用户来说很难估计。对前面交易数量的限制，在 LUCID 被常规用例（如交换）大量使用时无法很好地扩展，特别是因为上面讨论的延迟敏感型交易会争夺 LUCID 交易列表中的顶部位置。请注意，交易包（将多笔交易聚集以提高通信效率的能力）会汇总其威慑力，但这可能帮助不大：一个交易包可能更值得攻击，因为其中出现任何给定交易对的概率更高，因此概率性攻击成功的机会也更大。此外，如果交易包中的组成交易属于不同的发送者，则在设置交易包的聚合顶部区块费用时可能存在搭便车问题。
构建者可选性
LUCID 的设计意图是强制插槽 n+1 的构建者将那些在插槽 n 期间披露的交易包含在区块顶部。这通过负载及时性委员会（PTC）来强制执行，该委员会对这些披露的可用性进行投票：粗略地说，如果超过 50% 的委员会投票表示及时看到了披露，则构建者必须包含它；如果超过 50% 投票表示没有看到，则构建者不得包含它。问题在于，对于到达过晚的披露和/或分叉投票，存在一定的回旋余地。事实上，如果攻击者将投票设计成 45%/45% 的分裂，并对剩余的 10% 进行分叉投票，那么下一个构建者可以选择包含或不包含，从而也获得（可选性的另一个实例）。这可以通过在稍后做出选择来放大 CEX-DEX 套利的收益。实际上，这些披露本身很可能接近 50% 的分裂，因为套利者有动机尽可能晚地做出决定。一个后果是，任何有机会成为下一个插槽构建者的 PTC 委员会成员，实际上都有动机分叉投票并与套利者合作以获取费用。这也意味着，延迟披露你的交易可能无法防范概率性抢先攻击。
注意：分叉投票不会受到惩罚，因为该部分设计取自 FOCIL，其安全目标不会以同样的方式受到分叉投票的威胁。在 FOCIL 中，其目标是增强抗审查性，我们只需要确保那些被广泛传播的交易确实被包含进去。我们并不真正关心它的反面（即未被广泛传播的交易不被包含）。对于 LUCID，我们现在需要关心这个反面方向，因为它与构建者可选性有关。
用户体验问题
发送者元数据
LUCID 中承诺的交易不需要来自执行实际交易的同一地址。事实上，为了防止发送者元数据泄露，我们希望承诺的交易来自一个不可关联的地址。鉴于概率性抢先交易问题，泄露给定 LUCID 交易属于哪个用户实际上是致命的，因为它让抢先交易者很好地了解到交易内容以及是否值得攻击。这使得 LUCID 难以正确使用。用户要么需要通过隐私池将一些用于 gas 的资金发送到一个一次性地址，并带有足够的时间延迟，要么通过某个第三方中继（在链外支付费用）让交易进入。后者的典型场景是利用你在 CEX 上的余额，让 CEX 代表你发送承诺交易。第三方不需要知道交易的明文，但这仍然与不需要任何其他方以及拥有公共内存池的目标有些背道而驰。请注意，第三方仍然可以通过将你的交易与你关联来出卖你。
理想的解决方案基本上就是允许使用某种足够强大的账户抽象直接从隐私池支付。请注意，这避免了为每笔交易创建一个新地址。
选项太多——让钱包决定？
要正确使用 LUCID，用户需要某种不可关联的地址。对抗概率性抢先交易的对抗措施要求用户相应地设置优先费用（以位于 LUCID 交易顶部）和/或限制前面交易的数量。用户还需要选择是委托披露还是自己披露。我们严重怀疑普通用户能够做到这一切。
一个后果是，无论好坏，钱包可能会为用户做出这些决定。在披露委托的情况下，存在一个严重风险：钱包会将其视为自己的赚钱机会，而不是让用户默认选择最佳选项：钱包开发者可能会自己运行一个披露服务（或由某个服务付费），并默认使用它，从而收取费用，即使这对用户来说不是最佳选择。至于优先费用和前面交易数量的限制，即使钱包尝试去做，是否能正确设置也是值得怀疑的。
密码学无关性 / 灵活性
LUCID 的一个卖点是它与任何特定的加密机制无关，并且这发生在链下。从某种意义上说，这肯定是有好处的，因为它使我们不必实现具体的密码学（门限）加密方案。但出于几个原因，感觉这是一个坏主意。
为什么要委托？
不清楚用户为什么想要委托披露。唯一的真正优势是披露在某种程度上延迟关键，第三方可能处理得更好；然而，这几乎不能证明额外的信任假设是合理的，我们希望摆脱可信中继。此外，如果该方运行门限加密并通过委员会解密，这会增加相当大的延迟，这在一定程度上违背了目的。如果没有令人信服的用例说明为什么委托实际上是一个好选择（而“为钱包提供资金”并不是一个令人信服的理由），这就不太有说服力。从用户体验的角度来看，虽然委托允许“发送后即忘记”的交易发送，但大多数用户无论如何都想监视链上是否包含——这也允许钱包在不需要信任第三方的情况下稍后披露。
坏人也能灵活选择密码方案
一般来说，如果密码学灵活性允许知情的用户为自己的用例和所需安全性做出最佳选择，那可能是好的。然而，如果是对手选择方案，那就不好了。我们这里属于第二种情况：对手（比如发送概率性抢先交易的人）会简单地选择不使用任何加密，并自行披露（或不披露）。
该设计的前瞻性如何？
一个希望可能是我们可以现在部署 LUCID，然后在以后固化一个特定的门限方案，强制用户使用它而不是自行披露（从而消除可选性）。这有几个问题：
这将需要废弃现有的委托选项，而到那时这些选项很可能已经成为既得经济利益。
LUCID 可能不太适合这种设计：LUCID 期望的披露消息是单个明文（或一个交易特定的密钥，用于解密一个先前发送的特定密文为明文交易）。这不太适合未来可能出现的门限加密方案，其中单个密钥 k 可能解密多个密文。如果我们将这种方案接入 LUCID，我们将无法分发 k；相反，我们必须分别分发将 k 应用于每个密文的结果，这很浪费。
可能需要调整加密内存池设计以适应当前的密码学机制。例如，作者目前正在研究是否可以从没有所谓批处理的门限 IBE 中构建一个好的加密内存池设计，利用 LUCID 的一些想法。（这是正在进行的工作，无论如何不会立即给我们一个很好的替代方案，只会稍微降低对密码学方面的要求。）这样的设计需要对加密内存池进行更改以适应加密方案的限制，并且不能简单地插入 LUCID。
关于最后一点再详细说明一下：如果我们只是强制用户在 LUCID 内使用指定的固化门限方案，这只能解决交易发送者的可选性问题。它无法解决我们上面解释的构建者可选性问题。事实上，作者正在进行的、深受 LUCID 启发的工作，需要运行共识协议的一轮额外轮次来就哪些披露（或加密）被广泛传播达成共识，以防止构建者可选性；此外，额外的轮次意味着我们需要更仔细地考虑跨重组和错过插槽的重放攻击问题。
我们想澄清，对于 LUCID 的情况，运行这样的额外轮次可能在复杂性和用户体验方面成本过高，不值得：构建者可选性问题与发送者可选性问题相比只增加了一点。然而，如果我们能够消除发送者可选性问题，情况就会改变。
不良宣传
作为结束语：我们还需要非常小心地传达 LUCID（或一般的加密内存池）。如上所述，LUCID 难以正确使用，并且它不能防止抢先交易——它只是让抢先交易更难，而难多少取决于几个因素，而这些因素实际上很难向普通用户解释。
存在一个非常严重的风险：到达用户的信息将会是“以太坊现在有了加密内存池。你再也不用担心抢先交易了。”如果用户在使用 LUCID 时仍然被抢先交易，他们很可能会责怪以太坊未能保护他们，并在 X/Twitter 上发表非常非常愤怒的帖子。
从某种意义上说，承诺某事但没有完全兑现，可能比一开始就不承诺更糟糕——而我们远未完全控制哪些信息最终会到达用户手中。
[编辑：删除了一个“协调问题”条目，该条目仅因 EIP 中的误解/歧义而产生。我们正在尝试在 EIP 中澄清这一点。
编辑(2)：修正了“对抗措施”中的一个错误，该错误之前谈及 gas，这是对 Anders 回复的回应。还澄清了为什么交易包可能没有人们想象的那么有用。]
为了避免交易发送者的披露可选性，我们需要某种方法在不依赖发送者参与的情况下随后解密消息。从密码学方面来看，基本选项是：
(i) 使用某种基于时间的密码学，我们尝试确保即使强大的对手也需要至少 t_1 时间才能解密，但同时每个人都可以在允许的时间 t_2 > t_1 内完成解密。在我们的用例中，t_1 和 t_2 之间的差距极小，基本上排除了这种方法。
(ii) 使用某种可信执行环境（TEE），解密密钥安全存储，并且仅以某种正确方式使用（例如，TEE 拒绝解密，除非我们出示由多数验证者签名的时间戳）。这些方法的安全记录值得怀疑。
(iii) 使用门限加密，我们对一个验证者委员会（假设存在诚实多数）进行加密，每个成员持有某种解密密钥的一部分，并且只能联合解密。这将信任单个方的问题替换为更可接受的假设，即多数验证者是诚实的。不幸的是，对这样一个门限加密方案的需求清单太长了（足够的安全性、后量子安全性、适当的功能性、各种效率指标和低通信量），目前没有可用的方案符合要求。一个更精确的安全属性是，没有其他方可以了解交易 tx 的内容，并利用该知识在 tx 之前插入一笔交易。实际上，在 LUCID 中，交易内容在它被“正式”执行之前就变得已知，但在内容变得已知的时刻，直到 tx 正式执行之前的所有交易都已经固定下来。