基于阈值加密的内存池与mev-commit预确认 - 密码学

具有mev-commit预确认的阈值加密内存池

作者：Murat Akdeniz (Primev), Bernardo Magri (Primev), Christian Matt (Primev), Punit Jain (Shutter Network), Anthony Caravello (Shutter Network), Luis Bezzenberger (Shutter Network)

动机

以太坊用户每天都会因抢跑、三明治攻击和审查而损失价值。DEX 交易被夹击，NFT 铸造被抢跑。这些攻击之所以成功，是因为交易在被纳入之前会显示在公共内存池中。

用户端的解决方案是加密：在执行顺序确定之前隐藏交易内容。但仅靠加密是不够的。如何确保构建者在承诺后实际包含加密的交易？

这篇文章介绍了以太坊链下交易供应链的第一个阈值加密内存池。我们将 Shutter 的阈值加密与 mev-commit 的预确认基础设施相结合，以创建实际的抢跑保护，该保护可以在今天部署而无需共识更改。

关键属性：

• 用户提交加密交易以隐藏其意图
• 构建者在看到内容之前进行盲承诺
• Shutter Keypers 仅在获得足够的承诺后才发布解密密钥
• Oracle 验证包含情况并削减违反承诺的构建者
• 验证者可以通过 mev-boost、Commit-Boost 或任何其他支持中继的 sidecar 无缝选择加入，而无需额外的运营开销

我们正在 Hoodi 测试网上部署一个可用的概念验证。在当前的 PoC 中，排序器 / RPC 仍然在加密交易之前短暂地以明文形式看到交易，因此主要的可视性改进是在用户和公共内存池 / 构建者之间。与此同时，我们正在探索与 Kohaku 风格的方法集成，以转向端到端的执行前隐私，即使 RPC 也无法检查交易内容。

构建者集成：构建者通过扩展其现有的 mev-commit 提供者工作流程来接受和承诺盲加密的出价，从而与加密内存池集成。除了支持 Shutterised Bid 并将解密后的事务放在块的顶部之外，不需要更改块构建逻辑。

mev-commit 通过其标准提供者接口公开加密的出价，允许构建者像接收普通预确认出价一样接收它们，但没有交易内容。构建者评估这些盲标，发布与交易哈希相关的承诺，并依靠 keypers 在达到全局承诺阈值后发布解密密钥。密钥发布后，构建者通过提供者端点获取解密后的交易，并将其包含在区块构建中。

验证者集成： mev-commit 与 commit-boost、mev-boost 或任何其他支持中继的 sidecar 集成，允许验证者通过简单地在其 Commit-Boost 配置中选择启用 mev-commit 的中继来选择加入预确认。

背景：阈值加密和预确认

阈值加密将信任分配给多个称为 keypers 的参与者。在这种方案下加密的交易只有在阈值数量的 keypers（t out of n）合作释放其密钥份额时才能解密。这可以防止任何一方在没有公共解密触发器的情况下进行解密。

加密内存池的关键挑战是执行：我们如何确保构建者实际包含他们承诺的加密交易？存在三种方法：

1. 受信任：构建者承诺包含交易（无强制执行）
2. 经济：构建者质押抵押品，如果行为不当，抵押品将被削减（追溯执行）
3. 密码学：智能合约或共识规则阻止执行，除非满足条件（主动执行）

我们的设计通过 mev-commit 的预确认基础设施使用经济强制执行。构建者以密码学方式承诺包含特定交易，并以可削减的权益支持这些承诺。我们将此机制扩展到加密交易，创建一个构建者盲目承诺交易内容的系统。

关键的见解是承诺基础设施已经存在。与其等待共识更改或智能账户采用，不如利用 mev-commit 现有的削减条件并将其扩展到处理阈值加密的交易，从而立即部署加密内存池。

设计概述

我们的系统集成了三个组件：

1. 排序器：接收加密的交易以及身份 preimage（用于索引加密交易的随机 32 字节），为这些交易生成出价。
2. Keypers：监控构建者的承诺，在满足阈值时（≥3 个承诺）释放解密密钥
3. mev-commit：通过投标人/提供者节点和 oracle 提供承诺和削减基础设施

