通用内嵌加密交易池EIP - 权益证明

这是一个关于向以太坊添加与方案无关的加密 mempool 的EIP（编号待定）的讨论帖。以下是完整文本：

摘要

本 EIP 提议将加密的 mempool 写入协议。它使用户能够加密他们的交易，直到它们被包含在一个区块中，从而保护他们免受抢跑(front running)和三明治攻击(sandwiching attacks)，并提高抗审查性(censorship resistance)保证。该设计通过支持任意解密密钥提供者(decryption key providers)而与加密技术无关，这些提供者可以例如基于阈值加密(threshold encryption)、MPC 委员会(MPC committees)、TEE(可信执行环境)、延迟加密(delay encryption)或 FHE(全同态加密)方案。传统的明文交易仍然受支持，即使解密密钥提供者失败，链的进展也能得到保证。

动机

本 EIP 的目标是防止用户受到恶意交易重新排序攻击，并提高协议的实时（“弱”）抗审查性(censorship resistance)。它还旨在通过暂时使区块构建者(block builders)和其他协议参与者失明来降低其监管风险。目标不是提高用户隐私（例如，交易保密性），因为交易最终会公开。

这个提案建立在之前的工作之上，例如Shutterized Beacon Chain和一个已经部署在Gnosis Chain上的加密mempool的实时协议外实现。它解决了长期存在的交易抢跑(front running)问题，并有可能减轻 MEV(矿工可提取价值) 的有害二阶效应，例如构建者中心化(builder centralization)。该设计也自然适合写入提议者-构建者分离(enshrined proposer-builder separation, ePBS)，使其成为以太坊路线图的逻辑扩展。

规范

在执行层中，部署了一个名为密钥提供者注册表(key provider registry)的合约。它允许任何帐户注册一个密钥提供者，并为其分配一个唯一的 ID。注册需要指定一个具有解密(decryption) 和密钥验证(key validation)功能的合约，每个功能都接受一个密钥 ID 和一个密钥消息作为字节字符串。此外，密钥提供者可以指定其他提供者为直接信任的提供者，从而形成有向信任图。我们定义密钥提供者 A 信任另一个密钥提供者 B 当且仅当从 A 到 B 存在一条有向路径。信标链在其状态中复制密钥提供者注册表，类似于处理信标链存款的机制。

加密交易作为一种新的交易类型添加。它们由一个信封(envelope)和加密的载荷(payload)组成。信封(envelope)指定信封nonce(envelope nonce)、gas量、gas价格参数、密钥提供者 ID、密钥 ID 和信封签名(envelope signature)。加密的载荷(payload)包含载荷nonce(payload nonce)、价值、calldata(调用数据) 和载荷签名(payload signature)。

在一个有效的区块中，任何用密钥提供者 A 的密钥加密的交易只能位于以下交易之后：

• 明文交易
• 用密钥提供者 A 的密钥加密的交易
• 用密钥提供者 A 信任的密钥提供者的密钥加密的交易

在每个slot中，当密钥提供者观察到构建者发布的执行载荷(execution payload)时，他们会收集所有使用他们的密钥提供者 ID 加密的交易的信封(envelope)中引用的密钥 ID。对于每个密钥 ID，他们必须发布相应的解密密钥(decryption key)或密钥保留通知(key withhold notice)。相应的消息引用信标区块哈希(beacon block hash)以防止在未来的slot中重放。他们可以立即在观察到执行载荷后发布，也可以延迟发布到slot中的稍后时间点。

载荷及时性委员会(Payload Timeliness Committee, PTC)的成员必须监听所有加密交易引用的解密密钥，这些密钥由密钥提供者 ID 和密钥 ID 字段标识。他们必须使用注册表合约中指定的验证函数来验证这些密钥，每个密钥使用硬编码的小 gas 限制。最后，他们必须在载荷证明消息(payload attestation message)中证明每个加密交易是否存在有效密钥，该消息为此目的扩展了一个专用位域。

