原文标题:《科普 | Rollup 中的定序器》 我看到 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,用户可以惩罚定序器。这可以通过瞭望塔之类的服务自动化执行。 这是真正让我感到兴奋的地方 —— 定序器技术还处于发展初期。未来,我们将看到更多复杂的设计来解决我提到的很多问题。 (责任编辑:admin) |