架构

\ image2230×1416 108 KB

交易流程

1. 用户通过阈值密码学进行加密
2. 用户将加密的交易提交给排序器
3. 排序器将加密的出价提交给 mev-commit 投标人节点
4. 投标人将加密的出价中继给构建者（提供者）
5. 构建者评估并进行盲承诺
6. Keypers 验证承诺阈值，释放密钥
7. 构建者解密并将交易包含在区块的顶部
8. Oracle 验证 L1 上的包含情况
9. Oracle 证明 mev-commit 以获得奖励/削减

关键属性是有条件解密：只有在获得足够的构建者承诺后才释放密钥。这可以防止“解密然后审查”攻击，即构建者看到明文并有选择地排除交易。

强制执行机制

承诺阈值

Keypers 实现阈值验证逻辑：

func ShouldReleaseKey(identity Identity) bool {
  commitments := GetCommitments(identity)

  if len(commitments) < THRESHOLD {
    return false  // 承诺不足
  }

  for _, c := range commitments {
    bidderAddr := RecoverSigner(c.Signature)
    expectedIdentity := Keccak256(c.RandomPrefix + bidderAddr)

    if expectedIdentity != identity {
      return false  // 无效身份
    }
  }

  return true
}

PoC 使用 threshold = 3，但生产系统可以根据出价金额动态地设置此值，或者使用验证者支持的 keyper 集。

包含验证

mev-commit oracle 通过追溯削减来强制执行包含：

func ValidateInclusion(tx, commitment, block) Outcome {
  decrypted := Decrypt(tx.Encrypted, tx.Key)

  if !IsInBlock(decrypted, block) {
    if IsValidTransaction(decrypted) {
      return SLASH_BUILDER  // 恶意排除
    } else {
      return NO_SLASH  // 合理排除
    }
  }

  if block.Transactions[0].Hash != decrypted.Hash {
    return PARTIAL_REWARD  // 放置错误
  }

  return FULL_REWARD
}

削减结果：

• FULL_REWARD：完美履行（包含在区块的顶部）
• PARTIAL_REWARD：已包含但放置错误
• NO_SLASH：合理的未包含（无效交易）
• SLASH_BUILDER：已承诺但未能包含有效交易

这为构建者履行承诺创造了强大的激励。在 PoC 中，削减设置为全额出价（30 Gwei）。生产系统可以根据声誉实施按比例削减。

区块顶部强制执行

要求交易位于区块顶部可以防止一种微妙的攻击：构建者可以包含加密的交易，但在解密后用他们自己的交易抢跑它们。oracle 验证区块位置：

if block.Transactions[0].Hash != decrypted.Hash {
  return PARTIAL_REWARD
}

可以使用 TXINDEX 预编译（EIP-7793）进行链上验证，以用于未来结合经济和密码学强制执行的变体。

安全分析

抢跑保护

攻击：构建者承诺，接收解密密钥，然后重新排序以进行抢跑。

防御：Oracle 检测到错误的放置并进行削减。由于削减等于出价金额，因此只有当 MEV 提取超过削减惩罚时，抢跑才有利可图。实际上，这使得抢跑对于大多数交易在经济上是不合理的。

权衡：如果 MEV 超过权益，经济强制执行允许抢跑。密码学强制执行（智能合约在链上验证放置）可以无条件地防止这种情况，但需要共识更改和更高的 gas 成本。我们的方法是今天可以部署的。

抗审查性

攻击：构建者承诺然后故意排除交易。

防御：Oracle 削减全额出价。由于构建者错过了奖励并损失了权益，因此除非受到外部动机（例如，OFAC 合规性）的驱使，否则审查在经济上是不合理的。

限制：无法防止承诺之前的审查。如果没有构建者承诺，keypers 不会释放密钥，并且不会包含交易。这可以通过以下方式缓解：

1. 多个构建者竞争订单流
2. 构建者的声誉系统
3. 与 FOCIL（强制选择包含列表）集成

离线提议者攻击

