Rollups 中的预先确认保证的分类及其削减条件
感谢 mteam 和 Justin Drake 对本文的反馈和评论。感谢 Ink L2 为我的研究提供资金支持。
Optimistic Rollup 中的预确认机制可以为用户提供不同级别的保证，从基本的包含性到对排序和执行结果的强保证。然而，由于缺乏正式的分类法，导致讨论中存在定义重叠，甚至有时是重复的现象。本文档提出了一种结构化的预确认保证分类方法，旨在明确每种类型之间的界限。此外，文档还定义了相关的罚没条件以及执行这些条件所需的计算复杂度，从而使Rollup设计能够对安全性、用户体验和实现方式进行严格的权衡。
预先确认有四个基本保证：
- 包容性
- 通过签名消息强制包含需要预先确认的排序器将交易包含在指定的块中。
- 订购
- 通过签名消息强制排序需要预先确认排序器将交易包含在指定块中的指定序列号处。
- 执行成功
- 执行成功保证交易不会回滚，无论其确切的输入状态或 Gas 消耗如何。但是，除非还做出了状态后承诺，否则它不能保证特定的状态变化。
- 州后担保
- 通过签名消息强制执行后状态保证需要预确认测序器包含交易并确保执行期间的预状态参数和后状态突变与预确认测序器的签名响应相匹配。
类别 0
保证包含。不保证订购或执行成功。
这是最弱的保证。交易者通过预确认响应获得交易被包含的保证。然而，排序并不能保证，执行结果也不确定。
此类别的削减条件将是交易树中交易不包含的证明。
然而，无序交易树的非包含证明在 EVM 中计算起来很复杂，因为需要对交易树中的所有交易进行排除证明。
例子：
DEX 内存池纳入限价订单
用户向基于 Rollup 的 DEX 提交限价订单。排序器提供签名保证，保证该交易将被打包到下一个区块中，但最终排序方式尚未确定。这使得 DEX 前端可以向用户显示他们的订单将被处理，但不会承诺执行成功或结果（滑点、竞争条件或抢先交易可能会影响执行结果）。
第 1 类
保证包含和排序。不保证执行成功。
此类别的削减条件将是交易树中交易不包含的证明。
对已签名的序列器交易使用序列号可以降低计算复杂度，因为通过提供指定序列的交易和附带的 Patricia Merkle Tree (PMT) 见证，可以将不包含证明转化为矛盾证明。
例子：
优先插槽的 NFT 铸造
在 NFT 投放期间，用户可以付费购买优先铸币位。排序器会返回一个已签名的预确认，承诺铸币交易将被添加到特定的序列位置。但是，如果用户资金或 Gas 不足，交易仍可能被撤销。这确保了排序的公平性，同时将执行风险转移给了用户。
第 2 类
保证成功纳入并执行。不保证排序或后续状态。
此类别保证交易执行无逆转，且不保证交易执行时的状态树输入或输出。此保证使发出预确认的排序器能够从预确认的交易中提取 MEV，同时为交易者提供执行成功的强有力保证。
此类别的削减条件与类别 0 相同。但是，非逆转证明需要在 EVM 中重新执行The Block，直到交易执行完毕。
例子：
具有 MEV 灵活性的滑点约束 DEX 交易
用户向去中心化交易所 (DEX) 提交一笔指定最大滑点的交易（例如，“以至少 0.98 ETH的价格卖出 1000 USDC ”）。只要交易后价格在用户的滑点容忍度范围内，序列器就会返回预确认，保证交易成功（即不会回滚）。只要最终执行价格在允许范围内并成功，序列器就可以自由地相对于其他交易重新排序这笔交易，并提取 MEV（例如，通过“夹层”操作）。这让用户在无需特定排序或状态根的情况下，仍能保持执行的信心。
第 3 类
保证包含、执行成功和后状态。不保证顺序。
这是最强的保障。此保障为交易者提供了交易被包含和交易后状态变更的保证。虽然排序可以自然推断，但并非严格执行，因为交易的前后状态可以独立验证。只要交易的状态上下文保持隔离，交易在The Block中的位置可以发生变化，而不会影响其执行结果。
削减条件与第 2 类相同，但增加了 EVM 后状态证明，以验证后状态突变。
例子：
托管或有条件付款合同
在跨链桥接或支付通道中，用户发送交易，期望其最终产生精确的后状态突变（例如，balanceOf(user) += 1 ETH）。排序器会签署一份预确认，该预确认不仅承诺交易的纳入和成功执行，还承诺最终产生的特定后状态根。这使得预确认可以作为桥接协议或条件承诺中的链下证明，如果违反，将受到严厉的惩罚。
= 保证 | 
= 不保证
| 类别 | 包容性 | 订购 | 执行成功 | 州后担保 | 削减计算 |
|---|---|---|---|---|---|
| 0 | | | | | 在） |
| 1 | | | | | O(1) |
| 2 | | | | | O(n) + O(m) |
| 3 | | | | | O(n) + O(m) |
* O(m) 意味着交易执行
关于削减条件复杂性的脚注：
虽然验证 slashing 条件（例如，证明未包含或后状态不正确）的简单方法可能需要在 EVM 中进行 O(n) 或 O(m) 运算，但通过加密证明系统可以显著降低这些成本。如果Rollup利用 SNARK（或类似的简洁证明），则整个 slashing 验证过程（无论是检查包含、执行成功还是后状态有效性）都可以在链上压缩为常数时间验证成本，从而有效地将计算复杂度降低到 O(1)。
为什么要区分2类和3类？
第 2 类保证执行成功，但不保证执行后状态。这意味着排序器可以在The Block内重新排序交易，从而可能改变其执行前和执行后状态，只要它不被逆转。这种灵活性使得 MEV 提取或批处理优化成为可能，同时又能保证交易“成功”。
相比之下，类别 3明确保证了后状态，这意味着排序器必须确保交易导致特定的状态转换。只有当交易的预状态是隔离的（即不受周围交易的影响）时，才允许重新排序。如果预状态不是隔离的，则排序将隐式固定，因为任何排序的更改都会使预期的后状态无效。然而，排序本身并非罚没条件——只有已提交的后状态不匹配才可以被罚没。
