Custard——提升超级交易的用户体验——第二层网络

与 Kubi 共同完成。感谢 Drew, Justin, Ladislaus, Conor, Lin 的审查和反馈。反馈不一定代表认可。

Custard ( C onstraining U ser S tate T o A void R eneging D ownstream，约束用户状态以避免下游反悔) 是一种通过仔细的状态管理，在Based Rollup 上实现原子可组合的超级交易的技术。其关键在于，通过约束超级交易依赖的 L1 状态的特定部分，我们可以使验证者能够安全地提前发布 L1 执行预确认，而无需控制整个 L1 区块。这减少了引导预确认协议所需的验证者协调，并允许Based Rollup 更早地提供超级交易，且参与的验证者更少。本文探讨了三种实现 Custard 的方法：通过 EIP-7702、智能合约和排除预确认。

为什么这很重要？

基于排序的一个主要好处是，它实现了 L1 和Based Rollup (BRU) 之间的同步性和原子性。这意味着两层上的操作可以组合成我们所说的“超级交易”——这是一个跨两层的交易捆绑包，就像它们是一个交易一样。

一个真实的例子

让我们考虑一个实际的例子：L1→L2→L1 套利。想象一下，Alice 想要原子性地：

1. 将她的代币从 L1 转移到 BRU
2. 在 BRU 上进行交易
3. 将她的代币和利润转移回 L1

目前，这些将是独立的步骤，步骤之间存在延迟（例如，对于乐观 Rollup，步骤 2-3 之间通常有 7 天的延迟）。应用 Custard，Alice 可以将所有这些操作捆绑到一个超级交易中，该交易在单个以太坊区块内完成。

为了使超级交易得到广泛采用，我们需要解决三个关键挑战：

1. 实时证明：我们需要一种足够快地结算 BRU 状态的方法，以便在单个 L1 区块内提款
2. 保证原子性：我们需要确保超级交易的所有部分都成功完成，或者所有部分都不发生的机制
3. 验证者可用性：我们需要足够的验证者参与，以使用户能够可靠地使用超级交易

本文的其余部分将研究每个挑战和解决这些挑战的现有方法，然后在介绍 Custard 作为一种将它们结合在一起的方式。

挑战 #1：实时证明

传统方法及其局限性

到目前为止，人们普遍认为，从 Rollup 进行（无需信任的）即时提款需要“实时证明”——本质上，Rollup 的状态必须首先通过有效性证明来结算。为了让 Alice 的超级交易在一个 L1 区块（12 秒）内完成，有效性证明甚至需要更快地生成。然而，生成这些快速证明的技术（实时 SNARK）尚未在市场上部署，但目前有很多出色的工作正在进行中 ()。

当前的解决方法

一些项目（UniFi, Gwyneth, T1) 转而使用可信执行环境 (TEE) 作为 SNARK 的替代方案，用于证明 Rollup 的状态转换函数。虽然 TEE 可以比 SNARK 更快地生成证明，从而使实时证明成为可能，但它们有一个明显的缺点：它们需要信任硬件制造商和证明者。这种额外的信任假设给Based Rollup 带来了传统基于 SNARK 的系统所没有的新风险。

一种新的解决方案：求解器方法

Nethermind 最近提出 了一种解决方案，该解决方案实现了即时提款的用户体验，而无需实时证明。他们的方法：

• 使用求解器在 BRU 状态结算之前立即为 L1 上的用户提供提款流动性
• 保持原子性（求解器和 BRU 桥受到重组的保护）
• 保持无需信任（无需信任求解器或 TEE）
• 在我们等待实时证明技术成熟时，提供了一条切合实际的前进道路（以牺牲资本效率为代价）

挑战 #2：保证原子性

为了使 Alice 的超级交易无缝运行，我们需要确保所有子交易都成功完成，或者所有子交易都不发生。这就是执行预确认（EP）的用武之地。

执行预确认的角色

为了保证超级交易的成功，我们需要以太坊验证者提供四个具体的保证：

1. L1 存款保证：确认 Alice 的资金将成功地从 L1 转移到 BRU
2. L2 交换保证：确保 Alice 在 Rollup 上的交易将按预期执行
3. L2 提款保证：确认 Alice 将资金从 BRU 转移回 L1 的请求将被处理
4. L1 求解器保证：确保求解器在 L1 上转移 Alice 的资金

为什么以太坊验证者很重要

一个关键的见解是，这些保证必须来自以太坊验证者本身。他们具有独特的优势来做出这些保证，因为他们可以成为两层的提议者：

• 在以太坊上，他们对 L1 拥有写入锁定，因为他们拥有提议下一个区块的唯一权限
• 在 BRU 上，可以将它们配置为唯一有权在其Slot期间对交易进行排序的人

这种双重写入锁定使基于排序变得特别——只有以太坊验证者才能可信地承诺超级交易将完全按照计划执行。基于预确认 是验证者通过其承诺具有约束力的机制——通过质押资本，验证者成为预确认者，如果他们未能履行承诺，将面临经济处罚。

挑战 #3：验证者可用性

L1 EP 约束

L1 EP 的一个关键限制是它们的“及时性”性质。验证者只有在他们是当前区块提议者时才能安全地发布这些 L1 EP。为什么？因为未来的验证者对 L1 没有写入锁定，并且早期的验证者可能会以破坏其 L1 EP 的方式更改 L1 状态。

这与 Rollup 上的 L2 EP 不同，在 Rollup 上，验证者可以安全地提前做出承诺，因为 Rollup 的智能合约确保只有指定的预确认者才能在其回合之前和期间写入状态。

\ image1920×738 80.5 KB