攻击：提议者离线，解密的交易泄露，下一个提议者进行抢跑。

防御：在当前的 PoC 中，我们不阻止跨Slot的交易重用。但是，可以通过添加特定于Slot的验证来解决这个问题：

require(block.number == intendedBlock, "错误的区块");

即使已被解密，这也会使未来区块中的交易主体无效，类似于智能账户方法如何处理这种情况。此限制也可以在 dapp 上使用特定检查来处理，例如通过 AMM 交换 token 的截止日期。

Keyper 勾结

攻击：Keypers 勾结提前解密（< 阈值）。

防御：阈值假设（< t 的 n 个恶意）。对于 PoC，我们使用 t = 3，n = 5。生产改进：

1. 验证者支持的 keypers：从具有经济安全性的以太坊验证者集中选择
2. ShutterTEE：将密钥份额存储在 TEE 中，这些 TEE 仅在满足协议条件时才发布
3. 告密协议：检测并惩罚勾结的 keypers
4. 轮换：定期轮换 keyper 集

Shutter 路线图 深入探讨了这些改进。

今天的 RPC 可见性和端到端隐私

今天，排序器 / RPC 仍然在加密交易并将其转发到加密内存池之前以明文形式看到交易。这意味着：

• 公共内存池和构建者是盲的
• 但 RPC 运营商仍然是一个可见性瓶颈

我们更长远的目标是弥合这一差距，实现端到端的执行前隐私。我们正在探索：

• 类似于 Kohaku 的方法，用于将加密更靠近用户
• 与 PSE 合作，即使 RPC 在执行顺序确定之前也无法看到交易内容

此 PoC 应被视为朝着端到端模型迈出的一步。

经济考虑

构建者决定：盲目承诺还是跳过？

如果以下情况则承诺：E[TransactionValue] + Reputation > SlashingRisk

该设计保留了回溯 MEV，同时防止了抢跑。解密后，构建者可以包含回溯交易，而不会损害用户。各方（用户、构建者、keypers、oracle）都有经济动机诚实参与。

通过 PBS Sidecar（mev-boost / Commit-Boost）进行验证者参与

验证者参与加强了承诺的可信度，并使加密内存池能够提取最高的经济价值。但是，保持验证者的简单性至关重要。mev-commit 通过与 PBS sidecar（如 commit-boost 和 mev-boost）集成来实现这一点。

建筑：

• mev-commit 网络层：作为点对点网络服务和区块链的组合运行，用于执行出价和承诺
• PBS Sidecar 层：在验证者和承诺协议（例如，Commit-Boost、mev-boost） 之间提供标准化接口
• 中继委托：验证者将计算工作委托给中继，从而保持轻量级操作

它是如何工作的：

验证者可以运行支持多种承诺协议（包括 mev-commit）的单个 PBS sidecar。集成仅需要：

1. 安装 PBS sidecar（当前为 Commit-Boost；相同模式下的 mev-boost 或其他 sidecar）
2. 在 sidecar 配置中配置启用 mev-commit 的中继
3. 通过验证者注册表（EigenLayer、Symbiotic 或 vanilla staking）选择加入 mev-commit
4. 开始自动接收预确认奖励

验证者的好处：

• 低运营开销：除了通常的 PBS sidecar 之外，无需额外的基础设施
• 潜在收入：从预确认出价和加密交易 mev 中获取价值
• 降低风险：用于多个承诺协议的单个标准化接口
• 面向未来：无需更改基础设施即可准备好使用新的 mev-commit 服务

与替代方案的比较：

通过利用现有的 PBS sidecar，我们的加密内存池设计在提供对预确认市场的即时访问的同时，保持了与不断发展的验证者基础设施的兼容性。随着 mev-commit 扩展以支持除预确认之外的其他服务，使用这些 sidecar 的验证者会自动受益，而无需更改其设置。

概念验证实施

我们正在 Hoodi 测试网上部署 PoC，我们将很快提供它。

加密的内存池流将通过专用 FastRPC 端点公开，该端点支持但独立于主 RPC 接口，可供保护隐私的钱包使用。

组件：