在执行载荷处理(execution payload processing)期间，在所有明文交易之后，加密交易的信封(envelope)作为一个批次执行。这会更新信封(envelope)签名者的 nonce 并从信封(envelope)帐户支付费用。该费用涵盖信封(envelope)、解密载荷(payload)和解密密钥使用的区块空间成本，以及解密和密钥验证期间使用的计算。随后，使用密钥提供者注册表中的解密功能，使用信封(envelope)上的密钥提供者 ID 和密钥 ID 指定的密钥解密加密的载荷(payload)。如果解密成功，则根据信封(envelope)上指定的 gas 限制以及区块 gas 限制来执行生成的载荷(payload)交易。如果解密或执行失败，包括 PTC 证明解密密钥丢失的情况，则跳过该交易，不会回滚信封(envelope)。

原理

密钥提供者注册

注册与加密技术无关，以确保协议的中立性，最大限度地减少新密钥提供者的进入障碍，并使用户能够根据自己的目的选择最佳方案。选择执行层合约作为指定任意执行逻辑的标准方式。纯粹在 CL 上注册是一个合理的替代方案。

许多加密方案在 EVM 中表达效率低下，因此需要专用的预编译。但是，添加这些不属于本 EIP 的范围。

密钥提供者信任图

发送加密交易的用户不仅必须信任自己的密钥提供者，还必须信任用于区块中较早交易的任何密钥提供者（请参阅安全注意事项）。虽然协议应尊重用户的信任偏好，但如果每个用户只信任自己的密钥提供者，构建者将只能在每个区块中包含用来自单个密钥提供者的密钥加密的交易。这是不可取的，因为它使得市场份额较小的密钥提供者难以竞争，从而有可能形成密钥提供者垄断。

另一方面，要求用户明确说明他们信任哪些第三方提供者会增加交易规模的开销，并由于需要满足的大量潜在的竞争性用户偏好而使区块构建更加困难。作为一种折衷方案，本提案要求密钥提供者做出此选择。用户通过使用密钥提供者的密钥来隐式同意。

通过此解决方案，即使出现由单个主导密钥提供者组成的准垄断，并且此密钥提供者未将任何其他密钥提供者指定为受信任，构建者仍然可以包含使用其他小型密钥提供者的交易，而不会产生机会成本，只要小型密钥提供者信任主要的密钥提供者（并且可能彼此信任）。

交易顺序

该提案有效地将区块分成明文交易和加密交易部分。明文交易放在第一位，使构建者能够完全模拟此部分的执行并应用现有的区块构建技术和 MEV 提取策略。因此，构建者可以将加密交易附加到区块的末尾，而不会产生机会成本。如果顺序颠倒，则加密交易的费用必须高得多，以便包含它们的区块在 PBS 拍卖中与仅包含明文交易的区块相比具有竞争力。

交易执行

协议以及构建者必须受到保护，免受包含最终无法支付 gas 的加密交易的影响。为了确保在区块中任何加密载荷(payload)的内容无关紧要的情况下都是如此，费用支付是明文信封(envelope)的一部分，并且区块中的所有信封(envelope)都在任何加密载荷(payload)之前执行。不支付 gas 退款，以保证构建者和协议在区块构建时将收到的费用金额。

为了简单起见，加密的载荷(payload)包含签名。一种不太私密但更有效的替代方法是将信封(envelope)签名者视为发送者。

解密密钥保留

该协议明确允许解密密钥提供者在他们选择的条件下保留解密密钥。这使他们能够安全地实施规则来限制哪些用户可以使用哪些密钥，例如，基于先前的付款并防止密钥 ID 抢跑攻击（请参阅安全注意事项）。另一方面，未经正当理由保留的密钥可用于自定义罚没(slashing)机制和可靠性指标（请注意，协议记录了哪些密钥存在以及哪些密钥存在以及哪些密钥不存在）。

协议内缺乏密钥提供者激励

本提案没有写入密钥提供者的费用机制，也没有对不当行为的惩罚。这允许离线实施各种激励模型。例如，密钥提供者可以与构建者达成协议，由用户按交易付费，或作为公共物品运营。他们还可以让自己受到无端保留密钥的罚没(slashing)条件约束，以使他们的服务对用户更具吸引力。

执行载荷加密