引导挑战

这种及时性约束会产生两个重大问题：

1. 可用性有限：超级交易只能在以下区块中发生

L1 验证者已选择加入作为预确认者

2. 用户体验问题：除非每个以太坊验证者都参与该系统，否则在某些Slot中超级交易将不可用

让 100% 的以太坊验证者参与是一项巨大的商业拓展挑战。因此，我们需要一种替代解决方案：找到一种让验证者安全地提前发布 L1 EP 的方法。

什么是 Custard？

Custard 通过一个关键的观察结果为我们的时序问题提供了一个解决方案：我们并不总是需要控制整个 L1 区块才能做出安全的保证。相反，我们可以有选择地锁定我们超级交易需要使用的 L1 状态的特定部分。

这个见解非常强大，因为它意味着我们可以提前发布某些类型的 L1 EP，只要我们能保证我们关心的特定状态不会改变。通过仅锁定我们需要的内容，而不是要求控制所有内容，我们可以大大减少作为预确认者所需的验证者数量。

注意：我们接下来描述的实现方式是故意简化的，以清楚地说明这些机制。在实践中，可以对这些机制进行优化，以提高资本效率和通用性。

使用 EIP-7702 的 Custard

EIP-7702 使 User Account (EOA) 能够根据任何智能合约设置自己的自定义代码，实际上将其转换为智能账户。我们可以使用它来创建关于用户账户状态的限时保证。

它是如何工作的

让我们来看看 Alice 如何使用 EIP-7702 执行她的超级交易：

1. 初始锁定（Slot S）
   • Alice 锁定其账户的 nonce，直到未来的Slot S'
   • 这会阻止对她的账户进行任何更改，直到指定的Slot
2. 设置（Slot S + 1）
   • Alice 从将在未来Slot S' 提议的预确认者处请求她的超级交易
   • 该交易包括：
     • 将 B ETH 存入 Rollup
     • 执行套利交易
     • 提取 B + ε - f ETH（原始金额加上利润减去费用）
     • 让求解器在 L1 上完成提款
3. 验证（Slot S + 1）
   • 预确认者检查 Alice 的账户是否已正确锁定
   • 如果验证通过，预确认者会发布所有必要的预确认
4. 执行（Slot S'）
   • 预确认者执行整个交易：
     • 将 Alice 的 B ETH 存入 BRU
     • 将包含 Alice 交易的 BRU blob 提交给 L1
     • 完成求解器在 L1 上向 Alice 转移 B + ε - f ETH
5. 结算（Slot S' + Δ）
   • 在 Δ 个区块之后，BRU 状态得到证明
   • 求解器可以通过从 BRU 提款来收回 B + ε + f ETH

关键洞察

通过锁定她的账户，Alice 保证她在超级交易执行时将有足够的资金（B ETH）。如果预确认者要求账户首先被锁定，他们可以安全地提前发布 L1 EP，从而解决我们的时序问题。

使用智能合约的 Custard

在等待 EIP-7702 发布的同时，我们可以使用智能合约来实现类似的结果。关键的区别在于，用户必须首先将其资产存入强制执行相同保证的托管合约，而不是直接修改账户行为：

• 资产被锁定到目标Slot
• 资金只能存入 Rollup
• 在此之前不允许减少资产余额

\ image1920×916 86.9 KB

执行流程与 EIP-7702 方法类似，但有一个显着的优势：托管合约自然会累积锁定的资产池，从而可以在协议设计中实现潜在的资本效率优化。

使用排除预确认的 Custard

排除预确认代表一种不同类型的验证者承诺：验证者不是保证他们将做什么，而是承诺他们不会做什么。具体来说，他们承诺通过不允许发生特定的帐户操作来防止某些状态更改。虽然排除通常与以太坊的价值观背道而驰，但当在这种情况下谨慎使用时，它会起到建设性的作用：锁定特定的帐户状态以保持提前 L1 EP 的有效性。重要的是，只有在帐户所有者明确授权的情况下才允许这些类型的预确认，以避免审查。

它是如何工作的

让我们来看看 Alice 如何使用排除预确认执行她的超级交易：

1. 发布执行预确认
   • Alice 从验证者那里获得目标超级交易Slot之前的排除预确认
   • 每个排除预确认都承诺不：
     • 包含会增加 Alice 的 nonce 的交易
     • 包含会减少 Alice 的 ETH 余额的交易
2. 执行
   • 当目标Slot到达时，Alice 的 EOA 保证拥有所需的 ETH
   • 超级交易可以安全地进行

\ image1920×881 88.7 KB

这种方法的一个优点是所有执行预确认都是链下发布的，从而降低了 Gas 成本。但是，它引入了一些复杂性。超级交易仍然需要所有较早Slot验证者都作为 L1 排除预确认者 - 虽然比以前的方法更容易，但这仍然是一个重大的商业拓展挑战。此外，为排除预确认付费变得棘手，因为在正常情况下没有任何东西落在链上，并且在评估反悔风险时需要仔细考虑抵押品要求和削减条件。

这种方法的局限性

Nethermind 求解器方法的一个关键区别在于，提款请求具有简单的“L1 输出条件”——它们只需要验证代币是否到达特定的 L1 地址。这种简单性使得无需实时证明即可进行原子提款。但是，更复杂的超级交易可能需要 L1 输出条件依赖于复杂的 L2 状态更改，在这种情况下，我们可能需要实时证明 L2 状态。虽然 Custard 用于管理 L1 状态依赖项的原则仍然适用，但实现方式要么需要等待实时 SNARK 成熟，要么接受基于 TEE 的证明解决方案的额外风险。

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