• 排序器：专用于加密流的 FastRPC JSON-RPC 端点、Shutter 加密、mev-commit 投标人客户端、P2P keyper 网络
• Keypers：修改后的 rolling-shutter、阈值验证 (3-of-5)、DKG 协议
• mev-commit：扩展的投标人/提供者 gRPC API、oracle 包含验证

性能：

• 交易加密：~50ms
• 承诺阈值：3 个构建者
• 解密延迟：阈值后 2-5 秒
• 交易将被预先确认（一旦发生承诺）
• 完整流程：~12–15 秒（一个 L1 区块）

与其他方法的比较

经济 vs. 密码学强制执行

我们的 mev-commit 方法通过削减使用经济强制执行：

• 今天适用于 EOA
• 更低的 gas 成本（链下验证）
• 利用现有的 mev-commit 基础设施
• 与当前的 PBS 架构兼容
• 追溯执行（如果 MEV > 权益，则可能发生抢跑）
• 需要构建者参与 mev-commit

通过智能合约的密码学强制执行将提供：

• 无条件的抢跑保护
• 不会削减离线提议者
• 需要采用 ERC-4337 或类似的账户抽象
• 需要新的预编译（TXINDEX、SLOT）
• 更高的 gas 成本（链上验证）
• 限制为没有 EIP-7702 的智能账户

这些方法是互补的。未来的工作可以将 mev-commit 承诺与智能合约验证相结合，以实现分层安全性。

链下 vs. 链上

我们的链下 mev-commit 方法：

• 今天可以部署
• 迭代改进路径
• 更低的协调成本
• 比共识强制执行的保证弱
• 依赖于经济安全

链上集成 ( Shutter 路线图) 将提供：

• 最强的保证（共识强制执行）
• 无需外部削减基础设施
• 可以与 FOCIL 集成
• 需要硬分叉
• 更长的部署时间表

未决问题

机制设计：

1. 承诺阈值是否应因出价金额或验证者参与情况而异？
2. 比例削减与二元削减？如何处理重复违规者？
3. 加密交易相对于普通交易应如何定价？

集成：

5. 钱包内加密 vs. dapp 端加密？
6. 什么激励因素会推动构建者参与？

安全：

7. 生产环境的 Keyper 选择：随机验证者采样 vs. 专用集？
8. 如果没有构建者承诺会怎样？FOCIL 集成？
9. 跨域 MEV 处理？

经济学：

10. 回溯利润是否应与用户或 keypers 共享？
11. 加密交易如何竞争区块空间？
12. 费用能否长期支持 keyper 基础设施？

未来方向

短期（3-6 个月）： 构建者加入、性能优化、钱包集成、监控基础设施

中期（6-12 个月）： 动态阈值、具有削减功能的验证者支持的 keypers、中继集成

长期（12 个月以上）： 用于分层安全性的智能合约集成、ePBS 原生支持、FOCIL 集成、协议内转换路径，以及更深入的 Kohaku / PSE 风格的集成，以实现 RPC 盲、端到端的执行前隐私

模块化设计允许增量部署，而不会破坏现有功能。

结论

我们提出了一个实用的阈值加密内存池，该内存池利用 mev-commit 的预确认基础设施进行经济强制执行。虽然追溯削减比主动密码学强制执行弱，但它在以太坊现有架构内提供了一个可部署的向前路径。

Hoodi 测试网上的 PoC 是第一步。接下来的步骤包括扩大构建者参与、优化性能、通过端到端方法加强 RPC 可见性，以及收集数据以告知生产部署和未来的协议内设计。

加密内存池对于以太坊的公平性和去中心化至关重要。这项工作表明它们今天就可以部署。我们邀请构建者、验证者和协议开发人员试验 PoC 并提供反馈。

代码和文档：

• 排序器：GitHub - shutter-network/primev-sequencer
• Keypers: rolling-shutter PR #629
• mev-commit: github.com/primev/mev-commit

致谢： 这项工作建立在 Shutter Network 的阈值加密研究和 mev-commit 的预确认基础设施之上。感谢更广泛的加密内存池研究社区提供的宝贵见解。

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