加密帧交易 - 执行层研究

Thomas Thiery 感谢 Julian Ma, Anders Elowsson, Benedikt Wagner 和 Gottfried Herold 的反馈与审阅。

TL;DR

加密帧交易（Encrypted frame transactions）在区块内容和排序确定之前，隐藏了对 MEV 提取至关重要的执行参数。

构建者（Builder）在任何解密密钥泄露之前，先对完整的排序交易集进行承诺。在密钥公布后，它在同一个插槽（Slot）内执行该已承诺的排序。这使得同插槽加密执行成为可能，而无需将区块拆分为特殊的加密部分和明文剩余部分。

该设计复用了 LUCID 的加密方案：用户可以自己发布密钥，也可以委托给门限委员会或任何其他实体。它基于帧交易（EIP-8141），该提案用可编程的 VERIFY 逻辑取代了硬编码的授权（为后量子兼容方案开辟了道路），并通过基于帧的交易结构实现了字段级的选择性披露。

核心设计理念

实现同插槽加密执行的关键思想之一是排序与执行分离：构建者在任何解密密钥泄露之前承诺完整的排序交易集，然后在密钥公布后的同一个插槽内执行该已承诺的排序。

在 ePBS（EIP-7732）区块拍卖中，构建者的出价承诺了一个预先计算的执行结果。但这在这里行不通，因为最终的有效载荷取决于哪些加密交易被揭示以及它们解密后的内容。对于同插槽加密执行，出价必须首先承诺交易内容和排序，而与执行相关的输出（如最终有效载荷和区块级访问列表 BAL，EIP-7928）仅在揭示后才进行绑定。

这是与 LUCID 等下一插槽加密设计的主要区别。在 LUCID 中，加密交易在插槽 N 中承诺，密钥在插槽 N 期间发布，而执行则发生在插槽 N+1 顶部的专用通道中。当插槽 N+1 的构建者构建区块的明文部分时，它已经知道了揭示后的交易。

该设计还建立在帧交易（EIP-8141）之上，使其在两个方面具备未来兼容性：

1. VERIFY 帧：用可编程的公共验证取代了硬编码授权，为后量子兼容方案铺平了道路。
2. 帧结构：避免了硬编码单一的永久公共/隐藏字段划分。随着新帧类型的定义，发送者可以选择哪些执行参数公开承诺，哪些隐藏，而无需引入新的交易类型。

插槽 N 的工作流

每个加密帧交易都有一个公开的 VERIFY 帧和一个隐藏的加密执行阶段。交易信封承诺 exec_params_binding = H(exec_params)，将密文与发送者预期的明文绑定。

插槽 N 的流程如下：

1. 提议者（Proposer）广播包含获胜构建者出价的信标区块。该出价在任何密钥揭示前承诺完整的排序交易列表。
2. 密钥发布者（Key-releasers）观察信标区块并发布 k_dem（每笔交易的对称密钥），该密钥与 (slot, beacon_block_root, tx_reveal_id) 绑定。
3. 证明者（Attesters）缓存收到的揭示信息直到 T_rev_a 时刻，然后冻结其本地视图。
4. 构建者（Builder）在 T_rev_b 时刻冻结其揭示视图，执行已承诺的排序，并广播签名后的揭示后有效载荷信封。
5. PTC（有效载荷时效性委员会）在 T_PTC 截止日期对该信封进行投票。
6. 插槽 N+1 的证明者验证插槽 N 的有效载荷（包括 BAL 和 reveal_root），并根据其缓存视图进行投票。

注：图中未显示包含列表（Includer）和 Blob 相关职责，以避免过于拥挤。

说明：

• 揭示的时效性通过类似于 FOCIL (EIP-7805) 的证明者视图合并机制来强制执行。
• 该设计假设对于给定的 (slot, beacon_block_root)，最多只有一个规范的、受法定人数支持的揭示后有效载荷信封。

参与者角色

发送者 (Senders)

在提交之前，发送者运行密钥发布者的链下 KEM（密钥封装机制）生成 (k_dem, kem_ciphertext)，用 k_dem 加密 exec_params 生成 dem_ciphertext，设置 exec_params_binding = H(exec_params)，签署信封并提交至内存池。若选择自解密，则直接生成 k_dem 并将 kem_ciphertext 置空。

包含者 (Includers)

在插槽 N-1 期间，包含者广播包含列表。对于加密交易，他们验证交易信封和 VERIFY 帧，同时将加密执行部分视为受大小限制的不透明字节。

提议者 (Proposer)

在插槽 N 的 t=0s，提议者广播包含构建者出价的信标区块。出价承诺了：

• tx_ordering_root：完整排序交易内容的默克尔根。
• 包含列表（IL）位图。
• 构建者身份和出价。 交易集和排序在出价时锁定，此时密钥尚未揭示。

密钥发布者 (Key-releasers)

其职责是在协议内发布 k_dem。协议本身不对 KEM 构造做限制，但 k_dem 必须与特定交易和揭示域上下文绑定。用户需要信任所选的密钥发布者不会提前泄露密钥。

