与 Kubi 合作完成。感谢 Drew、Justin、Ladislaus、Conor、Lin 的审阅和反馈。反馈并不一定意味着认可。
Custard 
(通过谨慎的状态管理来限制用户状态,以避免下游的反悔)是一种技术,可以通过仔细管理状态来实现基于 rollup 的原子可组合的超级交易。关键洞见是,通过限制超级交易所依赖的特定部分的 L1 状态,我们可以使验证者在不需要控制整个 L1 块的情况下安全地提前发出 L1 执行预确认。这减少了引导预确认协议所需的验证者协调,并允许基于 rollup 更早地提供超级交易,而无需更多参与的验证者。本文探讨了三种实现 Custard 的方式:通过 EIP-7702、智能合约和排除预确认。
为什么这很重要?
基于序列化的主要好处是它可以在 L1 和基于 rollup (BRU) 之间实现同步和原子性。这意味着在两个层上的操作可以组合成我们所谓的"超级交易" - 一个跨两个层工作的交易包。
一个现实世界的例子
让我们考虑一个实际的例子:L1→L2→L1 套利。想象 Alice 想原子地:
- 将她的代币从 L1 转移到 BRU
- 在 BRU 上进行交易
- 将她的代币和利润转回 L1
目前,这些都是独立的步骤,中间会有延迟(例如,对于乐观 rollup,步骤 2-3 通常需要 7 天)。应用 Custard,Alice 可以将所有这些操作打包成一个超级交易,在一个以太坊块内完成。
为了使超级交易广泛采用,我们需要解决三个关键挑战:
- 实时证明:我们需要一种方法来快速结算 BRU 的状态,以便在单个 L1 块内提取
- 保证原子性:我们需要机制来确保超级交易的所有部分要么全部成功完成,要么全部不发生
- 验证者可用性:我们需要足够的验证者参与,以确保用户可靠地获得超级交易
本文的其余部分将检查这些挑战和现有的解决方法,然后介绍 Custard 作为将它们结合在一起的方法。
挑战 #1: 实时证明
传统方法及其局限性
到目前为止,人们普遍认为(无需信任的)即时从 rollup 提取需要"实时证明" - 本质上,rollup 的状态必须首先通过有效性证明进行结算。为了使 Alice 的超级交易在一个 L1 块(12 秒)内完成,有效性证明的生成速度需要更快。然而,目前市场上还没有部署能够如此快速生成这些证明(实时 SNARKs)的技术,但有许多令人惊叹的努力正在进行中(
)。
当前的变通方法
一些项目(UniFi、Gwyneth、T1)转向了可信执行环境(TEE)作为 SNARKs 的替代品,用于证明 rollup 的状态转换函数。虽然 TEE 可以比 SNARKs 生成证明更快,从而实现实时证明,但它们也带来了一个重大缺点:需要信任硬件制造商和证明者。这种额外的信任假设为基于 rollup 引入了传统 SNARK 系统所没有的新风险。
一种新的解决方案:解算器方法
Nethermind 最近提出了一种解决方案,它在不需要实时证明的情况下实现了即时提取的用户体验。他们的方法:
- 使用解算器在 L1 上立即为用户提供提取流动性,而无需先结算 BRU 状态
- 维护原子性(解算器和 BRU 桥接受到重组的保护)
- 维护无需信任(无需信任解算器或 TEE)
- 在实时证明技术成熟之前提供一条实际的前进道路(以资本效率为代价)
挑战 #2: 保证原子性
为了使 Alice 的超级交易顺利进行,我们需要确保所有子交易要么全部成功完成,要么全部不发生。这就是 执行预确认(EPs)的作用所在。
执行预确认的作用
为了保证超级交易的成功,我们需要以太坊验证者提供四个特定的保证:
- L1 存款保证:确认 Alice 的资金将成功从 L1 转移到 BRU
- L2 交换保证:确保 Alice 在 rollup 上的交易将按预期执行
- L2 提取保证:确认 Alice 将资金从 BRU 转回 L1 的请求将被处理
- L1 解算器保证:确保解算器在 L1 上转移 Alice 的资金
为什么以太坊验证者很重要
一个关键的洞见是,这些保证必须来自以太坊验证者自身。他们独特地位于这个位置,因为他们可以成为两个层的提议者:
- 在以太坊上,他们对 L1 拥有写锁定,因为他们有权提出下一个块
- 在 BRU 上,他们可以被配置为在他们的时间段内唯一有权排序交易的人
这种双重写锁定是基于序列化的特殊之处 - 只有以太坊验证者才能可信地承诺一个超级交易将完全按计划执行。基于预确认是验证者做出这些承诺并使之具有约束力的机制 - 通过质押资本,验证者成为预确认者,如果他们未能兑现承诺,将面临经济处罚。
挑战 #3: 验证者可用性
L1 EP 约束
L1 EPs 的一个关键限制是它们的"即时"性质。验证者只能在他们是当前块提议者时安全地发出这些 L1 EPs。为什么?因为未来的验证者没有对 L1 的写锁定,而早期的验证者可能会以破坏他们的 L1 EPs 的方式改变 L1 状态。
这与 rollup 上的 L2 EPs 不同,在 rollup 上,验证者可以安全地提前做出承诺,因为 rollup 的智能合约确保只有指定的预确认者可以在他们的回合之前和期间写入状态。
引导挑战
这种即时性约束造成了两个重大问题:
- 可用性有限:超级交易只能在 L1 验证者选择作为预确认者的块中发生
- 用户体验问题:除非每一个以太坊验证者都参与到这个系统中,否则总会有一些时隙无法提供超级交易
让 100% 的以太坊验证者参与是一个巨大的商业挑战。因此,我们需要一种替代方案:找到一种方式让验证者可以安全地提前发出 L1 EPs。
什么是 Custard?
Custard 通过一个关键观察提供了解决我们时间问题的方案:我们并不总是需要控制整个 L1 块来做出安全的保证。相反,我们可以选择性地锁定超级交易需要处理的 L1 状态的特定部分。
这一洞见很强大,因为它意味着我们可以提前发出某些类型的 L1 EPs,只要我们能够保证我们关心的特定状态不会改变。通过只锁定我们需要的部分,而不是要求控制所有内容,我们可以大大减少需要作为预确认者的验证者数量。
注意:我们接下来描述的实现都是有意简化的,以清楚地说明机制。在实践中,这些可以进行优化,以提高资本效率和通用性。
基于 EIP-7702 的 Custard
EIP-7702使用户账户(EOA)能够基于任何智能合约设置自己的自定义代码,从而将其变成一个智能账户。我们可以利用这一点来创建关于用户账户状态的时间锁定保证。
它是如何工作的
让我们来看看 Alice 如何使用 EIP-7702 执行她的超级交易:
- 初始锁定(插槽
S)- Alice锁定她账户的nonce直到未来的插槽
S' - 这可以防止在指定插槽之前对她的账户进行任何更改
- Alice锁定她账户的nonce直到未来的插槽
- 设置(插槽
S + 1)- Alice向将在未来插槽
S'提议的预配置器请求她的超级交易 - 该交易包括:
- 向Rollup存入
BETH - 执行套利交易
- 提取
B + ε - fETH(原始金额加上利润减去费用) - 让解算器在L1上完成提款
- 向Rollup存入
- Alice向将在未来插槽
- 验证(插槽
S + 1)- 预配置器检查Alice的账户是否正确锁定
- 如果验证通过,预配置器发出所有必要的预配置
- 执行(插槽
S')- 预配置器执行整个交易:
- 将Alice的
BETH存入BRU - 将BRU blob提交到L1,其中包含Alice的交易
- 完成解算器向Alice在L1上转账
B + ε - fETH
- 将Alice的
- 预配置器执行整个交易:
- 结算(插槽
S' + Δ)- 经过
Δ个区块后,BRU状态得到证明 - 解算器可以通过从BRU提款来收回
B + ε + fETH
- 经过
关键洞见
通过锁定她的账户,Alice保证在超级交易执行时会有足够的资金(B ETH)。如果要求账户首先被锁定,预配置器可以安全地提前发出L1 EP,从而解决我们的时间问题。
使用智能合约的Custard
在等待EIP-7702发布的同时,我们可以使用智能合约实现类似的结果。关键区别在于,用户必须先将资产存入一个托管合约,该合约强制执行相同的保证,而不是直接修改账户行为:
- 资产被锁定直到目标插槽
- 资金只能存入Rollup
- 在此之前不允许资产余额减少
执行流程与EIP-7702方法相似,但有一个明显的优势:托管合约自然会积累一池被锁定的资产,从而在协议设计中实现潜在的资本效率优化。
使用排除预配置的Custard
排除预配置代表了一种不同类型的验证器承诺:不是保证他们将做什么,而是承诺他们不会做什么。具体来说,他们承诺通过不允许发生特定的账户操作来防止某些状态变更。虽然排除通常与以太坊的价值观相悖,但在这种情况下谨慎使用,它可以发挥建设性作用:锁定特定的账户状态以保持提前的L1 EP有效性。重要的是,只有在账户所有者明确授权的情况下,才允许这种类型的预配置,以避免审查。
工作原理
让我们来看看Alice如何使用排除预配置来执行她的超级交易:
- 发布执行预配置
- Alice在目标超级交易插槽之前从验证器那里获得排除预配置
- 每个排除预配置承诺不会:
- 包含会增加Alice的nonce的交易
- 包含会减少Alice的ETH余额的交易
- 执行
- 当目标插槽到来时,Alice的EOA保证会有所需的ETH
- 超级交易可以安全地进行
这种方法的一个优点是,所有执行预配置都是在链下发布的,从而降低了gas成本。但它引入了一些复杂性。超级交易仍然需要所有早期插槽验证器成为L1排除预配置器 - 虽然比之前的方法更容易,但这仍然是一个重大的BD挑战。此外,支付排除预配置的费用变得很棘手,因为在最佳情况下什么都不会上链,而且在评估违约风险时,需要仔细考虑抵押要求和惩罚条件。
这种方法的局限性
Nethermind的解算器方法的一个关键区别是,提款请求有一个简单的"L1输出条件"- 它们只需要验证代币是否到达特定的L1地址。这种简单性是支持无需实时证明的原子提款的关键。但是,更复杂的超级交易可能需要L1输出条件依赖于复杂的L2状态变更,在这种情况下,我们可能需要实时证明L2状态。虽然Custard管理L1状态依赖性的原则仍然适用,但实现要么需要等待实时SNARK技术的成熟,要么接受基于TEE的证明解决方案的额外风险。
