通用的链上加密内存池 EIP——权益证明

这个线程用于讨论 EIP，该提案旨在为 Ethereum 添加一个与具体方案无关的加密 mempool（编号待定）。以下是全文：

摘要

此 EIP 提议将加密 mempool 固化到协议中。它使用户能够在交易被纳入区块之前对其进行加密，从而保护他们免受 front running 和 sandwiching attacks 的影响，同时提高抗审查保证。该设计在加密技术上与具体方案无关，通过支持任意的解密密钥提供者，例如基于 threshold encryption、MPC committees、TEEs、delay encryption 或 FHE schemes 的方案。传统的明文交易仍然受支持，即使解密密钥提供者失效，链的推进也有保障。

动机

此 EIP 的目标是防止用户遭受恶意的交易重排序攻击，并提高协议实时的“弱”抗审查能力。它还旨在通过暂时遮蔽 block builders 和其他协议参与者来降低他们的监管风险。其目标并不是提升用户隐私（例如 transaction confidentiality），因为交易最终仍会公开披露。

该提案建立在之前工作的基础之上，例如 Shutterized Beacon Chain 以及一个已经在 Gnosis Chain 上部署的链外加密 mempool 实现。它解决了 front running 这一长期存在的问题，并有潜力缓解 MEV 的有害二阶效应，例如 builder centralization。该设计也与 enshrined proposer-builder separation（ePBS）自然契合，因此是 Ethereum 路线图的一个合理扩展。

规范

在 execution layer 中，会部署一个名为 key provider registry 的合约。它允许任何账户注册一个 key provider，并为其分配一个唯一 ID。注册时需要指定一个包含解密函数和 key validation function 的合约，这两个函数都接受 key ID 和 key message 作为字节字符串。此外，key providers 还可以指定其他 providers 为其直接信任的对象，从而形成一个有向信任图。我们定义：当且仅当在该图中存在一条从 A 到 B 的有向路径时，key provider A 才信任另一个 key provider B。beacon chain 会在其状态中复制 key provider registry，类似于处理 beacon chain deposits 的机制。

Encrypted transactions 被作为一种新的 transaction type 加入。它们由一个 envelope 和加密后的 payload 组成。envelope 指定 envelope nonce、gas amount、gas price parameters、key provider ID、key ID 以及 envelope signature。encrypted payload 包含 payload nonce、value、calldata 和 payload signature。

在一个有效区块中，任何使用来自 key provider A 的 key 加密的交易之前，只能出现

• 明文交易

• 使用来自 key provider A 的 key 加密的交易

• 使用来自 A 所信任的 key providers 的 key 加密的交易

在每个 slot 中，当某个 key provider 观察到 builder 发布的 execution payload 时，它会收集所有以其 key provider ID 为目标的 encrypted transactions 的 envelopes 中引用的 key IDs。对于其中每一个，它都必须发布对应的 decryption key 或 key withhold notice。对应的消息会引用 beacon block hash，以防止在未来 slot 中重放。它们既可以在观察到 execution payload 后立即发布，也可以延迟到该 slot 中的稍后时间发布。

Payload Timeliness Committee（PTC）的成员必须监听所有 encrypted transactions 所引用的 decryption keys，这些 key 由 key provider ID 和 key ID 字段标识。他们必须使用 registry 合约中指定的 validation function 来验证这些 keys，并为每个 key 使用一个硬编码的小 gas limit。最后，他们必须在 payload attestation message 中对每个 encrypted transaction 是否存在有效 key 进行证明；为此，该消息扩展了一个专用 bitfield。

在 execution payload 处理期间，在所有明文交易之后，encrypted transactions 的 envelopes 会作为一个批次执行。此操作会更新 envelope 签名者的 nonce，并从 envelope 账户中支付 fees。该 fee 覆盖 envelope、解密后的 payload 以及 decryption key 所占用的 block space 成本，以及解密和 key validation 期间所消耗的计算成本。随后，使用 envelope 上的 key provider ID 和 key ID 所指定的 key，通过 key provider registry 中的 decryption function 对 encrypted payloads 进行解密。如果解密成功，得到的 payload transactions 会在 envelope 上指定的 gas limit 以及 block gas limit 的约束下执行。如果解密或执行失败，包括 PTC 证明 decryption key 缺失的情况，交易会被跳过，而不会回滚 envelope。