构建者 (Builder)

构建者决定所有交易（加密和明文）的排序。在 T_rev_b，构建者冻结揭示视图，解密并执行，最后广播包含有效载荷、BAL、reveal_root 和 k_dem 列表的 ExecutionPayloadEnvelope。

PTC

在 T_PTC 时刻，PTC 对有效载荷信封根进行投票。成员通过交易信封中的 k_dem_commitment 验证每个揭示的 k_dem，从而在不解密的情况下验证揭示的可用性。

证明者 (Attesters)

在插槽 N+1 的 t=3s，证明者使用信封中的 k_dem 解密并重新执行插槽 N 的区块，验证其有效性、BAL 以及包含列表的满足情况。

交易格式

交易布局概念上分为： [VERIFY 帧, 明文] [加密阶段, 密文]

加密帧交易包含一个加密执行阶段。VERIFY 帧首先运行，如果密钥已揭示，则随后运行加密执行阶段；否则跳过加密阶段。

信封特定字段：

加密执行阶段包含：

• kem_ciphertext: KEM 封装及元数据。
• dem_ciphertext: exec_params 的 AEAD 加密。

排序与有效性

构建者确定全序。出价承诺 tx_ordering_root。此外，reveal_root 覆盖加密条目：

• 若在 T_rev_b 前揭示，记录 (tx_reveal_id_i, k_dem_i)。
• 否则记录 (tx_reveal_id_i, empty)。

揭示结果的三种情况：

1. 未揭示：跳过加密执行，VERIFY 帧仍运行并扣费。
2. 承诺不匹配：发布的 k_dem 与 k_dem_commitment 不符，视为未揭示。
3. 解密失败：密钥正确但无法解密出满足哈希绑定的明文，条目被跳过。

构建者约束

构建者必须在看不到加密交易隐藏参数的情况下选择排序。这意味着构建者承担执行风险：如果前面的加密交易改变了状态，导致后面的明文交易失败，该明文交易仍消耗 Gas，发送者支付费用，但构建者损失了区块空间的价值。

加密机制

采用标准的 KEM-DEM 分离结构：

• KEM：完全存在于 kem_ciphertext 中，可随共识变化。
• DEM：共识关键部分。节点在揭示时本地解密 dem_ciphertext。
• AEAD 附加数据 (aad)：包含 chain_id, tx_reveal_id, sender 等，防止重放和移植攻击。

加密有效载荷 (Encrypted Payload)

exec_params = RLP(blinding_nonce, target, calldata, priority_fee?, padding?)

• blinding_nonce：确保相同参数产生不同承诺。
• target：目标合约在揭示前保持隐藏。
• padding：用于长度隐藏，Gas 统计会退还填充字节的成本。

隐藏优先费 (Hidden priority fee)

发送者可以将实际的 priority_fee 放在 exec_params 中。揭示前，构建者只看到费用上限。揭示后，协议验证并结算。如果交易因未揭示被跳过，则不收取隐藏优先费。

费用、跳过与免费期权

如果 k_dem 未能及时到达，交易被跳过。VERIFY 帧运行，消耗 Nonce，发送者支付基础成本。加密执行部分的 Gas 会被退还。

免费期权问题：自解密发送者可以观察已承诺的排序，决定是否发布密钥。如果排序不利，可以选择不发布（跳过）。可能的缓解措施包括对加密交易征收额外费用或对重复跳过进行惩罚。

隐私属性

加密帧交易仅提供交易前隐私 (pre-trade privacy)。

在揭示前，构建者看不到目标合约、调用数据、金额或交易对手。配合填充（Padding）使用时，可以进一步减少通过消息大小泄露的信息。

注意：这不提供网络层匿名性。揭示后，交易内容对所有节点公开。隐私也依赖于对密钥发布者的信任。

失败模式

• 密钥发布者不配合导致交易跳过。
• 密钥发布者与构建者串通提前泄露。
• 构建者在获取密钥后扣留有效载荷信封。
• 构建者在 reveal_root 上进行模棱两可的表态（Equivocation）。

zkEVM 路径

该设计可自然扩展到 zkEVM 环境。解密将成为证明义务而非直接的执行层检查。这需要证明系统是零知识的，且 k_dem 保持为私有见证。

与 LUCID 的关系

两者共享 KEM-DEM 模型，区别在于构建者承诺的时机：

• LUCID：在插槽 N 承诺，插槽 N 揭示，插槽 N+1 执行。构建者在排序明文前已知加密内容。
• 本方案：在揭示前承诺排序，同插槽执行，加密与明文交易交织排序。

开放问题

1. 揭示时机与证明者视图合并：需要精确校准揭示窗口，以平衡传播时间和执行时间。
2. ePBS 承诺变体：需要不同于 EIP-7732 的出价结构。
3. 免费期权问题：需要一种不引入复杂性或第二费率市场的缓解方案。

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