未来的 EIP 可能会提议让构建者使用来自密钥提供者的密钥来加密执行载荷(execution payload)。与仅在 50% 的slot标记处发布相比，这使他们能够在构建后立即发布执行载荷(execution payload)。这将提高 p2p 效率并保护构建者免受因崩溃而错过的slot的影响。此外，如果构建者附加了关于区块中使用了哪些密钥的零知识证明，则密钥显示时间窗口可以更早开始，因此可以更长。此功能未包含在本 EIP 中，以最大限度地降低复杂性。

向后兼容性

该提案对执行层和共识层协议进行了向后不兼容的更改。

安全注意事项

受信任的密钥提供者

用户必须信任他们用于加密交易的密钥提供者，以

• 不要过早发布解密密钥，这会允许抢跑(front running)和三明治攻击(sandwiching attacks)

• 不要过晚发布解密密钥，这会阻止交易的执行，同时仍然需要支付信封(envelope)费用。

密钥提供者可以通过加密机制（例如，阈值加密(threshold encryption)、硬件加密）、经济机制（例如，不当行为的罚没(slashing)）、治理机制（例如，投票选择具有社会声誉的实体）或这些机制的组合来赢得这种信任。

在较小程度上，用户需要信任用于区块中在其交易之前的加密交易的所有密钥提供者。这是因为密钥提供者可以选择发布或保留解密密钥，他们可以在观察到后续交易的解密密钥后采取此操作。此选项使他们对后续交易的 pre-state 具有一位的影响力。恶意选择的“解密”方案可以通过允许使用精心设计的解密密钥直接修改解密结果的特定部分或直接设置来使此攻击更加强大。这有效地实现了抢跑(front running)。

用户不必信任在其交易之后包含的交易使用的任何密钥提供者，因为用户的交易载荷(payload)的 pre-state 不受后续交易的载荷(payload)的影响（只有它们的信封(envelope)，但这些是在发布任何解密密钥之前选择的）。同样，明文交易的用户不必信任任何密钥提供者（但他们继续必须信任构建者）。

重组

解密密钥在相应的加密交易最终确定之前发布。因此，在链重组的情况下，即使交易不一定包含在链中，也可能变为公开。但是，由于解密密钥消息包含区块哈希(block hash)，因此可以通过密钥验证函数使其失效。这不会阻止信封(envelope)交易的包含，但会阻止载荷(payload)的执行，从而阻止抢跑(front running)。

密钥 ID 抢跑

当用户使用特定的密钥 ID 加密交易时，另一个用户可以观察到正在进行的此交易，并创建另一个指定相同密钥提供者和密钥 ID 的加密交易。如果第二个交易包含在比原始交易更早的区块中，则一个天真的密钥提供者将显示密钥，从而显示原始交易，即使它尚未包含。

密钥提供者可以保护他们的用户免受此攻击。一种可能的策略是“命名空间”密钥 ID：提供者仅发布密钥 ID 前缀为信封(envelope)签名者地址的密钥，并保留所有其他密钥。由于我们可以合理地假设攻击者无权访问信封(envelope)签名者帐户，因此攻击者将无法生成具有正确命名空间密钥 ID 的交易。

密钥提供者-子构建者共谋

要构建一个新区块，构建者需要知道前一个区块的 post-state，因此需要知道区块中使用的所有解密密钥以及其中哪些密钥被保留。一旦 PTC 作证，此信息就会公开。但是，恶意密钥提供者可能会与区块构建者勾结并提前通知他们。这将使构建者具有竞争优势，因为他们可以更早地开始区块构建过程。

该攻击的影响被认为是低的，因为载荷证明(payload attestations)的发布与slot结束之间的时间仍然足够长，可以进行区块构建。此外，区块构建期的开始远不如结束那么重要（因为只有那时才知道所有可包含的交易），这不受攻击的影响。此外，延迟发布解密密钥会带来它们未被 PTC 证明的风险，从而抵消了攻击者的竞争优势。最后，如果使用恶意密钥提供者的加密交易数量较少，则它们对树状态的影响可能也很小。这意味着不依赖于状态树完整知识的乐观区块构建策略可能是可行的，从而抵消了攻击。

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