理由

Key Provider Registration

Registration 在加密技术上与具体方案无关，以确保协议中立、尽量降低新 key providers 的进入门槛，并赋予用户为其用途选择最优方案的能力。选择 execution layer 合约作为指定任意执行逻辑的规范方式。仅在 CL 上进行 registration 也是一个合理的替代方案。

许多加密方案在 EVM 中表达效率低下，因此需要专门的 precompiles。不过，添加这些内容超出了本 EIP 的范围。

Key Provider Trust Graph

发送 encrypted transaction 的用户不仅必须信任自己使用的 key provider，还必须信任该区块中排在更前面的交易所使用的任何 key provider（见 Security Considerations）。虽然协议应尊重用户的信任偏好，但如果每个用户只信任自己的 key provider，那么 builder 在每个区块中只能包含使用单一 key provider 的 key 加密的交易。这并不可取，因为这会让市场份额较小的 key providers 难以竞争，并可能导致 key provider monopoly。

另一方面，如果要求用户显式声明他们信任哪些第三方 providers，会增加 transaction size 开销，并且由于需要满足的用户偏好数量可能很大且彼此竞争，block building 也会变得更加困难。作为折中，该提案要求 key providers 作出这一选择。用户通过使用该 key provider 的 keys，即表示默认同意。

采用这一方案后，即使出现由单一主导 key provider 构成的准 monopoly，而该 key provider 又没有将任何其他 key providers 指定为可信对象，builders 仍然可以在没有机会成本的情况下包含使用其他小型 key providers 的交易，只要这些小型 key providers 信任这个主要 provider（并且可能彼此也信任）。

交易顺序

该提案实际上将区块拆分为明文交易部分和加密交易部分。明文交易排在前面，使 builders 能够在这部分完整模拟执行，并应用现有的 block building 技术和 MEV extraction 策略。因此，builders 可以在没有机会成本的情况下将 encrypted transactions 附加到区块末尾。如果顺序相反，那么为了使包含 encrypted transactions 的区块在 PBS auctions 中相较于只包含明文交易的区块具有竞争力，encrypted transactions 的 fees 就必须显著更高。

交易执行

协议以及 builders 必须受到保护，避免包含最终无法支付 gas 的 encrypted transactions。为确保无论区块中任何 encrypted payload 的内容如何都满足这一点，fee 支付被放在明文 envelope 中，且区块中的所有 envelopes 都会在任何 encrypted payload 之前执行。为了保证 builder 和协议在 block building 时刻能够收到的 fee amount，gas refunds 不会支付。

为简化起见，encrypted payload 中包含一个 signature。一个隐私性较低但更高效的替代方案是将 envelope signer 视为 sender。

Decryption Key Withholding

协议明确允许 decryption key providers 在其自行选择的条件下 withholding decryption keys。这使他们能够安全地实施规则，限制哪些用户可以使用哪些 keys，例如基于先前支付的情况，并防止 key ID front running attacks（见 Security Considerations）。另一方面，对于无正当理由被 withheld 的 keys，可在自定义 slashing 机制和可靠性指标中加以利用（注意，协议会记录哪些 keys 存在，哪些 keys 曾经存在过，以及哪些 keys 不存在）。

缺乏协议内 Key Provider 激励

此提案没有为 key providers 固化 fee 机制，也没有对不当行为施加惩罚。这使得多种激励模型可以在链下实现。例如，key providers 可以与 builders 达成协议，由用户按交易逐笔支付，或者作为公共物品运行。他们也可以自行接受因无正当理由 withholding keys 而触发的 slashing 条件，以使其服务对用户更具吸引力。

Execution Payload Encryption

未来某个 EIP 可能会提议让 builders 使用来自 key providers 的 keys 来加密 execution payload。与仅在 slot 的 50% 时点发布 execution payload 相比，这使他们能够在构建完成后立即发布 execution payload。这将提高 p2p 效率，并保护 builders 免于因崩溃而错过 slot。此外，如果 builder 附带一个关于区块中使用了哪些 keys 的零知识证明，那么 key revelation time window 可以更早开始，因此也会更长。为了尽量降低复杂性，本 EIP 不包含此功能。

