Layer 2 中交易是如何排序的？了解 Rollup 中的定序器

定序器不能窃取用户的资金，但能审查用户的交易。

原文标题：《科普 | Rollup 中的定序器》 撰文：Kris Kaczor 翻译及校对：闵敏 和 阿剑

我看到 OptimismPBC 上部署的 Uniswap 的快速确认功能引起了很多人的兴趣。但这是如何做到的？用户可以放心使用吗？只靠一个定序器提供确认难道不会威胁到去中心化吗？让我来一一为你解答。

首先，最重要的是，定序器在许多 Rollup 系统中都属于享有特权的参与者 (Optimism、Arbitrum、StarkWare、zkSync）。它们接收来自用户的交易，对其进行排序并批量提交到 Layer 1 上。

定序器之所以存在，主要是因为单一协调者简单高效。现阶段，每个 Rollup 系统通常都会有一个定序器，由系统创建者运行。

定序器负责为交易排序。因此，在收到用户的交易后，定序器可以立即将其挖出，并向用户返回确认。这极大地改善了用户体验。

如果你担心定序器会攫取 MEV，那你是对的，不过我会单独讨论这个问题（留到最后分析）。

如果定序器忠于职守，则一切都好。但是，如果定序器作恶，欺骗用户并试图破坏网络，我们该怎么办？让我们来深入探讨这个问题。

最重要的问题是：定序器可以偷用户的资金吗？不能。状态转换的有效性由 Rollup 架构保障（Optimistic Rollup 靠的是欺诈证明，zk-Rollup 靠的是有效性证明）。

定序器能审查用户的交易吗？没错，它确实可以。定序器通常是 JSON RPC 节点。与 Infura 类似，定序器甚至可以谎报网络状态或审查用户交易。

幸运的是，审查不是什么大问题，因为所有 Rollup 系统都可以通过不可审查的 Layer 1 来发布 Layer 2 交易。协议会强迫定序器在几分钟内将用户交易打包到 Rollup 内。

如果定序器谎报状态，用户需要自己运行节点，根据发布到 Layer 1 的批量交易重新创建 Rollup 状态。这听起来可能很糟糕，但是与 Layer1 上的情况相同。

最后，定序器可以谎称交易已得到即时确认吗？可以。正如上文所述，定序器可以谎报当前网络状态以及用户交易是否被打包。

例如，定序器可以对用户谎称交易已成功，但是实际上被撤销了。用户只有基于 Layer 1 重新创建 Rollup 状态之后才会发现自己被骗了。

只有被发布在 Layer 1 上，Rollup 交易才算是被敲定了。这就是为什么 Rollup 的 Web 3.0 库一般可以让开发者轻松构建用户界面，以告知用户 Rollup 交易的处理进度。

未来有可能采取的一种解决方案是，让定序器在收到用户交易时签名确认，如果交易没有被打包到 Rollup，用户可以惩罚定序器。这可以通过瞭望塔之类的服务自动化执行。

这是真正让我感到兴奋的地方 —— 定序器技术还处于发展初期。未来，我们将看到更多复杂的设计来解决我提到的很多问题。

我们也可以运行一个由定序器组成的免许可型 PoS 网络来代替单个许可型定序器。每一批交易都由网络中随机选取的定序器打包到 Layer 1 上。这会大幅增强抗逆性和抗审查性。

当然了，每个定序器都需要提供保证金，一旦作恶就会遭到罚没。

其它项目如 Arbitrum 在试验一种 公平的协议 来发现正确的交易排序。

当然，也可以不打击 MEV，而是拥抱 MEV：参与方通过竞标的方式来获得在一段时间内运行定序器的权利（但是这个想法存在一些问题）。

如果你想更多了解 Rollup 的设计空间，可以阅读 Vitalik 的 这篇文章 中的 「谁可以提交批量交易」 一节。

总之，IMO 定序器在去中心化和速度之间取得了良好的平衡。我们目前看到的还只是定序器的最小可行产品，还有很多聪明人正在努力改进它。未来将一片光明！