向后兼容性

该提案对协议的 execution layer 和 consensus layer 引入了向后不兼容的变更。

安全考虑

受信任的 Key Providers

用户必然需要信任他们用来加密交易的 key providers，以确保

• 不会过早发布 decryption keys，从而允许 front running 和 sandwiching attacks

• 不会过晚发布 decryption keys，否则交易将无法执行，而 envelope fee 仍然必须支付。

Key providers 可以通过密码学机制（例如 threshold encryption、hardware encryption）、经济机制（例如对不当行为进行 slashing）、治理机制（例如投票选出在社会上可信的实体），或上述机制的组合来获得这种信任。

在较小程度上，用户还需要信任区块中排在自己交易之前的所有用于 encrypted transactions 的 key providers。这是因为 key providers 可以选择发布或 withholding decryption keys，而他们可以在观察到后续交易的 decryption keys 后再做出这一选择。这个选择使他们能够对后续交易的 pre-state 施加一位的信息影响。恶意选择的“decryption” schemes 可能通过允许使用精心构造的 decryption keys 直接修改 decryption results 的特定部分，甚至直接设定结果，从而使这种攻击强得多。这实际上等同于 front running。

用户无需信任任何用于排在自己之后的交易的 key providers，因为用户交易 payload 的 pre-state 不会受到后续交易 payloads 的影响（只会受到它们的 envelopes 的影响，但这些 envelopes 是在任何 decryption keys 发布之前就已确定的）。同样，明文交易的用户也无需信任任何 key provider（但他们仍然必须信任 builders）。

Reorgs

Decryption keys 会在对应的 encrypted transactions 最终确认之前发布。因此，在 chain reorg 的情况下，一笔交易可能会变为公开，即使它未必被包含在链中。然而，由于 decryption key message 包含 block hash，它可以被 key validation function 判定为无效。这不会阻止 envelope transaction 被包含，但会阻止执行，因此也会阻止 payload 的 front running。

Key ID Front Running

当用户使用某个特定 key ID 加密交易时，另一个用户可能会观察到这笔正在传播中的交易，并创建另一笔指定相同 key provider 和 key ID 的 encrypted transaction。如果第二笔交易被包含在比原始交易更早的区块中，一个天真的 key provider 就会公开该 key，从而公开原始交易，即使它尚未被包含。

Key providers 可以保护他们的用户免受这种攻击。一种可能的策略是对 key IDs 进行“namespacing”：providers 只发布前缀为 envelope signer 地址的 key IDs 对应的 keys，并 withholding 其他所有 keys。由于我们可以合理地假设攻击者无法访问 envelope signer 账户，因此攻击者将无法生成带有正确 namespacing 的 key ID 的交易。

Key Provider-Child Builder Collusion

为了构建新区块，builders 需要知道前一个区块的 post-state，因此也需要知道一个区块中使用了哪些 decryption keys，以及哪些被 withheld。这些信息一旦 PTC 作出证明，就会变为公开。然而，恶意 key providers 可能会与 block builder 合谋，并提前向其透露这些信息。这会给 builders 带来竞争优势，因为他们可以更早开始 block building 过程。

该攻击的影响被认为较低，因为在发布 payload attestations 与 slot 结束之间仍有足够长的时间用于 block building。此外，block building 阶段的开始远不如结束关键（因为只有到那时，完整的可纳入交易集合才已知），而攻击不会影响这一点。并且，延迟释放 decryption keys 也有可能导致它们未被 PTC 证明，从而抵消攻击者的竞争优势。最后，如果使用恶意 key provider 的 encrypted transactions 数量很少，那么它们对 state tree 的影响也可能很小。这意味着不依赖完整 state tree 信息的乐观 block building 策略可能可行，从而对抗这种攻击。

• LUCID: 使用分布式 payload 传播的加密 mempool
• GhostPool: 在加密 mempool 准入中隐藏身份关键元数据

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